2026-09-27 · 23 min read

Where to store 2FA backup codes: paper, vault, and handoff

Where to store 2FA backup codes: on paper, away from the password they protect. Vendor guidance compared, the circular-dependency trap, and a handoff plan.

Store 2FA backup codes on paper, kept apart from the password they protect — Google's own advice is to print a copy and store it "somewhere safe, like where you keep your passport or other important documents". A password manager is a defensible home for ordinary accounts, but never for the recovery code of the password manager itself or of the email address that resets everything else, because entering a backup code switches the second factor off rather than satisfying it. Keep a second copy in a different building, and make sure one named person knows where it is.

Is a backup code a second factor, or a way around one?#

It is a way around one, and the standards body says so in as many words. NIST SP 800-63B defines this class of credential as a look-up secret — "a physical or electronic record that stores a set of secrets shared between the claimant and the CSP" — and covers it in Sec. 3.1.2 as a "something you have" authenticator. One category, one factor.

Vendors are blunter in their own docs. Bitwarden states that once the recovery code is authenticated, "all previously set up two-step login methods will be deactivated" — the code does not pass the second check, it disconnects it. PyPI says recovery codes "are not a substitute for an authentication application or a security device and should only be used for recovery".

That distinction sets every storage rule below. You are not storing a second factor. You are storing the thing that turns the second factor off.

The mechanics are consistent across providers, and tighter than most people assume. NIST Sec. 3.1.2.2 requires that "a secret from a look-up secret authenticator SHALL be used successfully only once", and look-up secrets "SHALL be at least six decimal digits (or equivalent) in length". Google issues sets of 10 backup codes, 8 digits each, and "after you use a backup code to sign in, that code becomes inactive". GitHub issues 16, and "once you use a recovery code to regain access to your account, it cannot be reused". Microsoft issues a single 25-digit code.

Why does storing the codes beside the password undo 2FA?#

Because whoever holds both holds the account outright — the second check has nothing left to check.

The protection you are giving up is measurable. Microsoft's research on Azure AD accounts found MFA reduced the risk of compromise by 99.22% across the population, and by 98.56% in cases where credentials had already leaked. Microsoft's earlier and more widely quoted framing is that MFA blocks over 99.9% of account compromise attacks.

Read the second number again. MFA's real job is holding the line after the password is already out — credential stuffing, a vault breach, a reused password surfacing in an old dump. A bypass code filed next to that password gives back precisely the 98.56% case.

1Password concedes the underlying mechanic: "you lack a true second factor when both secrets originate from the same device". It still argues the trade is worth taking — its verdict is that "the short answer is that storing your TOTP in 1Password is safe", because the convenience buys consistency. That argument holds reasonably well for a rotating TOTP seed on an ordinary account. It holds much less well for a permanent bypass code on the account that owns every other account.

Where should you store 2FA backup codes? The options compared#

Four axes decide this, and most advice scores only one or two of them. NFPA counted 253,500 one- or two-family home structure fires in the US in 2024, so the fire column is a design constraint rather than a hypothetical.

Where you put them	Reachable when your phone is gone	Survives a house fire	Survives a laptop theft	Works if you go silent
Password manager entry, separate from that account's login	Yes, from any device you can sign in on	Yes — the vault is not in the building	Yes, if the master password is not on the laptop	Only with emergency access configured in advance
Screenshot in the camera roll	Yes	Yes	Yes	No — nobody else can search your gallery
Downloaded file left in Downloads	Only on that machine	No	No — enterprise tooling treats plaintext recovery codes on disk as a finding to remediate	No
Printed sheet in a desk drawer	Yes, at home	No — paper chars around 387°F and burns at 451°F	Yes	Yes, if someone knows the drawer
Printed sheet in a UL Class 350 fire safe	Yes, at home, with the combination	Yes — Class 350 keeps the interior below 350°F while the test furnace runs at 1,700–1,850°F	Yes	Only if the combination is handed over too
Printed sheet in a bank safe deposit box	Slowly, in banking hours	Yes	Yes	Only with access arranged in advance; the FDIC notes contents are not covered by deposit insurance
Half the sheet at home, half off-site	Yes, from either half	Yes — one fire cannot reach both	Yes	Yes, if both locations are documented
A sealed copy with a trusted person	Yes, by asking	Yes	Yes	Yes — Apple suggests giving a copy to a trusted family member
Offline flash drive in a drawer	Needs a working computer	No	Yes	Rarely — community advice favours keeping it disconnected, but it inherits every drawer problem

