Account recovery

Account recovery is what happens when a user can no longer authenticate: the phone is lost, the security key is broken, the password is forgotten and nothing else is registered. It is also, very often, the easiest way into an account. A strong authenticator protects nothing if a convincing phone call to the help desk can replace it. SP 800-63B-4 (July 2025) substantially rewrote its recovery rules. This page covers section 4.2, which recovery methods it recognizes and with what parameters, what each assurance level requires, notification, re-binding, and how to resist help-desk social engineering.

Why recovery is the weak link

SP 800-63B-4 section 6.3 (informative) says it directly: "The weak point in many authentication mechanisms is the process followed when a subscriber loses control of one or more authenticators and needs to replace them." Options are limited, cost pressure pushes toward cheap and weak methods, and "to the extent that authenticator recovery is human-assisted, social engineering attacks also pose risks". It also states a principle worth applying everywhere: one authentication factor must not be usable to obtain an authenticator of a different factor. For example, a password must not be enough to get a new list of look-up secrets.

OMB M-22-09 makes the same point for US agencies. Recovery processes "represent a potential bypass of standard authentication protocols" and should "require high-friction methods that are costly for an adversary to overcome, such as in-person verification, live video interaction, or other similar methods".

What counts as recovery

Section 4.2 defines account recovery as a subscriber recovering "from losing control of the authenticators that are needed to authenticate at a desired AAL". Afterwards the subscriber can bind one or more new authenticators, and recovery "always causes one or more notifications to be sent to the subscriber".

The four recovery methods

Section 4.2.1 recognizes four classes. CSPs SHALL support at least one. They MAY also support an application-specific method, such as interaction with a CSP agent, but only on the basis of a risk analysis that the CSP documents (SHALL).

Knowledge-based questions ("mother's maiden name") are not among the four recognized classes. Separately, section 3.1.1.2 forbids prompting users to set security questions when choosing passwords (SHALL NOT).

What each level requires

• Without identity proofing (4.2.2.1): recovery SHALL require a saved recovery code, an issued recovery code, or a recovery contact. Accounts that can only authenticate at AAL1 fall in this group.
• AAL2 (4.2.2.2): the CSP SHALL require one of: two recovery codes obtained by different methods; one recovery code plus authentication with a single-factor authenticator bound to the account; or repeated identity proofing, if the account was proofed.
• AAL3 (4.2.2.3): if proofed at IAL1 or IAL2, same as AAL2. If proofed at IAL3, the CSP SHALL perform a successful biometric comparison against the characteristic collected during the original on-site attended proofing, and MAY also require the original evidence.

Notification

Section 4.2.3: "In all cases, account recovery SHALL cause a notification to be sent to the subscriber or their designee." Section 4.6 sets how:

• CSPs SHALL support at least two notification addresses per account. For proofed accounts, at least one SHALL have been validated during proofing.
• Notifications SHALL go to all notification addresses except postal ones. Postal is used when it is the only kind on file, or for account recovery at AAL3 (SHALL).
• If the only other notification address is the one the issued recovery code was sent to, the recovery notification SHALL also go to a postal address. Otherwise an attacker who controls that one inbox would see both the code and the warning.
• The notification SHALL include clear instructions and contact information for the case where the recipient did not perform the action.

Re-binding authenticators after recovery

After recovery, the user binds new authenticators (section 4.1.2.1). Two rules matter:

• Binding a new authenticator SHALL require authentication at the maximum AAL currently available on the account, or at the maximum AAL the new authenticator will be used at, whichever is lower.
• The CSP SHALL notify the subscriber through a mechanism independent of the binding transaction.

Lost or compromised authenticators are dealt with in section 4.3: the CSP SHALL promptly suspend, invalidate or destroy compromised authenticators, and a lost authenticator should generally be assumed stolen. CSPs SHOULD encourage every user to keep at least two authenticators bound (section 4.1.2.1). That is the cheapest way to avoid recovery entirely.

Help-desk social engineering

SP 800-63B-4 Table 4 lists the mitigation for social engineering as avoiding authenticators "that present a social engineering risk to third parties (e.g., customer service agents)". In practice, help desks reset credentials every day, so the process has to be designed so that a confident caller with personal details found online cannot complete it. The following are common practices, not NIST requirements:

• Never accept caller ID, knowledge of personal data, or urgency as identity proof.
• Verify through a channel the caller does not control: a call back to the number on file in the HR system, the user's manager confirming over a separate authenticated channel, or a live video check against an ID photo on record.
• Prefer resets the user completes themselves with a recovery code or an existing authenticator. The agent only starts the flow.
• For privileged accounts, require in-person or video verification plus a second approver, and alert the security team on every reset. See privileged accounts.
• Do not let one factor be used to obtain an authenticator of a different factor, for example a password alone being enough to enroll a new MFA device (SP 800-63B-4 section 6.3 states this principle; its example is a password obtaining new look-up secrets).
• Notify the user on every address on file, and make it easy to report "this wasn't me".
• Log and review resets, and look for clusters by agent, by time or by target.

Design checklist

• Users are encouraged, at enrollment and after, to register at least two authenticators. For passkeys, at least one should survive device loss. See passkeys.
• Saved recovery codes have 64+ bits, are stored hashed, are single-use, and are replaced after use.
• Issued codes respect the maximum validity periods, and email is never the only factor for AAL2 recovery.
• AAL2 recovery requires two independent methods (or re-proofing), not one email link.
• Every recovery and every new authenticator binding sends notifications to all addresses on file.
• Recovery is throttled, logged and monitored like sign-in.
• Any application-specific method, such as agent-assisted recovery, has a documented risk analysis.
• Recovery for emergency and administrative accounts is defined separately. See break-glass accounts.

Sources

1. NIST SP 800-63B-4: Authentication and Authenticator Management, NIST. Public domain (U.S. government work).
2. OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, Office of Management and Budget. Public domain (U.S. government work).