Category: Multi-Factor Methods

Recovery Code

Also known as: Backup Code, Recovery Key

Simply put

A recovery code is a backup credential that lets you regain access to an account when your usual sign-in method is unavailable, such as when you forget your password or cannot complete multifactor authentication. It is typically issued in advance and stored safely so it can be used if you lose access to your phone or other authentication device. Because it can bypass a normal login step, it should be protected as carefully as a password.

Formal definition

A recovery code is a pre-issued backup credential used to restore account access when a primary authentication factor or MFA method is unavailable. In common deployments it functions as a possession-style secret that either substitutes for a lost factor or, depending on the provider, is used alongside other trusted elements (for example a trusted phone number and device) to complete account recovery. Implementations vary: some are single-use codes consumed on redemption (as in one-time backup codes), while others are longer fixed-format keys (for example a 25-character or 28-character code in specific vendor implementations). Because a recovery code can bypass a normal authentication factor, it should be treated as a high-value secret and stored securely; the exact recovery flow, format, and reuse behavior are provider- and configuration-dependent.

Why it matters

Recovery codes address a fundamental fragility in modern authentication: when a primary factor is lost or unavailable, a forgotten password, a lost phone, a changed phone number, or an inaccessible authenticator app, the user risks being permanently locked out of their account. By issuing a backup credential in advance, providers give account holders a path back in without depending solely on a device or channel they may no longer control. This is why services such as Google offer backup codes for use when a phone cannot receive codes by text, call, or authenticator app.

The same property that makes recovery codes useful also makes them dangerous. Because a recovery code can bypass a normal authentication factor, anyone who obtains it can potentially complete a recovery flow and take over the account. This inverts the usual security benefit of MFA: the recovery path becomes an alternative attack surface if the code is stored insecurely, screenshotted, emailed to oneself, or otherwise exposed. For this reason the code should be treated as a high-value secret and protected as carefully as a password.

In machine and non-human identity (NHI) contexts, this concern is amplified. As noted in NHI security guidance, a recovery code that bypasses a primary factor must be handled as a secret and subject to the same protection and hygiene expectations applied to other credentials, rather than being left in plaintext or shared across systems.

Who it's relevant to

IAM Engineers and Identity Architects

Those designing account recovery flows must decide how recovery codes are generated, whether they are single-use or reusable, and whether the code alone suffices or must be combined with other trusted elements such as a trusted device or phone number. Because these choices define an alternative path around normal authentication factors, they directly shape the recovery attack surface and warrant the same scrutiny as the primary login flow.

System Administrators and Help Desk Teams

Administrators supporting users who are locked out, after a forgotten password, lost phone, or changed phone number, need to understand how recovery codes fit each provider's flow, since format and behavior vary. They also need clear guidance for users on storing codes securely, given that a recovery code can bypass an authentication step and should be protected like a password.

Non-Human Identity and Secrets Management Practitioners

In NHI and machine-identity contexts, recovery codes are secrets that bypass a primary factor and should be managed accordingly, protected, not stored in plaintext, and not casually shared, consistent with the hygiene applied to other high-value credentials.

Security and Compliance Leads

Those responsible for credential hygiene and access assurance should account for recovery codes as a distinct, high-value credential type whose exposure can enable account takeover. Policies for issuing, storing, and, where supported, rotating or invalidating recovery codes help ensure the recovery path does not become an unmonitored weak point.

Inside Recovery Code

Backup credential

A recovery code is a single- or limited-use secret that serves as an alternative authentication factor, typically used when a user's primary factor (such as an authenticator app or security key) is unavailable. It functions as a knowledge/possession-adjacent fallback rather than a routine login method.

Pre-generated code set

In most deployments, recovery codes are issued as a batch of codes at enrollment (for example when MFA is first configured), with each code intended for one-time consumption. Once used, a code is typically invalidated so it cannot be replayed.

Association with an identity and factor context

Each recovery code set is bound to a specific user account and generally tied to the account's MFA or step-up authentication configuration. It participates in the authentication step (verifying who the principal is) and does not by itself grant authorization or define what the principal may do.

Storage and validation representation

Depending on configuration, the authoritative system typically stores recovery codes in a hashed or otherwise protected form rather than in plaintext, validating a presented code against that stored representation. The exact storage and hashing approach varies by vendor and deployment.

