Recovery Is Another Authentication System
A passkey proves control well when the subscriber can complete the normal ceremony. Account recovery begins when that proof is no longer available or no longer sufficient. This chapter treats recovery as its own authentication system: it classifies the evidence a service can accept, explains the combinations NIST specifies for an AAL2 account, and follows the operational details that make recovery either a controlled return to the account or an attractive route for an impostor.
Recovery is different from adding an authenticator
The first distinction is about the starting condition. If a subscriber can still authenticate with one or more authenticators already bound to the account and wants to add another, the service is binding an additional authenticator. The subscriber is proving control through an existing relationship and asking the service to create a new one. NIST treats that as post-enrollment binding.
Account recovery begins in a different state: the subscriber has lost control of the authenticators needed to authenticate at the desired assurance level. The service no longer has the ordinary proof available, so it needs another way to decide whether the claimant should regain ownership of the account and bind new authenticators. NIST notes that recovery is expected to be infrequent, generally less convenient than ordinary authentication, and potentially subject to extended waiting times. That friction is not automatically a defect. It can be the cost of requiring stronger or more independent evidence when the normal credential is absent.
The distinction matters in a familiar scenario. A user still has a working passkey on a laptop and wants to add a passkey on a new phone. The service can use the laptop authentication to authorize the new binding. The user is not recovering the account; they are extending the set of authenticators that can access it. If the laptop is also unavailable, the service may have to enter recovery instead. Calling both screens “set up a passkey” would hide the difference in what the claimant is proving.
NIST recognizes four general classes of recovery method:
- Saved recovery codes that the subscriber received earlier and stored for future use.
- Issued recovery codes sent when recovery is needed to a verified recovery address.
- Recovery contacts who receive or communicate a recovery code on the subscriber’s behalf.
- Repeated identity proofing that repeats enough of the original identity-verification process to establish that the claimant matches the existing account.
A credential service provider must support one or more of these classes. It may also use an application-specific method, such as interaction with a service agent, but NIST says an alternative method must be based on a risk analysis and documented by the provider. The list is therefore not a menu in which every channel is interchangeable. Each method changes what evidence the service accepts, who controls the channel, how quickly an attacker can attempt it, and how confidently the service can connect the claimant to the subscriber.
The difference between a code and identity proofing illustrates the point. A saved code demonstrates possession of something the subscriber was expected to preserve.