NIST SP 800-63: the assurance levels that measure 'strong enough'

“Make the login secure”

Daniel is in a planning meeting for a new customer app that will let people move money between accounts. The product manager says the sign-in has to be “secure but not annoying.” The compliance lead says it has to be “strong enough for the regulator.” The engineer next to Daniel asks what either of those means in practice. Nobody can answer, because “secure” and “strong enough” aren’t measurements. Then the compliance lead opens the regulator’s guidance and reads one line aloud: “IAL2 and AAL2.” Suddenly there’s something everyone can build to and check against.

That line comes from NIST SP 800-63. The previous articles toured protocols, from the core federation stack to the veterans and the vanguard. Knowing which protocol to use, Kerberos, SAML, OIDC, or FIDO2, tells you how identity works. It doesn’t answer the question a risk owner actually asks: how strong does this have to be? Strong enough for a discussion forum and strong enough for a bank are very different things, and you need a precise, shared vocabulary to specify and compare them.

NIST SP 800-63, the U.S. Digital Identity Guidelines, is cited far beyond the United States, by regulators, auditors, and procurement teams, as the standard way to measure identity assurance. Its central move is to refuse a single “security level” and break assurance into three independent dimensions, each rated from 1 to 3. A protocol tells you what’s possible; an assurance level tells you what’s required. You need both to turn “build something secure” into a design you can specify, build, and defend in an audit.

Three independent dials

The guidelines come in three volumes, one per dimension: 63A covers enrollment and proofing (IAL), 63B covers authentication (AAL), and 63C covers federation (FAL). They’re separate precisely because the three are meant to be chosen separately.

How sure you are about who the person is (IAL), how strongly they authenticate (AAL), and how safely a federated assertion travels (FAL) are three different questions. You can need strong proofing with modest sign-in friction, or the other way round. Merging them into one “level” is the mistake the standard exists to prevent. Let’s take each dial in turn and see how it connects to something from earlier in the module.

IAL: proofing who the person is

IAL answers a one-time question asked at enrollment: how confident are we that this is a real, specific person? It’s about identity proofing, what you do once, when the account is created, to tie it to an actual human. It says nothing about how they sign in later.

The jump that matters is from IAL1 to IAL2, from “you typed a name” to “we checked real evidence that you’re that person.” It’s the identity proofing that guards sensitive onboarding, and it’s why a telehealth specialist or a bank customer goes through document and liveness checks that a forum sign-up never asks for. A higher IAL means more friction and more data collected, so you raise it only when the risk of a fake or mistaken identity justifies it. For Daniel’s money-moving app, IAL2 is what keeps someone from opening an account in a stranger’s name.

How proofing actually happens

IAL2 proofing in practice has three steps: collect identity evidence, such as a government ID; validate that the evidence is genuine; and verify that the person presenting it is its rightful owner, more and more often by matching a selfie to the document with liveness detection that defeats printed photos and deepfakes. Something has fallen out of favor along the way: knowledge-based verification, questions like “what was your previous address?”, is now discouraged, because years of breaches have made those answers public. IAL3 adds a supervised step, in person or remote with a trained operator watching.

Proofing has become an arms race. Synthetic identities and AI-generated documents keep improving, so the bar for “we verified a real, specific human” keeps rising, which is also why proofing increasingly relies on signals beyond the document itself.

AAL: how strongly the user signs in

AAL answers a question asked at every sign-in: how strongly does the returning user prove it’s really them? This is the territory of the authentication factors and MFA articles, turned into levels.

AAL3 is where the FIDO2 and WebAuthn vanguard earns its place: only a phishing-resistant, hardware-bound authenticator clears that bar, which is why high-assurance systems are moving toward phishing-resistant, passwordless sign-in. And AAL is independent of IAL. A thoroughly proofed user (IAL2) who only ever uses a password is still at AAL1, and an anonymous account (IAL1) can sign in with a hardware key at AAL3. Proofing strength and sign-in strength are different questions.

Assurance wears off

AAL isn’t only about the moment of sign-in. It also governs how long a session can run before the user has to prove themselves again. Higher levels require shorter reauthentication windows: AAL2 expects reauthentication roughly every 12 hours, or after a period of inactivity (commonly 30 minutes), and AAL3 is stricter still. The reasoning is that assurance decays. The longer it’s been since the last proof, the weaker the guarantee that the person at the keyboard is still the one who authenticated. NIST already encodes the idea that a sign-in isn’t a permanent fact, even if it does so with coarse time intervals rather than live signals. The frontier takes that idea much further.

FAL: how safely the assertion travels

FAL applies when identity is federated, when an identity provider vouches for the user to a relying party. It measures how safely that assertion gets there.

