What to do if you lose your 2FA backup codes

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, 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 TheOneWP helps manage TOTP authentication and recovery codes without weakening protection for the rest of the site.

What are 2FA backup codes?

Backup codes are recovery credentials generated as part of some two-factor authentication systems.

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 setting up authenticator-based 2FA, see How to set up an authenticator app for WordPress.

How TheOneWP backup codes work

TheOneWP’s Two-Factor Authentication module uses TOTP-based authentication and provides backup codes as part of the recovery workflow.

Each enrolled user receives a set of single-use recovery codes that can be used when the normal authenticator app is unavailable.

The login flow normally looks like:

Password
+
Authenticator code
=
Successful login

If the authenticator is unavailable, a valid unused backup code can act as the recovery path instead.

This makes recovery part of the authentication design rather than something administrators need to improvise after a device disappears.

Are 2FA backup codes reusable?

Backup codes should normally be treated as single-use credentials.

Once a code has been 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 implementation varies between systems, but TheOneWP’s recovery codes are designed for one-time use.

The OWASP Multifactor Authentication Cheat Sheet also recommends treating MFA recovery as a security-sensitive part of the authentication system.

What happens if you lose your backup codes?

Losing the backup codes does not automatically mean you are locked out.

If your authenticator app still works, you can continue authenticating normally.

The missing backup codes become a serious problem only 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, replace your backup codes immediately

If you still have access to WordPress, fix the problem before you actually need the recovery codes.

A safe sequence is:

1. log in normally using your password and authenticator app;
2. open your user profile or 2FA settings;
3. locate the recovery-code controls;
4. generate a new set of backup codes;
5. treat the previous set as obsolete;
6. store the new codes securely;
7. test a fresh login before closing your current session.

Recovery credentials are useful precisely because they are prepared while normal access still works.

Generating a new set should replace the old one

If backup codes are genuinely lost, replacing the existing set is safer than assuming the missing copy will never reappear.

A printed sheet, exported file or copied note may have been misplaced, deleted or exposed.

Once a new recovery set is generated, older copies should be treated as obsolete.

This is especially important if the lost credentials may have escaped your control.

Do not simply create another copy of missing recovery codes

If a recovery-code list is missing, creating another copy of the same credentials does not solve the security problem.

The missing copy may still exist somewhere.

A fresh set is preferable because it gives you a clean recovery state rather than multiplying copies of credentials you can no longer account for.

If your authenticator still works, you are not locked out yet

Missing recovery codes are a recovery problem, not necessarily an immediate login failure.

If your authenticator app still generates valid codes, use that access to repair the backup-code configuration while you still can.

This is also a good time to confirm the authenticator still works by testing a login from another browser or private window.

Keep your current WordPress session open

If you are already logged in when you discover that your backup codes are missing, do not immediately log out.

Your active session may be the easiest recovery path available.

A safer process is:

1. keep the current WordPress session open;
2. generate replacement backup codes;
3. store them securely;
4. open a private browser window;
5. test a fresh login;
6. only close the original session after confirming authentication works.

Closing your only working session before testing the new recovery state is a wonderfully efficient way to upgrade a minor inconvenience into an actual lockout.

What if you lost both backup codes and authenticator access?

This is the point where recovery becomes more complicated.

If you no longer have:

• access to the authenticator app;
• unused backup codes;
• another configured second factor;
• an active authenticated WordPress session;

then another authorized recovery path may be required.

For a team-managed WordPress installation, this usually means involving another trusted administrator rather than weakening 2FA for the entire site.

Ask another WordPress administrator for a targeted reset

If another trusted administrator still has access, they may be able to reset the 2FA configuration for the affected user.

This is preferable to disabling two-factor authentication globally.

The recovery action should affect only the account that actually needs recovery.

After the reset, the user should enroll again immediately, generate a fresh set of recovery codes and confirm the new login flow works.

Recovery should be targeted, not global

TheOneWP’s Two-Factor Authentication module is designed around individual user enrollment.

That means a problem affecting one account should normally be resolved at the user level.

A sensible recovery sequence is:

Affected user
→ reset 2FA

Other users
→ remain protected

