NIST Digital Identity Guidelines: IAL, AAL, and FAL Levels

The NIST digital identity assurance levels are three separate 1-to-3 rating scales that federal agencies (and voluntarily, many private organizations) use to describe how strong a digital identity system has to be. Published in NIST Special Publication 800-63, the scales cover identity proofing (how confident the system is that you are who you claim), authentication (how strongly you prove it’s still you at login), and federation (how securely identity data moves between organizations).¹ Revision 4, finalized in July 2025, is the current version.²

Three Scales, Rated Independently

SP 800-63 splits digital identity into three components and rates each one on its own. That separation matters because a service might need very high confidence in who you are but only moderate login strength, or the reverse.¹

Identity Assurance Level (IAL) measures confidence that a real person matches the claimed identity. Defined in SP 800-63A.
Authenticator Assurance Level (AAL) measures the strength of the login process once the account exists. Defined in SP 800-63B.
Federation Assurance Level (FAL) measures the security of identity data passed between organizations. Defined in SP 800-63C, and only relevant where identity information crosses systems.

Across all three scales, Level 1 fits low-risk services where a mistake causes minimal harm, Level 2 fits moderate-risk systems handling sensitive but not critical data, and Level 3 is reserved for high-risk environments where identity fraud could cause serious damage, such as federal tax systems or medical benefits portals.³

Identity Assurance Levels (IAL1, IAL2, IAL3)

Identity proofing is the upfront step, before any credential is issued, in which the system confirms you’re a real person matching the identity you claim. SP 800-63A defines what evidence is required and how thoroughly it must be checked at each tier.⁴

IAL1: Self-Asserted

No formal identity proofing happens at IAL1. You might supply a name or email address, but nobody checks that it’s real. Attributes at this level are treated as self-asserted and are neither validated nor verified.⁴ It works fine for low-stakes services where a person’s real identity doesn’t affect financial records or legal standing.

IAL2: Verified Evidence, Remote or In-Person

IAL2 is where real checking begins. You submit evidence supporting the existence of your claimed identity, typically government-issued documents such as a driver’s license or passport, and a Credential Service Provider verifies both that the documents are authentic and that you’re legitimately associated with them.⁴

Revision 4 provides two pathways. A biometric pathway uses automated facial comparison or other biometric matching to confirm the person presenting the evidence is the person depicted on it. A non-biometric pathway relies on visual comparison by a proofing agent during a live or recorded session. Either way, presentation attack detection is required, so the system can resist spoofing with photos, masks, or screen injections.⁵

IAL3: On-Site, Attended

IAL3 requires an in-person proofing session attended by a trained agent, who inspects high-strength evidence with physical security features designed to resist counterfeiting. Biometric information is collected and retained for future comparison.⁴

Agencies that can’t station an agent with you may use a kiosk-based option instead. You visit a CSP-controlled kiosk while the agent participates by high-resolution video. The kiosk must include integrated scanners for digital validation, be physically monitored against tampering, and meet security controls comparable to the FISMA moderate baseline. This is not the same as doing IAL3 from your laptop at home; the agency controls the hardware and environment.⁴

Authenticator Assurance Levels (AAL1, AAL2, AAL3)

Once your identity is established, SP 800-63B governs how you prove you’re the same person at each login.⁶

AAL1: Single-Factor

AAL1 permits single-factor or multi-factor authentication. The most common single factor is a password. One clarification worth carrying forward: a biometric alone doesn’t count as an authenticator under these guidelines. A fingerprint scan on your phone counts as unlocking a physical authenticator (the phone) using biometrics, which is actually multi-factor, not a standalone biometric login.⁶

AAL2: Multi-Factor

AAL2 requires proof of two distinct factors: something you know (a password) combined with something you physically have (a hardware token or phone-based authenticator). That might mean entering a password and then approving a push notification, or using a dedicated security key alongside a PIN. At least one authenticator in the combination must be physical.⁶

AAL3: Hardware-Backed, Phishing-Resistant

AAL3 is the strictest login tier. The authenticator must use public-key cryptography with a non-exportable private key stored in a hardware-protected environment validated at FIPS 140 Level 1 or higher. The key cannot be copied or extracted, which is precisely what makes it trustworthy.⁷

Phishing resistance is mandatory at AAL3. NIST defines it as the ability of the authentication protocol to prevent disclosure of secrets to a fake login page without relying on the user to spot the deception. In practice, the authenticator cryptographically binds its output to the specific website or session, so a convincing phishing page gets nothing usable. Authenticators requiring manual entry of a code, including one-time passwords and SMS codes, explicitly fail this test.⁶

Password Rules Under Revision 4

Password requirements changed meaningfully in Revision 4. Passwords used as a single authentication factor now require a minimum of 15 characters. Passwords used only as part of a multi-factor setup can be as short as 8 characters.⁶

