Category: Identity & Access Management

Identity Assurance Level

Also known as: IAL, Identity Assurance Levels, IALs

Simply put

An Identity Assurance Level (IAL) is a rating that describes how confident an organization can be that a person is who they claim to be, based on how thoroughly their identity was checked when they first enrolled or registered. Higher levels reflect stronger identity proofing and greater confidence that a claimed identity matches a real person. IALs are defined by the National Institute of Standards and Technology (NIST) and are commonly used by federal agencies as part of assessing digital identity risk.

Formal definition

The Identity Assurance Level (IAL) is a category defined by NIST that conveys the degree of confidence that an applicant's claimed identity corresponds to their real identity, based on the rigor of the identity proofing process performed at enrollment. Under NIST SP 800-63, IAL is one of several distinct assurance components an agency selects when evaluating digital identity risk; for non-federated systems, SP 800-63-3 directs agencies to select an IAL together with an Authenticator Assurance Level (AAL), with the Federation Assurance Level (FAL) applying to federated scenarios. IAL is scoped specifically to identity proofing and enrollment confidence and should not be conflated with authentication strength (AAL) or federation assurance (FAL). NIST SP 800-63-3 establishes three defined levels, IAL1 (some confidence), IAL2 (high confidence), and IAL3 (very high, in-person or supervised remote proofing), and practitioners should confirm the exact level definitions and requirements against the applicable revision of the standard. Note that NIST issued SP 800-63-4 as a later revision that supersedes SP 800-63-3; readers should verify which revision governs their systems and consult the current authoritative NIST text, as level definitions, terminology, and requirements may differ across revisions and agency tailoring.

Why it matters

Identity Assurance Level matters because it isolates a specific and often underappreciated dimension of digital identity risk: how confident an organization can be that a claimed identity actually belongs to a real person, based on the rigor of identity proofing performed at enrollment. Many access-related failures originate not at the point of authentication but at the point of registration, when a weakly proofed identity is admitted into a system. By defining discrete levels, IAL1 (some confidence), IAL2 (high confidence), and IAL3 (very high confidence, involving in-person or supervised remote proofing), NIST gives agencies a structured way to match the strength of identity proofing to the sensitivity and risk of the transaction or resource being protected.

A common and consequential mistake is treating identity proofing (IAL) as interchangeable with authentication strength (AAL) or federation assurance (FAL). Under NIST SP 800-63-3, these are deliberately separated so that agencies can select each component according to its own risk analysis rather than assuming a single blanket 'assurance level.' Strong authenticators do not compensate for a weak or unverified enrollment, and a rigorously proofed identity can still be undermined by weak authentication. Compliance and security teams that conflate these components risk both over-engineering low-risk services and under-protecting high-risk ones.

Because IAL definitions, terminology, and requirements are anchored to a specific revision of NIST SP 800-63, practitioners must confirm which revision governs their systems. NIST issued SP 800-63-4 as a later revision that supersedes SP 800-63-3, and level definitions or requirements may differ across revisions and agency tailoring. Selecting an IAL is therefore not a one-time labeling exercise but a decision that must be revalidated against the current authoritative NIST text and any agency-specific implementation guidance.

Who it's relevant to

Federal agency identity and access management teams

Teams responsible for onboarding users and citizens to federal digital services use IAL to determine how rigorously an identity must be proofed at enrollment. Because SP 800-63-3 directs agencies to select an IAL alongside an AAL for non-federated systems (with FAL for federation), these teams must treat identity proofing as a distinct decision from authentication and federation assurance, and should confirm which revision of SP 800-63 applies to their systems.

Compliance officers and risk assessors

Those conducting digital identity risk assessments rely on IAL as one of the assurance components NIST defines for evaluating and documenting identity risk. They should ensure that the selected level (IAL1, IAL2, or IAL3) is justified by a documented risk analysis and validated against the current authoritative NIST text, rather than assuming a single blanket assurance rating covers proofing, authentication, and federation together.

System designers and identity solution architects

Architects designing enrollment and identity proofing workflows use IAL to calibrate how strongly identities are verified, up to IAL3's in-person or supervised remote proofing for very high confidence. They must avoid conflating IAL with AAL or FAL, since strong authenticators do not compensate for weak proofing, and should verify requirements against the applicable revision of SP 800-63, noting that SP 800-63-4 supersedes SP 800-63-3.

Auditors and assessors reviewing digital identity controls

Auditors evaluating whether an organization's identity proofing aligns with its stated assurance requirements should confirm that the claimed IAL matches the actual proofing rigor performed at enrollment, and that the governing revision of NIST SP 800-63 is correctly identified. Because level definitions and requirements may differ across revisions and agency tailoring, assessors should consult the current authoritative NIST source rather than relying on prior revision text.

Inside IAL

IAL Definition and Governing Publication

Identity Assurance Level (IAL) is a categorization defined in NIST Special Publication 800-63 (the Digital Identity Guidelines) that describes the rigor of the identity proofing process used to establish that a claimed identity corresponds to a real-world subject. IAL addresses identity proofing specifically and is distinct from Authenticator Assurance Level (AAL, covering authentication) and Federation Assurance Level (FAL, covering federated assertions). Readers should verify the currently applicable revision, as the guideline has evolved from SP 800-63-3 toward SP 800-63-4, which was finalized (reported as July 2025) and supersedes revision 3; agency adoption timelines may vary.

IAL1

The lowest identity assurance level. In most implementations under SP 800-63, IAL1 generally does not require identity proofing to be linked to a specific real-world person to the same rigor as higher levels, and self-asserted attributes may be permitted. Practitioners should confirm the exact requirements against the applicable revision, since specific proofing expectations differ between revision 3 and revision 4.

