Dean H. Saxe, Sr. Security Engineer, Amazon Web Services

© 2021, 2022, 2023 IDPro, Dean Saxe

To comment on this article, please visit our GitHub repository and submit an issue .

Table of Contents


Account Recovery

Defining AR

What is AR? You’ll see one definition above, but a fuller description follows. AR is a mechanism or collection of mechanisms that are used to maintain continuity of access to a user’s services. AR operates by providing an alternative authentication mechanism to reestablish authentication credentials , such as through re-identification of the user . A key property of any AR mechanism is that it must meet or exceed the security of the nominal authentication mechanism for the account that it serves to recover. If this property is not met, users may choose to execute the AR mechanism rather than remember their credentials. This also opens the door to AR being used as an account takeover mechanism.

A real example of the abuse of AR mechanisms happened to the author. Our family had shares of an American company; the shares were managed through an online portal. Each year I had to log in to collect the tax forms, but I could never remember the password. The service’s AR process required two pieces of readily available information: my mother-in-law’s maiden name and my wife’s date of birth. Each year I would log in with these pieces of known information, collect the documents I needed, and logout. The password was not required, nor did the AR process require a password reset or notify the account holder of the access!

An Iron Triangle of Account Recovery

As an owner of a resource, I have to decide the balance of three concerns - Privacy, Access Continuity, and Security - that meet my needs within the constraints of the service I’m accessing. In an iron triangle, I can move away from any vertex toward another to obtain relatively more of one concern (e.g., privacy) at the cost of another (e.g., security or access continuity). 6

In the stock example above, the system design focused on high access continuity exclusively to the detriment of security - the account is easy to access by malicious actors who could execute transactions - and privacy - the account owner is fully identified by the stock service, as is the nature for most financial systems. A gradiated grey triangle with Privacy at the top, Security on the bottom right, and Access Continuity on the bottom left.

In contrast, my current bank focuses on access continuity and security - it is hard to gain access to my account online due to strong authentication requirements, and (relatively) easy for me to regain access to my account by visiting a branch in person with government identification. The bank is obligated to identify me based on my government-provided identity documents (e.g., passport, driver’s license) for conducting certain transactions and uses this same in-person authentication of my government-issued credentials to restore access to my account if required. This is an act of authentication! The driver’s license looks normal, unaltered, anti-fraud elements are in place, the expiration date is valid, the image looks like the person standing in the bank, the document is machine-readable and matches the person, etc.; thus, I can conduct a transaction. (Note that this is not a fraud-free mechanism of authentication. However, the risk of a scalable attack in the physical world is significantly less than a purely online service.)

Finally, Reddit, a social news aggregation site, balances all three concerns. My email was validated on signup by forcing me to close the loop by clicking on a one-time use URL. Reddit allows me to use multiple MFA devices, and I can recover my account through a backup code. But if the backup codes are lost, the password unknown, and MFA devices are not available, I’ll lose access to my account without recourse.

Which one is correct? Potentially all of them, depending on the threat model.

Given these constraints, how can we apply this iron triangle to designing registration, authentication, and account recovery systems? Below are three continuums representing each vertex; movement toward the arrow is correlated with a higher score on the continuum toward the vertex in the triangle (values are relative, not absolute).

Three rows that capture the continuum of access continuity for privacy, security, and access.

Figure 2: The three continuums of an Iron Triangle of Access Continuity. Moving from left to right on each continuum leads closer to the appropriate vertex of the triangle.

In a nutshell, Identity architects can use the iron triangle to first identify where in the triangle the use case is situated and second to identify the trade-offs that are made to meet the needs of the use case. 7 However, the devil is in the details, and those details will differ wildly across different identity ecosystems.

Consumer AR

Consumer use cases are focused on end-users of commercial systems open to the general public. Depending on the nature of the consumer relationship, there may or may not be any in-person interactions, which can limit the mechanisms used for reestablishing credentials for the user.

The risk associated with consumer accounts varies widely depending on the service. While both banking and social networking need to operate AR mechanisms for their users, the risk of compromise of each account type is significantly different. There is also a different set of information available to these different consumer services to enable AR.

Enterprise AR

In the enterprise, the focus is usually on access continuity – minimizing user downtime - and security for AR processes. AR is generally straightforward for on-premises employees: Present yourself and your enterprise or government identification to the IT Help Desk and reset your credentials. This is a form of identity proofing for AR. However, as more corporate employees work remotely, this in-person mechanism may no longer work. In these cases, enterprises must look at remote mechanisms, which could include remote identity proofing, using a trusted intermediary (e.g., supervisor) to vouch for the employee, and intermediate the process of AR, using a quorum of trusted intermediaries to vouch for the employee, etc.

