Two-factor authentication (2FA) for WordPress: the setup that actually holds

Enabling 2FA on a WordPress site is two hours of focused work that prevents the single attack path that still dominates real incidents: a leaked or reused password. This article walks through the decisions (which method, which plugin, which roles), the exact setup flow, and the recovery mechanism you need in place before you turn enforcement on. The hardest part of 2FA is not enabling it. It is not locking yourself out.

If you are reading this because you already enabled 2FA and now you cannot log in, skip to the lockout recovery section. If you are here because you want 2FA but your site owners told you it is "too complicated for our editors", read the misconceptions section first and then come back to the top.

What you will have at the end

A WordPress site where every administrator and editor uses a second factor to log in, where the setup is enforced by role (not by trust), and where a lost phone does not mean a white-screen recovery via SSH at 11pm. Specifically:

• The right plugin installed and configured for your audience (wizard-driven for non-technical teams, minimal and community-maintained for developers).
• TOTP via an authenticator app as the primary method for every admin.
• Backup codes printed and stored somewhere that is not your password manager if that manager lives behind the same password.
• A grace period so users can set up 2FA at their own pace before enforcement kicks in.
• A documented recovery path for when a second factor is lost.

2FA is a how-to, not a project. If you are coming to this cold, the broader checklist it fits into lives in WordPress security hardening, and the companion control for the same login path lives in brute force protection in WordPress. Skim both if you have not yet locked wp-login.php down at the web server.

Prerequisites

• WordPress 6.0 or newer. Both recommended plugins target WordPress 5.5+ or 6.8+, and the WebAuthn companion plugin requires PHP 8.1.
• Administrator access to the site you want to protect.
• A second device (phone or hardware key) you will use for the second factor. Do not use the same machine that runs wp-admin for both the password manager and the authenticator app; that is a single-device compromise path.
• A way to receive email at the address on your WordPress account if you plan to use email 2FA, with reliable delivery. Stock WordPress wp_mail() uses PHP mail() by default, which drops into spam or vanishes on plenty of hosts. If you have not already configured transactional SMTP, do that first with WordPress SMTP configuration.
• SSH or SFTP access to the site as a fallback. If the worst happens, the only way to deactivate a 2FA plugin without logging in is to rename its folder on the filesystem.
• Five minutes to print a backup-codes sheet. If you skip this, every other step in this article is theatre.

Which method to pick, and why

WordPress 2FA plugins support three or four methods. Your choice depends on the admin's device situation and how much you care about phishing resistance. A fast decision table:

My recommendation in practice. TOTP for every admin as the baseline, because the setup works on any phone and the friction is 45 seconds. Passkeys for anyone with a modern laptop or phone who wants a tap-and-go experience. Email OTP only as a fallback for accounts that genuinely cannot run a TOTP app. SMS should not be on this list at all in 2026; NIST SP 800-63B Section 5.1.3.3 has been warning against SMS-based OTP as a "restricted authenticator" since 2017, and Microsoft's own guidance from 2020 calls SMS and voice "the least secure of the multi-factor authentication methods available today".

One clarification about passkeys that confuses people. WordPress 6.8 (April 2025) did not ship native passkey login in core; its security change was switching password hashing to bcrypt. As of April 2026, passkey support in WordPress is still plugin-only. The plugin ecosystem covers it well (covered below), but do not go hunting for a core toggle that does not exist.

And one more about TOTP. Every authenticator app that supports RFC 6238 works with every WordPress plugin that implements TOTP. Google Authenticator, Authy, 1Password, Bitwarden, Microsoft Authenticator, FreeOTP: all interchangeable. The only thing they have in common is that the shared secret (the QR code) and the current time (within about 90 seconds) determine the 6-digit code. If your phone clock is off by two minutes, TOTP fails.

Which plugin to use

Two canonical plugins, and one companion. Both options are free, both are actively maintained, and both reach 100,000+ installs on wordpress.org. Pick based on audience:

