Written by: Mike Horkey, VP of Growth.
Identity assurance levels, as defined by NIST SP 800-63, determine exactly how a Credential Service Provider must verify who a person is before issuing credentials or granting access. Many agencies select an IAL based on assumption rather than analysis, a gap that stays hidden until a FedRAMP audit, breach, or PIV review exposes insufficient proofing. This guide helps compliance teams, IT managers, and security architects make defensible IAL decisions that hold up under federal scrutiny.
June 19, 2026 Many agencies and organizations select an identity assurance level based on assumption rather than analysis, a pattern we observe regularly in pre-audit engagements. That gap stays hidden until something forces it into view: a FedRAMP audit flags insufficient proofing, a breach surfaces unverified identities, or a PIV credentialing review finds the enrollment process falls short of what HSPD-12 actually requires. Identity assurance levels, as defined by NIST SP 800-63, are not a sliding scale of preferences. They are a detailed technical framework specifying exactly how a Credential Service Provider must establish and confirm who a person is before issuing credentials or granting access.
This guide is written for compliance teams, IT program managers, and security architects who need to make defensible IAL decisions. As a Kantara IAL3 certified provider, NextgenID operates within this framework every day. What we consistently see is that the distance between reading the standard and implementing it correctly is where most organizations lose ground. The requirements are precise. The consequences of misreading them are real.
What NIST SP 800-63 defines about identity assurance levels
NIST SP 800-63 is the U.S. federal digital identity guideline suite. SP 800-63A specifically governs identity proofing and enrollment, and it establishes the three identity assurance levels that form the foundation of this framework. Each tier represents a progressively stronger requirement for how a Credential Service Provider establishes and confirms a claimed identity. The framework is entirely focused on the enrollment event: how confident the system can be that the person applying for a credential or access is who they claim to be, before anything is issued.
The standard also draws a clear line between two controls that organizations frequently conflate. IAL (Identity Assurance Level) governs the strength of identity proofing at enrollment. AAL (Authenticator Assurance Level) governs the strength of authentication at each subsequent login. IAL answers “who are you?” at setup. AAL answers “are you still that person?” every time they sign in. Per NIST SP 800-63-3, these are independent selections, chosen based on separate risk assessments. Treating them as a matched pair by default is one of the most common compliance errors we encounter.
It is also worth noting that the identity assurance levels defined by NIST sit within a broader international context. The European Union’s eIDAS regulation defines comparable levels of assurance (LOA), Low, Substantial, and High, that align roughly with IAL1, IAL2, and IAL3 in terms of proofing rigor. Organizations operating across jurisdictions should map their NIST IAL selections against applicable international LOA requirements to ensure consistent compliance posture.
What each identity assurance level actually requires
IAL1, evidence requirements and use cases
At IAL1, the Credential Service Provider places no requirement on linking the applicant to a real-world identity. Attributes may be entirely self-asserted. The CSP collects no identity evidence, performs no validation, and conducts no verification. This is not a security failure at the appropriate use case; it simply means identity proofing is not part of the security model. The risk calculus assumes that a fabricated identity at this tier causes minimal harm to the system or its users.
IAL2, proofing methods and evidence combinations
At IAL2, the CSP must resolve the applicant to a unique real-world identity and then validate and verify the evidence presented. Per NIST SP 800-63A, acceptable evidence combinations include one SUPERIOR piece, two STRONG pieces, or one STRONG plus two FAIR pieces. Verification must reach at least STRONG strength. Critically, IAL2 allows flexibility in how proofing occurs, it can be completed in person, remotely without supervision, or through attended remote sessions. Biometrics are optional at this tier, though some remote proofing flows incorporate liveness checks to strengthen verification against injection and spoofing attacks.
IAL3, in-person proofing, biometrics, and supervised remote sessions
At IAL3, the evidence-strength combinations are more demanding: two SUPERIOR pieces, one SUPERIOR plus one STRONG, or two STRONG plus one FAIR. The more significant change is the process itself. Proofing must occur in person, conducted by a trained proofing agent. Biometric capture and comparison are mandatory and must be bound to the enrollment event. Verification must reach SUPERIOR strength. NIST SP 800-63A Section 5.3.3.2 does allow supervised remote proofing as an alternative to physical co-location at IAL3, but only when the remote session meets the full supervised-remote requirements: continuous monitoring, a live operator for the entire transaction, tamper-resistant hardware, and integrated sensors for digital document verification. Standard remote proofing does not meet this bar. For the official NIST identity-proofing guidance, see NIST SP 800-63A identity proofing guidance, and for implementation specifics on supervised remote sessions consult the supervised remote proofing implementation notes.
Mapping identity assurance levels to the right use case
IAL1 belongs on public-facing services where no meaningful harm occurs if a user provides a fabricated identity. Informational portals, anonymous comment platforms, and low-risk self-service applications fall into this category. The defining marker is that the service does not deliver sensitive data, act on verified identity attributes, or grant access to anything of consequence based on who the user claims to be.
IAL2 covers a wide range of regulated applications where verified identity is required but physical presence is not operationally necessary. State and federal benefit portals, healthcare credentialing under non-PIV mandates, KYC and AML flows at financial institutions, and enterprise HR onboarding systems all commonly operate at IAL2. The flexibility of remote proofing makes IAL2 practical for distributed workforces and high-volume enrollment flows where supervised in-person sessions would create significant operational friction.
IAL3 is the appropriate tier when the consequences of a fraudulent enrollment are severe and when federal frameworks demand superior verification and physical presence. Programs commonly aligned with IAL3-equivalent proofing in practice include HSPD-12 and FIPS 201-3 PIV credentialing, FedRAMP High system access, DoD facility and classified system enrollment, and any program where applicable NIST or regulatory guidance requires verification at SUPERIOR strength. FedRAMP assessment guidance makes clear that identity-proofing controls must meet the required assurance level; selecting IAL2 for these programs because it seems close enough is a compliance failure, not a reasonable approximation. Auditors treat the distinction between tiers as a hard line, not a continuum.
How IAL and AAL interact in practice
NIST is explicit that organizations should select IAL and AAL as distinct risk decisions, and that matching them numerically is not a requirement. A system may require IAL3 at enrollment because it needs verified identity attributes bound to a specific individual, while only requiring AAL2 for ongoing authentication because session takeover risk is lower than enrollment fraud risk. The reverse configuration is equally valid in the right context. For the overarching NIST SP 800-63 guidance on assurance level selection, refer to the main SP 800-63 digital identity guideline.
The practical decision logic works like this: choose IAL based on the harm that results if a false identity is successfully enrolled into the system. Choose AAL based on the harm that results if a legitimate account is taken over after enrollment. For systems that deliver benefits, credentials, or access based on verified identity attributes, IAL is the primary risk driver. For systems where account compromise after enrollment is the dominant threat, AAL deserves the most attention. Most real systems require both evaluated carefully rather than defaulted to the same number.
Organizations that match IAL and AAL by habit rather than by analysis often under-invest in one control while over-investing in the other. The compliance goal is to select each level based on its specific threat model, implement it correctly, and document the rationale. When auditors review an authorization package, that documented rationale carries as much weight as the tier itself.
The real compliance cost of getting the tier wrong
Under-assuring is the more common and more consequential error. When an organization implements IAL2 for a system that requires IAL3, the downstream effects are concrete. Under FedRAMP High assessment guidance, a failure to meet required identity-proofing assurance can produce a “Not Satisfied” finding in the Security Assessment Report, and a single such finding can delay or block an authorization. Credentials issued through an insufficient proofing process may be invalid under FIPS 201-3. Any breach involving unverified identities compounds the legal and regulatory exposure because the organization cannot demonstrate it enrolled who it intended to enroll. NIST’s framework scales consequences to assurance level; choosing a lower tier does not reduce the obligation when the system’s risk profile demands a higher one.
Over-engineering is a real problem as well. Applying IAL3 controls to systems that only require IAL1 or IAL2 creates enrollment barriers, operational costs, and user friction without returning meaningful security value. IAL selection is a risk-calibrated decision, not a policy of maximum caution. NIST SP 800-63 guidance on risk-based selection makes this point directly: the objective is to match the tier to the actual threat model and implement it correctly, not to default to the highest available level across the portfolio. Agencies that over-engineer lower-risk systems often deplete the operational and budgetary resources they need to implement IAL3 correctly where it genuinely matters.
Achieving IAL3 without building the infrastructure yourself
Implementing IAL3 internally requires a specific set of operational capabilities that most agencies and large enterprises do not currently have assembled. Per NIST SP 800-63A, IAL3 demands trained proofing agents at physical enrollment locations, multi-modal biometric capture hardware, tamper-resistant enrollment environments, and audit-ready data packages. Add to that a certification path requiring independent third-party assessment, and most organizations find they are missing at least one critical element. Building the full stack from scratch takes years and significant capital investment, and the certification process alone demands sustained organizational commitment. For more on why additional layers beyond typical authentication are necessary, see IAL3 Identity Verification: Why MFA Alone Is Never Enough.
NextgenID holds Kantara IAL3 certification, independently audited against NIST SP 800-63, while also maintaining FBI CPL listing and operating as a PIV-I Credential Service Provider under a Federal Bridge Certified Certification Authority. Verifiable listings for these certifications are available through the Kantara Initiative registry, the FBI’s Criminal Justice Information Services division, and the Federal PKI program documentation. That combination of credentials on a single platform makes it possible to meet demanding federal identity requirements without building parallel infrastructure.
The practical advantage for agencies and large contractors is straightforward. NextgenID’s nationwide network of identity stations and mobile enrollment units brings IAL3-compliant supervised proofing to any workforce location, including remote sites, distributed contractor populations, and high-volume hiring environments. Enrollment packages are encrypted, audit-ready, and delivered directly into the agency’s or enterprise’s credential management systems. Read more about how large-scale programs deployed compliant proofing in How Federal Identity Proofing at Scale Was Achieved.
Kantara certification matters here precisely because it is not self-attestation. Many vendors claim alignment with NIST SP 800-63. Kantara’s third-party conformity assessment program means an independent assessor evaluated the process against NIST-derived criteria and approved it, a distinction auditors look for when determining whether IAL3 proofing on record is defensible.
What this means for your compliance program
The identity assurance levels defined by NIST SP 800-63 are a precise, consequential standard. Each tier carries specific evidence, presence, biometric, and verification requirements that determine whether an enrollment is defensible under federal guidelines. The decision is a risk calibration, not a checkbox. Many organizations misread the standard by treating IAL2 and IAL3 as roughly equivalent, a mistake that drives audit findings and credential validity failures once a program is under review.
For programs that require IAL3, partnering with a certified provider who has already built the infrastructure, earned the certification, and deployed the network is often the most direct path to compliance. NextgenID is built for exactly that work: certified, deployed, and operational across the country. If your agency or organization is working through an IAL determination or preparing for a FedRAMP or HSPD-12 review, we are ready for that conversation. For guidance on determining the right assurance level for your program, resources such as Login.gov’s assurance-level guidance can help frame the initial risk decision.
