Category: Multi-Factor Methods

Backup Code

Also known as: Recovery Code, Backup Codes, 2FA Backup Code

Simply put

A backup code is a pre-generated, one-time-use code that lets you sign in when your usual second-factor method, such as a phone or authenticator app, is lost or unavailable. You typically receive a small set of these codes to store somewhere safe and use them as a stand-in when your primary method won't work.

Formal definition

A backup code is a one-time-use recovery credential issued as a fallback within a multi-factor or 2-step authentication flow, used when a user's primary authenticator (for example a TOTP app, push, or hardware key) is unavailable, lost, or disrupted. It functions as a possession-style factor in most deployments, typically provisioned as a fixed batch of single-use codes (counts vary by provider, for example, some services generate a set of 12) that the user stores out of band and consumes one per authentication; each code is invalidated after use. Depending on configuration, backup codes may serve as a stand-alone MFA method or as a supplementary fallback to another factor. Note that backup codes address authentication (verifying the user during sign-in) and are distinct from account recovery governance or provisioning concerns; specifics such as code length, hashing at rest, and regeneration behavior are vendor-dependent and not established by the evidence here.

Why it matters

Multi-factor and 2-step authentication significantly strengthen account security, but they introduce a dependency on the availability of a primary authenticator such as a phone, authenticator app, push notification, or hardware key. When that authenticator is lost, damaged, replaced, or otherwise disrupted, the user can be locked out of their own account. Backup codes exist to close this gap: they provide a pre-provisioned fallback that lets a legitimate user complete sign-in without their usual second factor, reducing the risk that an MFA rollout translates into a wave of lockouts and help-desk escalations.

Because backup codes typically function as a possession-style factor stored out of band, their security depends heavily on how the user handles them. A set of codes written down and stored insecurely, or captured in a screenshot synced to a compromised account, becomes a standing bypass of the stronger primary factor. This makes backup codes a double-edged control, valuable for continuity, but a potential weak link if guidance on safe storage and single-use consumption is not enforced. The fact that each code is invalidated after use limits the blast radius of any single exposed code, but a full unused batch represents meaningful access if leaked.

For identity teams, backup codes matter as a deliberate design decision rather than an afterthought. Depending on configuration, they may serve as a stand-alone MFA method or as a supplementary fallback to another factor, and that choice shapes the overall assurance level of the authentication flow. Treating backup codes as an authentication concern, distinct from broader account recovery governance, helps teams reason clearly about where the fallback fits and what it protects against.

Who it's relevant to

IAM Engineers and Authentication Architects

Engineers designing MFA and 2-step flows must decide whether backup codes serve as a stand-alone method or a supplementary fallback, and how that choice affects the assurance level of the overall flow. They also need to account for vendor-dependent behavior around single-use consumption, code count, and regeneration when integrating a provider's backup-code capability.

System Administrators and Help Desk Teams

Administrators supporting users through lost or unavailable authenticators rely on backup codes to reduce lockouts during and after MFA rollouts. They benefit from clear guidance to users on generating, safely storing out of band, and consuming these one-time codes, one per sign-in, since a full unused batch stored insecurely can undermine the stronger primary factor.

End Users Enrolled in MFA

Users who adopt MFA need a reliable way to sign in when their phone, authenticator app, or hardware key is lost or disrupted. Backup codes give them a stand-in method that does not require their usual device, provided they store the codes securely and understand that each code works only once.

Security and Compliance Reviewers

Reviewers assessing authentication controls should evaluate backup codes as a possession-style fallback whose security depends on out-of-band storage and single-use invalidation. They may need to probe vendor-specific details, such as hashing at rest and regeneration behavior, that are not standardized, and to confirm the backup mechanism does not weaken the intended MFA assurance.

Inside Backup Code

Recovery Code Set

A backup code is typically issued as part of a set of single-use codes generated when a user enrolls in multi-factor authentication (MFA). Each code functions as a possession-factor fallback that can substitute for the primary second factor when it is unavailable.

Single-Use Semantics

In most deployments, each code is consumed on successful use and cannot be reused, so the available pool shrinks as codes are redeemed. This distinguishes backup codes from a reusable static secret.

Static, Pre-Generated Value

Unlike time-based one-time passwords (TOTP) that rotate on an interval, backup codes are static values generated in advance and valid until used or explicitly regenerated, depending on configuration.

Authentication-Step Role

