Two-Factor Authentication for WordPress

Two-factor authentication defeats the attack that actually works. Sites are rarely broken into through an exotic exploit; they are entered with a correct password obtained from a reused credential, a phishing page, or an infected machine. A second factor makes a stolen password insufficient on its own.

For the effort involved, nothing else on the security checklist returns as much.

Choose a second factor

TOTP from an authenticator app is the right default for most sites: free, offline, no dependency on a phone number or a mail server, and supported by every serious 2FA plugin.

Hardware keys and passkeys are worth it for administrator accounts on a site that matters. They are the only options that resist phishing, because the credential is bound to the domain — a fake login page cannot use it.

Email codes deserve a specific warning. If the code arrives at the same inbox that receives password resets, an attacker with the inbox has both factors. It is a second step, not a second factor.

SMS is the weakest option still in common use. Prefer anything else, and use it only if the alternative is nothing.

Enforce it where it matters

2FA that only the careful people enable protects only the careful people. Configure the plugin to require a second factor for administrators and editors — the roles that can install code or publish. Subscribers and customers can usually be offered it rather than required.

Two related settings do the rest of the work:

• A grace period for existing users, with reminders, so nobody is locked out on the day you turn it on.
• Blocking access until enrolment once the grace period ends, otherwise the requirement is advisory.

Which capabilities each role carries is set out in WordPress user roles explained. While you are there, audit the administrator list — every one of those accounts is a way in, and old ones are the usual culprits when a site is compromised.

Recovery codes, before you need them

Generate them at setup, store them somewhere that is not the device holding the authenticator — a password manager or somewhere physical. Each is single-use. Regenerate the set after using any.

If you have neither the device nor a code, recovery means server access:

wp plugin deactivate two-factor-plugin-slug

Then log in, re-enrol, and reactivate. The command works even when the admin is unreachable, which is one of several reasons WP-CLI is worth having. Without SSH, the alternative is disabling the plugin from the database or adding a fresh admin user via phpMyAdmin.

Confirm your recovery path before enforcing 2FA on every administrator, not after.

Application passwords for anything not a browser

A second factor assumes a human at a login form. Anything else — a mobile app, a deployment script, an external service reading the REST API — has no way to provide one.

WordPress ships application passwords for exactly this. Each is generated per application, scoped to one user, and individually revocable without touching the account password. Use them instead of granting an integration the real credentials, and revoke them when the integration is retired.

If a 2FA plugin offers to disable application passwords entirely, understand what depends on them first.

What 2FA does not do

Being clear about this prevents false confidence:

• It does not stop brute-force attempts from reaching your login page and consuming server resources. Rate limiting does that — at the host, at Cloudflare, or in a security plugin.
• It does not protect against a vulnerable plugin that never touches the login form.
• It does not help if the machine is already compromised and the session is stolen.
• It does not replace backups or keeping plugins updated.

It closes one specific and very common door. Close the others separately.

Common mistakes

• Enabling it only on your own account and calling the site protected.
• Email as the second factor on the inbox that receives password resets.
• No recovery codes, discovered on the day the phone is replaced.
• Locking out a client by enforcing it with no grace period and no warning.
• Breaking an integration that authenticated as a real user with a real password.
• Relying on a plugin that has not been updated in two years for the most security-sensitive part of the site.

Verify

Enrol, then log out and log in again in a private window — the second factor must actually be requested. Use one recovery code and confirm it works and is then rejected on reuse. Confirm a second administrator account also requires the factor. Confirm your scheduled tasks, mobile app or API integration still work. And confirm you can still get in if the phone is gone, using either a recovery code or WP-CLI.

That last check is the one that turns 2FA from a risk into a safeguard.