Recovery codes: the spare key you only get to see once

You switched on two-factor authentication, the service congratulated you, and then it showed you ten random codes and asked you to save them somewhere safe. Most people's somewhere safe is a screenshot that syncs to the same cloud the codes are meant to rescue, a text file on the desktop, or "I'll do that later." Later stays the plan until the phone goes into a lake.

This post is about those 2FA backup codes: what they are, why you only get one good look at them, where to keep them, and when to spend them. The everyday factor they back up — those rotating six-digit codes — is covered in what TOTP is; recovery codes are the static cousins that sit in a drawer for years until, one bad afternoon, they are all that stands between you and a support form.

What a recovery code actually is

A recovery code — Google calls its version backup codes, and the names are interchangeable — is a static, single-use code a service generates when you enroll a second factor, or later from its security settings. Each one works exactly once, typed in place of your rotating code at the login prompt, alongside your password. It is a spare key for the day the front door eats your keys.

The set is finite and service-generated. Google famously issues ten; other services typically hand out eight to twelve, and the count matters less than the two properties every set shares. Single-use: a spent code is dead forever. Static: unlike a TOTP, which is born and dead inside about a minute, a recovery code stays valid for years until you spend it. That shelf life is the whole trade-off — a superb emergency exit, a terrible daily factor — and it makes storage the entire game, because a static secret is exactly as safe as the place you keep it.

The one-look problem

Many services show the full set exactly once, at enrollment, in a dialog you can dismiss. Miss it and the codes are not retrievable — only replaceable: security settings usually offer a regenerate option, and regenerating typically invalidates the previous set. A set you never saved was never an asset; regenerating is how you convert a missed dialog into an actual backup.

Enrollment is the one moment a service has your undivided attention, and the one-look design bets on the sensible thing happening while the tab is open. Google is friendlier — its codes stay viewable and regenerable any time from your account's security settings, a path the Gmail 2FA setup guide walks through and support.google.com documents — but the industry default is one look. Treat every service that way: stop and save when the dialog appears. Thirty seconds now, or a support queue later.

Where to keep them (and where not to)

Ranked, honestly:

1. A password manager. Searchable, encrypted, immune to every phone you will ever lose, and findable at 2 a.m. because search beats rummaging. A secure note per account works; the options are compared in our best free password manager roundup. One caveat: the manager becomes a single point of failure, so protect its own account accordingly.
2. Paper, printed, dated, somewhere physically safe. Paper needs no battery, no operating system, no vendor that stays in business. Its failure modes are fire, flood, and the absence of Ctrl+F. Print the set rather than photographing it — photos land in camera rolls that sync somewhere.
3. Genuinely encrypted storage. An encrypted note in a zero-knowledge vault, or an encrypted volume you own. The operative word is genuinely: a password-protected document is not encryption, and the difference is the point.

Where not to keep them is one principle: never store rescue codes somewhere less protected than the account they rescue. That rules out screenshots synced to the same cloud as your email, plain text files on the desktop, photos in the camera roll, and notes in the drafts folder of the account the codes unlock. If an attacker can reach your codes more easily than your second factor, the codes are not a backup — they are a downgrade.

The ladder back in

There is an order to getting back in, worth knowing before you stand at the bottom of it. Rung one: the original factor still works. Verify that first — rejected codes are usually not lost codes, but clock drift, a wrong entry, or a rotated secret; the 2FA troubleshooting guide covers that diagnostic. Rung two: a second registered method — a hardware key, the authenticator on a tablet, a backup email. Rung three: the recovery codes — their moment. Rung four: formal account recovery — identity proof and timelines measured in days.

The codes exist precisely so you almost never climb to rung four. Rung four is slow on purpose: recovery flows are the side door attackers favor, so services make them expensive, and the friction is aimed at whoever is pretending to be you. Backup codes are the fast lane for the legitimate owner. That is the deal: store ten static secrets properly, and you never have to prove your identity to a form.

How each service does it

