You did the responsible thing and turned on two-factor authentication for WordPress. Then your phone died, or you switched authenticator apps and forgot to re-scan the QR code, or a plugin update reset your session — and now you're staring at a 2FA prompt with no way to answer it. Your password is right. It just doesn't matter anymore. Here's how to get back in without nuking your site.
Symptom: You Have the Right Password but 2FA Won't Let You Through
A few variations of the same lockout show up in support tickets constantly:
- You enter your username and password correctly, then hit a "one-time code" screen you can't answer because the authenticator app is on a phone you no longer have.
- You restored an old backup and now the 2FA secret stored in the database doesn't match the app on your current device.
- A security plugin (Wordfence, WP 2FA, miniOrange, or Google Authenticator by BestWebSoft) is enforcing 2FA for a role, but the "backup codes" you were supposed to save were never actually saved anywhere.
- You migrated the site to SkyServer and the new server's clock is out of sync, so time-based codes (TOTP) are rejected even though you're typing the right one.
In every case, the underlying issue is the same: WordPress core has no built-in concept of two-factor authentication. It's entirely handled by a plugin storing a secret key in wp_usermeta, and if that plugin's check can't be satisfied, there's no "forgot 2FA" link waiting for you — because WordPress itself doesn't know 2FA exists.
Cause: The 2FA Secret Lives in the Database, Not in Your Head
When you enable 2FA, the plugin generates a secret key and saves it as user meta — usually under a key like wp_2fa_totp_key, wordfence_2fa_secret, or similar, depending on the plugin. Your authenticator app doesn't "know" anything special; it just runs the same TOTP algorithm against the same secret every 30 seconds. If the phone with that secret is gone, the two sides can never agree again — there's nothing to reset on your end unless you can edit the database or deactivate the plugin.
Two extra wrinkles make this worse on shared hosting:
- Clock drift. TOTP codes are time-based with roughly a 30–60 second tolerance window. If your server's system clock has drifted, valid codes get rejected as expired even when your phone shows the right one.
- Caching. If you're on page caching (LiteSpeed Cache, WP Super Cache) and the login form itself gets cached, you might be looking at a stale form that's submitting to the wrong nonce, which looks like a 2FA failure but is actually a caching bug.
Fix: Three Ways In, From Easiest to "Last Resort"
Option 1 — Use a Backup Code, If You Saved One
Most decent 2FA plugins generate 8–10 single-use backup codes when you first enable the feature. Check wherever you'd have stored them — password manager, a note, printed sheet. If you have one, use it on the 2FA prompt instead of a TOTP code, then immediately go regenerate a fresh set once you're in.
Option 2 — Disable the Plugin via File Manager or SSH
This is the fastest fix and doesn't touch your data. Renaming a plugin's folder forces WordPress to deactivate it automatically, since it can no longer find the plugin's main file.
- Log in to cPanel and open File Manager, or connect over SSH/SFTP.
- Go to
/public_html/wp-content/plugins/. - Find the 2FA plugin's folder (e.g.
wp-2fa,wordfence,miniorange-2-factor-authentication) and rename it, e.g. add-disabledto the end. - Log in to WordPress normally — you'll see a "plugin has been deactivated due to an error" style notice, which is expected.
- Rename the folder back once you're logged in and want to reconfigure 2FA properly.
Over SSH, the same thing in one line:
mv wp-content/plugins/wp-2fa wp-content/plugins/wp-2fa-disabledOption 3 — Clear the 2FA Secret Directly in the Database
Use this if you'd rather keep the plugin active and just clear your own lockout. Open phpMyAdmin from cPanel, select your WordPress database, and run a query against wp_usermeta for your user ID (find it under the wp_users table first):
SELECT * FROM wp_usermeta WHERE user_id = 3 AND meta_key LIKE '%2fa%';That will surface the exact meta_key your plugin uses (it varies by plugin — Wordfence, WP 2FA, and miniOrange all name theirs differently). Delete that row, or clear it:
DELETE FROM wp_usermeta WHERE user_id = 3 AND meta_key = 'wp_2fa_totp_key';Log back in with just your password. WordPress will treat 2FA as never having been set up for your account, and most plugins will prompt you to re-enrol on next login.
If you have terminal" class="auto-link">WP-CLI access on a VPS or SSH-enabled hosting, this is safer and faster than a raw SQL query:
wp user meta delete 3 wp_2fa_totp_keyIf It's a Clock Drift Problem, Not a Lost Device
If your phone's app shows a code and it's still rejected, check the server time before touching any plugin data:
date
timedatectl statusOn a SkyServer VPS, sync it with:
sudo systemctl restart chronyd
sudo chronyc makestepA drift of even a couple of minutes is enough to invalidate every TOTP code the plugin sees, which is easy to mistake for "the plugin is broken."
Prevention: Don't Let This Happen Again
| Do This | Why It Matters |
|---|---|
| Save backup codes somewhere outside the site itself | They're your only self-service recovery path — a password manager entry works fine |
| Keep a second admin account with 2FA on a different device | One locked-out phone shouldn't be able to lock out the entire site |
| Enable 2FA per-role, not force-enrol every user blindly | Editors and contributors rarely need the same enforcement as admins, and fewer enrolled accounts means fewer lockout tickets |
| Keep server time synced with chrony/NTP | TOTP is entirely time-based — drift breaks it silently |
| Document which plugin handles 2FA and its usermeta key name | Saves you the SELECT query scramble next time someone's locked out |
Two-factor authentication is genuinely worth having — it stops the overwhelming majority of automated wp-login.php attacks cold. It just needs a documented escape hatch before you turn it on, not after you're locked out.
Frequently Asked Questions
Will deactivating the 2FA plugin delete my other users' accounts or settings?
No. Renaming or deactivating the plugin folder only disables the 2FA check itself. User accounts, roles, and passwords are untouched — they're stored separately in wp_users, not in the plugin.
Can I just reset my WordPress password instead of dealing with 2FA?
Resetting your password (via wp-login.php?action=lostpassword or a database update) won't help if 2FA is enforced, because the 2FA prompt comes after a successful password check. You need to clear the 2FA requirement itself, not the password.
Why does my authenticator app show a valid code that WordPress still rejects?
This almost always means your server's system clock has drifted from real time. TOTP codes are generated from the current time plus the shared secret, so even a minute or two of drift causes every code to fail verification. Sync the server clock with chrony or NTP and retest.
Is it safe to leave 2FA disabled while I fix this?
Only briefly. Re-enable it (or set up a fresh 2FA enrolment) as soon as you're back in, and change your WordPress password at the same time in case the lockout was caused by a compromised device rather than a lost one.
Which 2FA plugin do you recommend for WordPress?
WP 2FA and Wordfence's built-in 2FA are both solid, actively maintained options that support backup codes and per-role enforcement out of the box. Whichever you pick, generate and store backup codes the same day you enable it — don't leave that step for later.
