NIST SP 800-63 Digital Identity Guidelines: Assurance Levels Explained

The NIST SP 800-63 Digital Identity Guidelines are the federal government’s technical framework for verifying who someone is online and keeping their identity secure across digital services. The framework, now in its fourth revision (SP 800-63-4, finalized July 2025), separates digital identity into three distinct problems and rates each one independently: proving a person is who they claim to be at enrollment, authenticating them when they return, and safely sharing identity data between organizations.¹ Federal agencies are required to follow it. Most private organizations handling sensitive data treat it as the benchmark for their own identity systems.

The Three Volumes

The framework is published as three companion documents, each addressing a different stage of the identity lifecycle. An organization might need strong proofing but only moderate login security, or the reverse, so the levels are chosen independently rather than bundled together.

SP 800-63A covers identity proofing: collecting evidence about a person, confirming that person exists, and tying them to a new account. Get this wrong and every later security measure protects a fraudulent identity.²

SP 800-63B handles authentication and credential management: how a returning user proves they are the same person who originally enrolled. It covers password policies, one-time codes, hardware tokens, biometrics, and session management.³

SP 800-63C addresses federation: letting a user log in through one identity provider and access other services without creating separate credentials for each. It specifies how identity data should be packaged, signed, encrypted, and transmitted between organizations.⁴

How Agencies Pick Assurance Levels

Earlier federal guidance under OMB M-04-04 used a single “Level of Assurance” score from 1 to 4, which forced agencies to apply the same intensity to proofing, authentication, and federation even when the risks in those areas were very different. Starting with Revision 3, the framework retired that approach. Agencies now select an Identity Assurance Level (IAL), an Authenticator Assurance Level (AAL), and a Federation Assurance Level (FAL) independently for each system.⁵

To make the selection, agencies run a Digital Identity Risk Assessment. They evaluate potential harms across categories that include financial loss, unauthorized release of sensitive information, damage to reputation, harm to agency programs, threats to personal safety, and civil or criminal violations. Each category is rated Low, Moderate, or High. The highest-impact rating across all categories drives the minimum assurance level needed.⁵

Not every combination is valid. If a system stores personal information, even at IAL1, it cannot rely on single-factor authentication at AAL1. Multi-factor authentication at AAL2 or higher is required whenever personal data is involved, because weak login security on an account full of verified personal details creates an easy path to identity theft.⁵

Revision 4 broadens the risk assessment to include impacts on individuals and communities, not just the organization. Agencies must consider whether their controls create barriers for people with different capabilities, resources, or technology access.⁶

Identity Assurance Levels

Identity Assurance Levels describe how confident an organization can be that it has correctly identified a real person at enrollment. There are three tiers, and the requirements changed significantly between Revision 3 and Revision 4.

IAL1

Under Revision 3, IAL1 required no proofing at all. Users could self-assert their attributes. Revision 4 raised the bar. IAL1 now requires collecting at least one piece of identity evidence at the “fair” level (something that can be digitally validated or includes a photo) or higher, and validating the applicant’s core attributes and government identifier against an authoritative source.⁷ Even low-risk services now have a baseline check to catch the most obvious fabricated or stolen identities.

IAL2

IAL2 requires stronger evidence, typically a government-issued photo ID like a driver’s license or passport, validated against the issuing or authoritative source. Remote proofing is allowed, often using high-resolution document images combined with liveness checks that confirm a real person is physically present rather than a photograph. Not every field on every document type can be verified this way.⁸ Federal agencies collecting this information must comply with the Privacy Act of 1974, which limits how they store, use, and share personal records.⁹

IAL3

IAL3 is the most rigorous tier and the only one that requires on-site, attended proofing. The applicant must appear before a trained proofing agent in person or through a controlled kiosk. Multiple pieces of high-integrity evidence are checked for security features and compared against the person’s physical appearance using biometrics. This level is reserved for systems where the cost of identity fraud is extreme, such as those handling sensitive medical data or large financial transactions.⁷

Authenticator Assurance Levels

Authenticator Assurance Levels define how hard it is for an attacker to break into an account after the rightful owner has been proofed and enrolled. Each tier stacks additional technical requirements on top of the one below.

AAL1

AAL1 allows single-factor authentication. A password alone can suffice. The framework permits this but encourages services to offer multi-factor options even at this level. Passwords get phished, reused, and stuffed into automated attack tools every day, so AAL1 is rarely appropriate for any system holding personal or financial data, and the framework outright prohibits pairing IAL2 or higher with AAL1.¹⁰

AAL2

AAL2 requires multi-factor authentication. The user must prove at least two of the following: something they know (a password), something they have (a phone or hardware token), or something they are (a biometric). A compromised password alone is not enough, which eliminates the most common remote attack vectors. Most modern services aiming for a practical balance of security and usability target this tier.¹⁰

AAL3

AAL3 is the ceiling. It requires a hardware-based cryptographic authenticator with a private key that cannot be exported from the device. The authenticator must also be phishing-resistant, meaning the login protocol itself blocks the attack rather than relying on the user to notice a fake website. Under Revision 3, multi-factor authenticators at AAL3 must be validated at FIPS 140 Level 2 overall with at least Level 3 physical security, ensuring tamper resistance against physical attacks on the device.¹⁰¹¹

Phishing Resistance

Phishing resistance is one of the framework’s most consequential concepts. An authenticator qualifies as phishing-resistant only if the protocol itself prevents a user from handing valid credentials to a fake site. That rules out one-time codes sent by SMS or generated by an app, because those require manual entry and don’t bind to the specific session or server. To qualify, the authenticator output must be cryptographically tied to either the authenticated communication channel (channel binding) or the verified hostname of the real server (verifier name binding). FIDO2/WebAuthn-based authenticators are the most common example.¹²

