The question that started this conversation
During the September 10, 2026, Office Hours livestream, a viewer asked about security plugin options. They knew Nathan still uses Kadence Security Pro but found that their only way to get it was to buy the entire Kadence bundle. This is the part of the question Nathan focused on:
What other security options would be more cost effective for a small agency using hosting.com for hosting? Patchstack security?
Instead of doing the obvious thing and just rattling out a list of options, Nathan took the educational approach. He wondered what he would look for in a security plugin if he was to start his agency from scratch today. This is how he framed it:
What needs to be in good application security for WordPress? Let's put it that way. There's really, I would say, two main features. I want to be able to protect the login area. And I want to be able to somehow protect vulnerable themes and plugins.
We examine his answer in the rest of this post. We'll look at these specific things:
Because pricing and licensing change often (as this viewer found), we'll focus on the things to keep an eye out for instead of comparing products.
What each layer of website security does
Before we go any further it's crucial to understand what the layers of website security entail. You'll quickly see why the more feature-rich plugins aren't necessarily the best choice, depending on your setup. It is also why we hinted at just two jobs a plugin is best suited for above.
A simple way to think about website security is in three layers: network, server, and the application itself (in this case, WordPress). Each layer interacts with different elements of a website, making it better suited to certain security tasks.
Network layer: CDNs and web application firewalls (such as Cloudflare) typically live here. They sit in front of your site and filter traffic before it reaches your server. That includes malicious IP addresses, bots, DDoS attacks, and scripted login attempts.
The layers work best together, not when one tries to replace the others. A recent example of this was a bug fixed in WordPress 7.0.2 that allowed anyone to create an admin account. Cloudflare's free plan, the network level, blocked the exploit for sites behind it, before they got patched. Of course, patching is still the real fix, but Cloudflare definitely bought time for those websites.
For a closer look at how the network and server levels handle things, our post on whether you need a security plugin if you set up Cloudflare goes into more detail. Spoilers, as you might imagine by the existence of this blog: yes, you do.
The bottom line is that a good security plugin should only do things within the application layer. It should focus on what it does best and allow the other layers to do the same.
What should a security plugin for WordPress focus on?
Nathan brought two primary jobs for a security plugin: protecting the login area and keeping you informed about vulnerable plugins and themes.
As you can see, such a plugin will have clear insight into your plugin and theme stack, will know and protect your users’ login details, and doesn't meddle in the server or network levels.
How should a plugin protect logins?
The WordPress login page is one of the most targeted parts of any WordPress site. It makes sense since it's the most direct route to instant admin access. There are two parts to keeping it safe.
The first is stopping automated attempts. A managed challenge on the network level already covers most of this, as we explain in our post on whether every login page needs a Cloudflare challenge. If you don’t have one, your WordPress setup should add a CAPTCHA to the login page and to the comments. Nathan's rule of thumb about this:
If you're not filtering at the network level with Cloudflare, with good WAF rules, protect the login page.
The second is protecting the accounts themselves, and this is where two-factor authentication and passkeys come in. According to We Watch Your Website's data, 64% of the WordPress infections they see are caused by stolen administrator credentials.
No network or server-level safeguard can tell if a password is stolen. To them, if a password works, it's fine. That leaves this level of protection to the application layer.
You don't need one single plugin to do this either. There are many individual ones that add pieces of what we described above. One can add a 2FA to your site, while another a Cloudflare Turnstile CAPTCHA. Regardless of how you go about it, this is what we recommend you look for:
Together, these make a stolen password much less useful and automated guessing much less likely to succeed.
How should a plugin handle vulnerable plugins and themes?
The network and server levels usually don't know what plugins and themes your site is using, unless they are specialized managed hosting, but in that case, everything (including patching) is typically handled for you anyway.
So that leaves only something within WordPress to tell you when a plugin or a theme you've installed has a known vulnerability.
To that end, look for a plugin that both alerts you for such vulnerabilities and offers virtual patching. That type of patching will protect you until the plugin developer ships a fix.
If you are using such a plugin already, you might have even noticed an increase in alerts like these. Nathan has seen the same thing in his agency and explained why:
AI doing security research is a good thing. Like, it's finding problems that we didn't know ever existed. But we get a lot of notifications as a result.
That's good news overall, but it means more notifications to sort through. When one arrives, check whether the update is a security fix or a feature, since security fixes deserve a faster response.
Why can’t a security plugin reliably scan for malware?
Earlier we mentioned how many security plugins include a malware scanner, and it’s easy to assume that’s a good thing. In some ways it is, if that’s all you have, but Nathan’s view is that it isn’t the right place for that job.
The reason is that the scanner runs in PHP, the same layer as the rest of your site’s code. This is how Nathan explained it:
More advanced malware, all that stuff's running in the same PHP layer. And so, the malware can tell the malware scanner, which is operating at the same layer, to just, don't report me.
The same limitation applies to any external scanning tool that works in the PHP layer. However, server-level scanning doesn’t have that problem since malware can’t easily tell it to look the other way. That’s why Nathan’s advice is short and firm: malware scanning should be done in the server layer.
Plugin malware scanners are useful, but they shouldn’t be the only thing you rely on. Using them to spot simple, known threats is perfectly reasonable, but they are likely to miss more complex malware.
Why shouldn’t a plugin run its own firewall?
The same principle we described in the previous section applies to firewalls. A firewall inside WordPress only gets to act after the dangerous request has reached your server and loaded PHP code.
A firewall on the network or server level, however, can stop that traffic before it gets anywhere near your site. There is another upside to letting the network or server handle that job, too: you avoid your site’s performance slowing down while the firewall (or malware scanner for that matter) works.
Since plugin firewalls work inside your site, everything they do uses CPU, memory, and PHP capacity that come with your hosting plan. Protection at the network and server level, however, typically runs on separate resources, which is how it works at hosting.com.
Because of that, if your host already offers that protection, a plugin firewall consumes i resources to perform work that’s already being handled for you.
How to choose a security plugin for WordPress
Now that we’ve discussed the jobs a plugin should and shouldn’t do, choosing one has become a lot easier. Before you install a plugin, run through this list of questions, which will help you arrive at an educated decision:
Does it duplicate what your host or CDN already does? Check what your host covers before you add anything. That way, you aren’t paying for (if it’s a premium plugin), or slowing down your site with, the same protection twice.
How is it licensed? If you manage multiple sites, check how the plugin is priced across them. Nathan noted that virtual patching purchased separately can get pricey per site, while some plugins bundle it.
Working through these will help you end up with a plugin that complements your hosting setup, instead of competing against it.
However, if your host doesn’t provide server and network protection, an all-in-one plugin with a firewall and a scanner can be a reasonable fallback. We discuss that scenario in our WordPress plugin security guide for 2026. In that case, you are filling a gap and not duplicating something that’s already covered.
What’s the bottom line?
We’ve talked a lot about protection layers and what security plugins shouldn’t do. During the stream, Nathan summed that entire conversation neatly in a single sentence:
The best security solution for WordPress is going to be user protection and some kind of virtual patching and letting you know when your themes and plugins are vulnerable.
So, the key takeaway from this blog: a good security plugin is a specialist and not an generalist. It protects your logins, tells you where a plugin or a theme is vulnerable, and that’s it. It leaves everything else to the server and network security.
If you have a question about your own setup, though, or want to learn more about WordPress, agency work, AI, or anything related to web hosting, join us every Thursday at 2 p.m. ET for Office Hours, and ask it live.
FAQ
Can I turn off my security plugin's scanner if my host already scans?
In most cases, yes, and it can reduce the load on your site. Before you do, confirm your host's scanning covers your site and check whether you'd lose anything you rely on, such as activity logs. If you do need an audit trail, you can often keep it with a separate logging tool.
What is virtual patching, and how is it different from updating a plugin?
Virtual patching blocks attempts to exploit a known vulnerability without changing the vulnerable plugin’s code. An update, on the other hand, replaces the vulnerable code with a fixed version.
Because virtual patching leaves the code alone, it doesn’t replace updating. Instead, it protects you while you wait for a fix or while you test an update on a site that can’t afford to break. It can also be the only protection available for a plugin whose developer has stopped maintaining it. Even then, plan to update or replace the plugin when you can.
What’s the difference between two-factor authentication and a passkey?
Two-factor authentication adds a second step to your password, such as a code from an authenticator app. A passkey replaces the password with a credential stored on your device, which you unlock with a fingerprint, face scan, or PIN.
The main difference is phishing resistance. A passkey only works on the real site it was created for, so a fake login page can’t capture it, while a 2FA code can be typed into a fake page. If your plugin supports passkeys, they’re generally the stronger option, and 2FA is still a big improvement over a password alone. Support varies by plugin, so check what yours offers.
Can my CDN’s firewall rules replace virtual patching?
Not entirely. A web application firewall, like Cloudflare’s, can block exploit attempts for some widely known vulnerabilities, as it did for the WordPress 7.0.2 core bug.
But it doesn’t know which plugins your site has installed, and coverage depends on whether a rule has been written for that specific vulnerability. Virtual patching at the application layer is matched to what’s on your site. The two work best together, and neither replaces keeping everything updated.