Skip to main content
Comply Defense
Category: Identity & Access Management

Authenticator Assurance Level

Also known as: AAL, Authentication Assurance Level
Simply put

Authenticator Assurance Level (AAL) is a classification that describes how much confidence a system can have that the person logging in actually controls the credential tied to their account. Higher levels generally require stronger authentication methods, such as combining multiple factors. It is defined in NIST Special Publication 800-63B, and the specific requirements at each level should be verified against the current revision.

Formal definition

AAL is a NIST-defined measure, established in the SP 800-63B Digital Identity Guidelines, that categorizes the strength and reliability of an authentication process by which a claimant demonstrates control of one or more authenticators bound to a subscriber account. As described in the evidence, AAL1 provides basic confidence that the claimant controls a bound authenticator and generally permits single-factor authentication using a range of authenticator types enumerated in SP 800-63B. Higher levels (commonly referenced as AAL2 and AAL3) impose progressively stronger requirements, which in practice may include multi-factor and phishing-resistant authentication; practitioners should confirm the precise requirements, authenticator options, and level definitions against the applicable revision of SP 800-63B, as this terminology and the associated criteria have evolved across versions. Note that AAL addresses authentication strength specifically and is distinct from identity proofing assurance and federation assurance concepts within the broader NIST digital identity framework; agency tailoring and compliance context may affect which AAL applies.

Why it matters

Authenticator Assurance Level matters because it gives agencies and their contractors a common, standardized way to reason about how much trust to place in an authentication event, rather than relying on ad hoc judgments about password strength or login methods. In defense and public sector contexts, the AAL selected for a given system helps determine whether single-factor authentication is acceptable or whether multi-factor and phishing-resistant methods are needed. Because higher levels generally impose progressively stronger requirements, choosing the appropriate AAL is a risk decision tied to the sensitivity of the system and the information it handles.