Affected user
→ enroll again

New backup codes
→ generated and stored

This preserves the security state of accounts that are functioning normally.

Verify identity before resetting 2FA

A request to reset two-factor authentication is security-sensitive.

An administrator should not disable or reset 2FA simply because somebody sends a message claiming to have lost their phone.

An attacker may attempt to bypass strong authentication through social engineering rather than by defeating the authenticator itself.

Before resetting a privileged account, organizations should use an appropriate identity-verification process.

This can include:

• confirming the request through a known company communication channel;
• contacting the user through previously verified information;
• requiring confirmation from a manager or site owner;
• following a documented internal recovery procedure.

The OWASP MFA security guidance discusses recovery and reset procedures in more detail.

Do not disable 2FA globally for one locked-out user

If one account loses access to its authenticator, turning off 2FA for the entire WordPress site is usually the wrong response.

Global deactivation removes protection from users whose authentication is working correctly.

The recovery action should be as narrow as possible.

Reset the affected user’s 2FA configuration, restore access and require re-enrollment.

What if you are the only WordPress administrator?

If you are the only administrator and have lost every available second factor, recovery can be more difficult.

The available options depend on the site, hosting environment and 2FA implementation.

Authorized technical administrators may have recovery access through:

• the hosting control panel;
• SSH;
• WP-CLI;
• the WordPress database;
• the filesystem;
• documented plugin-specific recovery mechanisms.

These methods should only be used by someone authorized to manage the site and familiar with the authentication system involved.

Blindly deleting options or user metadata is a poor recovery strategy because authentication data may be stored in several places.

Do not turn emergency access into a permanent weak account

A documented recovery path is useful.

A permanently weak administrator account with no 2FA is not.

That simply creates a more convenient route around the protection you were trying to add.

If multiple administrators manage the site, the safer approach is to make sure more than one trusted privileged account is properly protected and capable of handling user recovery.

Can you deactivate 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.

This should be treated as a last-resort recovery technique.

Deactivating the entire 2FA implementation may change authentication for every protected account.

If a documented per-user reset exists, use that instead.

Do not delete random 2FA database values

Manual database editing may be appropriate for experienced administrators in specific emergencies, but guessing which values belong to 2FA is risky.

An implementation may store:

• TOTP secrets;
• backup code hashes;
• enrollment state;
• user-specific configuration;
• role enforcement settings;
• other authentication metadata.

Deleting the wrong values can make recovery harder or affect unrelated account settings.

Use documented recovery procedures whenever possible.

What if you still have an authenticated browser session?

An existing authenticated session may save you from a much more complicated recovery process.

If WordPress still recognizes the session, you may be able to open the profile and replace the 2FA configuration.

Some systems may require additional verification before sensitive changes, so this is not guaranteed.

But if the session is still valid, preserve it until the recovery path is clear.

What if you changed phones?

Changing phones is one of the most common reasons users believe they have lost 2FA access.

Before resetting anything, check whether the authenticator app supports:

• account synchronization;
• encrypted backup;
• device migration;
• manual transfer.

You may discover that the authenticator entry can still be restored.

If you still have the old phone, do not erase it until a code generated by the new device has been tested successfully.

Prepare for device replacement before it happens

If you use TheOneWP Two-Factor Authentication, the safest device-change process is simple:

1. keep the old authenticator available;
2. confirm that your recovery codes are still accessible;
3. transfer or reconfigure the authenticator;
4. test a login from the new device;
5. only then remove the old device configuration.

For the broader enrollment workflow, see How to set up an authenticator app for WordPress.

Check time synchronization before assuming 2FA is broken

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 lost enrollment at all.

Check that the device uses automatic date and time synchronization.

TOTP derives 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 recovery codes

If you find an old list of backup codes but do not know whether it is still current, avoid repeatedly submitting random entries.

Repeated failures can make troubleshooting more difficult and may interact with other login protections.

If the recovery set has already been replaced, discard the old copy rather than trying every code in the hope one survived.

What if one backup code has already been used?

With 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 no longer know which codes are valid, generate a fresh recovery set while authenticated access is still available.

Where should you store new 2FA backup codes?

