SYSTEM STATUS
Client Login
Managed-WP.™ logo
Client Login

WordPress security hardening: a step-by-step guide to protecting your site and identity

← All articles

Reviewed: 27 September 2026

WordPress account security is not a single setting; it is a short sequence of decisions about who can sign in, what software you expose and how you recover. The official WordPress hardening guide frames it as risk reduction rather than risk elimination, and that is the right expectation. This guide explains where WordPress compromises usually start, then walks through the steps you can take on a live site today.

What actually creates risk

Most WordPress incidents trace back to a handful of causes: a weak or reused administrator password, a plugin or theme that has not been updated, an integration that was given more access than it needed, and a backup that was never tested. Hiding the login page or the WordPress version does not fix any of those. The steps below focus on the causes that matter.

Step 1 — Inventory accounts and integrations

List every user, every application password and every third-party connection. Remove accounts for former staff the same day they leave, and revoke tokens for integrations you no longer use. You cannot protect access you have forgotten about.

Step 2 — Fix authentication

  • Unique passwords in a password manager. Length matters more than forced complexity. Current NIST guidance (SP 800-63B) favours long passphrases, permits at least 64 characters, and recommends screening passwords against known breach lists rather than forcing composition rules and regular expiry.
  • App-based or hardware two-factor authentication. TOTP apps and security keys are stronger than SMS codes, which can be intercepted or defeated by SIM swapping.
  • Passkeys where they are available. Passkeys and hardware keys (WebAuthn/FIDO2) are phishing-resistant because they cannot be typed into a fake login page. WordPress core does not ship built-in two-factor or passkey login, so this depends on your security plugin or a host/identity-provider sign-in.

Step 3 — Apply least privilege

Most people who write content do not need the Administrator role. Give each person the lowest role that lets them work, keep at least two administrators so you are never locked out, and use Application Passwords only for the specific integration that needs one.

Step 4 — Patch core, themes and plugins

WordPress 7.1.2 was released on 22 September 2026, shortly after the 7.1.1 maintenance and security release on 17 September 2026. Most publicly reported WordPress vulnerabilities are found in plugins and themes rather than in core, so patching is the highest-value routine task. Enable automatic updates where you can, test on a staging copy where custom code is involved, and delete anything you do not use — inactive code stays on the server and still needs maintenance.

Step 5 — Reduce the surface you expose

  • Serve the whole site over HTTPS and redirect HTTP.
  • Follow the official hardening guidance: correct file ownership and permissions, restrictive permissions on wp-config.php, disabling the built-in file editor with DISALLOW_FILE_EDIT, and a database user with only the privileges WordPress needs.
  • Block XML-RPC if no required integration uses it.
  • A web application firewall and login rate limiting reduce automated abuse, but they are compensating controls — they do not repair a vulnerable plugin or a weak password.
  • Add security headers such as HSTS, Content-Security-Policy and X-Content-Type-Options.

Step 6 — Backups you have restored

A backup that has never been restored is an assumption. The official backup guidance suggests keeping three to five recent copies in different locations; the common 3-2-1 rule (three copies, two media, one off-site) is a sensible minimum. Encrypt backups and limit who can reach them, because a leaked backup is a complete copy of your site and database. Test a restore, not just a backup run.

Step 7 — Monitor and prepare a response

Review the user list, plugins, scheduled tasks and file integrity regularly. Warning signs include administrator accounts you did not create, unfamiliar files or <code>mu-plugins</code>, unexpected outbound email, and unexplained redirects. If a site is compromised, preserve logs and a snapshot before cleaning, rotate all credentials and the WordPress salts in <code>wp-config.php</code>, restore from a backup taken before the incident, then update and rescan.

Quick checklist

  1. Every administrator has a unique password in a password manager.
  2. Two-factor or passkeys are required on administrator accounts.
  3. Unused users, plugins, themes and application passwords are removed.
  4. Core, themes and plugins are up to date, with a staging test for custom code.
  5. HTTPS is enforced and the hardening settings in the official guide are applied.
  6. Off-site backups are encrypted and a restore has been tested.
  7. You know who to call and what to do in the first hour of an incident.

Related guides

How Managed-WP can help

Managed-WP provides managed WordPress cloud hosting with 24/7 support, managed updates and backups, and a web application firewall. If you would rather not carry the checklist above alone, or you want help applying it to a live site, you can compare plans on our pricing page, review the WP security and OWASP service, or open the live chat below and tell us what your site runs.

Sources and further reading