MFA Recovery Codes: Store and Check Your Backup

Cybersecurity & Privacy · Account access · Recovery planning

Save MFA recovery codes while you can still sign in, protect them like credentials, and keep a copy you can reach without the phone or account you are trying to recover. Check each provider’s rules: a single-use backup code, a password-reset recovery code, and an authenticator backup can serve different purposes.

The useful test is simple: if your usual phone disappeared today, could you identify the correct backup, access it securely, and follow the service’s recovery process? A screenshot saved somewhere is not a complete plan if you need the missing phone to unlock it.

This guide covers personal accounts and small-team planning. Provider documentation was checked on 25 October 2026. Examples are hypothetical; no live accounts or recovery codes were tested.

Identify the backup before you save it

A recovery code belongs to the service that issued it. It is not a universal code for your phone or all accounts inside an authenticator app. The same email address can identify several services with unrelated recovery arrangements.

Google’s backup-code guidance, for example, describes using a saved code for the second sign-in step when the usual verification method is unavailable. Using one makes that code inactive.

Google Authenticator’s official documentation describes account synchronization and manual transfers. Those features concern authenticator credentials; they are different from downloading a service’s emergency code list.

For choosing your everyday method, read our passkeys vs authenticator apps guide. Recovery preparation is the next question: what remains available if your preferred method is lost?

Check the provider’s rules instead of assuming one workflow

Start from the service’s official security settings, reached through its known website or app. Look for recovery methods, backup codes, or two-factor authentication settings. You may need to authenticate again before viewing or generating sensitive material.

Google Account backup codes

Google places backup codes under Security & sign-in → 2-Step Verification → Backup codes. It supports downloading or printing a set. Generating a new set inactivates the old one. Google also notes that backup-code downloads are unavailable for accounts in its Advanced Protection Program. Follow the options actually available on your account.

GitHub recovery codes

GitHub’s recovery-method documentation places recovery codes in Settings → Password and authentication. Codes can be downloaded, printed, or copied. Each is single-use; a newly generated set invalidates the previous set. GitHub also recommends configuring two or more authentication methods.

Microsoft personal-account recovery code

Microsoft’s personal-account guidance describes a 25-digit recovery code. It cannot retrieve an existing code for you; if you can sign in, you can generate a new one, which replaces the previous code. Microsoft recommends printing it and keeping it somewhere safe, away from a device used to sign in.

This is not interchangeable with a GitHub or Google MFA backup code. Microsoft’s documented recovery process can include a 30-day delay for changes when two-step verification is enabled. Do not assume possessing a recovery code guarantees immediate access.

Mozilla account backup authentication codes

Mozilla’s setup guidance includes one-time backup authentication codes as a recovery method. It asks users saving codes to confirm one during setup. Follow that built-in confirmation rather than inventing a test that removes your existing protection.

Choose storage that survives the failure you are planning for

Use the issuer’s instructions first. For providers that permit password-manager storage, check that you can unlock the vault after losing your main phone. GitHub explicitly recommends a secure password manager for its codes. Microsoft’s personal-account advice instead calls for a printed copy stored away from sign-in devices.

Compare storage against your actual failure scenarios. The following is a planning checklist, not a claim that any one storage method is risk-free.

Consider a hypothetical traveler whose only copy is inside the same cloud account that requires the lost phone. The file exists, but the dependency prevents access. A separate, protected recovery route would address that particular failure.

Label the saved material with the service, account identifier, and creation date. Keep the label private too. Avoid scattering copies across chat messages, email drafts, ordinary photo libraries, and shared folders merely for convenience.

A paper copy needs updating when the service replaces its codes. A digital copy needs an intentional storage location; the download folder should not become an accidental long-term credential archive.

Verify the copy without disabling MFA

Begin with a storage check. Confirm that the saved copy opens or is legible, identifies the right account, and contains the complete material the provider issued. Compare it while you still have normal access. Avoid exposing it in screen shares, screenshots, support tickets, or demonstrations.

Next, rehearse the access path without submitting a code: locate the document, unlock the permitted storage, find the official help page, and identify the recovery option. Record the steps without copying the secrets into the checklist.

If you choose to perform a real sign-in test, read the provider’s instructions first, keep your normal method available, and understand that a single-use code will be consumed. Mark the used code afterward. Do not remove your authenticator, erase your old phone, or sign out of every device merely to test recovery.

Microsoft’s broader recovery flow can change credentials or involve waiting periods, so it is unsuitable as a casual code-validity check. Use preparation and provider guidance rather than starting a reset simply to see what happens.

Use only the official recovery route when access fails

Open the service through a known address or trusted bookmark. Follow its alternative sign-in or recovery prompts. Supply a code only where the official workflow requests that specific type of code.

GitHub’s recovery instructions describe choosing a 2FA recovery code under the sign-in options. They also explain that available recovery methods matter: if none can be used, access may be permanently lost. Do not build a plan around an assumption that support can always bypass MFA.

Login.gov’s backup-code guidance warns that saved codes are vulnerable to theft and phishing and should receive the same care as a password. Having a backup does not make an unexpected request for it legitimate.

Google says it never asks for a backup code except at sign-in. Do not send your code list to someone claiming to perform a security check. For work accounts, use the organization’s known IT contact process rather than contact details supplied in an unsolicited message.

Replace codes deliberately and keep copies consistent

After using a single-use code, mark it unavailable in every copy you intend to keep. If you generate a replacement set, replace the active backup everywhere and securely dispose of superseded copies. A creation date helps distinguish the current record from an older download.

If a list was exposed, follow the service’s process to invalidate or regenerate it while you still have access. Review other account security settings and unfamiliar activity as well; replacing codes alone may not address a broader account compromise.

Before a phone replacement, check the recovery materials for your important accounts and verify the new everyday sign-in method before retiring the old device. Treat that change as an account-access project, not just a phone-data migration.

• The saved record identifies the correct service and account.
• The copy is accessible without the device being replaced.
• Used codes and superseded sets are clearly accounted for.
• Additional permitted sign-in methods are documented.
• The official recovery instructions are easy to find.

Plan work-account recovery through the administrator

Personal-account instructions may not apply to organization-managed identities. Confirm the approved process with your administrator before storing work recovery material in a personal vault or creating an informal shared code list.

Google Workspace’s recovery guidance documents administrator-generated backup codes, subject to the appropriate privileges. Recovering another administrator requires a super administrator. That illustrates why the role and account type belong in a team’s recovery plan.

For a small team, name the authorized recovery contact, verify identity through an established process, and record who can handle an administrator lockout. Keep continuity documentation separate from individual employees’ secret codes.

OWASP’s MFA guidance emphasizes that recovery must balance restoring access with preventing attackers from bypassing MFA. The appropriate process depends on the service and its users. A convenient shared workaround should not silently replace the organization’s approved controls.

Frequently asked questions