Where to store your 2FA backup codes

GitHub has just shown you sixteen strings and told you to save them somewhere safe. Google hands over ten. Stripe gives you exactly one, once, and will not show it again. They are all called some variation of backup codes, and the instruction attached to them is always the same unhelpful word: safely.

This page is about the decision you make before anything goes wrong. If the phone is already gone, lost your phone? how to get your authenticator codes back is the page for the day after; come back here once you are back in.

What a backup code set actually is

Almost every argument about where to keep backup codes goes wrong by treating them as another copy of the secret in your authenticator. They are a different kind of credential, and the difference decides everything else.

The secret behind your six-digit codes is a shared seed. The service holds it, your app holds it, and from then on both sides compute the same number from the clock without ever talking to each other. It is never used up, and one seed produces codes forever. TOTP vs HOTP walks through the arithmetic.

A backup code set is the opposite: a short, finite list of one-time secrets. NIST's authenticator taxonomy has a name for them — look-up secrets — and two requirements worth knowing. "A secret from a look-up secret authenticator SHALL be used successfully only once", and they "SHALL be at least six decimal digits (or equivalent) in length". The verifier, meanwhile, "SHALL store look-up secrets in a form that is resistant to offline attacks" (NIST SP 800-63B-4). So the service keeps hashes, the way it keeps your password, and the only readable copy in the world is the one you were handed.

Three things follow, and they are the ones the forum threads on this question never settle:

• Spending a code changes nothing about your authenticator. The TOTP secret is untouched; the app keeps working; the only thing that has happened is that one line on your sheet is now dead.
• A code is a bypass, not a backup. It does not produce a second factor, it replaces one. Whoever holds your password and one unused code is in. That is why the sheet cannot be filed next to the password, and why a readable sheet counts as one of the five ways 2FA gets bypassed rather than as a backup that went wrong.
• The two fail independently. Losing your phone does not touch the sheet; losing the sheet does not touch your phone. Keeping them apart is precisely what makes either one survivable.

The rule that decides where they go

One sentence does most of the work here.

A backup code must not sit anywhere that already holds your password or your authenticator.

Run that against the usual hiding places and most of them disqualify themselves. Not in the password manager entry beside the password for the same account — that is the single-basket problem, argued both ways in should your 2FA codes live in your password manager?, and it is sharpest here, because codes and password together are a complete login. Not as a screenshot in the phone's camera roll, which syncs to the cloud account the codes were meant to protect — the same reasoning that rules out keeping a screenshot of the 2FA QR code, except that the QR is the worse of the two to lose. Not emailed to yourself, since your email is the account most of the others recover through — and if that mailbox is itself guarded by a code in your authenticator, the sheet has been filed inside the ring described in locked out of email and 2FA. Not in a note on the phone that runs the authenticator.

That is one constraint. There is a second, and it pulls the other way: the sheet also has to survive a house fire, a flood, a burglary and the day somebody tidies the desk. A set of codes that is perfectly separated and then burns is not a recovery plan.

Everything below is a way of satisfying both at once.

Where to put them, ranked

1. Paper, somewhere rated for fire and sealed against water. The strongest option, because paper cannot be read remotely, does not need a format to still exist in ten years, and cannot be exfiltrated by malware. The trap is the word fireproof, which means nothing. What means something is a UL 72 class. UL 72, "Tests for Fire Resistance of Record Protection Equipment", rates a box by the maximum temperature its interior reaches during the test: Class 350 is the paper rating, Class 150 adds magnetic tape and photographs, and Class 125 is the one that also covers flexible computer disks (UL 72). So a box rated for documents is not automatically rated for the USB stick lying next to them. Put the printout in a sealed freezer bag before it goes in, because a fire is followed by a hose.

Honest cost: you cannot read it from a hotel room, and if you move house it is one more thing to not leave behind.