Those four columns score availability, not exposure, which is why the camera-roll row looks healthy here and gets disqualified two sections down by malware that reads your gallery. Read the table for "can I still get in", then apply the exposure rules separately.

No single row scores four out of four. That is the actual finding: one location is always a bet on which failure arrives first. Two locations of different kinds — one paper, one vault, or one at home, one off-site — is the smallest setup without an obvious hole.

What do Google, GitHub, Microsoft and Apple actually tell you to do?#

They contradict each other, openly, which is why generic articles on this topic manage to sound confident and vague at the same time.

Provider	What it issues	Where it says to keep it
Google	10 codes, 8 digits each	Physical: print a copy and store it "somewhere safe, like where you keep your passport or other important documents"
GitHub	16 recovery codes	Digital: "We recommend saving them with a secure password manager"
Microsoft	one 25-digit code	The opposite of GitHub: "Print the recovery code and keep it in a safe place. For security, do not store the code on a device used to sign in to your account."
Apple	a recovery key	Named exclusions: "Don't store your recovery key in your Apple Passwords app, iCloud Photos, Notes, or iCloud Drive"
Bitwarden	one recovery code	"A printed copy kept in a safe place is a good option, because it prevents digital theft and accidental deletion."
PyPI	recovery codes	Both: "Consider printing them out and storing them in a safe location or saving them in a password manager"
1Password (Emergency Kit)	a printed kit	A fire-resistant safe, a locked drawer, a safe deposit box, attached to your will, or with a spouse or family member

The disagreement is not sloppiness. GitHub is optimising for a developer who would otherwise lose the codes entirely. Microsoft is optimising against the case where the device you sign in from is the device that gets compromised. Apple is optimising against the circular dependency below. Each is right about its own threat model, which is why the answer depends on which account the codes belong to, not on picking a favourite vendor.

One rule survives all of them. Google warns: "Do not share your backup codes with anyone. Google never asks for a backup code other than at sign in". Any request for a code outside a live login screen is a phishing attempt, with no exceptions worth debating.

What is the circular-dependency trap?#

Storing the recovery credential inside the system it is meant to recover. When that system is the one that has locked you out, the credential is inside the locked room.

Apple names it outright: don't store the recovery key in the Apple Passwords app, iCloud Photos, Notes, or iCloud Drive — all of which are reached through the very account the key exists to recover. The same shape recurs everywhere:

The password manager's own recovery code saved inside the password manager.
Google backup codes left in a Gmail draft, reachable only by signing in to Gmail.
An Apple recovery key in iCloud Drive, reachable only with the Apple Account it unlocks.
Every code in one vault, with that vault's own master password written nowhere.

Test any storage location with one question: if this account is the one I am locked out of, can I still reach this? If the answer is no, it is not a backup. It is a copy.

Can I store backup codes in my password manager?#

For most accounts, yes, with two conditions. Keep the codes in a separate item from that account's password, so a shoulder-surfed or shared login does not expose both. And accept that the vault is now a single point of failure worth one non-digital copy.

For two accounts, no.