A common expert correction is that AAL addresses authentication strength specifically and should not be conflated with identity proofing assurance (how confidently a person's real-world identity was verified) or federation assurance within the broader NIST digital identity framework. Meeting a given AAL does not by itself establish that the subscriber's identity was rigorously proofed, nor does it substitute for the other assurance dimensions an authorizing official may need to consider. Practitioners should also remember that AAL requirements and authenticator options have evolved across revisions of SP 800-63B, so a control considered compliant under one version may not map cleanly to another.

Because guidance such as recommendations to meet at least AAL2 with phishing resistance, and AAL3 where business, industry, or compliance drivers require it, depends on the applicable revision and on agency tailoring, teams should verify the precise requirements against the current authoritative text of SP 800-63B rather than assuming a fixed definition. Selecting an AAL is best treated as a documented, defensible decision within a system's overall risk and compliance posture.

Who it's relevant to

Information System Security Managers and Security Engineers
Those responsible for designing and operating authentication use AAL to determine whether single-factor authentication is acceptable or whether stronger multi-factor and phishing-resistant methods are required for a given system. They should validate authenticator choices and level requirements against the current revision of SP 800-63B and reflect any agency tailoring.
Authorizing Officials and Compliance Officers
Selecting an AAL is a risk-based decision that supports authorization and compliance posture. These stakeholders should ensure the chosen level is documented with a clear rationale, and should treat guidance such as targeting AAL2 with phishing resistance, or AAL3 where compliance or business needs demand it, as dependent on the applicable revision and context rather than a fixed mandate.
Identity and Access Management Practitioners
Those implementing IAM platforms need to distinguish AAL from identity proofing and federation assurance within the NIST digital identity framework. AAL speaks only to authentication strength, so it should not be assumed to establish how a subscriber's real-world identity was verified.
Auditors and Assessors
When evaluating authentication controls, assessors should confirm which revision of SP 800-63B governs and whether the implemented authenticators and processes satisfy the intended level. Because level definitions and authenticator options have evolved across versions, findings should reference the applicable authoritative text.

Inside AAL

AAL Concept and Source
Authenticator Assurance Level (AAL) is a concept defined in the NIST SP 800-63 Digital Identity Guidelines, specifically the SP 800-63B volume on authentication and authenticator management. AAL expresses the degree of confidence that a claimant controls the authenticator(s) bound to a subscriber's account at the time of an authentication event. Practitioners should verify the applicable revision of SP 800-63B, as the guidelines have been revised and the terminology continues to evolve.
AAL as Distinct from IAL and FAL
Within the SP 800-63 model, AAL addresses authentication strength and is separate from Identity Assurance Level (IAL), which addresses identity proofing, and Federation Assurance Level (FAL), which addresses federated assertions. Conflating these components is a common error; each is generally selected independently based on the risk to the system or transaction.
Tiered Assurance Levels
AAL is expressed as a set of ascending levels that reflect increasing authentication rigor, generally moving from single-factor authentication at the lowest level toward multi-factor and hardware-based or verifier-impersonation-resistant approaches at higher levels. Because the precise requirements, permitted authenticator types, and level definitions depend on the applicable revision of SP 800-63B, readers should confirm the exact criteria against the current authoritative text rather than relying on remembered numeric thresholds.
Relationship to Authenticator Types
AAL determinations depend on the characteristics of the authenticators used, such as memorized secrets, out-of-band devices, cryptographic software or hardware, and multi-factor authenticators. The level achievable in a given implementation is tied to which authenticator types are permitted and how they are managed, per the applicable SP 800-63B requirements.
Risk-Based Selection
The appropriate AAL for a system or transaction is generally selected through a risk assessment that considers the potential impact of authentication errors. In federal contexts, this selection often interacts with agency risk management processes and, where applicable, the NIST Risk Management Framework and SP 800-53 controls, though AAL itself is defined under SP 800-63B rather than those documents.

Common questions

Answers to the questions practitioners most commonly ask about AAL.

Does achieving a higher Authenticator Assurance Level (AAL) automatically mean a system is more secure overall?
No. AAL, as described in NIST SP 800-63B (part of the NIST SP 800-63 Digital Identity Guidelines), addresses the strength of the authentication process specifically, how confidently a system can assert that a claimant controls one or more authenticators bound to an account. A higher AAL reduces the risk of authenticator compromise, but it does not by itself address other security dimensions such as access control, encryption of data at rest, vulnerability management, or the assurance of the original identity proofing. Authentication assurance and overall system security are distinct concepts, and compliance with a target AAL should not be equated with a comprehensive security posture. Readers should verify how AAL requirements integrate with their broader control implementation against current authoritative sources.
Is AAL the same thing as the Identity Assurance Level (IAL) or Federation Assurance Level (FAL)?
No, these are distinct components within the NIST SP 800-63 framework and should not be conflated. In the revised structure of the Digital Identity Guidelines, Identity Assurance Level (IAL) concerns the identity proofing process, the confidence that an applicant is who they claim to be. Authenticator Assurance Level (AAL) concerns the authentication process, the confidence that a returning claimant controls the bound authenticator. Federation Assurance Level (FAL) concerns the strength of assertions conveyed in a federated environment. An organization generally selects each level based on separate risk assessments, and a given system may combine different levels for each component. Confirm the current terminology and structure against the applicable revision of NIST SP 800-63, as this guidance has evolved across revisions.
How does an organization determine which AAL applies to a given system or application?
AAL selection is generally driven by a risk assessment that considers the potential impact of an authentication failure, consistent with the process described in NIST SP 800-63. In federal contexts, this determination is typically made in coordination with the system's risk management activities and may be influenced by agency-specific tailoring and the categorization of the information involved. There is no single fixed mapping that applies universally, and requirements can differ between federal civilian systems under FISMA, DoD systems under the RMF, and other environments. Organizations should document the rationale for the chosen AAL and verify applicable requirements against current official guidance and any agency-specific direction.
What types of authenticators are generally associated with higher AALs?
Higher AALs generally require stronger authentication mechanisms, and in most implementations they call for multi-factor authentication combining factors such as something you know, something you have, and something you are. NIST SP 800-63B describes progressively stronger requirements as the AAL increases, including provisions related to cryptographic authenticators and resistance to certain attacks at the highest level. Because the specific permitted authenticator types and their required properties are defined in the applicable revision of SP 800-63B and may change, readers should consult the current authoritative text rather than relying on generalized descriptions when configuring authenticators.
Does meeting a target AAL at initial authorization satisfy the requirement on an ongoing basis?
Not necessarily. Authentication controls, like other controls, are generally subject to ongoing verification within a continuous monitoring program rather than being treated as a one-time achievement. Authenticator technologies, threat conditions, and the requirements in the applicable revision of NIST SP 800-63 can change over time, and reauthorization or reassessment activities may re-examine whether the implemented authentication mechanisms still meet the intended AAL. Organizations should confirm how their monitoring and reauthorization processes address AAL against current authoritative sources and any agency-specific direction.
How does AAL relate to compliance obligations under frameworks such as FISMA or the DoD RMF?
AAL is defined within the NIST SP 800-63 Digital Identity Guidelines and provides a way to express authentication strength that other frameworks may reference or incorporate. How AAL requirements flow into obligations under FISMA for federal civilian systems, or under the DoD Risk Management Framework, generally depends on the applicable control baselines, agency tailoring, and any supplemental guidance in effect. AAL by itself is not a complete compliance regime, and satisfying an AAL does not automatically satisfy the full set of authentication or identity-related controls a given authorization may require. Readers should verify the specific relationship against the current authoritative publications and applicable agency requirements.

Common misconceptions

A higher AAL is always better and should be applied everywhere.
AAL is intended to be selected based on the assessed risk of a specific system or transaction. Applying an unnecessarily high AAL can impose cost and usability burdens without a corresponding risk reduction. The appropriate level is generally the one commensurate with the impact of an authentication failure, as determined through a risk assessment against the applicable SP 800-63B guidance.
AAL, IAL, and FAL are the same thing or must all be set to the same level.
Under the SP 800-63 model these are distinct components: AAL covers authentication strength, IAL covers identity proofing, and FAL covers federated assertions. They are generally selected independently, so a system may combine different levels across these dimensions depending on its requirements.
Meeting a given AAL means a system is compliant and secure.
AAL addresses only the authentication assurance component and does not by itself constitute overall compliance or security. Compliance is not the same as security, and an AAL determination does not replace broader control obligations, authorization decisions, or continuous monitoring required under the relevant framework applicable to the system.

Best practices

Confirm which revision of NIST SP 800-63B applies to your environment before determining or citing AAL requirements, since level definitions and permitted authenticator types have changed across revisions.
Select AAL through a documented risk assessment tied to the potential impact of authentication errors, rather than defaulting to the highest level or a uniform level across all systems.
Treat AAL, IAL, and FAL as separate determinations and document each independently to avoid conflating authentication strength with identity proofing or federation assurance.
Verify that the authenticator types deployed actually support the intended AAL under the applicable SP 800-63B criteria, including management and lifecycle requirements for those authenticators.
Coordinate AAL decisions with your broader risk management and authorization processes, recognizing that meeting an AAL is one component and not a substitute for overall compliance or security obligations.
Reconfirm agency-specific interpretations or tailoring where applicable, and validate any specific level requirements against current official NIST guidance before implementation.