NIST authenticator assurance levels AAL1, AAL2 and AAL3 explained

NIST SP 800-63B defines three authenticator assurance levels. AAL1 allows single factor sign-in, AAL2 needs two factors with a phishing-resistant option offered, and AAL3 requires a phishing-resistant cryptographic authenticator with a non-exportable private key. Higher levels also shorten reauthentication windows.

AAL1: basic confidence

Single-factor or multi-factor authentication is allowed. Verifiers should make multi-factor options available. The overall reauthentication timeout should be no more than 30 days.

Fits low-risk services where an account takeover has limited consequences.

AAL2: the common workforce target

AAL2 needs two distinct factors, or one multi-factor authenticator. At least one authenticator must be replay-resistant, and the verifier must offer at least one phishing-resistant option.

Reauthentication guidance is tighter: the overall timeout should be no more than 24 hours and inactivity no more than 1 hour.

Fits business applications holding customer or employee data, and admin consoles.

AAL3: highest assurance

AAL3 requires a phishing-resistant cryptographic authenticator with a non-exportable private key, and authentication must demonstrate intent. The overall timeout shall be no more than 12 hours and inactivity should be no more than 15 minutes.

Because syncable authenticators need exportable keys, NIST says they shall not be used at AAL3. A hardware security key is the usual fit.

How to choose

1. List what an attacker gains from each kind of account. Read-only, data export, money movement, admin.
2. Map consumer or low-risk roles to AAL1 or AAL2, and privileged roles to AAL2 with a phishing-resistant method required, or AAL3 where your rules ask for it.
3. Check whether a customer contract, regulation or framework names a level. Do not assume one does. Read the actual wording.
4. Set session lengths to match the level. See session timeouts and logout.

Common confusion

• Assurance levels describe how a user authenticates. They are not the same as identity proofing or federation levels, which NIST covers in separate parts of the 800-63 suite.
• An app does not need AAL3 just because it is important. Many teams are well served by AAL2 with passkeys.

I did not read the federation or enrollment volumes for this post, so check those if your work spans them.

If you are writing this into a policy, name the level per application class rather than per person. For example, internal admin consoles at one level and the general staff portal at another. That keeps the policy short, and it lets your identity provider rules map directly to the text. Review the mapping when a new application is added, since that is when exceptions tend to appear.

Quick check

Sources

• NIST SP 800-63B-4

Last reviewed: 19 October 2026.