Losing your 2FA backup codes can be stressful, especially if your authenticator app is also unavailable. The important thing is to separate two situations: losing the backup codes while you can still authenticate normally, and losing both the backup codes and access to your usual second-factor method.
If you can still access your WordPress account, the situation is usually straightforward. Generate a new set of recovery codes if your 2FA implementation supports them, replace the previous set and store the new credentials somewhere secure.
If you are already locked out, recovery depends on the two-factor authentication system protecting the account, your WordPress permissions and whether another trusted administrator or documented recovery mechanism is available.
In this guide, we will look at what to do when 2FA backup codes are lost, how to recover access safely and how to avoid turning a missing recovery credential into a full account lockout.
What are 2FA backup codes?
Backup codes are recovery credentials that some two-factor authentication systems generate when 2FA is configured.
They are designed for situations where the normal second factor is unavailable.
For example, backup codes can help if:
- your phone is lost or stolen;
- your authenticator app is deleted;
- you replace your phone and the authenticator entry does not transfer;
- your device is damaged;
- you accidentally remove the WordPress account from the authenticator app;
- your normal 2FA device is temporarily unavailable.
A backup code is therefore not a replacement for your normal authenticator. It is an emergency recovery method.
If you are still configuring authenticator-based 2FA and have not completed enrollment yet, see How to set up an authenticator app for WordPress first.
Are 2FA backup codes reusable?
Many 2FA implementations design backup codes as single-use credentials.
After a code is successfully used, that individual code should no longer be relied upon for another login.
This is an important security property because a recovery credential that has already been used should not remain indefinitely useful if somebody copied it.
The exact behavior depends on the 2FA system installed on the WordPress site, so check the documentation of the implementation you are using rather than assuming every recovery-code system works identically.
The OWASP Multifactor Authentication Cheat Sheet also recommends designing recovery mechanisms carefully because account recovery can become an alternative path around otherwise strong authentication controls.
What happens if you lose your backup codes?
Losing the backup codes does not automatically mean you are locked out.
If your authenticator app or another configured second factor still works, you can normally continue using that method to authenticate.
The missing backup codes become a serious problem when the primary second factor is also unavailable.
The practical risk therefore depends on which authentication paths you still control.
If you can still log in, regenerate your backup codes immediately
If you still have access to WordPress, deal with the problem before you actually need the recovery codes.
A safe sequence is usually:
- log in normally using your password and current second factor;
- open your user profile or 2FA settings;
- locate the backup or recovery code section;
- generate a new set of backup codes if the implementation supports it;
- confirm that the previous set has been replaced or invalidated;
- store the new codes securely.
Do not wait until the authenticator becomes unavailable. Recovery credentials are useful precisely because they are prepared while normal access still works.
Generating new backup codes may invalidate the old ones
Many 2FA systems replace the existing recovery-code set when a new one is generated.
This is desirable when the old codes are genuinely lost or may have been exposed.
If a printed sheet, exported file or other copy has disappeared, you cannot know with certainty whether somebody else may eventually gain access to it.
When the implementation replaces recovery codes, treat every previous copy as obsolete after generating the new set.
Do not simply create another copy of missing codes
If you believe your existing recovery codes have been lost rather than merely stored in a known secure location, generating a fresh set is safer than making another copy of the old credentials.
The distinction matters.
A duplicate copy does nothing to invalidate the missing credentials. A newly generated set can replace them when the 2FA system supports that behavior.
When authentication credentials may have escaped your control, replacement is generally safer than duplication.
If your authenticator app still works, you are not locked out yet
Missing backup codes are a recovery problem, not necessarily an immediate login failure.
If you can still produce valid codes from your authenticator app, use that access to repair the recovery configuration while you still can.
This is also a good time to confirm that the authenticator entry really works by testing a fresh login in another browser or private window.
Keep your current WordPress session open while fixing 2FA
If you are already logged in when you discover that your backup codes are missing, do not immediately log out.
Your existing authenticated session may provide a valuable recovery path while you repair the 2FA configuration.
A safer process is:
- keep the existing WordPress session open;
- generate replacement backup codes when available;
- store them securely;
- open a private or incognito browser window;
- test a fresh login using your normal second factor;
- only close the original session after confirming that authentication works.
Closing your only working session before testing the replacement configuration is an unnecessarily adventurous way to perform account maintenance.
What if you lost both your backup codes and authenticator access?
This is the situation where account recovery becomes more complicated.
If you no longer have:
- access to the authenticator app;
- a working hardware security key or other configured second factor;
- unused backup codes;
- an existing authenticated WordPress session;
then you may need another trusted administrator or an authorized recovery mechanism to reset the 2FA configuration.
The exact procedure depends on the plugin, identity provider or authentication system protecting the account.
Ask another WordPress administrator for help
If another trusted administrator still has access to the site, they may be able to reset or disable 2FA for your individual account.
This is generally preferable to disabling two-factor authentication across the entire website.
A targeted recovery process preserves protection for other users while restoring access only for the affected account.
After the reset, configure a new second factor promptly rather than leaving the account permanently without additional protection.
Your identity should be verified before another administrator resets 2FA
A request to reset two-factor authentication is security-sensitive.
An administrator should not disable 2FA simply because somebody sends a message claiming to have lost their phone.
An attacker who knows a username, email address or employee name may attempt to bypass 2FA through social engineering rather than by defeating the authentication mechanism itself.
Before resetting a privileged account, organizations should use an appropriate identity-verification process.
Depending on the team, that could involve:
- confirming the request through a known company communication channel;
- contacting the user through previously verified contact information;
- requiring confirmation from a manager or site owner;
- using an established internal account-recovery procedure.
OWASP specifically recommends treating MFA reset and recovery as sensitive operations because a weak recovery process can undermine otherwise strong multi-factor authentication. See the OWASP MFA security guidance for broader recovery and reset recommendations.
Do not disable 2FA globally for one locked-out user
If one account loses its second factor, avoid turning off 2FA for every WordPress user unless there is a genuine system-wide failure.
Global deactivation removes protection from accounts that are functioning correctly.
The recovery action should be as narrow as possible.
Ideally, reset or remove the 2FA configuration only for the affected user and require that user to enroll again after access is restored.
What if you are the only WordPress administrator?
If you are the only administrator and you have lost every available second factor, recovery can be more difficult.
The available options depend on the site, hosting environment and 2FA implementation.
Authorized site owners or technical administrators may have recovery access through:
- the hosting control panel;
- SSH;
- WP-CLI;
- the WordPress database;
- the filesystem;
- plugin-specific recovery mechanisms.
These methods should only be used by someone authorized to administer the site and familiar with the authentication system involved.
The exact recovery procedure varies between 2FA implementations, so blindly deleting options or database records is a poor strategy. Authentication state may live in user metadata, plugin-specific tables, configuration or several locations at once.
Can you disable a 2FA plugin through the filesystem?
In some emergency situations, an authorized administrator with filesystem or hosting access may be able to deactivate a WordPress plugin outside the dashboard.
However, this should be treated as a last-resort recovery technique rather than the normal solution to a single user’s lockout.
Deactivating an entire 2FA plugin may affect every protected account and can change the security state of the whole site.
If the plugin provides a documented per-user reset or recovery method, use that instead.
Do not delete random 2FA database values
Manually editing the WordPress database can be appropriate for experienced administrators in specific recovery situations, but guessing which values belong to 2FA is risky.
A 2FA implementation may store information such as:
- shared authentication secrets;
- backup code hashes;
- enrollment state;
- trusted device information;
- enforcement settings;
- user-specific authentication metadata.
Deleting the wrong values can make recovery harder or affect unrelated account settings.
Use documented recovery procedures whenever they are available.
What if you still have an authenticated browser session?
An existing authenticated session can sometimes save you from a much more complicated recovery process.
If WordPress still recognizes your browser session, you may be able to open your profile and repair or replace the 2FA configuration.
Do not assume this will always be permitted. Some implementations require reauthentication before sensitive account changes.
But if the session is still valid, preserve it until you know whether it can help with recovery.
What if you changed phones?
Changing phones is one of the most common reasons users believe their 2FA access has disappeared.
Before resetting anything, check whether your authenticator application supports account synchronization, encrypted backup or device migration.
You may discover that the existing authenticator entry can still be restored.
If you still have the old device, do not erase it until you have confirmed that codes generated by the new device work correctly.
Do not assume authenticator apps automatically transfer
Some authenticator apps support synchronization or migration, while others require an explicit transfer or re-enrollment process.
Replacing a phone without checking the authenticator configuration can therefore remove access to accounts that appeared to be safely configured.
Before replacing a device, verify:
- whether the authenticator app supports transfer or backup;
- whether the WordPress account appears on the new device;
- whether a generated code from the new device is accepted;
- whether backup codes remain accessible.
Check time synchronization before assuming your authenticator is lost
Time-based one-time passwords depend on synchronized time.
If the authenticator entry is still present but every code is rejected, the problem may not be the 2FA enrollment itself.
Check that the device uses automatic date and time synchronization.
TOTP derives authentication codes from a shared secret and the current time, so significant clock drift can cause otherwise valid-looking codes to fail. The underlying algorithm is defined in RFC 6238.
Do not keep trying random backup codes
If you find an old list of recovery codes but are unsure whether it is still active, avoid repeatedly submitting random entries.
Repeated failures may interact with other login protection controls and make troubleshooting more difficult.
If you know the recovery set has already been replaced, discard the old copy rather than testing every code to see whether one happens to work.
What if one backup code has already been used?
If your 2FA implementation uses single-use recovery codes, a successfully consumed code should be treated as invalid.
Other unused codes from the same active set may remain available.
If you are unsure which codes remain valid or whether the list is complete, generate a fresh recovery set while you still have authenticated access.
Where should you store new 2FA backup codes?
Backup codes should be stored somewhere secure and accessible during an authentication emergency.
Possible storage options include:
- a trusted password manager;
- an encrypted company credential vault;
- an encrypted offline backup;
- a controlled organizational recovery system;
- a securely stored physical copy where appropriate.
The correct choice depends on the organization and its security requirements.
The important point is that the recovery method should not depend entirely on the same device used for the primary second factor.
Do not store backup codes in an unprotected text file
A file named something like:
wordpress-backup-codes.txtstored openly on a desktop or shared folder is not a meaningful security strategy.
Recovery codes are authentication credentials.
Anyone who obtains the required first-factor credentials together with a valid unused recovery code may be able to complete the authentication process.
They should therefore be protected accordingly.
Do not store your password and backup codes together insecurely
Two-factor authentication is designed to require more than one authentication factor or step.
If the WordPress password and every recovery code are stored together in the same unencrypted document, compromising that document may defeat much of the benefit of the additional authentication layer.
A protected credential manager is different because the vault itself provides encryption and access controls. An ordinary text document or spreadsheet does not.
Should backup codes be printed?
A physical copy can be a reasonable recovery option in some environments if it is stored securely.
For example, an organization might keep emergency recovery credentials in a controlled physical location accessible only to authorized staff.
Printing backup codes and leaving them beside the computer, attached to a monitor or sitting in an unlocked drawer rather defeats the exercise.
The medium matters less than the controls around access to it.
How many copies of backup codes should you keep?
One secure copy may be sufficient for an individual user, while organizations may choose controlled redundancy for particularly important accounts.
Too many uncontrolled copies create additional exposure.
The goal is to avoid a single point of failure without scattering authentication credentials across devices, inboxes and chat histories.
Should you email 2FA backup codes to yourself?
Ordinary email is generally a poor substitute for a dedicated credential vault.
An email account may be synchronized across multiple devices, exposed through forgotten sessions or itself become the target of an account compromise.
If recovery credentials need to be transferred electronically, use a process appropriate to the sensitivity of the account rather than leaving them indefinitely in an inbox.
Never send backup codes through ordinary team chat
Copying recovery codes into Slack, Teams, WhatsApp or another general-purpose chat system creates additional copies that may remain in message history, backups and synchronized devices.
Administrators should not ask users to send their recovery codes as proof that they possess them.
Recovery codes should remain private authentication credentials.
Regenerate backup codes after a suspected compromise
If you believe somebody else may have seen or copied your recovery codes, the issue is no longer only availability.
The credentials should be treated as potentially compromised.
If you can still access the account:
- generate a fresh recovery set;
- confirm that the previous set is no longer valid when supported;
- review recent account activity where available;
- change the password if there is reason to believe it may also be compromised;
- verify that the configured authenticator belongs to you;
- review privileged account settings.
Finding another copy of the old codes does not remove the possibility that somebody else copied them too.
Change your password if the incident involves more than missing backup codes
Losing recovery codes does not automatically mean your WordPress password has been compromised.
However, if the codes were stored together with the password or lost as part of a stolen device, exposed document or compromised credential vault, changing the password may also be appropriate.
Consider the entire incident rather than treating the recovery codes in isolation.
Review active sessions after recovering access
After recovering a privileged account, consider reviewing active sessions if your WordPress setup provides that capability.
If the loss of recovery credentials may have involved unauthorized access to a device or account, terminating unfamiliar or unnecessary sessions can reduce residual risk.
For administrator accounts, recovery is also a sensible time to review whether unexpected site or account changes occurred.
Generate fresh recovery codes after a 2FA reset
If an administrator resets your 2FA configuration, treat the subsequent enrollment as a new authentication setup.
After configuring the new authenticator:
- verify a fresh authenticator code;
- generate a new recovery-code set when supported;
- store the codes securely;
- test a new login before closing your current session.
Test the recovery process before depending on it
If your 2FA implementation supports a safe recovery-code test, performing one controlled test can help confirm that you understand the recovery workflow.
Remember that single-use codes should be considered consumed after a successful test.
The goal is not to test every recovery credential. It is to understand the process before an emergency occurs.
Do not regenerate backup codes constantly
Regenerating recovery codes every few days does not inherently improve security.
It can instead create confusion over which set is current.
Generate a new set when there is a reason, such as:
- the existing codes were lost;
- the codes may have been exposed;
- too many codes from the active set have already been used;
- the 2FA configuration was reset;
- organizational policy requires rotation.
When a new set is created, securely destroy obsolete copies where practical.
Administrators should have a documented 2FA recovery process
On a team-managed WordPress site, recovery should not depend on one administrator remembering what they did the last time somebody lost a phone.
A basic procedure should explain:
- who is allowed to request a 2FA reset;
- how the user’s identity is verified;
- which administrators are authorized to perform the reset;
- how the reset is performed;
- how the user is required to re-enroll;
- how new backup codes should be stored;
- whether the recovery event should be logged.
Documented recovery makes security incidents more predictable and reduces the temptation to disable protections globally under pressure.
The OWASP Multifactor Authentication Cheat Sheet also recommends carefully designed recovery procedures, including strong identity verification when users need assistance recovering an MFA-protected account.
If you are preparing 2FA for several users, establish this process before enforcement begins. See How to roll out 2FA to a WordPress team without lockouts.
Do not create an unprotected emergency administrator account
Maintaining a recovery path does not mean keeping a permanent administrator account with a weak password and no additional authentication protection.
That simply creates an easier target.
Emergency administrative access should itself be protected, documented and monitored according to the importance of the site.
Remember that not every WordPress authentication method uses 2FA
Authenticator-based 2FA usually protects an interactive login flow, but WordPress can also use other credentials for programmatic access.
WordPress Application Passwords, for example, are separate revocable credentials designed for API authentication by applications and integrations rather than ordinary browser logins.
Other systems may also use:
- API tokens;
- OAuth credentials;
- integration-specific secrets;
- custom REST API authentication.
If a privileged account is involved in a security incident, review those credentials separately instead of assuming that resetting interactive 2FA automatically secures every access path.
For WordPress’s built-in programmatic credential system, see the official WordPress Application Passwords documentation.
Backup codes are not a substitute for proper account management
Recovery codes solve one specific problem: losing access to the normal second factor.
They do not replace:
- strong unique passwords;
- individual user accounts;
- appropriate WordPress roles and capabilities;
- removing former users;
- login monitoring;
- secure administrator recovery procedures.
For privileged websites, it is worth periodically checking whether users still have the permissions they actually need. See How to audit user roles on a WordPress site for a broader permissions review.
How to avoid losing access again
Once access has been recovered, use the incident to improve the setup rather than returning to exactly the same configuration.
A practical prevention process includes:
- configure a reliable authenticator method;
- generate fresh backup codes when available;
- store the recovery codes securely;
- avoid keeping the only copy on the authenticator device;
- test a fresh login;
- understand the administrator recovery process;
- prepare before replacing or wiping a phone.
2FA backup code recovery checklist
- Check whether your authenticator app still works.
- Keep any existing authenticated WordPress session open.
- Generate new backup codes immediately if you still have access.
- Treat lost recovery codes as potentially exposed when appropriate.
- Store the new codes securely.
- Do not store recovery codes in an unprotected text file.
- Do not send backup codes through ordinary team chat.
- Test a fresh login before closing your current session.
- Check whether an old authenticator device is still available.
- Verify device time synchronization if TOTP codes are being rejected.
- Ask another trusted administrator for a targeted reset if necessary.
- Verify identity before resetting another user’s 2FA.
- Avoid disabling 2FA globally for one locked-out account.
- Re-enroll immediately after an administrator resets 2FA.
- Generate a fresh recovery set after re-enrollment.
- Review the incident if the lost codes may have been exposed.
Using Two-Factor Authentication in TheOneWP
TheOneWP includes a dedicated Two-Factor Authentication module for adding an additional authentication step to WordPress user accounts.
When using 2FA on an important WordPress site, backup codes should be treated as part of the authentication setup rather than an optional detail that can be considered later.
Users should complete enrollment, save their recovery credentials and confirm that the normal login flow works before they depend on the configuration.
If a team is enabling two-factor authentication across multiple accounts, recovery should be planned before enforcement begins.
The safest deployment is one where users know how to enroll, administrators know how to verify legitimate recovery requests and no individual lockout requires weakening authentication for everybody else.
Final thoughts on lost 2FA backup codes
Losing 2FA backup codes is inconvenient, but it does not necessarily mean losing your WordPress account.
If your authenticator still works or you still have an authenticated session, generate a fresh recovery set as soon as possible and store it securely.
If both the normal second factor and the recovery codes are unavailable, use the site’s documented recovery procedure or ask another trusted administrator to reset 2FA for the affected account.
Avoid solving individual lockouts by weakening authentication for the entire website.
The most important lesson is preventative: backup codes only help when they have been generated, stored securely and remain accessible when the primary authenticator fails.
Prepare the recovery path while everything is working normally. Authentication emergencies are considerably less dramatic when the emergency procedure existed before the emergency.