2. A second, offline encrypted store. An encrypted file on a dedicated USB stick that is plugged in only when needed, kept in a drawer rather than on the keyring. Stripe's own ranking of storage places puts "a dedicated USB drive, only connected to your computer when needed to minimize exposure to malware" above a password manager, and the reasoning is sound: a drive that is unplugged is not reachable by anything running on your laptop (Stripe).

Honest cost: media and formats rot quietly. An encrypted container you cannot open is the same as no backup, and you will not find out until the worst possible moment. The yearly audit below exists mostly for this.

3. A password manager, with the basket named out loud. This is the option people actually keep up to date, and a current set in an imperfect place beats a perfect set that is three regenerations out of date. Two conditions make it defensible: the codes go in a different entry from the password for that account — Stripe suggests storing them "as a password field, not as plain text" so they are at least masked — and the password manager's own recovery codes never go in it.

Honest cost: an attacker inside your vault has both factors for every account stored that way. For the long tail of accounts where a compromise is an annoyance, that trade is fine. For your primary email, your password manager, anything financial, your domain registrar and your cloud console, it is not.

4. Split across two locations. A copy at home and a copy somewhere else: a relative's house, a desk drawer at work, a safe deposit box. This is the only option that survives the house burning down with the box in it.

Be clear about what splitting does and does not buy. It does not improve secrecy — one unused code is all an attacker needs, so half a sheet in the wrong hands is as bad as a whole one, and every extra copy is another place to be stolen from. What it buys is that losing one location still leaves you with working codes. Because the codes are independent and single-use, you can genuinely cut the sheet in half and keep half in each place; either half still signs you in.

Honest cost: every copy has to be replaced when you regenerate, and the copy you forget is a live credential sitting in someone else's drawer.

What to do the moment you spend one

Four steps, and the third is the one everybody skips.

1. Mark it used. Google's instructions say exactly this: after you sign in with one, "mark the code as used", because the sheet itself will not tell you (Google). Strike it through on the paper, right then, not later.
2. Fix the reason you needed it. A spent code means your normal second factor failed. Phone lost, app wiped, clock wildly wrong, laptop stolen. Get the authenticator working again and re-register it before you close the tab, because the next failure will cost another code. If the app is right there and the digits are simply being refused, work out why the 2FA code stopped working first: most of those causes are fixable in a minute and do not cost a code at all.
3. Count what is left. Two codes remaining is a different situation from nine, and nobody notices the difference until there are none.
4. Regenerate when the set is running low, or when its secrecy is in any doubt. Regenerating issues a fresh set and kills the old one everywhere. That is also the right response to "I think I emailed these to myself in 2019" and "the laptop with the text file was stolen last week". Afterwards the old sheet is waste paper — destroy it, and replace every copy you distributed.

And the most useful sentence on this page for anyone who has just realised they have no codes saved for anything: you do not need the old set to get a new one. You need to be signed in. Nothing about regenerating requires the sheet you lost.

How to regenerate at the services most people have

The shapes differ more than people expect, so check what a service actually issued rather than assuming ten lines on a page.

• GitHub — 16 recovery codes. Settings, then Password and authentication, then Recovery codes, then View, with Download, Print and Copy offered. "Generate new recovery codes" issues a fresh set and "will invalidate any codes you previously generated"; a used code "cannot be reused" (GitHub docs).
• Google — 10 codes, 8 digits each. Google Account, then Security, then 2-Step Verification, then Backup codes; the refresh control creates new ones, and "when you create a new set of codes, the old set automatically becomes inactive". Note the exception: "you can't download backup codes if you're in the Advanced Protection Program" (Google).
• Stripe — one code, shown once when you first turn on two-step authentication, and "it's only displayed once". If it is lost and you can still sign in, generate a new one from the two-step authentication settings, which "will invalidate the old code" (Stripe).
• Cloudflare — a set, under Profile, Authentication, Two-Factor Authentication, Manage, Backup codes, Regenerate. Each code is one-time use, and "regenerating your backup codes will invalidate your previous codes" (Cloudflare docs).
• Microsoft — not a set at all, but a single 25-digit recovery code, generated from the account security page. You cannot retrieve the old one, only create a new one, and "as soon as you create a new recovery code, any previous codes will no longer work". Microsoft also tells you not to keep it on a device you sign in with (Microsoft).
• Apple — no backup codes. A 28-character recovery key instead, and turning it on changes the rules: it switches off Apple's standard account recovery, so the key plus a trusted phone number becomes the way back in, and "if you lose it, Apple can't provide you with your recovery key" (Apple Support).
• AWS — also no backup codes. A root user recovers by verifying the account's email address and primary contact phone number, or through AWS Support; an IAM user has to ask an administrator to deactivate the device. AWS's own advice is to register more than one MFA device instead, up to eight (AWS docs).