Your password manager's own recovery code. Bitwarden's recovery code deactivates every two-step login method on the account at once, and it is worthless to you if it lives behind the login it repairs. Bitwarden's own instruction is to save it as soon as you enable two-step login, and it calls a printed copy in a safe place a good option. 1Password makes the matching point about its Emergency Kit: writing your account password onto the printed kit "is an added vulnerability if someone gets hold of the document" — a recovery document should carry recovery material, not the daily credential.

The email address that resets everything else. Your primary inbox is the reset path for most of your other accounts, so a lockout there cascades. Google's advice for that account is explicitly physical, and accounts in Google's Advanced Protection Program cannot download backup codes at all.

The community position is genuinely split rather than settled — forum discussion runs from "a password manager is definitely not a bad option" to keeping the codes on a flash drive "disconnected from the rest of the network", with separation of concerns as the argument for keeping 2FA material out of the vault. The split is real, but nearly all of it is a disagreement about ordinary accounts. Almost nobody argues for the vault's own code living in the vault.

Should you print them, and where does the paper go?#

Paper is a legitimate medium here, not a fallback. The UK's NCSC accepts that some people write passwords down in a journal or dedicated password book, and says this "can suit certain scenarios". It attaches the honest caveat: anyone with access "will be able to remember them or make a copy, possibly without your knowledge", and simply hiding the paper is not enough if people can get into the room.

Two practical constraints most articles skip.

A cash box is not a fire safe. UL Class 350 is the rating that matters for paper: contents must stay under 350°F while the test furnace runs at 1,700–1,850°F, because paper chars at around 387°F and burns at 451°F. A gun safe or lockbox without that rating protects the paper from people, not from heat.
Some banking terms forbid writing credentials down. NCSC warns you may be breaking the terms and conditions of the service, naming online banking services that forbid users to write down their passwords. Worth checking before you print the bank's codes.

If you use a bank's safe deposit box, price in what it is not. The FDIC states a safe deposit box "is not a deposit account", so the contents, "including cash, checks or other valuables, are not insured by FDIC deposit insurance if damaged or stolen" — cover comes only from a rider on a homeowner's or renter's policy. 1Password lists the box as a valid option while flagging the "added risk of tampering or theft".

Delivery matters as much as storage. NIST requires look-up secrets be delivered securely — in person, in an authenticated session at AAL2 or higher, or by postal mail — and stored by the verifier in hashed form, and its implementation resources note that backup look-up secrets "would normally be stored in a locked container on the subscriber's premises", and that "non-secure mechanisms such as email are unsuitable for the distribution of look-up secrets". Emailing yourself the codes fails the standard before it reaches your inbox.

Is a screenshot in the camera roll safe?#

No, and this is a documented live threat rather than a theoretical one.

Kaspersky found the SparkCat Trojan active in both the App Store and Google Play since at least March 2024, using machine learning to scan image galleries for screenshots of cryptocurrency wallet recovery phrases, and also able to find other sensitive data in images, such as passwords. It was the first known OCR-based stealer to reach the App Store; downloads from Google Play alone exceeded 242,000 across 10 apps, with 11 more found on the App Store. The technique did not retire after disclosure — on 2 April 2026 Kaspersky reported a new variant in both stores, with the iOS version scanning photo libraries for English-language wallet mnemonic phrases and sending any matching image to the attackers.

A camera roll is a searchable, cloud-synced, third-party-readable folder, and an app only needs the photo permission you already grant without thinking. Apple's exclusion list names iCloud Photos for exactly this reason. If codes are already in yours, delete them, empty the recently-deleted album, and regenerate the set — treat the old ones as read.

Can you split the sheet across two locations?#

Yes, and this is where backup codes behave differently from most other secrets you store.

A set of backup codes is a list of independently valid, single-use secrets. Google issues 10 codes and each one works on its own, so a 10-code sheet can be cut into two sheets of 5 with no loss of function: either half still signs you in five times. You get geographic redundancy for free, and you halve what any one location exposes.