Backup codes participate in the authentication step, verifying that the principal presents a valid possession factor, not the authorization step. They do not determine what a principal may do once authenticated.

Regeneration and Invalidation

Most systems allow a user to regenerate a fresh set, which typically invalidates any previously issued unused codes, so only one active set exists at a time.

Common questions

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

Is a backup code a form of multi-factor authentication on its own?

Not on its own. A backup code is a single knowledge-like factor (a pre-generated secret the user possesses in written or stored form) that typically serves as a recovery or fallback authenticator when a user's primary second factor is unavailable. Whether its use still constitutes MFA depends on the deployment: if the code substitutes entirely for the second factor after a password, the resulting flow may effectively fall back to a weaker posture than the intended possession- or inherence-based factor. Treat backup codes as a recovery mechanism rather than as a standalone MFA method.

Are backup codes the same as one-time passwords (OTPs) generated by an authenticator app?

They are related but not the same. Both are typically single-use secrets, but TOTP/HOTP codes from an authenticator app are generated dynamically from a shared seed on a schedule or counter, whereas backup codes are a fixed set of pre-generated static values issued in advance. Backup codes do not rotate over time; each is valid until consumed or invalidated. Because they are static and often stored by the user in less controlled locations, their threat profile differs from that of app-generated OTPs.

How should backup codes be stored on the server side?

In most deployments backup codes should be treated as credentials and not stored in plaintext. A common approach is to store only a salted hash of each code so that the raw value cannot be recovered from the datastore, verifying an entered code by hashing and comparing. The exact hashing scheme and storage location depend on the platform and vendor implementation; consult the specific product's security documentation, as behavior varies by configuration.

Should a backup code be invalidated after it is used?

Typically yes. Backup codes are generally designed as single-use secrets, so a code should be marked consumed and rejected on any subsequent attempt. Many implementations also let users regenerate the full set at any time, which invalidates all previously issued codes. Whether unused codes expire automatically depends on the deployment; some systems keep them valid indefinitely until regenerated, while others impose limits.

How many backup codes should be issued to a user, and what happens when they run low?

There is no universal standard for the count; implementations commonly issue a small fixed batch and let the user regenerate a new set on demand. As codes are consumed, systems often surface the remaining count and prompt regeneration when few remain. Regenerating typically invalidates the prior set, so users should record the new codes and discard the old ones. Exact thresholds and prompts vary by vendor and configuration.

How do backup codes fit into an account recovery flow alongside other authenticators?

Backup codes typically function as a fallback authenticator invoked when a user cannot present their primary second factor, such as a lost phone or unavailable authenticator app. In a well-designed flow they supplement stronger factors rather than replace them, and their consumption is often logged and may trigger step-up verification or user notification. Because they can be the weakest link in a recovery path, many deployments pair them with additional controls; the specifics depend on the identity provider's recovery configuration.

Common misconceptions

A backup code is a form of two-factor authentication on its own.

A backup code is a fallback possession factor used in place of a primary second factor. Whether its use still constitutes MFA depends on configuration, if it is presented alongside a knowledge factor such as a password, the overall flow can remain multi-factor, but the code itself is a single factor.

Backup codes are functionally the same as TOTP codes.

TOTP codes are derived from a shared secret and the current time and rotate continuously, whereas backup codes are static, pre-generated, single-use values that remain valid until redeemed or regenerated. They serve as a fallback, not as an equivalent primary mechanism.

Once generated, backup codes are permanently valid and always available.

Each code is typically consumed on use, the pool depletes over time, and regenerating a new set generally invalidates the prior set. Codes can also be revoked or reset by administrators depending on the platform.

Best practices

Treat backup codes as sensitive possession-factor credentials: store them offline or in an encrypted secret store rather than in plaintext, and never reuse the same set across accounts.

Prompt users to regenerate their code set after any code is used or if compromise is suspected, and ensure regeneration invalidates the previously issued unused codes.

Track the remaining number of unused codes and alert users to generate a fresh set before the pool is exhausted, so account recovery does not fail when the primary factor is unavailable.

Where supported, log and monitor backup-code redemptions as higher-risk events and consider requiring step-up authentication for sensitive operations performed after a code-based sign-in.

Present backup codes as a fallback rather than a primary method, steering users toward stronger factors such as authenticator apps or WebAuthn/FIDO2 authenticators for routine authentication.

Confirm whether your deployment still enforces a second factor when a backup code is used, and document the exact policy so administrators and auditors understand what assurance a code-based login provides.