Google issues its ten as a downloadable text file, viewable and regenerable at any time; regenerating kills the old set. Microsoft takes a different shape: a single recovery code, not a set, shown when you turn on two-step verification — one bullet instead of ten. GitHub and Discord both hand over their sets as a downloadable text file at enrollment; support.discord.com covers Discord's version.

Steam is the one that confuses everyone, because its R-code is not a sign-in code at all. It is a revocation code: its single job is proving to Steam Support that you own the account when Steam Guard needs removing — say, because the phone carrying it has gone missing. You cannot type it into a login prompt; it will not work there and was never meant to. Different mechanism, same lesson: save it at enrollment — the day you need it is a bad day to discover you never wrote it down. help.steampowered.com has the details.

At the weak end sit services that email you codes as a fallback — the weakest form, because your inbox is already the password-reset channel for most of your accounts. When your backup factor and your reset channel are the same folder, your 2FA collapses to your email account's security.

Rotation hygiene

A few habits keep a set healthy across the years in the drawer. Treat a spent code as spent forever — services reject reuse, and retrying a burned code is a classic lockout story. Date your printouts, so you can tell a current set from a half-spent predecessor. Regenerate after heavy use or any suspicion of exposure — a screenshot that went astray, a shared file, a printed card seen by the wrong person. Regenerating typically invalidates the old set wholesale, which is how you retire a set you no longer trust.

Codes versus a second factor

A set of recovery codes is static and finite: ten emergencies, then done until you regenerate. A second registered method — a hardware key, the authenticator on a second device, a printed TOTP seed — is renewable: it keeps producing proof of identity for as long as the account stands. Backup codes versus an authenticator is not really a contest; they are different tools for different days. The best setup is both: a second method for resilience, codes for the true emergency.

A zero-knowledge vault is one legitimate home for both kinds of secret, codes and TOTP seeds alike. In 2FA by DependsiT's vault, everything is encrypted in your browser before upload — salted PBKDF2 key derivation, HKDF key separation, AES-256-GCM, the server storing ciphertext it cannot read — so the codes are reachable from any machine without trusting the storage. If that is the drawer you have been missing, create a free account.

The enrollment dialog appears for thirty seconds; the codes it shows stay valid for years. That asymmetry is the whole subject: one minute of attention now, or support queues later. If the authenticator is already lost and the codes were never saved, the next post — the lost-phone playbook — is the one you want.

Frequently asked questions

What is a two factor recovery code?

A single-use, static code, generated when you enable 2FA or later from security settings, that works in place of your rotating code at login, alongside your password. Services issue a set, typically eight to twelve codes; Google's ten is the best-known example. Each works exactly once and the set stays valid for years — an emergency fallback, not a daily factor.

Where do I find my Google backup codes?

Sign in to your Google account, open Security, then 2-Step Verification: the backup codes are listed there, viewable and regenerable any time — friendlier than services that show the set only once. If you never saved them, generate a fresh set now and store it somewhere better than a screenshot. Regenerating invalidates the previous set.

Can I use the same backup code twice?

No. Each recovery code is single-use: once accepted, it is spent forever, and typing it again gets it rejected. If a code is refused and you are sure it was never used, suspect a typo or lookalike character first, then suspect you used it and forgot. Sign back in with the next unused code, and regenerate a fresh set once you are inside.

Are backup codes as safe as an authenticator app?

They are different tools. An authenticator's codes rotate every thirty seconds, so an intercepted one is dead within a minute; a backup code is static and valid for years, so a leaked one stays live until spent. For daily logins, the app wins. For the day the app is gone, the codes win by existing. Keep both, and protect the codes like a password.

What happens if I lose my recovery codes and my phone?

You land in each service's formal account recovery: identity verification, ownership proof, and days-long waits. Check first whether you are still signed in anywhere — a live session can often add a new second factor — and whether a second method was registered. If neither exists, the recovery form is the remaining road, and the lost-phone playbook walks it service by service.