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

From “which protocol” to “how much assurance”

The last two articles toured protocols — the veterans and the vanguard — and the next one looks to the frontier. This one is the bridge between them. Knowing which protocol to use (Kerberos, SAML, OIDC, FIDO2) answers how identity works. It doesn’t answer the question a risk owner actually asks: how strong does this need to be? “Strong enough” for a discussion forum and “strong enough” for a bank are wildly different, and you need a precise, shared vocabulary to specify and compare them. That vocabulary is NIST SP 800-63.

NIST SP 800-63, the U.S. Digital Identity Guidelines, is referenced far beyond the U.S. — by regulators, auditors, and procurement teams worldwide — as the standard way to measure identity assurance. Its central move is to refuse a single “security level” and instead break assurance into three independent dimensions, each rated 1–3. It’s the normative connective tissue of this whole module: the protocols are the how, NIST is the how much, and the frontier is where “how much” becomes continuous rather than decided once.

That bridging role is exactly why this article sits where it does — between the concrete protocols of the veterans and vanguard and the forward look of the frontier. 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 actually specify, build, and defend in an audit.

Three independent dials

The guidelines are organized into three volumes, one per dimension — 63A (enrollment and proofing → IAL), 63B (authentication → AAL), and 63C (federation → FAL) — precisely because the three are meant to be chosen separately.

Fullscreen

Let’s take each dial in turn, and notice how each connects to a protocol or concept from earlier in the module.

IAL — Identity Assurance Level (proofing)

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

The jump that matters is IAL1 → IAL2: from “you typed a name” to “we checked real evidence that you are that person.” This is the identity proofing that gates 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 does. Higher IAL means more friction and more collected data — so you raise it only when the risk of a fake or mistaken identity justifies it.

How proofing actually happens

IAL2 proofing in practice is three steps: collect identity evidence (a government ID), validate that the evidence is genuine, and verify that the person presenting it is its rightful owner — increasingly by matching a selfie to the document with liveness detection to defeat printed photos and deepfakes. Note what has fallen out of favor: knowledge-based verification (“what was your previous address?”) is now discouraged, because years of breaches made those answers public. IAL3 adds a supervised step — in person, or tightly supervised remote with a trained operator. The modern reality is that proofing is an arms race: synthetic identities and AI-generated documents are getting better, so the bar for “we verified a real, specific human” keeps rising — which is also why proofing increasingly leans on signals beyond the document itself.

AAL — Authenticator Assurance Level (authentication)

AAL answers a question asked on every login: how strongly does the returning user prove it’s really them? This is the dimension our authentication factors and MFA articles live in, now formalized into levels.

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

Reauthentication: assurance decays over time

AAL isn’t only about the moment of login — it also governs how long a session may ride before the user must prove themselves again. Higher levels mandate shorter reauthentication windows: AAL2 expects reauthentication on the order of 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 since the last proof, the weaker the guarantee that the person at the keyboard is still the authenticated user. This is a quiet foreshadowing of the frontier’s continuous evaluation: NIST already encodes the idea that a login isn’t a forever-fact, just at coarse, time-based intervals rather than live signals.

FAL — Federation Assurance Level (the assertion)

FAL applies when identity is federated — when an identity provider vouches for the user to a relying party. It measures how safely that assertion travels:

FAL ties together threads from the whole module. FAL1’s “bearer” is exactly the bearer-token risk we kept flagging — possession equals use. FAL2 adds the confidentiality of JWE. And FAL3’s holder-of-key is the same proof-of-possession idea as DPoP and mTLS from the frontier: bind the assertion to a key so a stolen one is worthless. Reading FAL, you can feel the whole module connecting — assurance levels are where the protocols get graded.

Combining the dials for a use case

Because the three are independent, designing for a use case means assessing each dimension’s risk and picking 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 are you, really — sets the Identity Assurance Level from 1 to 3. Authentication — how strongly do you prove it each login — 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 login?] --> 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

Some worked postures:

• A retail bank: at least IAL2 / AAL2. Money and regulation demand verified identity (IAL2) and MFA (AAL2); FAL applies if customers arrive via federation, scaled to sensitivity.
• An anonymous discussion forum: IAL1 / AAL1 is fine. There’s no reason to know who the person really is, and a password may suffice — raising the dials would add friction with no risk reduction.
• Government benefits or privileged admin access: pushing toward IAL3 / AAL3 — verified-in-person identity and a phishing-resistant hardware authenticator, because impersonation is high-impact.

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

A subtler case shows the independence at its sharpest: a privacy-minded service may deliberately choose IAL1 with a high AAL — it has no wish to know who you really are (low proofing), but still wants a strong, phishing-resistant login (high authentication). Knowing less about the human 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 login” always rise together, this is the case that breaks it — and the reason the dials are separate.

How the dials map to the access decision

The three dials line up cleanly with the access 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. It’s the proofing that happens before the account is ever used.
• AAL is about authentication — verifying, 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.

Notice what’s not on the list: authorization. NIST assurance answers “how sure are we who this is, and how safely did we establish it” — not “what may they do.” Authorization (the xBAC models, policies, and entitlements of the next domain) consumes that assurance as an input: a high-value action can require a minimum AAL before it proceeds — the step-up authentication idea, now with a precise level attached. Assurance levels are the unit in which “prove yourself more before doing this” gets specified.

Why the levels matter in practice

Assurance levels aren’t an academic taxonomy — they’re how identity gets specified and audited:

