MFA Backup Codes and Recovery Codes: Storage and Design

Backup codes and recovery codes are a second set of keys to an account protected by multi-factor authentication, and whoever holds them can sign in without your phone or security key. They exist so that losing an authenticator does not lock you out for good, but they are often saved as a text file in Downloads, emailed to oneself, or printed and forgotten, and some admin consoles can mint them for any user. This guide explains how the major services issue and replace backup codes, where to store them, what to do when you use one or suspect they have leaked, and how they are abused in account takeover. The second half is for developers and identity teams designing recovery codes: the NIST SP 800-63B Rev. 4 requirements for look-up secrets, storage, rate limits, notifications and admin controls. For help desk and identity-proofing recovery, see the Account Recovery and Help Desk Security Guide.

Key takeaways

A backup code is a full sign-in factor. With the password, one code gets an attacker past MFA, so protect the list like the account itself.
Each code works once, and a new set kills the old. Google issues 10 eight-digit codes and GitHub 16; generating a fresh set invalidates every previous code, which is the fix when a list may have leaked.
Store them offline or in a password manager, not next to the account they unlock. Apple warns against storing its recovery key in apps you could not open if you were locked out.
Some recovery choices remove the safety net. Turning on an Apple recovery key turns off Apple's standard recovery process, and GitHub Support states it will not restore access to 2FA accounts if all methods are lost.
Designers must treat codes as look-up secrets. NIST requires at least six decimal digits from an approved random generator, single use, hashed storage, salting for short codes, and rate limiting.

How the major services issue codes

Service	What you get	Single use?	Replacing them	Notes from the vendor
Google Account	Sets of 10 backup codes, 8 digits each	Yes	Refresh creates a new set and deactivates the old	Downloads are named Backup-codes-username.txt; Advanced Protection users cannot download backup codes; use "Try another way" at sign-in
Google Workspace (admin)	Admins with the User management privilege can get backup verification codes for a user	Yes	Admin console, user, Security, 2-step verification	Only super administrators can do this for another admin; in "Only security key" enforcement users cannot generate their own
GitHub	16 recovery codes	Yes	Regenerating cancels all previous codes; disabling and re-enabling 2FA also refreshes them	View at Settings, Password and authentication; GitHub advises a secure password manager
Apple Account	Optional 28-character recovery key	Reusable key, not a list	Replace Recovery Key in Sign-in & Security	Turns off standard account recovery; Apple cannot provide a lost key; recovery contact is the alternative with Advanced Data Protection

Other services follow similar patterns: a list of single-use codes shown once at MFA setup, with an option to regenerate. Check each service's own help page, because counts, formats and what regeneration does vary.

For individuals: storing and using backup codes

Where to keep them