That property does not transfer. A seed phrase is a single secret whose words are useless in part and complete in whole, so splitting it naively destroys the backup — the reasoning behind where to store a seed phrase does not carry over here, and advice written for one gets misapplied to the other constantly. Backup codes split cleanly. Seed phrases need a scheme.

The trade-off, stated plainly: two locations means two places where someone could read five valid codes. Split for disaster resilience, not for secrecy.

What happens if you lose your backup codes?#

It depends entirely on the provider, and the range runs from trivial to terminal.

Recoverable while you are still signed in. Google lets you revoke a lost set and get new ones from the 2-Step Verification section — "Show codes", then "Get new codes", and creating a new set automatically makes the old set inactive. GitHub likewise lets you generate another list once all 16 are used.
Not retrievable, only replaceable. Microsoft states you cannot retrieve or download an existing recovery code — you can only create a new one, and "as soon as you create a new recovery code, any previous codes will no longer work".
Permanent. GitHub states flatly: "GitHub Support will not be able to restore access to accounts with two-factor authentication enabled if you lose your two-factor authentication credentials" — the only remaining move is unlinking the email address so it can be attached to another account. Apple is equally final: "If you lose it, Apple can't provide you with your recovery key".

The number of people hitting this is visible in public. PyPI tells users who have lost every two-factor method and hold no recovery codes to file an issue on its tracker to request help with account recovery, and warns that you may permanently lose access to your account. GitHub's own recovery documentation names the habit behind it: "You may have saved your recovery codes to a password manager or your computer's downloads folder" — and enterprise security tooling ships checks specifically to detect plaintext recovery codes sitting on disk, which tells you the downloaded-and-forgotten file is the default outcome, not an edge case.

Who can get in if you go unreachable?#

Storage answers where. It does not answer who reaches it when you are in hospital, somewhere without signal, or simply out of contact for weeks while a client, a domain renewal or a payroll run waits.

Three vendor mechanisms cover parts of this, and each covers a different part.

Bitwarden Emergency Access covers the vault. You nominate a trusted contact with either View access — read access to all items in your individual vault, including passwords and attachments — or Takeover access, which has them set a new master password and removes any two-step login methods previously set up, after a wait time you choose. The setup is not casual: the contact must have their own Bitwarden account on the same server geography, the invitation is valid for only five days, and you must then confirm them by verifying their fingerprint phrase. The difference between Bitwarden's View and Takeover access decides whether your contact reads the vault or repossesses it, so pick deliberately — and arrange and verify it in advance, or it does not exist.
Google Inactive Account Manager covers silence rather than any specific event. You choose an inactivity period of 3, 6, 12 or 18 months, after which Google notifies the contacts you nominated and can share the data categories you chose.
Apple Legacy Contact is narrower than most people assume. It gives a nominated person access to your Apple Account data after your death, and needs iOS 15.2, iPadOS 15.2 or macOS Monterey 12.1 or later to set up. Apple's security documentation adds the limit that matters here: the beneficiary's keys do not "encompass the information necessary to decrypt the decedent's iCloud Keychain" — so saved passwords and passkeys do not travel with it, and none of it helps in the far more common case of being temporarily out of reach.
A human copy. Apple's plainest advice is to keep a copy of the key in a safe place, consider storing it in more than one place, and consider giving a copy to a trusted family member; 1Password lists attaching the kit to your will or leaving it with a spouse or family member among its storage options.

Notice the gap they leave. Every one of them is per-provider, and none of them says what to do — which client is mid-project, which domain renews next month, which invoice is unsent. Proceedly's check-in and handoff plan covers that layer: you answer a check-in on a schedule, and missing it past a grace window means a person you name confirms — or, on a paid plan, it releases automatically — before your encrypted handoff plan reaches the people who depend on you. It holds your instructions and says where the codes live. The codes and passwords themselves stay where you put them.

How do you stop the set going stale?#

