"I Have a Security Plugin" Comes Up a Lot
When I bring up hardening with someone who already has a security plugin installed — Wordfence, Sucuri, iThemes, whichever — the reaction is usually some version of "oh, I'm covered, I have a plugin for that." I get why. Those plugins are genuinely good at what they do, and a lot of them market themselves as complete security solutions. But a plugin runs inside WordPress. It can only see and control what WordPress itself has access to, and there's a whole layer underneath that it simply can't touch.
What a Security Plugin Actually Handles
The good ones do real work, and it's worth being specific about what that is:
- Malware scanning. Checks files and the database for known malicious code patterns, usually on a schedule.
- An application-level firewall. Filters requests before they hit WordPress itself, based on rule sets the plugin maintains.
- Login protection. Rate-limiting, CAPTCHA, sometimes two-factor authentication — all bolted onto WordPress's own login flow.
- File integrity checks. Flags when core, theme, or plugin files have changed unexpectedly.
All of that is useful, and I'd rather a site have a decent security plugin than nothing. But everything on that list runs from inside the WordPress install — which means it inherits whatever the server underneath it is or isn't doing.
What's Underneath, Where a Plugin Can't Reach
Hardening covers a layer that has nothing to do with WordPress's own code, and a plugin has no access to any of it:
- PHP version and server configuration. An outdated PHP version can carry its own vulnerabilities. No plugin can upgrade that for you.
- Server-level firewall rules. Blocking known attacker IPs before the request ever reaches WordPress — faster and more thorough than filtering it after the fact inside the app.
- File permissions. Whether files and directories on the server are set so a compromised process can or can't write where it shouldn't.
- Disabling things like XML-RPC or the file editor at the server or config level. Some of this overlaps with what a plugin can toggle, but doing it at the server level means it isn't dependent on WordPress being intact and unmodified to keep working.
Why This Distinction Actually Matters
If a site gets compromised through something below the WordPress layer — a server misconfiguration, an outdated PHP version with a known hole, a compromised neighboring account on shared hosting — a security plugin sitting inside WordPress isn't positioned to stop it, because the problem never went through WordPress in the first place. It's a bit like putting a good lock on your front door while a window around back is left open. The lock is real, it's doing its job, it's just not covering the whole house.
The reverse is also true. Hardening a server well doesn't replace what a good security plugin does inside the application — scanning for malware that's already made it in, or flagging when a plugin file changes unexpectedly. Each layer catches things the other one structurally can't.
How We Handle Both
On every site we manage through our managed WordPress plan, hardening happens at the server and configuration level as a baseline — not something you install or configure yourself. Where a plugin genuinely adds something the server layer doesn't cover, we're not against running one alongside it. What we don't do is treat a plugin as a substitute for the parts of security that only exist at the hosting layer, because they're not interchangeable, and treating them as if they were is how gaps happen. If your site's security posture matters enough that this distinction should actually be checked and maintained over time, the Managed Stability plan keeps both layers current, not just installed once.