Education AR

Similar to enterprises, the focus for education is on access continuity. On-campus staff and students can use in-person services for account recovery. Remote students and staff may use similar mechanisms to enterprises, adapted to their unique environment.

Government AR

Due to the wide variations in government systems and services, there is little consistency in this realm. Implementers should be observant of local, national, and supranational laws, regulations, and cultural norms when working with account recovery in this space.

AR Mechanisms

Below we review common AR mechanisms. However, we would be remiss to not include as the first and primary mechanism Make Losing Access Difficult. In other words, if we do not first start with a focus on maintaining access continuity for our users in the happy path, we will see more requests for AR . Identity architects must consider the AR use cases as a primary concern when designing authentication systems and not treat AR as a second-class use case.

Make Losing Access Difficult

How do services make access continuity easy and losing access difficult? At the most basic level, services should nudge their users into making good decisions. This can include:

Identity providers should also guide their users to avoid single points of failure on the user side. For example, if the user places their credentials in a password safe and recovery codes are stored in the same safe, loss of access to the password safe eliminates at least one recovery pathway. Although we cannot always prevent users from shooting themselves in the foot, we can try to limit the damage that the user can do to themselves.

User Notifications

Before diving into the mechanisms of AR, we must pause to talk about user notifications as an important component of the AR process user experience. All actions that impact the user’s ability to maintain access continuity must be reported to the user. These include, but are not limited to:

Due to the time-sensitive nature of these messages, they should be broadcast to all available channels which the use has consented to, such as email, SMS, and push notifications. Notification should be sent to the prior email address and/or phone number during a change request, allowing the user an opportunity to identify a fraudulent change and revert the change before further damage occurs.

Bearer Tokens

Bearer tokens, when used for AR, can be thought about as paper tickets to a concert or sports event. The tickets (or bearer tokens) are used once to access a service in lieu of the user’s normal credentials.

These bearer tokens take a few forms:

Grouping these mechanisms as bearer tokens allows us to reason about their usability and security together. The assurance level of a bearer token is directly correlated to how it was delivered. Recovery codes obtained in an authenticated session are generally higher assurance than one-time codes or magic links; however, this is dependent upon how they are stored by the user.


Threats and Mitigations

Knowledge-Based Authentication / Security Questions

Both Knowledge-Based Authentication (KBA) and Security Questions are used as recovery mechanisms by having the user “prove” they are the legitimate owner by answering questions known only to the user. Unfortunately, both KBA, based on public information databases or recent user transactions, previous passwords, and security questions, based on preconfigured questions and answers provided by the user, are relatively weak recovery mechanisms.

KBA mechanisms often utilize information such as home addresses, loan dates/amounts, and credit report data to weakly identify the human owner of an account. However, due to numerous data breaches, this information is insufficiently secret and should not be depended upon as a recovery mechanism for accounts with any significant value.

Information used for KBA may often be available to family members or other parties close to the user, reducing their efficacy.

Similarly, security questions often have predictable or easily identifiable answers. Questions such as favorite color have low entropy (according to this study, 64% of Americans choose one of four favorite colors, blue (29%), green (21%), purple (8%), and red (8%)), while questions about a favorite sports team or high school mascot may be readily discoverable through social media.

As a low assurance mechanism, KBA and security questions are only recommended for the lowest-risk operations as a last resort.


Threats and Mitigations

Identity Verification / Identity Proofing

In some use cases where privacy of the individual’s identity is not the overriding concern, systems may use identity verification or identity proofing to establish the real-world identity of a human, often based upon government (driver’s license, passport), enterprise (employee badge), or educational credentials (university or school ID) issued by a trusted authority. Early in the account lifecycle, perhaps as a requirement to establish the account, the user’s identity is verified, binding the identity to the user account. This may take place in person (e.g., at a bank, registering for a trusted traveler program, at a university during registration, at an employer on the employee’s first day), or remotely. Since these require in-person interactions, they cannot easily be automated and provide a higher barrier to entry for fraudulent access. In the remote use case, a common modality is to ask the user to take an image of their identity document and a selfie or short selfie-video. The identity documents are reviewed for signs of tampering or other fraud markers. The image on the identity document is compared with the selfie or video, which is usually tested for liveness by asking the user to do certain behaviors such as look up, down, left, right, before confirming that the human at the keyboard is the same human on the identity document (to some level of certainty).