A stale printout is worse than no printout, because you will plan around it and find out it is dead at the exact moment you need it. Google states: "When you create a new set of codes, the old set automatically becomes inactive". GitHub: "Generating a new set of recovery codes will invalidate any codes you previously generated". Microsoft: any previous code stops working the moment you create a new one.

Run this once, then twice a year:

Write the generation date on the sheet itself, or in the vault item's notes.
Cross off each code the moment you use it — they are single-use at Google, GitHub and PyPI.
Regenerate when fewer than three codes remain unused, and destroy every old copy the same day.
After any regeneration, update both locations. The second copy is the one people forget, and the one they will reach for.
Keep a plain list of which accounts have codes and where each copy lives. Not the codes. The map.
Confirm your emergency contact or handoff arrangement still points at the right person and the right place.
Know which of your second factors would survive losing the phone in the first place — what happens if you lose your phone with 2FA sorts them.
Re-read the map as a stranger would. If it says "the usual drawer", it fails.

What does a defensible default look like?#

Tier the accounts first, because treating a forum login like your inbox is how people end up with no system at all.

Tier 1 — the accounts that reset the others: primary email, password manager, phone carrier, domain registrar.

Printed, and never stored on a device you sign in from — Microsoft's rule.
Two copies, two buildings. Split the sheet when the provider issues several codes.
One copy in a UL Class 350 rated safe, not a generic lockbox.
Never inside the system it unlocks — Apple's rule.
One named person knows the location and can reach it.

Tier 2 — valuable but not load-bearing: GitHub, cloud storage, work SaaS, social accounts.

A password manager entry is fine — GitHub recommends exactly this.
A separate item from the account's password, not a note appended to the login.
One paper copy of the Tier 2 list stored with the Tier 1 paper, for the vault-is-gone case.

Tier 3 — everything else. Vault entry, no paper. Accept that recovery may mean re-registering, and stop spending attention on it.

Then delete the failures: screenshots in the camera roll, files in Downloads, codes emailed to yourself, codes in a notes app that syncs to the account they protect. Regenerate anything that was stored that way.

FAQ#

Are backup codes and recovery codes the same thing? Functionally yes, and the naming is inconsistent across vendors. Google calls them backup codes and issues 10, GitHub calls them recovery codes and issues 16, Microsoft issues one 25-digit recovery code. NIST puts them all in one category: look-up secrets.

Can I keep backup codes in the same password manager entry as the password? You can, and it collapses your two factors into one for that account. Use a separate item at minimum, and keep Tier 1 codes out of the vault entirely — Bitwarden's recovery code deactivates every two-step method on the account, which is not something to leave sitting next to the login.

Is a screenshot really that risky? Yes. OCR-based gallery-scanning malware shipped in both the App Store and Google Play, with Google Play downloads alone exceeding 242,000, and a new variant was reported on 2 April 2026.

What if my account is in Google's Advanced Protection Program? You can't download backup codes at all, so the storage question becomes a question about your physical security keys instead — with the same two-locations logic.

Someone asked me for a backup code over chat. Is that ever legitimate? No. Google states it never asks for a backup code other than at sign in. Treat any request outside a login screen as phishing.

Can support restore my account if I lose both the device and the codes? Often not. GitHub Support will not be able to restore access to accounts with 2FA enabled if you lose your two-factor credentials, and Apple cannot provide a lost recovery key. PyPI accepts account-recovery requests on its tracker but warns you may permanently lose access.

How do I let someone else in without handing them my codes now? Use the mechanisms built for it: Bitwarden Emergency Access with a chosen wait time, Google's Inactive Account Manager with a 3-, 6-, 12- or 18-month inactivity period, or a sealed copy with a trusted person as Apple suggests. All of them have to be set up and confirmed before you need them.

Should I store a crypto wallet backup the same way? A wallet has no backup codes — it has a seed phrase, and the rules differ because the seed is one indivisible secret rather than a list of one-use ones. See where to store a seed phrase for that case.