Hardening WordPress, defined as work rather than advice
Hardening WordPress has an enormous amount of published guidance and very little of it is an engagement. Here is what is actually delivered, what it changes, and where the decisions are yours rather than ours.
Hardening advice is free and it rarely gets applied
Every WordPress hardening checklist says the same things: update promptly, use strong passwords, remove unused plugins, take backups. All of it is correct and most sites do some of it inconsistently, because it is a set of intentions rather than a piece of work with an owner and an output. The gap between knowing and being hardened is where compromises happen.
- Updates are applied when somebody remembers
- Nobody can say which plugins are actually used by the site
- Administrative accounts exist for people who have left or changed role
- Backups are taken and nobody has restored one to check it works
- Two-factor authentication is not used for administrative access
- The site was compromised before and the changes made afterwards were not recorded
- Nobody would notice a compromise until a visitor or a search engine reported it
- A client, insurer or procurement process is asking what security measures are in place
The people who usually bring us this problem
An owner who wants this to stop being an intention
You know what should be done and need it as defined work with an owner and a result.
Someone who has already been compromised once
You want the preventive work done properly rather than a repeat of the cleanup.
Someone who has to answer a security question
A client, insurer or procurement process needs a statement of what is actually in place.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Most WordPress compromises arrive through maintenance gaps
An unpatched plugin with a published vulnerability, a credential reused from a breach elsewhere, an account nobody removed. These are not sophisticated attacks and they do not need to be — the population of sites with a maintenance gap is large enough that finding one is trivial.
A backup you have never restored is not a backup
Backups fail in ways that are invisible until the moment they are needed: incomplete, corrupted, or capturing the compromise itself. The only way to know is to restore one to a working environment and check, and almost nobody does.
Being compromised is expensive beyond the cleanup
Search results carrying a warning, advertising partners and payment providers taking action, hosting suspending an account, and an investigation that costs more than the preventive work would have. The asymmetry is the argument, and it is usually made after the fact.
Hardening changes how the site is used, and editors have to agree
Removing plugins, restricting the file editor, enforcing stronger authentication and limiting what roles can do all change someone's working day. Applied without agreement, hardening gets worked around — which is why the decisions are put to you rather than made quietly.
Capabilities
Each of these is work we carry out, not an area we advise on.
Update discipline, with an owner
A defined policy for what is updated, how quickly, by whom, and what happens when an update breaks something. The policy is written down and has a named owner, because an update policy nobody owns is a set of intentions again.
Plugin and theme inventory and removal
Establishing what is installed, what is actually used, what is abandoned and what is duplicated. Unused and abandoned components are removed — a plugin that is inactive is still code on the server, and abandoned code receives no fixes.
Access control and account review
Every account, its role and its necessity; administrative capability reduced to the people who need it; two-factor authentication for administrative access and for hosting and control-panel accounts; and a process for removing access when someone leaves. The hosting account matters as much as WordPress here, and it is the one people forget.
Backup verification
Backups confirmed to be complete, off the site's own infrastructure, and capable of restoring the site — tested by actually restoring one. Retention set to a period that covers how long a compromise can run undetected, since a backup from last night may already contain it.
Server-level and edge controls
Where the site's hosting allows it: web application firewall rules, rate limiting on authentication, disabling execution in upload directories, and the server software and PHP version brought to supported releases. These controls sit under WordPress and catch classes of attack the application cannot.
Integrity and change monitoring
File integrity checks against a known baseline, and notification when something changes. This is what converts finding out from a visitor into finding out when it happens, and it is the mechanism that makes a retrospective removal faster.
A posture statement you can hand to someone
A written account of what is in place, what is not, and what the residual risk is — suitable for answering a client, insurer or procurement question. Stated plainly, including the parts that are not done, because a security statement that overstates is worse than none.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish what is actually installed and used
The inventory comes first because it determines most of the rest. Unused and abandoned components are the largest preventable category of exposure on WordPress sites, and nobody knows what is installed until someone counts.
Prefer removal to configuration
Removing an unused plugin is better than configuring it safely, and the same applies to accounts, capabilities and access. Every component that is not installed is a component that cannot be exploited, and configuration is a weaker guarantee than absence.
Put the decisions to the owner
Some hardening changes how the site is used: disabling the built-in file editor, enforcing authentication strength, restricting what an editor role can install. These are put as decisions with their consequences, because hardening that gets worked around is not hardening.
Test the things that fail silently
A backup that has never been restored, a monitoring rule that alerts to nothing, an access removal that did not take effect. Anything whose failure is invisible is verified by exercising it rather than by assuming it is configured.
Give the routine an owner and a schedule
The update policy, the backup restore test, the access review. Hardening is not a state that is reached once; it is a routine, and a routine with no owner is the thing that degrades while everyone believes it is in place.
State the residual risk, including what is not done
The posture statement names what is in place and what is not. Some exposures are outside the site's control — the hosting provider's own practices, a third-party service, a decision the owner declined. Naming them is what makes the statement usable, and a statement that only lists strengths is one nobody should rely on.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Assessment
- Complete inventory of installed plugins and themes, with use, maintenance status and duplication
- Every account, its role and its necessity, including hosting and control-panel access
- Current update practice, and where it actually stops
- Backup configuration, retention, and whether a restore has ever been tested
- Server-level controls available on the current hosting
- What is already in place, stated without inflating it
Hardening
- Unused and abandoned components removed
- Administrative access reduced to necessity, with two-factor authentication where it can be enforced
- A written update policy with a named owner
- Backups verified by restoring one, with retention set against how long a compromise can run undetected
- Edge and server controls applied where the hosting supports them
- File integrity and change monitoring in place, with a baseline
Handover
- A posture statement suitable for a client, insurer or procurement question
- The routine, with its owner and its schedule
- What was decided against, and the consequence of that decision
- What remains exposed and why, including anything outside the site's control
- What to do if a compromise is suspected, and who to contact
Architecture and technology
The layers, and what each one catches
- Hosting and control-panel access — the account that can rebuild the site
- Server and PHP — unsupported releases and configuration weaknesses
- Edge controls — authentication rate limiting and known exploit patterns
- WordPress core — kept on a supported release with updates applied promptly
- Plugins and themes — the largest exposure surface on most sites
- Administrative access — accounts, capabilities and authentication strength
- Detection — integrity and change monitoring, so a compromise is found rather than reported
- Recovery — a backup that has been proven to restore, with retention that covers the detection gap
The decisions that are yours, not ours
- Whether the built-in plugin and theme editor is disabled for administrators
- How strong authentication must be, and whether two-factor is required or encouraged
- What each editorial role is permitted to install and configure
- How long backups must be retained, given storage cost against detection lag
- Whether to restrict administrative access by network location
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The site is compromised now
Removal and verification, including the WordPress-specific places code hides.
WordPress malware removalYou want the routine run for you
Updates, backups, monitoring and access review as an ongoing service.
WordPress maintenanceThe assessment needs to cover more than WordPress
The whole estate: hosting, edge, dependencies and remediation order.
Website securitySecurity has to be maintained rather than achieved
A cadence of reviews, patch verification and access checks.
Website security maintenanceFrequently asked
What exactly do we get?
An inventory of what is installed and used, an access review covering WordPress and the hosting account, unused components removed, a written update policy with a named owner, backups verified by restoring one, edge controls applied where the hosting allows, integrity monitoring with a baseline, and a posture statement you can hand to a client or insurer. The routine and its owner are documented too, because hardening that nothing maintains is a state the site will drift out of.
Will hardening break anything?
Some of it changes how the site is used, and that is put to you rather than decided quietly. Removing unused plugins occasionally reveals that something was not as unused as it looked; restricting capabilities can affect a workflow; changing authentication affects how people log in. Each of those is stated with its consequence before it is applied, and the changes that alter how editors work are your decision, not ours. Hardening imposed without agreement tends to get worked around, which returns the site to where it started.
Can you guarantee we will not be hacked?
No. What hardening does is remove the exposures that require the least effort to exploit — unpatched components, abandoned plugins, superfluous administrator accounts, unverified backups — and add detection so a compromise is found rather than reported by a visitor. That removes most of the realistic risk on a typical WordPress site. It does not remove all of it, some of it sits with your hosting provider or a third-party service, and the posture statement says which parts are not covered rather than implying they are.
Our backups are already running. Why does it matter whether we have tested them?
Because the failure modes are invisible until the moment you need the backup. Incomplete sets, corrupted archives, a backup that includes the compromise because it ran after it, and a backup that restores the files but not the database are all common and all undetectable from the fact that backups are running. Restoring one to a working environment is the only check that establishes it works, and it is also usually the point where retention gets reconsidered — a nightly backup is not much use if a compromise has been running quietly for weeks.
Do we need to change hosts?
Not necessarily, and it is a finding rather than a starting assumption. Some hosting does not provide the server-level controls that make a meaningful difference — the ability to rate-limit authentication, to disable execution in upload directories, to run a supported PHP version. Where that is the case it will be stated as a limit with its consequence, and whether to move is your decision. Plenty of sites are perfectly capable of being hardened on their current platform, and moving is disruptive enough that it should not be proposed without a specific reason.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.