Assurance levels: IAL, AAL, FAL

NIST's Digital Identity Guidelines describe the strength of an identity system with three separate assurance levels: IAL for identity proofing, AAL for authentication, and FAL for federation. Each has three levels, and you select each one separately. This page summarizes all three from SP 800-63-4 (July 2025) and its companion volumes, with a detailed table of AAL1 to AAL3 requirements from SP 800-63B-4, including the reauthentication timeouts and the phishing-resistance rules that changed in this revision.

Three assurance levels, three questions

SP 800-63-4 section 3.3.1 defines them by the failure each one guards against:

IAL, Identity Assurance Level

"The robustness of the identity proofing process to determine the identity of an individual." Is this person who they claim to be in real life?

AAL, Authentication Assurance Level

"The robustness of the authentication process itself and the binding between an authenticator and a specific individual's identifier." Is the person signing in the same one who enrolled?

FAL, Federation Assurance Level

"The robustness of the federation process used to communicate authentication and attribute information to an RP from an IdP." Can the relying party trust the assertion it received?

Selection starts from an impact assessment (SP 800-63-4 section 3.3.3). The initial mapping is low impact to level 1, moderate to level 2, and high to level 3. For FAL, high impact maps to FAL2 or FAL3 after a further assessment of the risk of a compromised IdP. Organizations then tailor. Federal agencies SHALL select at least AAL2 when personal information is made available online (SP 800-63B-4 section 2).

IAL in brief

• IAL1: supports the real-world existence of the claimed identity and provides some assurance the applicant is associated with it. Core attributes are validated against authoritative or credible sources.
• IAL2: additional evidence and a more rigorous process for validating evidence and verifying identity.
• IAL3: adds a trained proofing agent interacting with the applicant in an on-site attended session, and collection of at least one biometric.

Proofing is optional when a service does not need validated personal information. In that case there is no IAL. The requirements are in SP 800-63A-4.

AAL1, AAL2 and AAL3 requirements

From SP 800-63B-4 sections 2.1 to 2.3 and the non-normative summary in Table 1. Strength words are as written in the normative sections.

Two reminders from the same document. Section 3.2.5 says out-of-band and OTP authenticators "SHALL NOT be considered phishing-resistant". Section 3.1.7.2 says that if a multi-factor authenticator's flag shows the activation factor was not used (for WebAuthn, UV not set), the authentication "SHALL be treated as single-factor". See MFA strength and phishing-resistant MFA.

What changed from SP 800-63B (2017)

• Reauthentication. In 2017, AAL2 sessions SHALL reauthenticate at least every 12 hours and after 30 minutes of inactivity. AAL3 was 12 hours and 15 minutes, both SHALL. In SP 800-63B-4, AAL2 is a SHOULD of 24 hours overall and 1 hour inactivity. AAL3's 12-hour overall limit remains a SHALL, but its 15-minute inactivity limit is now a SHOULD.
• Phishing resistance at AAL2. 2017 did not require AAL2 verifiers to offer it. SP 800-63B-4 makes offering it a SHALL.
• AAL3 hardware. 2017 required a hardware-based authenticator at AAL3. SP 800-63B-4 requires a non-exportable key instead (Appendix E) and lowers the required FIPS 140 level for AAL3 authenticators. In practice hardware is still involved: section 3.2.13 says a non-exportable authenticator SHALL be a separate piece of hardware or an embedded processor or execution environment such as a secure element, TEE or TPM.

FAL briefly

SP 800-63C-4 Table 1 summarizes the federation levels:

At every FAL the IdP SHALL sign the assertion and the RP SHALL validate it. FAL3 adds protection against a compromised IdP: the RP SHALL verify that the subscriber also controls an authenticator, either named in a holder-of-key assertion or bound at the RP. The protocol details are on OpenID Connect and SAML.

Choosing levels for privileged users

SP 800-63-4 Table 2 describes the user profile for AAL3 as including cases where "privileged user access could result in a breach that would constitute a major incident under OMB guidance". Table 1 places "administrator access to servers, systems, or security data" in the IAL3 profile. For administrators of identity systems, cloud tenancies and security tooling, the practical reading is:

• Authenticate administrators at AAL3: device-bound, non-exportable, phishing-resistant cryptographic authenticators (security keys, smart cards), not synced passkeys. See privileged accounts.
• Enforce the 12-hour overall limit and a short inactivity timeout for admin sessions, and require full reauthentication at AAL3.
• If admin access is federated, treat the IdP as part of the admin attack surface, and consider FAL3 where IdP compromise is in your threat model.
• For ordinary workforce users, AAL2 with phishing-resistant authenticators offered (and required, for US federal systems) is the baseline.
• Document the selected xALs per user group and why. SP 800-63-4 requires that the selection process be documented (SHALL).

Sources

1. NIST SP 800-63-4: Digital Identity Guidelines, NIST. Public domain (U.S. government work).
2. NIST SP 800-63B-4: Authentication and Authenticator Management, NIST. Public domain (U.S. government work).
3. NIST SP 800-63C-4: Federation and Assertions, NIST. Public domain (U.S. government work).
4. NIST SP 800-63B (2017): Authentication and Lifecycle Management (superseded), NIST. Public domain (U.S. government work).