Identity Assurance Levels Explained (NIST 800-63)
NIST Special Publication 800-63 separates confidence in a person’s identity, their login method and federated sign-in transactions. Its assurance levels help organizations match verification and authentication controls to the harm a mistaken decision could cause.
Identity assurance is the degree of confidence that a digital identity belongs to the person claiming it. It matters when an organization must decide whether to grant access, issue a benefit, disclose sensitive information or permit a high-impact transaction.
NIST Special Publication 800-63 is a widely used US framework for digital identity. It does not prescribe one universal identity check. Instead, it separates several kinds of assurance, allowing an organization to assess the risks in its service and select controls that are proportionate to those risks. The framework is influential beyond US federal systems, including among private-sector providers and organizations serving EU users.
Three dimensions of assurance
A common mistake is to treat identity verification and login security as the same problem. NIST treats them separately. Identity Assurance Levels, or IALs, concern identity proofing and enrollment. Authenticator Assurance Levels, or AALs, concern how a person authenticates after enrollment. Federation Assurance Levels, or FALs, concern the protections used when an identity provider sends sign-in information to a relying party, meaning the service that relies on that information.
- IAL asks: how confidently has the organization linked this account to a real-world identity?
- AAL asks: how confidently does a login prove control of the account and its authenticators?
- FAL asks: how safely is identity and authentication information conveyed between organizations in a federated sign-in flow?
Identity Assurance Levels: IAL1, IAL2 and IAL3
IAL1 provides the lowest level of confidence in a claimed identity. It can support accounts where an organization does not need to establish a verified real-world identity. A user may provide self-asserted information, but the service should not interpret that as proof that the person is who they say they are.
IAL2 requires identity proofing. At a high level, this involves collecting identity evidence, checking whether it appears genuine and valid, verifying that the evidence relates to the applicant, and binding the resulting identity to an account. The framework allows different proofing methods, including remote and in-person approaches, provided their controls meet the applicable requirements. IAL2 is often relevant where incorrect identity binding could cause meaningful financial, privacy or service-delivery harm.
IAL3 is intended for the highest-risk uses. It adds stronger proofing and verification expectations, greater confidence in the evidence and applicant relationship, and more rigorous controls around the proofing process. It is appropriate where a false identity claim could produce especially serious consequences, such as substantial harm to an individual, critical operations or high-value transactions. The precise methods and requirements are set out in the relevant NIST guidance and should not be reduced to a simple document-upload checklist.
AAL: assurance at sign-in
An IAL does not determine how securely someone signs in later. That is the role of AAL. AAL1 supports basic authentication for lower-risk access. AAL2 generally requires multi-factor authentication, meaning two or more different types of authentication factors, such as something a person knows, has or is. AAL3 is for the most sensitive access and applies stronger requirements, including phishing-resistant authentication and more demanding protections for authenticators and account recovery.
Phishing resistance is important because a user can enter a password and one-time code into a convincing fake website. Cryptographic authenticators, such as security keys and platform passkeys used through standards such as FIDO, can help prevent credentials from being used on the wrong site. NIST’s framework recognizes that authentication strength is also affected by enrollment, recovery, device binding and authenticator management, not just the login prompt.
FAL: assurance in federated sign-in
Federation is used when one organization, the identity provider, authenticates a person and another organization, the relying party, accepts the result. Examples include enterprise single sign-on and government or consumer identity-provider integrations. FAL addresses the assertion, the message that communicates the sign-in result and related identity information.
At a high level, FAL1 provides baseline protections for assertions. FAL2 adds stronger confidentiality protections so assertion contents are better protected in transit and from unintended disclosure. FAL3 adds protections that tie an assertion more directly to the party presenting it, helping reduce the risk that a stolen assertion can be replayed by someone else. The right FAL depends on the sensitivity of the data and transactions shared through the federation.
Choosing assurance based on risk
NIST’s central principle is risk management, not a rule that every service should use the highest level. Organizations should assess the likely impact if an account is opened under a false identity, an attacker takes over an account, or federated data is intercepted or misused. They should also consider the likelihood of those events, their user population, legal obligations, fraud patterns and the availability of accessible alternatives.
A low-risk newsletter account may need little or no identity proofing, while still benefiting from sensible account-security controls. A service handling sensitive personal records may need IAL2 and AAL2 or higher. A system supporting particularly consequential actions may need stronger proofing, phishing-resistant authentication and higher federation protections. The selections can differ: an organization may need a well-proven identity but only moderate authentication for a limited task, or minimal identity proofing but strong authentication for protecting a valuable account.
Why higher assurance creates friction
Higher assurance usually requires more evidence, more checks and stronger authentication steps. Users may need to present identity documents, complete a liveness or other verification process, use a security key or passkey, or follow stricter recovery procedures. These measures can increase completion time, create accessibility challenges and exclude people who lack conventional documents, stable devices or reliable connectivity.
That trade-off is why proportionate design matters. Organizations should minimize data collection, provide clear error handling and human support where appropriate, offer usable phishing-resistant options, and test for disparate impacts. Higher assurance can reduce fraud and improve confidence, but it is justified only when the reduction in risk outweighs the added burden on legitimate users.