Backup codes should be stored somewhere secure and accessible during an authentication emergency.

Possible 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 important point is that the recovery method should not depend entirely on the same device used for the primary authenticator.

Do not store backup codes in an unprotected text file

A file such as:

wordpress-backup-codes.txt

left on a desktop or shared folder is not meaningful credential protection.

Recovery codes are authentication credentials.

If someone obtains the password and a valid unused recovery code, they may be able to complete the login process.

Do not store passwords and backup codes together insecurely

Two-factor authentication exists to require more than one authentication 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 2FA.

A protected password manager or company vault is different because the vault itself adds encryption and access controls.

Should backup codes be printed?

A physical copy can be a reasonable recovery mechanism if it is stored securely.

For example, an organization may keep emergency credentials in a controlled physical location available only to authorized staff.

Printing them and taping them beside the monitor would, unsurprisingly, reduce the sophistication of the entire exercise somewhat.

How many copies should you keep?

One secure copy may be enough for an individual user.

Organizations may choose controlled redundancy for particularly important accounts.

Too many uncontrolled copies create additional exposure.

The objective is to avoid a single point of failure without scattering recovery credentials across devices, email accounts and message histories.

Should you email backup codes to yourself?

Ordinary email is generally a poor substitute for a dedicated credential vault.

Email accounts can be synchronized across many devices, exposed through forgotten sessions or compromised independently.

If recovery credentials need to be transferred electronically, use a process appropriate to the sensitivity of the account.

Never send backup codes through ordinary team chat

Copying recovery codes into Slack, Teams, WhatsApp or another general-purpose chat system creates more copies that may remain in history, backups and synchronized devices.

Administrators should also never ask users to send recovery codes as proof that they possess them.

Recovery codes should remain private credentials.

Regenerate backup codes after a suspected compromise

If you believe somebody else may have seen or copied your recovery codes, treat the issue as a credential compromise rather than merely a storage problem.

If you can still access WordPress:

1. generate a fresh recovery set;
2. treat the old set as invalid;
3. review recent account activity where available;
4. change the password if it may also have been exposed;
5. confirm the enrolled authenticator still belongs to you;
6. review privileged account settings.

Change your password when the incident involves more than backup codes

Losing recovery codes does not automatically mean the WordPress password has been compromised.

However, if the codes were stored together with the password or lost as part of a compromised device or file, changing the password may also be appropriate.

Consider the whole incident rather than treating the backup codes in isolation.

Review active sessions after recovery

After recovering a privileged account, consider reviewing active sessions if your WordPress setup provides that capability.

If the incident involved a lost or compromised device, removing unfamiliar or unnecessary sessions can reduce residual risk.

Recovery is also a good time to review whether unexpected account or site changes occurred.

Use account activity to support recovery decisions

TheOneWP’s Last Login module can help administrators understand when an account last authenticated successfully.

This does not replace a full security audit, but it can provide useful context when reviewing dormant or suspicious accounts.

For example:

Recently active privileged user
→ verify recovery request carefully

Dormant account not used for months
→ review whether access is still required

Recovery incidents are often a good excuse to clean up permissions that should have been reviewed months earlier. Humans do enjoy waiting for a small emergency before doing maintenance.

Generate fresh recovery codes after a 2FA reset

If an administrator resets your 2FA configuration, treat the next enrollment as a completely new authentication setup.

After configuring the new authenticator:

1. verify a fresh authenticator code;
2. generate a new recovery-code set;
3. store the codes securely;
4. test a new login before closing the current session.

Test the recovery process before depending on it

A controlled test can help users understand how recovery works before an actual emergency occurs.

If a recovery code is tested successfully, remember that single-use codes should be treated as consumed.

The purpose is not to test every code. It is to confirm that the recovery process is understood.

Do not regenerate backup codes constantly

Generating new recovery codes every few days does not inherently improve security.

It can instead create confusion over which set is current.

Generate a fresh set when there is a reason, such as:

• the current codes were lost;
• they may have been exposed;
• many codes have already been consumed;
• 2FA was reset;
• organizational policy requires replacement.

When a new set is generated, securely destroy obsolete copies where practical.

Administrators need a documented 2FA recovery process

