What practical WordPress security means
Security is risk reduction, not a permanent state. The realistic goal is to make compromise less likely, detect it sooner, and recover faster. Absolute certainty does not exist.
Therefore any provider promising an unbreakable site is selling something else. In reality the measurable questions are narrower: how much is exposed, who can reach it, how quickly would you know, and what happens next.
The work that reduces risk
- Reduce the attack surface. Remove what is unused, update what remains, and replace abandoned code.
- Fix access hygiene. Named accounts, appropriate roles, removal of old accounts, and two-factor authentication where supported.
- Harden configuration. Apply deliberate WordPress and server settings rather than installing a plugin and assuming the work is done.
- Make recovery possible. Keep backups that have been restored at least once.
- Watch useful signals. File and user changes, and the events that commonly precede visible problems.
Why unused code is the usual entry point
The plugin nobody uses still runs. It still receives requests, still exposes endpoints, and still ships whatever flaw it had when it was abandoned.
Deactivating is not deleting either: files left on disk can often still be reached directly. Consequently the cheapest security work is usually removal, followed by replacing anything that has stopped receiving updates. For the canonical baseline, the WordPress hardening documentation sets out the standard measures.
Access hygiene beats almost everything else
Most compromises that reach an administrator account do so through a credential rather than an exploit. In particular, shared logins, former contractors who were never removed, and passwords reused from a breached service account for a large share of real incidents.
The fixes are unglamorous and effective. Give every person their own account. Grant the lowest role that does the job. Remove access the day it stops being needed. Above all, never share a credential in email or chat.
What a security plugin can and cannot do
A security plugin is useful for detection, blocking obvious noise, and occasionally virtual patching. However, it runs inside the application it is protecting, so it cannot save a site whose credentials have been handed over or whose host is compromised.
Similarly, installing two of them mostly produces conflicts and false confidence. One, configured deliberately, is worth more than three left on defaults.
Detection is worth as much as prevention
Prevention reduces how often something gets in. Detection decides how much damage it does once it has.
The gap between compromise and discovery is where the real cost accumulates: spam pages get indexed, a browser warning appears, or the host suspends the account. Therefore the useful signals are the boring ones. New administrator accounts. Changes to core files. Scheduled tasks nobody created. Outbound mail volume that suddenly rises.
Notably, each of those is cheap to watch and hard to fake. A monitor that only checks whether the homepage loads will miss every one of them.
When a vulnerability is announced
A disclosure against a plugin you run is not automatically an emergency, and treating every advisory as one leads to fatigue. The questions that matter are whether you run the affected version, whether the vulnerable feature is reachable, and whether a fix exists yet.
Where no fix exists, the honest options are removing the plugin, restricting access to it, or accepting a stated risk deliberately. Choosing the third silently is how sites end up compromised.
Where hosting responsibility ends
The host secures the server. Site owners remain responsible for WordPress, plugins, themes, users, and passwords. The boundary must be understood before a hardening plan is agreed.
Managed hosting narrows that gap but does not close it. For example, a managed platform may patch PHP and block known attacks while still leaving plugin choice, user roles and file permissions entirely to you.
Start with the current state
Inventory the site, its users, supported code, update process, backup process, and hosting controls before prescribing changes. Otherwise you are buying a checklist rather than an improvement.
That inventory usually answers the question on its own. Most sites do not need exotic measures; they need three abandoned plugins removed, four stale accounts closed, and a backup that has actually been restored once.
How this connects to the rest of the work
Hardening is a point-in-time exercise, so it decays as plugins, people and hosting change. Keeping it current is what ongoing maintenance plans are for. For anything outside prevention, see WordPress support, and read the service scope to see what DuePress declines before making contact.