Option 1: WP 2FA by Melapress (recommended for most sites)

WP 2FA is the right default for sites with a mix of technical and non-technical users. It has a wizard-driven setup targeted at non-developers, role-based enforcement with grace periods, and TOTP + email + one free passkey in the free tier. The current version as of this article is 3.1.1.2 (released February 2026), tested up to WordPress 6.9.4. Passkey support arrived in v3.1.0, not earlier. Melapress is a commercial plugin shop; the free tier is genuinely usable and the premium tier adds WooCommerce customer 2FA, multiple passkeys per user, and YubiKey hardware keys.

Pick this if: you manage a site with editors, marketers, or contributors who will ask you "how do I log in again" if the flow is confusing, or if you need to enforce 2FA by role.

Option 2: Two Factor by the WordPress community

Two Factor is the minimal, community-maintained option. Current version is 0.16.0 (released 2026-03-27). It ships TOTP, email codes, backup codes, and a dev-only "dummy" provider. There is no enforcement mechanism built in: every user opts in from their own profile page. Legacy FIDO U2F support was removed in 0.16.0 on 2026-03-27 because browser support had eroded; the replacement for hardware keys is the companion plugin below.

Pick this if: you are a developer managing your own sites, you want the smallest possible code surface, and you want the plugin that the WordPress core contributors themselves maintain.

Option 2 companion: WebAuthn Provider for Two Factor

WebAuthn Provider for Two Factor is the companion plugin that adds passkey and hardware-key support to the community Two Factor plugin. Current version is 2.6.1, maintained by Volodymyr Kolesnykov. It works with Windows Hello, macOS Touch ID, YubiKeys, and any FIDO2 authenticator. It also migrates previously registered FIDO U2F keys, which matters if you were running the old Two Factor plugin before 0.16.0 shipped. Requires PHP 8.1+ and WordPress 6.0+.

Install this alongside Option 2 if you want passkeys on the community plugin path.

The rest of the walkthrough uses WP 2FA as the example because it fits more readers. The same decisions apply to Two Factor, with the caveat that enforcement and grace periods do not exist there; each user opts in on their own profile page.

Step 1: back up before you touch authentication

Before enabling a single 2FA plugin, take a snapshot. If enforcement catches you in a wrong state, or a plugin bug hits your specific user row, the fastest recovery is "restore the users table and the options table from thirty minutes ago". Any full-site backup works: UpdraftPlus, BackWPup, a managed-host snapshot, or wp db export from the command line. If you already have automated backups configured via the WordPress backup strategy, trigger a manual run now.

# From the WordPress root as a user that can read wp-config.php
wp db export backup-before-2fa-$(date +%Y%m%d-%H%M).sql

Expected output: a file backup-before-2fa-20260408-1430.sql (or similar) in your current directory, a few MB in size for a typical site.

Keep that file somewhere you can reach without logging in to wp-admin. That constraint is deliberate.

Step 2: install and activate WP 2FA

In wp-admin > Plugins > Add New, search for WP 2FA by Melapress. Verify the author name (there are look-alikes) and the install count (100,000+). Install and activate. The plugin adds a WP 2FA top-level menu and launches a first-run wizard on the first admin who visits it.

Walk through the wizard's four prompts, but pick "Let users choose a method" at the method step. Forcing one method for everyone looks clean in theory and in practice traps the one admin whose phone is dying that day.

On the final wizard step, choose Optional for now, not Required. You are going to configure your own 2FA in Step 3, configure everyone else's in Step 4 and 5, and only then switch the global policy to required. If you pick Required here before anyone has enrolled, every user including you gets walked through a forced setup on their next login, which is fine if you are sitting next to them and not fine if they log in from a conference hotel Wi-Fi.

You will know it worked when the WP 2FA menu shows the status "2FA is enabled for the users that set it up" and your own user profile (wp-admin > Users > Your Profile) has a Two-Factor Authentication section.

