Authentication assurance levels describe how confident a service can be that the person logging in is the legitimate holder of an account. The idea is most closely associated with NIST Special Publication 800-63, the US digital identity guidelines, which define three levels known as AAL1, AAL2 and AAL3.
This article explains what each level asks of authenticators, how the levels connect to identity proofing and federation, and how organizations decide which level a given application needs. It focuses on the reasoning behind the framework, so you can apply it sensibly rather than treating it as a checkbox exercise.
Why One Login Standard Cannot Fit Every Service
A recipe website and a system that releases medical records both ask users to sign in, yet the harm from a stolen account is very different. Requiring hardware keys for the recipe site would drive users away, while allowing a password alone for health records would expose sensitive data.
Assurance levels give organizations a shared vocabulary for this trade-off. Instead of arguing about individual products, a team can agree that an application needs a certain level of confidence and then select any authenticators that meet the requirements for that level. The decision becomes repeatable and easier to audit.
The concept also helps users understand why services behave differently. When a benefits portal insists on a security key or authenticator app while a newsletter accepts a simple password, the difference usually reflects a deliberate judgment about risk, not inconsistency. Higher stakes justify stronger and sometimes less convenient authentication.
Where Authentication Assurance Levels Come From
NIST, the US National Institute of Standards and Technology, publishes SP 800-63 as a suite of documents. One part covers identity proofing, another covers authentication and authenticator management, and a third covers federation. The authentication volume is where the three authentication assurance levels are defined.
The guidelines are mandatory for US federal agencies, but many private companies, universities and governments elsewhere use them as a reference because they are detailed, publicly available and regularly revised. Other frameworks, such as the European eIDAS regulation, use their own assurance levels with different names and criteria, so mappings between systems need care.
Because the documents are revised over time, specific requirements can change between editions. Teams designing systems should read the current edition directly from NIST rather than relying on summaries, including this one, and should note which edition their policies reference so that later audits compare against the right text.
The Three Levels at a Glance
Each level builds on the one below it, adding requirements for factors, cryptography and resistance to specific attacks. The descriptions below summarize the intent of each level rather than every technical clause.
AAL1: Some Confidence
AAL1 provides basic assurance that the claimant controls an authenticator bound to the account. Single-factor authentication is permitted, so a password alone or a single possession-based authenticator can qualify. It suits low-risk services where an account takeover would cause limited harm and would not expose sensitive personal information.
Even at this level, services are expected to block commonly used or previously breached passwords and to limit repeated guessing.
AAL2: High Confidence
AAL2 requires proof of possession and control of two different authentication factors, using approved cryptographic techniques. A password combined with a one-time code generator, or a device-bound passkey activated with a PIN or fingerprint, are typical examples. Recent guidance places increasing emphasis on offering phishing-resistant options at this level.
Many consumer banking, email and workplace applications target AAL2 because it balances strong protection with everyday usability.
AAL3: Very High Confidence
AAL3 requires a hardware-based authenticator whose private key cannot be exported, used together with a second factor, and it must resist phishing and verifier impersonation. Smart cards and hardware security keys protected by a PIN are common examples. This level fits privileged administrators and systems where compromise could cause severe harm.
Users at this level should always hold a registered backup authenticator, because replacing a lost hardware device takes planning.
Authenticator Types and How They Map to Levels
NIST describes authenticators by type rather than brand. Knowing the types helps you read any vendor claim critically, because the type and its configuration, not the marketing name, determine which level an authenticator can support.
- Memorized secrets: passwords and PINs, usable alone only at the lowest level.
- Look-up secrets: printed recovery code lists, typically used as a backup option.
- One-time password devices: apps or tokens that generate short-lived codes, usually one factor in a two-factor combination.
- Cryptographic software authenticators: keys stored in software on a general-purpose device, such as some synced passkeys.
- Cryptographic hardware authenticators: keys held in dedicated, tamper-resistant hardware such as security keys and smart cards.
The same physical device can reach different levels depending on how it is used. A hardware key that is touched but never asks for a PIN provides one factor, while the same key requiring a PIN provides two. Configuration details therefore matter as much as the product chosen.
What Separates AAL2 From AAL3
The jump from AAL2 to AAL3 is mostly about where the secret lives and what attacks it can withstand. At AAL2, cryptographic keys may sit in software on a phone or laptop. At AAL3, the key must stay inside hardware designed to prevent it from being copied out.
AAL3 also requires verifier impersonation resistance, meaning the authenticator will not produce a valid response for a fake site pretending to be the real one. FIDO2 security keys and properly configured smart card logins provide this property because they bind each response to the identity of the service requesting it.
In practice, AAL3 involves more logistics. Organizations must buy and distribute hardware, register backup authenticators, and plan for lost devices. For many internal applications, a well-configured phishing-resistant AAL2 setup gives most of the security benefit, while AAL3 is reserved for the accounts that would cause the greatest damage if misused.
A useful test is to ask what happens when an employee’s laptop is stolen while signed in. If the key could be extracted from that laptop, the setup is not AAL3, however strong the login prompt appears.
How AALs Relate to Identity and Federation Assurance
Authentication assurance is only one of three dimensions in the NIST model. Identity assurance levels, or IALs, describe how thoroughly a person’s real-world identity was verified at enrollment. Federation assurance levels, or FALs, describe how securely identity information is passed from an identity provider to another service.
The three dimensions are chosen independently. A whistleblower platform might need strong authentication to protect accounts but deliberately avoid identity proofing to preserve anonymity, giving it a high AAL with the lowest IAL. A tax service, by contrast, may need both strong proofing and strong authentication.
Federation adds a third consideration when users sign in through a separate identity provider. Even if the provider authenticates users at AAL3, a weak assertion, the signed message that carries the login result, can undermine that strength. The overall assurance is limited by the weakest of the three links.
Choosing the Right Level Through Risk Assessment
Selecting an assurance level starts with understanding what could go wrong. NIST frames this as a digital identity risk assessment, in which teams consider the impact of an authentication failure on users, the organization and other parties before choosing controls.
- List the actions an authenticated user can perform and the data they can see.
- Estimate the harm if an attacker gained that access, including financial loss, privacy damage and safety risks.
- Map the harm to an initial assurance level, choosing a higher level when harm could be severe.
- Consider the user population, including accessibility needs and access to devices.
- Document the chosen level, any compensating controls and the reasoning behind them.
The last step is easy to skip but valuable. Written reasoning lets future teams revisit the decision when the application changes, such as when a read-only portal later gains payment features that justify a higher level.
Sessions and Reauthentication at Each Level
Assurance does not end at login. The guidelines link each level to expectations about how long a session may last and how often users must prove themselves again. Higher levels call for shorter sessions and more frequent reauthentication, reflecting the greater harm a hijacked session could cause.
Session controls include limits on total session length and on inactivity, after which the user must authenticate again. The exact time limits appear in the current edition of the guidelines and may change, so teams should take them from the source document rather than from memory or older internal policies.
Reauthentication can sometimes use a single factor if the session is still active and other conditions are met, which keeps strong assurance from becoming unbearable for users. Designing these rules carefully avoids a common failure in which strict login requirements are undermined by sessions that effectively never expire.
Account Recovery Without Lowering the Level
An account protected at AAL3 is only as strong as its recovery process. If a user who loses a security key can regain access with an emailed link, the effective assurance drops to whatever protects that email account. Attackers frequently target recovery for exactly this reason.
Sound practice is to register more than one authenticator during enrollment, so a lost device can be replaced by signing in with the backup. When every authenticator is lost, recovery should require evidence comparable to the original level, which may mean repeating identity proofing rather than answering simple security questions.
Organizations should also notify users through established channels whenever authenticators are added or removed. These notifications give legitimate users a chance to react quickly if someone else attempts to take over their account through the recovery path, and they create a useful audit trail for investigations.
Common Misreadings of Assurance Levels
Assurance levels are widely referenced and frequently misunderstood. Several recurring mistakes can leave systems weaker than their documentation suggests, so they are worth checking for during design reviews and audits.
- Treating any two-step login as AAL2, even when both steps rely on the same factor category.
- Assuming a product label guarantees a level without checking how the authenticator is configured.
- Ignoring session length and recovery, which can quietly undo strong login requirements.
- Confusing authentication assurance with identity proofing, as if a strong login proves who someone is in real life.
- Using a NIST level as a legal compliance claim in regions where different rules apply.
Avoiding these errors usually requires collaboration between security, product and support teams. Support staff in particular handle recovery requests and need clear procedures that match the level the application claims to provide.
Putting Assurance Levels Into Practice
Start by inventorying applications and assigning each a provisional level based on the harm a takeover would cause. Many organizations discover that a few high-impact systems, such as administrator consoles, payroll and customer data stores, deserve the most attention and can be upgraded first.
Next, choose authenticators that meet those levels while fitting your users. Offer more than one compliant option, include accessible alternatives for people who cannot use certain devices, and test the enrollment and recovery experience with real users before enforcing new rules across the organization.
Revisit the assessment whenever applications change or new guidance is published. Authentication technology is moving steadily toward phishing-resistant, passwordless methods, and assurance frameworks are evolving alongside it. Treating assurance levels as a living decision, not a one-time label, keeps protection aligned with real risk over time.
For individuals, the framework offers a simple lesson. The accounts that matter most to you deserve the strongest authenticator they support, a registered backup, and recovery settings you have checked yourself.