Mandatory periodic password rotation is now prohibited. Organizations cannot force users to change passwords on a schedule. The only exception is when there’s evidence the password has been compromised, in which case a change must be forced.⁸

Federation Assurance Levels (FAL1, FAL2, FAL3)

Federation is how one system tells another who you are. When you log into a government service using credentials managed by a separate identity provider, that provider sends a signed digital statement (an assertion) about you. SP 800-63C sets the rules for how those assertions are created, transmitted, and protected.⁹

FAL1: The identity provider digitally signs the assertion to prove its origin. The receiving party can verify the data hasn’t been altered, but the assertion travels in readable form.
FAL2: The assertion must be both signed and encrypted to the receiving party’s public key, so only the intended recipient can read the identity information.
FAL3: On top of FAL2 protections, you must cryptographically prove possession of a key bound to the assertion, preventing an attacker from intercepting an assertion and replaying it in a separate session.

These tiers map to common protocols. Security Assertion Markup Language (SAML) and OpenID Connect are the most widely used, with FAL1 corresponding to basic implementations and higher levels adding encryption and key-binding features.¹⁰

How Agencies Pick a Level

Each component is chosen against the risk profile of the specific service. A public information portal with no personalization might sit at IAL1/AAL1 because there’s nothing sensitive behind the login. A benefits system that pays out real money will likely require IAL2 proofing at minimum, AAL2 authentication for routine access, and a step-up to AAL3 for high-value transactions. Systems handling classified or medically sensitive data cluster at the top.³

Because the three scales are independent, mixed combinations are normal. A service might use IAL2 proofing (because it needs to know your real identity) with AAL2 authentication (because moderate login security is enough for the transactions involved) and no federation at all.

Where Syncable Passkeys and Wallets Fit

Two Revision 4 additions cross these tiers in ways worth flagging, because the level a technology can reach isn’t obvious from the marketing.

Syncable passkeys, which copy across your devices through a cloud sync service, are permitted at AAL2 but prohibited at AAL3. The private key must be exportable to enable syncing, and that makes the authenticator unable to meet AAL3’s non-exportable key requirement. When used at AAL2, the sync fabric must encrypt authentication keys using at least 112-bit security strength, and access to the sync service must be protected by multi-factor authentication equivalent to AAL2.⁸

Subscriber-controlled wallets, new in Revision 4, let you store attribute bundles issued by a CSP and present them directly to services. A wallet must require an activation factor (biometric confirmation or a PIN) before it can sign anything, and signing keys cannot be synced or shared across devices. If the wallet’s signing key doubles as a holder-of-key authenticator at FAL3, non-exportable key storage becomes mandatory.¹¹

Who Has to Comply

Federal agencies are required to follow NIST guidelines through the Federal Information Security Modernization Act of 2014, which directs agencies to implement information security protections proportional to the risk and magnitude of harm from unauthorized access or data loss.¹² For private-sector organizations, adoption is voluntary, though government contractors, healthcare providers handling federal data, and financial institutions often face contractual or regulatory pressure to meet the standards.

NIST itself has no enforcement authority. It writes the standards; other agencies and contracting bodies enforce them. That means the practical consequences of noncompliance depend on the regulatory context: a federal agency faces FISMA audit findings, a defense contractor faces contractual remedies and potential DOJ investigation, and a private company with no government ties faces no direct penalty, though adopting the standards remains a strong defense in litigation involving data breaches or identity fraud.¹³

1
National Institute of Standards and Technology. Special Publication 800-63
2
National Institute of Standards and Technology. SP 800-63-4, Digital Identity Guidelines
3
National Institute of Standards and Technology. NIST Special Publication 800-63-3 – Digital Identity Guidelines
4
National Institute of Standards and Technology. NIST Special Publication 800-63A – Digital Identity Guidelines: Enrollment and Identity Proofing Requirements
5
National Institute of Standards and Technology. Identity Proofing Requirements
6
National Institute of Standards and Technology. NIST Special Publication 800-63B – Authentication and Lifecycle Management
7
National Institute of Standards and Technology. Authentication Assurance Levels
8
National Institute of Standards and Technology. Digital Identity Guidelines: Authentication and Authenticator Management (NIST SP 800-63B-4)
9
National Institute of Standards and Technology. NIST Special Publication 800-63C: Federation and Assertions
10
National Institute of Standards and Technology. NIST Special Publication 800-63C – Digital Identity Guidelines: Federation and Assertions
11
National Institute of Standards and Technology. Subscriber-Controlled Wallets
12
National Institute of Standards and Technology. Federal Information Security Modernization Act (FISMA) Background
13
National Institute of Standards and Technology. Regulated Cybersecurity: The Consequences of Non-Compliance