FAL ties together threads from the whole module. The “bearer” in FAL1 is the bearer-token risk we kept flagging: holding it is enough to use it. FAL2 adds the confidentiality of JWE. And FAL3’s holder-of-key is the same proof-of-possession idea as DPoP and mTLS: bind the assertion to a key so a stolen copy is worthless. FAL is where the protocols from earlier get graded.

Combining the dials for a use case

Because the three are independent, designing for a use case means assessing the risk in each dimension and choosing the lowest level that covers it.

flowchart LR
  accTitle: Combining IAL, AAL, and FAL into an assurance posture
  accDescr: Three independent questions feed three independent assurance dimensions. Identity proofing, who you really are, sets the Identity Assurance Level from 1 to 3. Authentication, how strongly you prove it at each sign-in, sets the Authenticator Assurance Level from 1 to 3. Federation, how safely the assertion is conveyed, sets the Federation Assurance Level from 1 to 3. The three chosen levels combine into the overall assurance posture required by the use case, each dial set to the risk of its own dimension.
  P[Proofing<br/>who are you, really?] --> IAL[IAL 1-3]
  A[Authentication<br/>how strongly, each sign-in?] --> AAL[AAL 1-3]
  F[Federation<br/>how does the assertion travel?] --> FAL[FAL 1-3]
  IAL --> POS[Assurance posture<br/>for this use case]
  AAL --> POS
  FAL --> POS

A retail bank, like Daniel’s app, needs at least IAL2 and AAL2. Money and regulation call for verified identity and MFA, and FAL applies if customers arrive through federation, scaled to how sensitive the assertion is. An anonymous discussion forum is fine at IAL1 and AAL1. There’s no reason to know who the person really is, a password may be enough, and raising the dials would add friction without reducing any risk. Government benefits or privileged administrator access push toward IAL3 and AAL3, identity verified in person and a phishing-resistant hardware authenticator, because impersonation there does serious damage.

The discipline is to set each dial to its own risk, not to crank everything to the maximum, which wears out users and budgets, or to leave everything low, which invites fraud. That’s the whole value of separating the dimensions: strong where it matters, light where it doesn’t.

A less obvious case shows the independence most clearly. A privacy-minded service may choose IAL1 with a high AAL on purpose. It has no wish to know who you really are, so proofing is low, but it still wants a strong, phishing-resistant sign-in. Knowing little about the person while authenticating them strongly is a perfectly coherent posture, and NIST even supports pseudonymous federation, where the relying party learns that a valid, well-authenticated subject is present without receiving their real-world identity. If your instinct was that more identity and stronger sign-in always rise together, this case breaks it, and it’s the reason the dials are separate.

It also explains a common design error: reaching for the wrong dial. If accounts are being taken over at sign-in, that’s an AAL problem. Add MFA or phishing resistance; demanding more identity documents won’t help. If fraudsters are opening fake accounts, that’s an IAL problem. Strengthen proofing; forcing hardware keys on everyone won’t help. Naming which dial a risk belongs to is half of fixing it efficiently. Raising friction on a dial that isn’t the source of the risk costs usability and adoption while buying no real security. Honest users suffer while the actual gap stays wide open.

How the dials map to the access decision

The three dials line up with the stages from the IAAA pillars, which is why the model feels natural once you’ve seen them. IAL is about identification and enrollment, establishing once that a real person stands behind the account. AAL is about authentication, checking on each access that the returning subject is that same person. FAL is about how the resulting assertion is carried when authentication is delegated to an identity provider.

What’s missing from the list is authorization. NIST assurance answers how sure we are about who this is and how safely we established it, not what they may do. Authorization, the models, policies, and entitlements of the next domain, uses that assurance as an input. A high-value action can require a minimum AAL before it goes ahead, which is the step-up authentication idea with a precise level attached. In Daniel’s app, viewing a balance might be fine at the session’s current level, while adding a new payee requires a fresh AAL2 check.

Why the levels matter in practice

Assurance levels aren’t an academic taxonomy. They’re how identity gets specified and audited. Procurement documents and RFPs state required levels (“the solution must support AAL2”), turning a vague “make it secure” into a requirement someone can check. Regulators and auditors refer to them: a control framework can require a level for a class of data, and an assessor can verify it objectively. Risk assessments use the three dials as a structured way to reason about an application instead of arguing about “security” in the abstract. That’s exactly what happened in Daniel’s meeting: once the requirement was IAL2 and AAL2, product, compliance, and engineering were talking about the same thing.

Beyond NIST

