§01 Identity & Access
Account Recovery Without a Back Door: Secure With the Narrowest Path

Helvetesmaskin, 1600-tal - Skoklosters slott - 102579 / Unknown authorUnknown author, Public domain
When account holders lose the things that authenticate them, the path to recovery is a security control, not a support convenience. Brute-forcing it open is a known attack, and falsely enabling it makes this attack worryingly easy. While every scenario requires recovery options, the fewer ways for users to regain access and the stronger the checks, the better. What is the narrowest and most verifiable path to verifying identities online?
The [NIST Digital Identity Guidelines](pages.nist.gov/800-63-4/) updated July 2025 describe account recovery as the point where a subscriber no longer has the authenticators they started with for their account-level assurance (AAL). If this happens, the system must find a way to confidently reassociate the subscriber with the account, or else it will not be able to control access and ownership.
[NIST SP 800-63B](pages.nist.gov/800-63-4/sp800-63b.html) defines four methods for doing recovery. The narrowest is saved recovery codes, which are codes that are pre-generated in the onboarding process and securely stored on the subscriber's device. They are tied to the subscriber, not the device, and are to attacks. This is the mechanism used in [FIDO Authenticator Recovery](fidoalliance.org/wp-content/uploads/2019/02/FIDO_Account_Recovery_Best_Practices-1.pdf).
A second option is _issued recovery codes_. These are generally codes given to the subscriber as part of an ongoing credential or subscription, and again should be protected secrets that are not discoverable. They are a stricter form of saved recovery codes, given outside the enrollment process, they do not have as close a link to the authenticators that verified the subscriber's initial control over the account. Given that they are more complicated to manage, they offer little for many systems and power.
Third is the use of recovery contacts. In this model, the subscriber designates a set of trusted contacts, and uses the credential of one or more of those contacts to demonstrate recovery. It is well-documented for this to fail due to the recovery contacts themselves not following through with their promise. It also creates unfriendly telemetry on those contacts, whose own systems may detect and improperly flag it.
The final form of recovery allowed by NIST 800-63-4 is repeated identity proofing, or re-enrolling. This is viewed as the most expensive and difficult form of recovery, as it involves re-running all the checks an identity goes through in enrollment. Candidates for online enrollment, such as (https://pages.nist.gov/800-63-4/sp800-63b/events/) or [(pages.nist.gov/800-63-4/sp800-63b-pa1.html), may need checkpoints, government-issued IDs, and cross-referencing of databases that would ordinarily slow the registration to a crawl. Successfully doing this also must trigger proper monitoring of authenticity. [NHIMG notes that recovery is often not at the least as strong as the primary authenticator, but must be at least that strong.
The goal of recovery is to recreate access for subscribers that have enrolled, even as direct evidence has somehow been lost. If a recovered account cannot be trusted, the account SHALL be considered abandoned and a new enrollment SHALL be required. Previously, attackers could restore an account via recovery to send to Service Desk operators with the credo that they can't know for sure that the person asking isn't the legitimate user. Section 6 of 800-63-4 clarifies that "As part of the recovery process, the verifier MAY ask the current subscriber about an issue related to the authenticator so that one thing becomes known to both entities without becoming available to an attacker." and that this qualified process is backed up by documentation and audits that enable security teams to review the account changes.
One way to avoid recovery being the most-used access path (#to-verify) is to give the user multiple authenticators, and multiple factors, in the first place. The FIDO Alliance recommends [multiple authenticators per account as supportive of making recovery less common. They also recommend re-running the whole enrollment process for recovery, including re-registrations when they are normally required. In theory, recovery lets the user regain a secure form of access to the account, and is not valid as a secondary path of access during lost authenticator events. By giving more ways to authenticate one's own account, this becomes harder to use as an extra mode of authentication.
If re-enrollment is not viable and only partial recovery can be done, then it should be required to be at least as stringent as the membership credential it is replacing Sec 6 of 800-63-4. NHIMG notes that this is a minimal guarantee that has not been standardized, or enforced across platforms by the platform's rules.
The account recovery field is a known attack vector, and as such, the patterns for implementors should be to make it reliable and protected against known threats. Wherever credentials are potentially already compromised, rejection should be made automatic and quick, and recovery should not be an open invitation to someone requesting unauthorized access.
Users need to know how to recover, but teams also need to verify that how the user did recover was valid and controlled. All recovery paths must be documented, even the responder's decision. Logs should include the decision-maker, when it was made, and what circumstances it applied to. Whatever recovery was selected, the account should automatically treat it as a new enrollment.
Account recovery is the process of taking an account that has lost its main proof of enrollment and giving it a substitute to get back into the system. The substitute must be far enough from the original enrollment to invalidate accounts without them, but easy enough for the account to be restored when it has them. More ways for the user to recover increases the attack surface and cost of the recovery, from needing ticketing and issue-tracing and potentially fending off attacks, so each platform or site should choose the narrowest one possible. Where recovery is impossible, and subscriber can't prove what they never needed to access, they need a new account.