Common questions

Answers to the questions practitioners most commonly ask about Recovery Code.

Are recovery codes a form of multi-factor authentication?

Not in the way MFA is typically intended. A recovery code is generally a single knowledge-factor-like secret used as a fallback when a primary factor (such as a possession-based authenticator) is unavailable. Because it usually stands in for another factor rather than adding an independent one at the moment of use, presenting a recovery code often reduces an authentication flow to a single factor. In most deployments it is best understood as an account recovery mechanism, not as an MFA factor in its own right.

Is a recovery code the same thing as a backup of my authenticator, like a spare TOTP seed?

No. A recovery code is typically a pre-generated, often one-time-use string that lets a user regain access when their normal authenticator is lost, whereas a TOTP seed is the shared secret that continuously derives time-based codes. Restoring a TOTP seed reconstitutes the original possession factor, while consuming a recovery code generally bypasses that factor for a single authentication event. They serve related goals but are distinct constructs with different security properties and lifecycles.

How should recovery codes be stored on the server side?

Because recovery codes function as high-value secrets, most implementations store only a hashed representation using a suitable password-hashing approach rather than the plaintext, so that a database compromise does not directly expose usable codes. Whether each code is individually hashed and marked as consumed depends on the design. As with any credential store, the specifics vary by vendor and deployment, and treating recovery codes with the same protection as primary credentials is the common practice.

Should recovery codes be single-use, and how are they typically invalidated?

In most deployments recovery codes are single-use: once a code is redeemed it is marked consumed so it cannot be replayed. Many systems also invalidate and regenerate the entire set when a user requests new codes, changes primary factors, or completes a recovery event. The exact invalidation behavior, per-code versus whole-batch, depends on configuration and the identity platform in use.

How many recovery codes should be issued and when should users regenerate them?

There is no universal number; implementations commonly issue a small fixed batch and let users regenerate the set on demand. Regeneration is typically prompted after codes are used, when the count runs low, or as part of periodic security hygiene. Because behavior varies by vendor and profile, the appropriate count and regeneration cadence should be driven by your account recovery policy and risk tolerance rather than a fixed rule.

How does using a recovery code interact with step-up authentication and audit logging?

Since redeeming a recovery code often reduces assurance to effectively one factor, some deployments treat a recovery-code login as a lower-assurance event and require step-up authentication before granting access to sensitive operations, depending on configuration. From a governance standpoint, recovery-code redemption is typically a security-relevant event worth capturing in audit logs and, in many environments, surfacing through alerting, so that recovery flows remain observable and reviewable.

Common misconceptions

A recovery code is a form of multi-factor authentication in itself.

A recovery code is a fallback factor used when a primary factor is unavailable; presenting it typically substitutes for the missing factor rather than adding an independent one. Depending on the deployment, use of a recovery code may reduce the overall assurance of the authentication event, so it is not equivalent to standard MFA.

Recovery codes are interchangeable with passwordless mechanisms like passkeys or WebAuthn.

Recovery codes are shared-secret style codes that the user must retain, and they are distinct from FIDO2/WebAuthn passkeys, which are public-key credentials bound to authenticators. A recovery code is a break-glass fallback, not a phishing-resistant possession factor.

Recovery codes handle account recovery and authorization decisions.

Recovery codes operate within the authentication step to re-establish access when a primary factor is lost. They do not determine what resources the principal may access; authorization remains a separate step governed by the access control model in effect.

Best practices

Present recovery codes to the user only once at generation time and require secure offline storage, since the authoritative system typically retains only a hashed representation and cannot redisplay them.

Enforce single-use consumption by invalidating each code after it is redeemed, and provide a mechanism to regenerate the full set (invalidating prior codes) when the user suspects exposure.

Store recovery codes in a hashed or otherwise protected form rather than plaintext, consistent with how other authentication secrets are handled in the deployment.

Treat recovery-code sign-in as a lower-assurance or exceptional path where appropriate, and consider triggering step-up authentication or additional verification before allowing sensitive actions after such a login.

Log and alert on recovery code usage so that IGA and monitoring processes can review anomalous or unexpected fallback authentications.

Prompt users to regenerate codes after a portion of the set has been consumed, ensuring a usable break-glass option remains available without indefinitely reusing an aging batch.