Two services on that list give you nothing to file away, which is the point: for Apple and AWS the equivalent of saving codes is registering a second factor in advance. Hardware keys make that concrete, and have their own trade-offs — see authenticator app vs security key.

The once-a-year audit

This is the part nobody does, and it is the part that decides whether any of the above worked. Put a recurring date in the calendar now. Half an hour, once a year.

1. List the accounts worth the trouble. Open your password manager and pull out the ones with 2FA enabled. Email first, then the password manager itself, then money, then your registrar and cloud console, then everything else. 2fa.directory is useful here for spotting accounts that support a second factor you never turned on.
2. Ask one question per account: do I have an unused, current set of codes, and do I know where it is? There are three answers, and "not sure" counts as no.
3. For every no, sign in and generate a set now. This is the step that catches the accounts you enabled 2FA on in a hurry and clicked past the codes screen. It costs a minute each.
4. For the services that issue nothing, register a second factor instead — another authenticator, a security key, a recovery contact — and write down where it is.
5. Actually spend one code, on a low-stakes account, to prove the sheet you are holding is the sheet the service is holding. An untested backup is a belief, not a backup. Then regenerate and refile.
6. Check the storage, not just the codes. Is the printout still legible and still in the box? Does the USB stick still mount? Does the second copy still exist at the other location, and is it the current set or the one from two regenerations ago?

Most of what this catches is not drama. It is a sheet for an email address you stopped using, a set that was regenerated after a phone upgrade and never reprinted, and two accounts that quietly have no codes at all.

Where KeyNesta fits

KeyNesta is a TOTP and HOTP authenticator. It holds the secrets that generate your six-digit codes. It does not hold backup codes, and there is nowhere in it to put them: an entry has a service name, an account, a display name, the secret, the OTP parameters, a space, a group and tags — no notes field and no custom fields, which the features page lists plainly among what is not built. It also has no passkeys and no security keys.

That limitation happens to point the right way. Your backup codes are the thing that gets you in when the authenticator is unavailable, so the authenticator is the one place they must not be.

What KeyNesta does do is make the backup code a rarer emergency. Encrypted backup files and end-to-end encrypted sync mean a lost or replaced phone is a restore rather than a recovery process — that is 2FA backup and sync, and the step-by-step for a device that is already gone is in lost phone recovery. What it cannot do is recover anything for you. The sync server holds ciphertext and no key that opens it, so a forgotten passphrase is not a support ticket; what zero-knowledge costs you is the long version of that trade. The web app at app.keynesta.com needs no sign-up.

Takeaway

Treat a backup code sheet as what it is: a full login in a drawer, with a limited number of uses, that only you have a readable copy of. Keep it off every device that holds your password or your authenticator, keep it somewhere rated for fire and sealed against water, keep a second copy somewhere else so one disaster is not two, and strike each code off the moment you use it. When the sheet runs low, or you lose track of a copy, regenerate — you have never needed the old set to get a new one. Then put a date in the calendar, because the only thing that distinguishes a plan from a pile of paper is having checked it at least once since you made it.