Beyond the password · 5 min read

Recovery codes and backups: how they work

Recovery codes are one-time secrets for when your usual login fails. Here is how they are generated, how strong they need to be, and where they fit.

When you turn on two-factor authentication, many sites hand you a short list of codes and suggest you print them or store them somewhere safe. These are recovery codes, sometimes called backup codes. Each one is a single-use way in for the day your phone is lost, your security key is broken, or your authenticator app was not backed up.

They look trivial. They are worth understanding, because the recovery path is often the weakest way into an account.

What NIST calls them

NIST SP 800-63B-4 describes two related things.

A look-up secret is “a physical or electronic record that stores a set of secrets shared between the claimant and the CSP” (the credential service provider, the site). It is an authenticator in its own right, “something you have,” and NIST names the typical use: “one-time saved recovery codes … that the subscriber stores for use if another authenticator is lost or malfunctions.”

A saved recovery code is NIST’s term in its account recovery section for a code issued at enrollment and kept offline for later.

The main requirements, quoted:

• Generation: the site “SHALL use an approved random bit generator … to generate the list of secrets.”
• Length of a look-up secret: “Look-up secrets SHALL be at least six decimal digits (or equivalent) in length.”
• Length of a saved recovery code: “The recovery code SHALL include at least 64 bits from an approved random bit generator.”
• One use only: “A secret from a look-up secret authenticator SHALL be used successfully only once.” For saved recovery codes, after one is used the site “SHALL invalidate that recovery code and SHALL issue a new saved recovery code.”
• Storage: look-up secrets “SHALL be stored in a hashed form using an approved hashing function.” Ones shorter than 112 bits “SHALL be stored in a salted and hashed form using a suitable password hashing scheme.”
• Guessing limits: the verifier “SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts.”

NIST also says plainly: “Look-up secrets are not phishing-resistant.” A code typed into a fake page can be passed to the real one, just like any other typed code.

Worked example: how long is 64 bits?

A code is just a random number written in some alphabet. The number of characters needed to carry at least 64 bits depends on how many bits each character holds:

The digit row: 64 / 3.322 = 19.27, so 19 digits fall just short and 20 are needed. That is why a code meeting NIST’s saved-recovery-code rule tends to look long, often split into groups for readability.

Now compare the six-digit minimum for a look-up secret: 10^6 possible values, 19.93 bits. Online, with rate limiting at NIST’s ceiling of 100 consecutive failures, a blind guesser’s chance is 100 in 1,000,000, or 1 in 10,000. Offline it is a different story. If a site’s database leaked and six-digit codes had been stored with a fast hash, an attacker at 10^11 guesses per second would try all of them in about 10 microseconds. Even with a slow hash at 10,000 guesses per second, the whole space takes 100 seconds. That is why NIST requires short look-up secrets to be salted and hashed like passwords, and why a short code only works where an online limit stands in front of it.

Codes sent to you versus codes you keep

NIST separates saved recovery codes, which you keep, from issued recovery codes, which the site sends to an address you registered when you need them. Issued codes need only “at least six decimal digits (or equivalent),” and they are short-lived. NIST sets maximum lifetimes: “10 minutes when sent via text message or voice,” “24 hours when sent to an email address,” and 21 or 30 days by post depending on destination.

A forgotten password is a separate case. NIST notes that replacing a forgotten password while you can still sign in with another authenticator counts as binding a new authenticator, not account recovery.

Where to keep them

Recovery codes exist to survive the loss of your usual devices, so where they are stored decides whether they work when needed. There are trade-offs rather than one right answer:

• On paper, stored somewhere private. Immune to device loss and remote attack. Can be lost, damaged, or found by someone with physical access. NIST’s own description is that saved codes “are intended to be maintained offline (e.g., printed or written down) and stored securely.”
• In a password manager. Convenient and encrypted. But if the manager is the thing you lost access to, the codes are inside it. Keeping the recovery codes for the manager’s own account in the same manager defeats their purpose.
• In an encrypted file or a second device. Works if that file or device does not share a failure with the first one.

Whatever the location, the codes are as sensitive as a password plus a second factor combined. Anyone holding one can typically sign in without your phone.

Related backup paths

• More than one authenticator. Registering a second security key or passkey on another device is a backup that does not rely on a list of codes at all. See passkeys explained.
• Exporting an authenticator app’s secret. NIST allows a TOTP secret to be moved to a new device or stored in a qualifying sync service. See how authenticator apps work.
• Security questions. Some sites still use them as a recovery step. NIST’s position and the research on why they are weak are covered in security questions.

Using a code

When a recovery code is used, the site should treat it as consumed and, under NIST’s rules for saved recovery codes, give you a new one. NIST also says “an account recovery event always causes one or more notifications to be sent to the subscriber,” so that a recovery you did not make does not go unnoticed. After a recovery it is common for a site to ask you to set up a new second factor, since the old one is presumably gone.

For how recovery fits into the wider picture of second factors, see two-factor authentication explained.

General explanation, not advice for a particular situation. Updated 2026-10-31.