IAL2

An intermediate assurance level that generally requires identity proofing with evidence supporting the real-world existence of the claimed identity and verification that the applicant is associated with that identity. IAL2 permits remote or in-person proofing in most implementations, subject to the controls specified in the applicable revision. Exact evidence and validation requirements should be confirmed against the current authoritative text.

IAL3

The highest identity assurance level defined in SP 800-63. IAL3 generally imposes the most stringent identity proofing requirements, historically including additional verification rigor and, in revision 3, an in-person or supervised remote proofing component. Because these requirements have been revised in SP 800-63-4, practitioners should verify the current in-person, supervised remote, and evidence requirements against the applicable revision rather than assuming prior-revision language still governs.

Relationship to Overall Digital Identity Risk

IAL is selected based on a risk assessment of the identity proofing needs of a given service or transaction, and it is chosen independently of AAL and FAL under the SP 800-63 model. The appropriate level is a function of the impact of identity-proofing errors, and agency tailoring may apply. This entry does not cover how a specific agency maps its risk assessment to a chosen IAL; that must be confirmed against agency-specific guidance and the applicable revision.

Common questions

Answers to the questions practitioners most commonly ask about IAL.

Does a higher Identity Assurance Level automatically mean stronger authentication for a system?

No. IAL addresses the confidence in the identity proofing process, how well the system establishes that a person is who they claim to be. It does not by itself measure the strength of the authentication mechanism used at each login. In NIST SP 800-63, authenticator strength is addressed separately by the Authenticator Assurance Level (AAL), and federation aspects by the Federation Assurance Level (FAL). A common expert correction is to avoid treating IAL, AAL, and FAL as a single combined 'level'; they are selected independently based on the risks to the transaction, so a high IAL does not imply a correspondingly high AAL.

Are there really only two Identity Assurance Levels, IAL1 and IAL2?

No. NIST SP 800-63 defines three Identity Assurance Levels: IAL1, IAL2, and IAL3. IAL1 generally involves little or no identity proofing, IAL2 involves stronger evidence and validation of a claimed identity, and IAL3 involves the most rigorous proofing, which in most implementations includes verification by an authorized representative. Omitting IAL3 is a frequent error; readers should confirm the specific requirements for each level against the applicable revision of the publication.

Which revision of NIST SP 800-63 should I be working from when selecting an IAL?

You should confirm the revision currently in effect for your program and agency. NIST SP 800-63-4 was published as a final version and supersedes the earlier revision 3. Because assurance level definitions, proofing requirements, and terminology can change across revisions, and because agencies may adopt updated guidance on their own timelines, verify which revision your authorizing official or contracting authority requires before finalizing an IAL selection.

How do I determine the appropriate IAL for a given application?

The applicable revision of NIST SP 800-63 generally describes a risk-based process in which you assess the potential impacts of an identity proofing error for the specific transaction, then select the level that mitigates that risk. This selection is made independently of the AAL and FAL selections. Because agency tailoring and mission-specific factors can affect the outcome, confirm the required process and any agency-specific interpretations against current official guidance and with your authorizing official.

Does selecting an IAL satisfy an agency's overall identity and access requirements?

Not on its own. IAL addresses identity proofing confidence, but a complete implementation generally also requires selecting an appropriate AAL for authentication and, where federation is used, an FAL. In addition, the identity solution typically must fit within the broader control set applied to the system, such as the relevant NIST SP 800-53 controls under RMF or FISMA. Verify how identity assurance requirements integrate with your system's full control baseline and authorization process.

Can one IAL be applied uniformly across all users and transactions in a system?

Generally, a single IAL is not required to apply to every function. The risk-based approach in NIST SP 800-63 allows assurance levels to be evaluated per transaction or service based on the impact of an identity error, so different functions within the same system may warrant different levels. Confirm how your agency expects assurance levels to be scoped and documented, as interpretations and tailoring can vary.

Common misconceptions

There are only two Identity Assurance Levels (IAL1 and IAL2).

NIST SP 800-63 defines three Identity Assurance Levels: IAL1, IAL2, and IAL3. Omitting IAL3 is incomplete and can mislead readers about the highest-rigor proofing option available.

IAL measures how strong the authentication or login process is.

IAL specifically addresses identity proofing, not authentication. The strength of authenticators is covered by the Authenticator Assurance Level (AAL), and federated assertion strength is covered by the Federation Assurance Level (FAL). These are selected independently under the SP 800-63 model.

The IAL requirements defined in SP 800-63-3 are the current authoritative requirements.

SP 800-63-4 was finalized (reported as July 2025) and supersedes SP 800-63-3. Requirements for the IAL levels, including proofing components at IAL3, have been revised, so practitioners should verify against the currently applicable revision rather than relying on revision 3 language.

Best practices

Verify which revision of NIST SP 800-63 applies to your system before selecting an IAL, recognizing that SP 800-63-4 supersedes SP 800-63-3 and that specific proofing requirements have changed across revisions.

Select IAL (IAL1, IAL2, or IAL3) based on a documented risk assessment of the identity-proofing needs of the service, rather than defaulting to a familiar level.

Treat IAL, AAL, and FAL as separate determinations, and do not assume that a chosen identity proofing level dictates the authentication or federation assurance level.

Confirm the exact evidence, validation, and in-person or supervised remote proofing requirements for IAL3 against the current authoritative text rather than relying on prior-revision assumptions.

Check for agency-specific tailoring or interpretation of IAL requirements, as adoption timelines and implementation details may differ across organizations.

Consult the current official NIST SP 800-63 publication for authoritative requirements before implementing or asserting a given IAL, since summarized descriptions do not capture full implementation specifics.