Storage option	Protects against	Risk	Verdict
Printed, in a safe place at home	Online theft, malware	Fire, loss, household access	Good for your most important accounts
Password manager entry (separate from the account's password where possible)	Loss, convenience	If the manager is compromised, codes go with it; do not store the codes for the password manager itself inside it	Good for most accounts; GitHub recommends it
Text file in Downloads or desktop	Nothing much	Infostealer malware collects files and browser data from infected devices	Avoid: move it, then delete the file
Email to yourself or cloud notes	Loss	Anyone in your mailbox gets your MFA bypass; you may not reach the notes if locked out	Avoid; Apple warns against storing its recovery key in Notes, Passwords, iCloud Photos or iCloud Drive
Photo on your phone	Nothing if the phone is lost	Lost with the phone; synced to cloud photos	Avoid

The account to plan first is your main email, because it resets everything else. Keep its backup codes offline. See the Personal Account Recovery Planning Guide.

When you use a code

Sign in using the backup code option (on Google, "Try another way").
Cross off or delete the code you used: it will not work again.
If you used it because you lost your phone or key, enrol a replacement authenticator straight away, then remove the lost one from the account.
If you are running low, generate a new set and store it; the old codes stop working.

If you think your codes leaked

Sign in and generate a new set immediately, which invalidates the old list on Google and GitHub.
Change the password, because codes are only useful with it.
Sign out other sessions and review recent sign-in activity, connected apps and recovery email and phone.
If the file was on a computer that might have malware, clean or rebuild it before generating new codes there. See the Infostealer Threat Guide.

Backup codes compared with other recovery methods

Codes are one option among several. NIST SP 800-63B encourages subscribers to keep at least two separate means of authentication, and notes that look-up secrets or an additional out-of-band device can be issued for use if the main authenticator is lost, stolen or damaged. The best setup combines two or three of the following.

Method	Phishing-resistant?	Survives losing your phone?	Main risk	Best use
Backup or recovery codes	No: a fake page can ask for one	Yes, if stored away from the phone	Theft of the stored list	Last-resort fallback on every account that offers them
Spare security key or second passkey on another device	Yes	Yes	Losing both devices together	Email, admin and finance accounts
Authenticator app backup or sync	No	Yes, once restored to a new phone	Weak protection of the backup; OWASP notes TOTP seeds may be stored insecurely	Convenience for many low-risk accounts; GitHub lists TOTP app backups among recovery options
SMS to a phone number	No	Only if the number is moved to a new SIM	SIM swap, which OWASP highlights as a reason SMS is weak for recovery	Avoid as the only fallback
Recovery contact (trusted person)	Depends on the service	Yes	Social engineering of the contact	Apple accounts with Advanced Data Protection, as an alternative to a recovery key
Vendor account recovery process	No	Yes, slowly	Weakest link if it accepts easily found facts	Safety net; GitHub's process uses verified devices, SSH keys or tokens and takes up to three business days

A simple recovery kit

For each account that matters (main email, Apple, Google or Microsoft account, password manager, bank, work admin), record on paper: the account name, which authenticators are enrolled, where the backup codes or spare key are kept, and the date the codes were last regenerated. Keep the sheet with the printed codes in a secure place at home, and review it once a year or whenever you change phone. The point is that when a phone is lost or broken, nothing on the recovery path depends on that phone. A password manager's own recovery codes or emergency kit belong on that paper sheet, never inside the manager. Organisations can give staff the same template for work accounts, minus the codes themselves, which should go through the help desk's verified process instead.

How backup codes are abused

Stolen code files: a downloaded code file sitting on disk is collected along with saved passwords by malware, giving an attacker both factors at once.
Codes generated after takeover: an attacker with a hijacked session can often view or generate backup codes, creating a way back in that survives the victim changing their phone. OWASP's MFA guidance is to require reauthentication with an existing factor for changes like this, not just a live session. See the Session Hijacking and Cookie Theft Guide.
Admin-issued codes: in Google Workspace, an admin with User management can get backup codes for a user; a compromised or socially engineered admin can therefore sign in as staff. Restrict that privilege and review its use.
Phished codes: fake sign-in pages ask for "a backup code" as readily as for a one-time password. A backup code is not phishing-resistant.
Help desk pressure: callers claiming to have lost both phone and codes push support staff into weaker resets. See the Account Recovery and Help Desk Security Guide.

For developers: designing recovery codes

Backup codes are what NIST SP 800-63B Rev. 4 calls look-up secrets. Its requirements, and the OWASP Multifactor Authentication Cheat Sheet, give a clear design.

Design point	Requirement or practice	Source
Length and randomness	At least six decimal digits (or equivalent), generated with an approved random bit generator; longer codes (for example 8 to 10 characters, or alphanumeric) add margin	SP 800-63B 3.1.2.1
Single use	Each secret SHALL be used successfully only once	SP 800-63B 3.1.2.2
Storage	Store hashed with an approved hash; codes with under 112 bits of entropy must also be salted with at least a 32-bit salt; never store plaintext	SP 800-63B 3.1.2.2
Rate limiting	Limit failed attempts effectively, as for other authenticators	SP 800-63B 3.1.2.2 and 3.2.2
Issue at enrolment	Offer several single-use codes when the user sets up MFA	OWASP MFA Cheat Sheet
Encourage a second authenticator	SHOULD encourage at least two separate means of authentication so codes are a last resort	SP 800-63B
Regeneration	Generating a new set invalidates every unused code from the old set; require reauthentication with an existing factor first	Google and GitHub behaviour; OWASP
Notification	Notify out of band when a code is used, when codes are viewed or regenerated, and when factors change	OWASP MFA Cheat Sheet
No downgrade	Do not let recovery fall back from a phishing-resistant authenticator to a weaker method unless policy requires it	OWASP MFA Cheat Sheet

Implementation steps

Generate: create 10 to 16 codes with a cryptographically secure generator; show them once with download, print and copy options and a clear warning.
Store: hash each code with a salt; keep a used flag per code; never log codes.
Verify: compare in constant time, mark used on success, and apply the same lockout and rate limits as for other factors.
After use: show remaining count, prompt the user to enrol a replacement factor, and notify them by email or push.
Regenerate: require a fresh MFA check, invalidate the old set atomically, notify.
Test: confirm reuse fails, regenerated sets invalidate old codes, rate limits apply to code entry, and codes never reach logs or analytics.
Roll back: if changing code format, accept old-format codes until users regenerate, rather than invalidating existing codes silently.

Decision guidance

Consumer service: backup codes plus a second authenticator (passkey on another device) is a sound default; avoid SMS-only recovery because of SIM swap risk, which OWASP highlights. See the SIM Swap Fraud Guide.
Workforce identity: prefer two registered phishing-resistant authenticators per person and an identity-verified help desk process; if codes are allowed, restrict who can generate them for others.
High-value accounts (admins, finance): use security key only enforcement where available; Google notes users in "Only security key" mode cannot generate their own backup codes, so plan a spare key per admin instead. See the Admin panels and super admin accounts.
Self-custody options like Apple's recovery key: suit users who accept permanent lockout risk in exchange for removing the vendor's recovery path.

Where identity fits

Shared mailboxes and service accounts sometimes have MFA enrolled by one person, with the backup codes stored in a team wiki so others can sign in. That turns a non-human or shared account into an unattributed one with a static bypass secret. Move these accounts to proper service identities or delegated access, and if a shared account must remain, vault its codes with access logging and rotate them when anyone with access leaves. See the Top 10 MFA Mistakes.

Detection and measurement

Sign-ins by backup code: alert when a backup code is used from a new device or location, especially for admins.
Code generation events: alert on backup code generation or viewing shortly after a password reset or a sign-in from a new location, and on any admin generating codes for another user.
Factor changes: MFA method added or removed within the same session as a backup code sign-in is a takeover pattern.

Metric	Target
Users with at least two registered authenticators	Rising; 100% for admins
Admin-generated backup codes per month, each with a ticket	Low, 100% ticketed
Backup code sign-ins followed by new factor enrolment within 24 hours	High (shows users replace lost factors)
Backup code sign-ins from unfamiliar locations investigated	100%
Help desk MFA resets per 1,000 users	Falling as self-service recovery improves

Common failure patterns

Code file left in Downloads: the default download name makes it easy for malware or anyone with access to find.
No regeneration after suspected exposure: old codes stay valid until a new set is created.
Generating codes with only a session: no reauthentication lets a hijacked session mint persistence.
Broad admin rights to mint codes: every admin with user management can sign in as staff.
Plaintext storage server-side: a database leak exposes every user's MFA bypass.
Codes as the only backup: users lose the paper and phone together; encourage a second authenticator.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-63B Rev. 4	3.1.2 Look-Up Secrets; 3.2.2 Rate Limiting	Code generation, storage, single use, attempt limits
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; IA-2(1) multi-factor authentication to privileged accounts	Issuing and protecting authenticators
NIST CSF 2.0	PR.AA-01 identities and credentials managed; PR.AA-03 users authenticated	Credential lifecycle
MITRE ATT&CK	T1111 Multi-Factor Authentication Interception; T1556.006 Multi-Factor Authentication; T1539 Steal Web Session Cookie	Capturing codes, tampering with MFA settings, session theft that leads to code generation

Practitioner checklist

Store backup codes for email and admin accounts offline, never in the same mailbox or notes they protect.
Delete code files from Downloads and desktops after moving them.
Regenerate codes after any suspected exposure or device infection.
Encourage or require a second authenticator so codes are a last resort.
Require reauthentication with an existing factor before codes are viewed or regenerated.
Hash and salt codes server-side, enforce single use and rate limits.
Notify users out of band on code use, regeneration and factor changes.
Restrict which admins can generate codes for other users and alert on it.
Give admins spare security keys instead of codes where security key only mode is enforced.

MFA backup codes and recovery codes guide: Store, use and design them safely