On a team-managed WordPress site, recovery should not depend on one administrator remembering what happened during the previous lockout.

A basic recovery procedure should define:

• who may request a 2FA reset;
• how identity is verified;
• which administrators may perform the reset;
• how the reset is carried out;
• how the user must re-enroll;
• how new backup codes should be stored;
• whether the recovery event should be logged.

If you are introducing 2FA across a team, establish this process before enforcement begins.

See How to roll out 2FA to a WordPress team without lockouts for the full deployment process.

Do not create an unprotected emergency administrator

Maintaining a recovery path does not mean keeping a permanent Administrator account with a weak password and no 2FA.

That simply creates a bypass around the protection applied to every other account.

Emergency administrative access should itself be protected, documented and limited to trusted users.

2FA recovery and WordPress roles

Recovery is more sensitive for privileged users because restoring access also restores whatever permissions that account already has.

A recovered Administrator account is not equivalent to a recovered Subscriber account.

For that reason, it is worth reviewing whether privileged users still need the roles they have.

TheOneWP’s Role Manager can help administrators review and adjust WordPress roles and capabilities as part of the broader account-security workflow.

For a deeper review, see How to audit user roles on a WordPress site.

Backup codes are not a substitute for 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;
• secure administrative recovery;
• reviewing access periodically.

Remember that not every WordPress credential uses 2FA

Authenticator-based 2FA usually protects the interactive browser login.

WordPress can also use separate credentials for programmatic access.

Application Passwords, for example, are revocable credentials designed for APIs and integrations.

Other systems may also use:

• API tokens;
• OAuth credentials;
• integration secrets;
• custom REST authentication.

If a privileged account is involved in a security incident, review those credentials separately rather than assuming that resetting interactive 2FA secures every access path.

See the official WordPress Application Passwords documentation for WordPress’s built-in programmatic credentials.

How to avoid losing access again

Once access has been recovered, use the incident to improve the setup instead of returning to exactly the same configuration.

A practical prevention process includes:

1. configure a reliable authenticator app;
2. generate fresh backup codes;
3. store the codes securely;
4. avoid keeping the only copy on the authenticator device;
5. test a fresh login;
6. understand the administrator recovery process;
7. 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 a new recovery set immediately if you still have access.
• Treat genuinely lost codes as potentially exposed where appropriate.
• Store the replacement 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 the current session.
• Check whether the old authenticator device is still available.
• Verify 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 account.
• Re-enroll immediately after a reset.
• Generate a fresh recovery set after re-enrollment.
• Review the incident if the lost codes may have been exposed.

Manage 2FA recovery with TheOneWP

The main TheOneWP module for this workflow is Two-Factor Authentication.

It provides TOTP-based authentication and user-level recovery codes directly inside WordPress.

The core workflow includes:

• authenticator-app enrollment;
• TOTP verification;
• single-use backup codes;
• role-based 2FA requirements;
• individual user enrollment and recovery.

This makes backup-code recovery part of the normal authentication system instead of an emergency process built from random snippets or database edits.

The surrounding account-security workflow can also involve:

• Role Manager for reviewing the permissions restored when an account is recovered;
• Last Login for understanding recent successful account access;
• Two-Factor Authentication for the actual authenticator and recovery-code layer.

The objective is not to add complexity for its own sake. It is to make recovery predictable without weakening authentication for every other user on the site.

Final thoughts on lost 2FA backup codes

Losing 2FA backup codes is inconvenient, but it does not necessarily mean losing access to WordPress.

If your authenticator still works or you still have an authenticated session, replace the recovery-code set as soon as possible and store the new credentials securely.

If both the authenticator and backup codes are unavailable, use a targeted recovery process through another trusted administrator or the site’s documented emergency procedure.

TheOneWP’s Two-Factor Authentication module provides the technical recovery layer through TOTP authentication and single-use backup codes.

The human part still matters: recovery codes must be saved before they are needed, administrator resets must verify identity and individual lockouts should not become excuses to weaken protection across the entire site.

The best recovery procedure is the one prepared while everything still works. Authentication problems become considerably less dramatic when the backup plan existed before the backup codes disappeared.