WordPress Security Without a Plugin

The problem with plugin-based security

A WordPress security plugin runs inside WordPress — using the site's own PHP process, its own database connection, its own file access. That's not a flaw exactly, it's just how plugins work. But it means the tool watching over your site shares the exact same attack surface as the site itself. If WordPress is ever compromised at a level deep enough to matter, the plugin protecting it is compromised right along with it.

There's a second, quieter cost: every plugin is more code that has to be kept updated, more surface area for a future vulnerability, and often another admin-level credential stored somewhere in the stack. Security tooling is supposed to shrink your risk, not add to the pile of things that can go wrong.

What "outside-in" security actually means

Anything a plugin can read — WordPress core files, theme and plugin files, the uploads directory, the database — is also reachable a completely different way: over SSH, using a dedicated key scoped to that purpose. The tool never touches your WordPress admin login, never runs as a WordPress user, and never becomes part of the application it's checking.

Concretely, that means:

• Core file integrity checks run by comparing WordPress's actual files against known-good checksums — done from a shell session, not a PHP hook inside WordPress.
• Malware and backdoor scanning reads theme, plugin, and upload directories directly off disk, the same way a human investigator would over SSH.
• Database checks connect using credentials read from wp-config.php, without WordPress's own query layer or any of its plugin hooks involved.
• Fixes — when they're safe and reversible — are applied the same way: directly to the filesystem or database, never by triggering code inside a running WordPress process.

Why SSH instead of a WordPress login

An SSH key can be generated specifically for one purpose, imported into a hosting account's key manager, and revoked at any time without touching anything else about the account — see exactly how in our installation guide. That's a fundamentally smaller footprint than a plugin holding a standing admin session inside WordPress itself. It also means the security tool keeps working even if WordPress's own login system is the thing that's compromised.

What this approach can't do

Being honest about the tradeoff: outside-in tooling needs SSH access, which most hosts provide but a few restrict or disable by default. And it can't hook into WordPress's own runtime the way a plugin can — so it's not the right fit for things like real-time request filtering, which is what a DNS-level firewall is actually for. Outside-in scanning and an edge firewall solve different problems, and many sites are well served running both.