What category of publication this is
NIST Special Publication 800-63-4 is Digital Identity Guidelines. It is a guideline suite covering the identity proofing, authentication, and federation of users (for example employees, contractors, or private individuals) who interact with government information systems over networks. It defines technical requirements for identity proofing, enrollment, authenticators, management processes, authentication protocols, federation, and related assertions. It supersedes SP 800-63-3.
Who it commonly frames: federal agencies and the identity services that serve them, plus identity architects, relying parties, and GRC readers who borrow its vocabulary. It is not a statute and not a product. Whether a real private organization has an obligation to follow it depends on law, contract, or program terms that this page does not decide.
What security people most often confuse: they fold proofing, authenticators, and federation into one word, login, and then read "we turned on MFA" as the whole assurance story. This page separates the three jobs.
Edition pin
SP 800-63-4, Date Published July 2025, Final history stamp 2025-07-31. Supersedes SP 800-63-3 (03/02/2020). DOI 10.6028/NIST.SP.800-63-4. The CSRC Final page is csrc.nist.gov/pubs/sp/800/63/4/final.
Re-open the CSRC page at publish. If a newer Final appears, update this pin and treat the older claim as UNKNOWN.
One suite, three specialist volumes
SP 800-63A-4, Identity Proofing and Enrollment (DOI 10.6028/NIST.SP.800-63a-4). SP 800-63B-4, Authentication and Authenticator Management (DOI 10.6028/NIST.SP.800-63b-4). SP 800-63C-4, Federation and Assertions (DOI 10.6028/NIST.SP.800-63c-4). Each part: Date Published July 2025, Final 2025-07-31.
Publication names keep an uppercase letter (SP 800-63B-4). The DOI path uses a lowercase letter (800-63b-4). This page names the parts and links out to them. It does not teach them as three separate courses, and Atlas has no separate A, B, or C pages.
Three assurance lanes, side by side
Read these as three lanes, one per part. They are categories of assurance at concept depth, not a scorecard. This page does not reprint level tables or quote normative requirements.
Identity assurance (IAL themes, 63A): how strongly the provider checked, during proofing and enrollment, that a claimed real-world identity belongs to the applicant. Proofing is not "the password worked." Proofing also handles personal data, so the privacy boundary habit applies (/learn/topics/privacy-vs-security/).
Authenticator assurance (AAL themes, 63B): how strongly the claimant controls the authenticators bound to that digital identity at authentication time. Authenticator category and management matter. "MFA on" is not the whole story.
Federation assurance themes (63C): how strongly a relying party can trust assertions from an identity provider or federation. At slogan depth, ask whether the assertion is fresh, whether it was meant for this audience, and whether it is bound to this session. Accepting a federation ticket is not finishing proofing.
Each lane answers a different question. A strong answer in one lane does not fill in another.
Passkeys fold under authenticator categories
Passkeys and other phishing-resistant authenticator categories illustrate stronger authenticator choices under AAL themes in 63B. That is category literacy, not a product shop. This page does not rank products, recommend vendors, or hand out a rollout plan.
Shipping passkeys is not forever passwordless for every account. Recovery, fallback authenticators, and authenticator lifecycle (enrollment, loss, replacement, and removal) still exist, and each one is part of the authenticator story. F4 already warns that a help-desk reset can become the real front door (/learn/topics/identity-authn-authz/).
What SP 800-63 is not
Not DIY MFA rollout homework. Not an authenticator shopping list or an identity provider bake-off. Not a Kerberos replacement. Not a claim that Atlas grants IAL or AAL. Not a universal mandate on every private company (coverage and adoption questions escalate to the owner). Not three separate vanity pages for A, B, and C.
Kerberos is a ticket protocol for network authentication (RFC 4120), taught on the Kerberos explainer (/learn/explainers/kerberos/). 800-63 assurance categories are guideline literacy for proofing, authenticators, and federation. Different objects. This page does not place Kerberos, or any SSO ticket, at a named assurance level.
Rewrite the one-blob claim
Replace "we are MFA, passkey, SSO, and 800-63 compliant" (as one blob) with separate objects. For example: we use SP 800-63-4 literacy to sort proofing (IAL themes), authenticators (AAL themes), and federation assertions, which is different from a Kerberos ticket, an OAuth access token, an OIDC ID Token, or a SAML assertion.
For the ticket side, start from F4 (/learn/topics/identity-authn-authz/), then the Identity federation path (IF1, IF2, and IF3) and the Kerberos explainer.
At work, for one login path your team touches, privately name whether the live question is proofing, authenticator strength, or federation trust. Do not paste real identity provider configurations, authenticator details, or personal data into Atlas.
MFA is not AAL done, and a ticket is not proofing finished
Teaching table only. It does not assign an assurance level, assess an identity provider, or find that any guideline has been met.
| Phrase people say | Literacy correction |
|---|---|
| We turned on MFA, so AAL is done | MFA is a common pattern. AAL is an authenticator-assurance category under 63B themes. Turning on a second factor is not automatically "AAL done." Term: /reference/terms/mfa/. |
| We shipped passkeys, so we are forever passwordless | Passkeys are a phishing-resistant authenticator category example. Recovery, fallback authenticators, and lifecycle still matter. Not a forever badge. Term: /reference/terms/account-recovery/. |
| Kerberos ticket = 800-63 assurance level | Kerberos is a ticket protocol (RFC 4120). 800-63 assurance categories are guideline literacy for proofing, authenticators, and federation. Different objects. Atlas card: /learn/explainers/kerberos/. |
| Federation SSO worked, so identity proofing is finished | IF1, IF2, and IF3 tickets assert claims under federation trust. Proofing and enrollment (63A) is a different job. A ticket is not proofing finished. Lessons: /learn/topics/who-holds-the-ticket/, /learn/topics/assertion-claims-not-admin/, and /learn/topics/federation-failure-modes/. |
Claims to retire
MFA on means AAL done.
MFA is a common pattern. AAL is an authenticator-assurance category under 63B themes, and authenticator category and management still matter. Turning on a second factor is not automatically AAL done.
A passkey means forever passwordless, with no recovery risk.
Passkeys are a phishing-resistant authenticator category. Recovery, fallback authenticators, and lifecycle still exist, and any of them can become the weaker door.
Kerberos, or any SSO ticket, is an 800-63 assurance level.
A ticket is a protocol object. 800-63 assurance categories describe proofing, authenticators, and federation. This page does not map Kerberos to any named level.
Federation sign-in finished identity proofing.
A federation assertion carries claims under federation trust. Proofing and enrollment (63A) is a separate job that happened, or did not, before any ticket existed.
800-63 is only for federal identity providers, so private teams can ignore the inequalities.
The guidelines are written for government information systems, and this page does not decide whether any private organization is obligated. The inequalities still describe different objects, so the sorting habit applies wherever a team says MFA, passkey, or SSO.
Finishing this Atlas lesson is an IAL or AAL determination.
Atlas issues no IAL, AAL, or federation assurance determinations, seals, or badges. Completing a lesson is not a validated assurance level.
CHECK THE CATEGORY
Which sentence matches this page?
Glossary and nearby pages
- F4: Identity, authentication, authorization, and recovery (cites SP 800-63-4)
- Identity federation path: Trust tickets, not hallway trust
- IF1: Who holds the ticket, and what does it open? (OAuth access tokens)
- IF2: ID Token and SAML assertion are claims, not blank admin passes
- IF3: Five ways the ticket still burns you (federation failure modes)
- Kerberos explainer (ticket protocol, not an 800-63 assurance level)
- Privacy is not a CIA checkbox (proofing and personal data boundary)
Use the agency page in the sources for the authoritative text. This page has no figure.