• Procurement and RFPs state required levels (“the solution must support AAL2”), turning a fuzzy “make it secure” into a checkable requirement.
• Regulators and auditors reference them: a control framework can mandate 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.
• International alignment: the EU’s eIDAS levels of assurance (low / substantial / high) map roughly onto this thinking, so the IAL/AAL/FAL mental model travels.

This is why the standard is the bridge in this module: the veteran and vanguard protocols give you the mechanisms, and NIST SP 800-63 gives you the measuring stick to say how much mechanism a given risk demands — the shared language between the engineer who builds it and the risk owner who signs off on it.

Beyond NIST: how the model travels

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 vocabulary:

• eIDAS (EU) defines Levels of Assurance — low / substantial / high — for electronic identification. They don’t split cleanly into three separate dials the way NIST does, but “substantial” and “high” track closely with 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 entity-authentication assurance model that predates and parallels NIST’s thinking.
• Sector and regional rules — financial regulators, healthcare privacy regimes, government identity programs — frequently reference an assurance level rather than re-specifying controls, because “must meet AAL2” is far more precise and auditable than “use strong authentication.”

The practical upshot: even if a given project is governed by eIDAS or a local regulation rather than NIST directly, the IAL/AAL/FAL mental model still works as a lingua franca for reasoning about assurance — which is exactly why it’s worth learning as a standard, not just as a NIST artifact.

Revision 4: where the standard is heading

The guidelines are living documents, and Revision 4 (finalized in 2025) signals where assurance thinking is moving — worth knowing so you’re not anchored to the older version:

• Phishing-resistance moves to the center. The newer guidance leans harder on phishing-resistant authentication, reflecting that credential phishing and MFA bypass are now the dominant attack, not weak passwords alone.
• Syncable authenticators (passkeys) are embraced. Earlier revisions sat awkwardly with cloud-synced credentials; Rev 4 gives clearer guidance on where synced passkeys fit, acknowledging the FIDO2 reality.
• Fraud, equity, and usability get real weight. The standard increasingly recognizes that proofing that’s too burdensome excludes legitimate people, and that identity fraud must be designed against — assurance isn’t only about keeping attackers out but about letting the right people in.
• A nudge toward continuous, risk-adaptive assurance. The point-in-time model is being softened toward ongoing evaluation — the same direction the frontier is sprinting.

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

The bridge to the frontier

One more connection points forward. NIST’s model is, classically, assurance established at a point in time — you proof once (IAL), you authenticate at login (AAL), the assertion is conveyed (FAL), and access is granted. The frontier we turn to next pushes exactly on that “point in time”: continuous access evaluation, sender-constrained tokens, and short-lived workload identity all ask “is this assurance still valid right now?” rather than trusting a level set minutes or hours ago. NIST itself is evolving toward continuous and risk-adaptive thinking. So read the assurance levels as the solid ground the frontier builds on: first learn to measure assurance at a moment, then watch the field learn to re-measure it continuously.

Recap

NIST SP 800-63 is the vocabulary for specifying how strong identity must be:

1. Three independent dials, each 1–3 — you set them separately to a use case’s risk, never as one combined “level.” That separation is the standard’s whole idea.
2. IAL (proofing): how sure you are who the person is — 1 self-asserted, 2 verified evidence, 3 in-person with strong evidence. A one-time, enrollment question.
3. AAL (authentication): how strongly they prove it each login — 1 single-factor, 2 MFA, 3 phishing-resistant hardware (FIDO2). The home of factors and MFA.
4. FAL (federation): how safely the assertion travels — 1 bearer, 2 encrypted, 3 holder-of-key. FAL3 is the same proof-of-possession idea as DPoP.
5. Combine by risk: banking ≈ IAL2/AAL2, a forum ≈ IAL1/AAL1, high-value access → IAL3/AAL3 — strong where it matters, light where it doesn’t, and the right dial for the right risk, even a deliberate IAL1-with-high-AAL when you want a strong login but no knowledge of who the user is.
6. Assurance decays and authorization consumes it: higher AAL means shorter reauthentication windows, and sensitive actions can require a minimum level (step-up) — assurance is the unit authorization asks for.
7. It’s the bridge: protocols are the how, assurance levels are the how much, the model travels (eIDAS, ISO 29115), and the frontier is where “how much” becomes continuous. Learn to measure assurance at a moment here, then watch the field learn to re-measure it continuously next.

Hands-on exercises

These are practical — do them, don’t just read them:

1. Rate a service you use (use case). Pick an app you log into and estimate its IAL, AAL, and FAL. What evidence did it collect at sign-up (IAL)? What does it require at login (AAL)? If you “sign in with” a provider, how is that assertion protected (FAL)?
2. Pick the dial (use case). For each problem, name whether it’s an IAL, AAL, or FAL issue and the fix: fake accounts flooding sign-up; credentials phished and replayed; a federated assertion intercepted and reused at another relying party.
3. Design a posture (use case). Specify IAL/AAL/FAL for: a children’s game; a stock-trading app; an internal admin console for production infrastructure. Justify each dial against its risk.
4. Defend the independence (use case). A stakeholder says “just make everything level 3.” Give the two-sentence argument for why setting all dials to maximum is usually the wrong call.
5. Map to a protocol (use case). 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 back to a protocol from earlier in the module.
6. Translate the regulation (use case). A rule says a service handling health records must meet “IAL2/AAL2 with reauthentication.” List the concrete proofing steps (IAL2), the login requirement (AAL2), and roughly how often the user must reauthenticate — then map 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) does not, and which frontier technology embodies the same idea?
3. A regulator requires “IAL2 and AAL2” for an application. Translate that into concrete, implementable requirements for proofing and for login.