Where Passkeys Fit

Passkeys, the industry term for syncable FIDO credentials stored in a cloud-based key chain, are now explicitly addressed in Revision 4. They can satisfy AAL2 requirements, provided the sync fabric encrypts keys at rest with at least 112 bits of security strength and access to the sync fabric itself is protected by multi-factor authentication. The verifier must also confirm the user was locally verified on the device (the “User Verified” flag). Passkeys cannot meet AAL3, because syncing inherently violates the requirement that private keys be non-exportable.¹³

Federal enterprise deployments face additional constraints. The sync fabric must meet FISMA moderate protections, devices must be managed by mobile device management software, and agency-managed accounts must control access to the sync fabric.¹³

Federation Assurance Levels

Federation Assurance Levels govern what happens when identity data travels between organizations, such as when someone logs into a government service using a credential issued by a separate identity provider. Even if the login is solid, a poorly protected assertion could leak personal data or be replayed by an attacker.

FAL1

FAL1 requires the identity provider to digitally sign the assertion using approved cryptography. The relying party validates the signature to confirm the assertion hasn’t been tampered with and came from the expected identity provider. This is the baseline for any system using protocols like SAML or OpenID Connect.¹⁴

FAL2

FAL2 adds encryption on top of the signature. The identity provider encrypts the assertion contents using either the relying party’s public key or a shared symmetric key unique to that specific relying party. If an attacker intercepts the assertion in transit, they cannot read its contents.¹⁵

FAL3

FAL3 requires the user to prove they personally control a cryptographic key linked to the assertion. This prevents replay attacks, where an attacker intercepts a valid assertion and reuses it to impersonate the legitimate user. The identity provider and relying party must use a holder-of-key or bound-authenticator mechanism to verify that the person presenting the assertion is the same individual who originally authenticated.¹⁴

What Revision 4 Changed

Revision 4’s most visible policy shift is its focus on equity. Earlier versions optimized almost exclusively for security. Revision 4 treats barriers to access as a risk category alongside unauthorized access. When a portion of the target population lacks the technology needed for remote proofing, such as affordable broadband or a smartphone with a decent camera, agencies are directed to offer in-person alternatives. The guidelines specifically mention appointments at community centers, post offices, or partner business facilities, and even proofing at an individual’s home.⁶

Biometric systems face new performance requirements. A facial recognition system used for identity proofing must achieve a false match rate of one in 10,000 or better across all demographic groups, including breakdowns by sex and skin tone. A single fixed threshold must be used. Adjusting the threshold per demographic group is not allowed.¹⁶

Organizations must also provide a documented grievance and redress process that is accessible and trackable. When automated systems flag or reject an applicant, human support staff must be available to intervene and override algorithmic decisions, and those staff must be trained on the alternatives available to help someone gain access through a different path.⁶

Who Has to Follow It

Two OMB memoranda drive federal adoption. M-19-17 is the foundational directive that requires all federal executive agencies to align their identity management systems with the SP 800-63 framework. Agencies must assess each digital service, document their selection of assurance levels based on the potential impact of a failure, and report progress to OMB.¹⁷

M-22-09, issued in January 2022, layers zero trust requirements on top. It mandates that all agency staff, contractors, and partners use phishing-resistant multi-factor authentication, the kind where the protocol itself blocks credential theft. The original deadline for meeting these goals was the end of fiscal year 2024.¹⁸ The mandate remains in effect, and agencies that fall short face scrutiny under the Federal Information Security Modernization Act, which gives the Department of Homeland Security authority to oversee civilian agencies’ implementation of information security policies.¹⁹

For organizations outside the federal government, none of these mandates apply directly. But many industries, including healthcare, financial services, and state government, treat the SP 800-63 framework as a de facto standard when designing their own identity systems, and auditors increasingly reference it when evaluating the adequacy of authentication and proofing controls.

1
NIST Computer Security Resource Center. SP 800-63-4, Digital Identity Guidelines
2
National Institute of Standards and Technology. NIST SP 800-63A – Digital Identity Guidelines: Enrollment and Identity Proofing
3
National Institute of Standards and Technology. NIST SP 800-63B – Digital Identity Guidelines Authentication and Lifecycle Management
4
National Institute of Standards and Technology. NIST SP 800-63C – Federation and Assertions
5
National Institute of Standards and Technology. NIST SP 800-63-3 – Digital Identity Guidelines
6
National Institute of Standards and Technology. NIST SP 800-63-4 – Digital Identity Guidelines
7
National Institute of Standards and Technology. NIST SP 800-63A – Identity Assurance Level Requirements
8
National Institute of Standards and Technology. NIST SP 800-63A – IAL2 Remote Identity Proofing
9
Office of the Law Revision Counsel. 5 USC 552a – Records Maintained on Individuals
10
National Institute of Standards and Technology. NIST SP 800-63B – Authentication Assurance Levels
11
NIST Computer Security Resource Center. FIPS 140-3, Security Requirements for Cryptographic Modules
12
National Institute of Standards and Technology. NIST SP 800-63B – Authenticators
13
NIST Pages. SP 800-63B – Syncable Authenticators
14
National Institute of Standards and Technology. NIST SP 800-63C – Federation Assurance Level
15
National Institute of Standards and Technology. NIST SP 800-63C – Federation and Assertions
16
National Institute of Standards and Technology. NIST SP 800-63B-4 – Digital Identity Guidelines: Authentication and Authenticator Management
17
Digital.gov. M-19-17 Enabling Mission Delivery through Improved Identity, Credential, and Access Management
18
The White House. M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
19
Cybersecurity & Infrastructure Security Agency. Federal Information Security Modernization Act