Step 3: enrol your own admin account

Go to wp-admin > Users > Your Profile and scroll to Two-Factor Authentication. Click Configure two-factor authentication. You will see three method options: authenticator app, email, and passkey.

Pick authenticator app first. A QR code appears. On your phone, open Google Authenticator (or your preferred RFC 6238 app), tap + > Scan QR code, and point the camera at the screen. A six-digit code appears in the app, rotating every 30 seconds. Type the current code into the WP 2FA prompt and click Next.

Now generate and store backup codes. WP 2FA prompts for this at the end of the wizard. Click Generate backup codes. You will see a list of 16-digit codes; each one works exactly once. Print them or write them down on paper and put them in a place your phone cannot burn in. A password manager is fine if your password manager is not also on the phone you use for the authenticator app; if both live in the same browser profile, they are one compromise away from being useless together.

One more step that people skip and regret: log out and log in again, with the authenticator code, from a private/incognito window. Confirm the flow works end to end before moving on. If the login fails and you have backup codes, use one to get back in and figure out why (usually clock drift on the phone; resync the phone's clock).

You will know it worked when a full fresh login cycle from incognito asks you for a 6-digit code and succeeds.

Step 4: add the passkey option (optional but worth doing)

On your profile page under Two-Factor Authentication, click Set up next to the Passkey method. Your browser prompts you to authenticate with the device's built-in WebAuthn (Touch ID on macOS, Windows Hello on Windows, fingerprint on Android, or a hardware key like a YubiKey on a USB port). Complete the prompt. The passkey is now registered and you can use it as a second factor instead of the TOTP code on the next login.

On the WP 2FA free tier, one passkey per user is supported. If you want to enrol a second passkey (desktop + phone, for example), that is in the premium tier. For most solo admins, one passkey plus a TOTP fallback plus backup codes is enough.

You will know it worked when the passkey option on your profile page says "Registered".

Step 5: enrol the other users

Two paths, depending on how much hand-holding you are willing to do.

Walk-them-through path. For each admin/editor, schedule 10 minutes, have them at their workstation with a phone in hand, and walk them through Step 3. Send them the backup codes by a secure channel (encrypted note in Bitwarden shared folder, Signal message, paper envelope). This is the right path for three to ten people.

Email-invitation path. WP 2FA can send a "please set up 2FA" email to every user that has not enrolled yet. Go to WP 2FA > Settings > Notifications and enable the user invitation email. Users receive a message with a link that takes them directly to their 2FA setup wizard. This is the right path for ten to a hundred people, with a follow-up for stragglers.

Regardless of path, do not move to Step 6 until every user who will be subject to enforcement has enrolled. The grace period is there to give you a buffer, not to skip this step.

Step 6: turn on enforcement with a grace period

This is the step that converts 2FA from "available" to "required". Go to WP 2FA > Settings > 2FA Policy. Change the policy from Optional to Required. Under Apply this to, pick either All users or All users with specific roles (recommended: administrators and editors, skip subscribers and customers unless you run WooCommerce with customer 2FA in WP 2FA Premium).

Set a grace period of seven days. This is the single most important field in this screen. When a user logs in during the grace period without 2FA set up, they see a nag screen pointing them to setup, but they can log in anyway. When the grace period ends, users without 2FA cannot log in at all until they enrol. Seven days gives you a realistic window to chase down the one person who does not read their email.

Save the policy. WP 2FA now nags every non-enrolled user at login and blocks them after seven days. Log out and log back in to confirm your own enrolment still works.

You will know it worked when a fresh login from incognito, as a user without 2FA configured, lands on the "please set up 2FA within 7 days" screen.

Step 7: document lockout recovery

Before you close this tab, write down where the recovery bits live. A template:

WordPress 2FA recovery (yoursite.nl)
- 2FA plugin: WP 2FA 3.1.1.2
- Plugin path: wp-content/plugins/wp-2fa/
- Backup codes: stored in [location]
- SSH access: user [deploy], host [host.example.nl]
- Database: user [wordpress_user], DB [wordpress_db]
- Last full backup: [date, location]
- Deactivate-via-SSH command:
    cd /var/www/yoursite.nl/wp-content/plugins
    mv wp-2fa wp-2fa.disabled

Paste that into the same password manager vault where the backup codes do not live. The point of this paragraph is that two years from now, the person who writes this article into runbook form is your own future self squinting at a locked-out admin account.

Three misconceptions worth addressing

"Enabling 2FA blocks all my users immediately." It does not. Both plugins in this article leave users able to log in normally until they enrol in 2FA, unless and until you enable enforcement with no grace period. WP 2FA's default on a fresh install is optional; Two Factor has no enforcement at all. An admin who clicks activate and panics about their editors will find that nothing changed for them. The grace period is your actual enforcement knob.

"Email 2FA is as secure as TOTP apps." It is not, and this matters more than people realise. Email 2FA sends a 6-digit code to the user's registered email address at login time. Three problems: the code travels over a network (email can be intercepted or delayed), it depends on a second account staying uncompromised (if the email is a Gmail with a reused password, you added zero factors), and it depends on your site's email delivery working reliably (if wp_mail() falls into spam, the user waits indefinitely). TOTP generates the code offline on the user's device using RFC 6238; it never transmits. Use TOTP as the default, email only as a fallback for users who genuinely cannot run an app.

"2FA is too technical for my editors." Not with WP 2FA's wizard. Scanning a QR code and typing a 6-digit code is a 45-second flow. What is genuinely hard is the recovery case (phone replaced, backup codes lost), and that is a human-process problem, not a technical one. The fix is Step 7 above: document the recovery path once, then teach editors to hold on to their backup codes.

Lockout recovery: when you cannot reach your second factor

The recovery hierarchy, in order of how much damage they do to the site:

1. Use a backup code. Every plugin in this article generates single-use backup codes at enrolment time. If you stored them in Step 3, this is a 10-second recovery. The code goes in the field where the TOTP code would normally go. It is consumed on first use; regenerate new codes immediately after.

2. Ask another admin to remove your 2FA configuration. If you have more than one administrator, another admin can go to wp-admin > Users > [your user] > Edit and remove your 2FA configuration from their side. You log back in with just your password, then re-enrol from scratch. This is the second-best path and the reason to never be your site's only admin.

3. Disable the plugin from the filesystem. If the above two fail, SSH into the server and rename the plugin folder:

# Replace with your actual WordPress root and the folder of your active 2FA plugin
cd /var/www/yoursite.nl/wp-content/plugins
mv wp-2fa wp-2fa.disabled

WordPress detects the plugin is no longer there and auto-deactivates it on the next request. You can log in with just your password, reinstall the plugin, and re-enrol. The trade-off is that during the window between the rename and the re-enrolment, 2FA is off on the whole site. Schedule the re-enrolment for immediately after, not "tomorrow".

4. Go to the database directly. If you do not have SSH but you do have phpMyAdmin or an equivalent, you can remove the WP 2FA-specific rows from the wp_usermeta table for your user. For WP 2FA, the relevant meta keys start with wp_2fa_. Delete them and log back in with just your password. This is a last resort; use the plugin deactivation path instead if you have any shell access at all.

If you are fully locked out and none of these paths work, the problem has escalated beyond a login recovery and you need to collect the incident bundle described in cannot log in to WordPress before asking for help. The two articles belong together; 2FA lockouts are one of the specific flavours covered in that routing hub.

WooCommerce and customer-facing 2FA

Customer accounts are a different problem from admin accounts. The admin flow above covers wp_users with edit_posts or higher. Customers (who have read or customer role in a WooCommerce store) do not use wp-admin; they log in to /my-account/ and place orders.

As of April 2026, the free Two Factor plugin does not cover WooCommerce's front-end login page. WP 2FA Premium does, and it is the main reason to consider the paid tier if you run a store. For a free approach, you can use WooCommerce's own account security features (strong passwords, email verification on password reset) combined with rate limiting at the web server for /my-account/ in the same pattern as wp-login.php. That is worth doing; it is not the same thing as 2FA. If customer 2FA is a hard requirement, the realistic path is WP 2FA Premium or a specialised store-security plugin.

Final configuration, assembled

A minimal setup that works for a site with three to ten admins and editors, optimised for "nobody locks themselves out":

1. WP 2FA installed and active. Current version 3.1.1.2.
2. Policy: Required for administrators and editors, with a seven-day grace period.
3. Methods allowed: TOTP + email + passkey (WP 2FA free tier).
4. Backup codes generated and stored offline for every enrolled user.
5. Recovery document written (Step 7) and saved in the team password vault.
6. At least two administrator accounts on the site, each with independent 2FA configured, so one admin can clear another's configuration without SSH.
7. SSH or SFTP access verified as a last-resort recovery path, with the exact mv command written down.
8. Reliable SMTP configured per the WordPress SMTP article if any user falls back to email 2FA.
9. Scheduled backup running daily, off the web server, per the WordPress backup strategy.

Reload wp-admin with the final settings in place and do one more end-to-end login test. If that passes, 2FA is live, enforcement is coming in seven days, and you have a recovery path. You can close the tab.

Common things that go wrong

• TOTP code rejected repeatedly. Clock drift on the phone. On iOS: Settings > General > Date & Time > Set Automatically. On Android: Settings > System > Date & time > Set time automatically. For Google Authenticator specifically: menu > Settings > Time correction for codes > Sync now.
• "I lost my phone and I also lost my backup codes." Path 2 (another admin clears your 2FA) or path 3 (SSH rename). Covered above. If this happens twice to the same user, they do not get to skip the backup-codes step a third time.
• Enforcement turned on, and one user is locked out during the grace period. Either walk them through enrolment on the phone, or use path 2 to temporarily clear their 2FA and have them re-enrol. Do not turn the enforcement back off for the whole site.
• The passkey setup button does nothing. Your browser does not support WebAuthn, or the site is not on HTTPS. WebAuthn requires a secure context; if wp-admin is still served over HTTP, passkeys will not work. Fix the HTTPS first; the SSL certificate article covers how.
• Email 2FA code never arrives. Your wp_mail() is broken. Log in with a backup code (or have another admin clear your 2FA), then fix SMTP per the WordPress SMTP article, then switch to TOTP as your primary method anyway.

When to escalate

Call for help when any of these is true, and collect the list below first.

• You have followed the recovery hierarchy and you are still locked out of every administrator account on the site.
• A plugin update to WP 2FA or Two Factor has broken login for every user, and a rollback from backup is not restoring the pre-update state.
• You enabled enforcement and a large fraction of users are locked out simultaneously (more than one or two), with no clear cause.
• The site shows signs of compromise (unexpected admin users, unexpected posts) and you want to know whether the attacker got in through or around 2FA.

Collect before asking:

• WordPress version, PHP version, and the 2FA plugin name + version.
• Whether SSH or SFTP access is available.
• Whether a fresh backup from before enforcement was turned on exists, and where it lives.
• The list of users who cannot log in, and whether any admin accounts still work.
• A copy of your recovery document from Step 7, so the person helping does not have to rediscover it.
• If the problem is "I can log in with my password but the 2FA step fails", the exact error message on the 2FA screen and the plugin's own log entries under WP 2FA > Settings > Advanced > Debug log.

Two-factor authentication is the cheapest, highest-value security upgrade a WordPress site can make. The operational work is not the enrolment; it is the recovery plan. Do the plan first, enforcement second, and the rest is muscle memory.