Hardening reduces the likelihood of another compromise and limits what an attacker can do if one control fails. It should be based on the actual hosting environment, business requirements, and findings from the incident.
Core hardening areas
Updates and software inventory
Remove abandoned plugins and themes, patch supported components, verify update channels, and reduce duplicate functionality that expands the attack surface.
Identity and least privilege
Use unique administrator accounts, strong authentication, appropriate roles, limited service accounts, secure credential storage, and multi-factor authentication where supported.
Filesystem and execution controls
Reduce unnecessary write access, protect configuration files, restrict script execution in upload locations where compatible, and separate sites that should not trust each other.
Edge and application protections
Apply sensible rate limits, bot controls, login protections, proxy or WAF rules, XML-RPC restrictions when appropriate, and origin-access controls.
Backups and recovery testing
Maintain versioned backups outside the web root and test that files, databases, encryption keys, and recovery instructions are actually usable.
Logging and alerting
Retain web, authentication, file-integrity, mail, security, and hosting logs long enough to investigate suspicious activity and establish timelines.
Hardening is not a substitute for cleanup
Security plugins, WAF rules, password changes, and updates cannot be trusted to neutralize malware that is already running. Compromised code and persistence must be removed first; hardening follows a validated recovery.
Recovered but not confident?
A post-incident review can verify administrator accounts, software integrity, scheduled tasks, exposed credentials, backup readiness, and the controls most relevant to the original compromise.