NIST SP 800-63 is U.S. guidance, but the way of thinking is global, and other frameworks express the same idea in their own terms. eIDAS in the EU defines levels of assurance, low, substantial, and high, for electronic identification. They don’t split into three separate dials the way NIST does, but “substantial” and “high” sit close to the IAL2/AAL2 and IAL3/AAL3 region, and the EU’s digital identity wallet work is raising their profile. ISO/IEC 29115 offers an international four-level model of entity-authentication assurance that predates and runs parallel to NIST’s thinking. And sector and regional rules, from financial regulators to healthcare privacy regimes and government identity programs, often refer to an assurance level instead of specifying controls again, because “must meet AAL2” is far more precise and auditable than “use strong authentication.”

So even when a project is governed by eIDAS or a local regulation rather than by NIST directly, the IAL, AAL, and FAL model still works as a common language for reasoning about assurance.

Revision 4: where the standard is heading

The guidelines are living documents, and Revision 4, finalized in 2025, shows where assurance thinking is going. Phishing resistance has moved to the center, reflecting that credential phishing and MFA bypass, not weak passwords alone, are now the dominant attacks. Syncable authenticators, meaning passkeys, are embraced; earlier revisions sat awkwardly with credentials synced through the cloud, and Rev 4 gives clearer guidance on where they fit, acknowledging the reality of FIDO2. Fraud, equity, and usability carry real weight: the standard increasingly recognizes that proofing that’s too burdensome shuts out legitimate people, and that assurance is as much about letting the right people in as keeping attackers out. And the point-in-time model is softening toward ongoing, risk-adaptive evaluation.

You don’t need to memorize revision numbers, but you should know the direction: toward phishing resistance and passkeys, and away from assurance as a one-time stamp.

The bridge to the frontier

That last point leads into the next article. NIST’s model is classically assurance established at a point in time. You proof once (IAL), you authenticate at sign-in (AAL), the assertion is carried (FAL), and access is granted. The frontier pushes on exactly that “point in time”: continuous access evaluation, sender-constrained tokens, and short-lived workload identity all ask whether the assurance is still valid right now, instead of trusting a level set minutes or hours ago. Learn to measure assurance at a moment here, then watch the field learn to measure it again and again.

Recap

NIST SP 800-63 is the vocabulary for specifying how strong identity has to be.

1. It defines three independent dials, each from 1 to 3, set separately to a use case’s risk and never merged into one “level.”
2. IAL (proofing) measures how sure you are who the person is: self-asserted, verified evidence, or in person with strong evidence. It’s a one-time enrollment question.
3. AAL (authentication) measures how strongly they prove it at each sign-in: one factor, MFA, or phishing-resistant hardware such as FIDO2. Higher AAL also means shorter reauthentication windows.
4. FAL (federation) measures how safely the assertion travels: bearer, encrypted, or holder-of-key. FAL3 is the same proof-of-possession idea as DPoP.
5. You combine them by risk: banking around IAL2 and AAL2, a forum around IAL1 and AAL1, high-value access toward IAL3 and AAL3, and even IAL1 with a high AAL when you want a strong sign-in without knowing who the user is. Fix a risk with the dial it belongs to.
6. Authorization uses assurance as an input, so sensitive actions can require a minimum level. The model travels beyond the U.S. (eIDAS, ISO 29115), and it’s moving toward continuous evaluation.

Hands-on exercises

These are meant to be done, not just read.

1. Rate a service you use. Pick an app you sign in to and estimate its IAL, AAL, and FAL. What evidence did it collect at sign-up? What does it ask for at sign-in? If you sign in through another provider, how is that assertion protected?
2. Pick the dial. For each problem, say whether it’s an IAL, AAL, or FAL issue and what the fix is: fake accounts flooding sign-up; phished credentials being replayed; a federated assertion intercepted and reused at another relying party.
3. Design a posture. Specify IAL, AAL, and FAL for a children’s game, a stock-trading app, and an internal administration console for production infrastructure. Justify each dial against its risk.
4. Defend the independence. A stakeholder says, “Just make everything level 3.” Give the two-sentence argument for why setting every dial to the maximum is usually the wrong call.
5. Map to a protocol. Your design calls for AAL3 and FAL3. Name a concrete authenticator that meets AAL3 and a concrete assertion mechanism that meets FAL3, and connect each to a protocol from earlier in the module.
6. Translate the regulation. A rule says a service handling health records must meet “IAL2/AAL2 with reauthentication.” List the concrete proofing steps, the sign-in requirement, and roughly how often the user must reauthenticate, then connect each requirement to something the earlier articles described.

Three questions to test yourself

1. Explain why IAL and AAL are independent, with an example of a high-IAL, low-AAL account and a low-IAL, high-AAL account.
2. What does FAL3 (holder-of-key) protect against that FAL1 (bearer) doesn’t, and which frontier technology embodies the same idea?
3. A regulator requires “IAL2 and AAL2” for an application. Turn that into concrete, buildable requirements for proofing and for sign-in.