Threats and Mitigations

Trusted Intermediary

Common in corporate settings, users are able to recover access through a trusted intermediary, such as the user’s manager. The general use case is that when an employee loses access and needs to reset a password or configure a new MFA device, the helpdesk or the user’s manager (or skip-level, etc., though this brings diminishing returns) can authenticate to a recovery service to help the user reestablish corporate credentials. Individual processes may vary depending on the familiarity of the user with the trusted intermediary. For example, a direct report to a manager may have the manager mediate recovery without presenting any identity information. The same user who approaches the helpdesk for a password reset will have to present a corporate badge or similar identity information before executing the reset. In a services industry, a sales manager or technical account manager may be the trusted intermediary for their customers if access is lost. The process may be completed in person, over the phone, or via video conference.

Facebook uses a trusted contacts model to create a self-service recovery mechanism.

Multiple intermediaries can be used, as well, in a quorum ( m of n ) based solution. Quorums are useful for higher assurance use cases to eliminate the threat of social engineering or a single malicious user using the AR process to gain access to unauthorized accounts.


Threats and Mitigations

Possession Factor

Similar to the bearer token discussed above, a possession factor – such as the ability to sign a transaction with a specific private key – can be used as a recovery factor. However, the average user should not be expected to generate and manage their own keys securely. The addition of FIDO2 security keys and passkeys creates a secure mechanism for creating and managing account-specific key pairs. When used as a first-factor device (e.g., the passwordless flow), a security key or passkey can be registered as a “recovery key” for the account. 9 Only the owner in possession of the key and with the biometric or PIN to unlock it can recover the account. Applications on a mobile device can be used as a possession factor when unlocked with the user’s biometric or PIN code. This can be done using common protocols, such as FIDO passkeys, or using a bespoke mechanism.

Last, self-sovereign identity (SSI) can use a similar mechanism. By proving ownership of a specific private key associated with the user’s DID document, the owner can conceivably recover an account.


Threats & Mitigations

Customer Service

The final mechanism for AR is through a customer service mechanism, such as customer service for an enterprise. Customer service may use one or more of the mechanisms identified above to process an AR request. For additional information on using CS for AR, see “Managing Identity in Customer Service Operations” by Arynn Crow and JP Rowan. 10

No Account Recovery

In some scenarios, no account recovery may be the secure and private option. While not recommended for most use cases, not supporting any account recovery is seen in practice and may be the preferred option for some high-security services in order to minimize the risk of account takeover.


Account recovery is a mechanism to support authentication for your service. Building an AR service requires service owners to consider what they, and their customers, value: access continuity, security, or privacy, and build mechanisms to support AR that balance these three concerns. Which AR mechanisms are chosen will additionally depend on the support environment that the service is deploying into: education, enterprise, government, etc. Each has different abilities available to them that may enable stronger AR mechanisms. However, all AR mechanisms share one thing in common: users must register for them implicitly or explicitly if they are to regain access to lost accounts. Therefore, AR is more than just a technical solution to be implemented; it is a user experience and human behavior problem to be solved.


Author Bio

Dean H. Saxe is a Senior Security Engineer with the AWS Identity team and a founding member of IDPro. He can be reached at or on Twitter @n3rd1ty.

Change Log

Date Change
2023-10-27 V3 published; addition of info on passkey recovery
2022-06-03 V2 published; clarifications added to AR mechanisms
2021-04-19 V1 published

  1. Flanagan (Editor), H., (2021) “Terminology in the IDPro Body of Knowledge”, IDPro Body of Knowledge 1(7). doi:

  2. Ibid.

  3. Ibid.

  4. Ibid.

  5. Ibid.

  6. Caccamese, A. & Bragantini, D. (2012). “Beyond the iron triangle: year zero.” Paper presented at PMI® Global Congress 2012—EMEA, Marsailles, France. Newtown Square, PA: Project Management Institute,

  7. Bucci, Steven. “The Iron Triangle of Cybersecurity.” Security Debrief. February 23, 2011. .

  8. Thimot, Tom, “The IRS/ debacle: A teaching moment for tech,” Venture Beat post, 15 April 2022, .

  9. The astute reader will note that this is the same mechanism proposed by the FIDO Alliance for recovering from loss of a security key. At this time, there is no way to backup a security key, therefore registering multiple keys is the specified mechanism of account recovery.

  10. Crow, A. & Rowan, J. P., (2021) “Managing Identity in Customer Service Operations”, IDPro Body of Knowledge 1(4). doi: .