What category of publication this is
NIST Special Publication 800-63-4 is the subject. The official title is Digital Identity Guidelines. It is a guideline suite for the identity proofing, authentication, and federation of users. Those users, for example employees, contractors, or private individuals, 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.
It commonly frames federal agencies and the identity services that serve them. It also frames identity architects, applications that accept federation assertions, and GRC readers who borrow its vocabulary. It is not a statute. It is not a product. Whether a real private organization has an obligation to follow it depends on law, contract, or program terms. Counsel and the program owner decide those terms.
SP 800-63-4 splits identity assurance into three jobs: proofing, authenticators, and federation. Each job has its own part. MFA belongs to the authenticator job only.
Edition covered
SP 800-63-4, Date Published July 2025, Final history stamp 2025-07-31. It 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.
The habit is to re-open the CSRC page at publish. If a newer Final appears, this pin must change. The older claim is then 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 has Date Published July 2025 and Final 2025-07-31.
Publication titles keep an uppercase letter (SP 800-63B-4). The DOI path uses a lowercase letter (800-63b-4). The three parts are in one suite, not three separate courses.
Three assurance lanes, side by side
These are three lanes, one per part. They are categories of assurance, not a scorecard. The level tables and the normative requirements stay in the NIST volumes.
Identity assurance (IAL themes, 63A) is how strongly the provider checked that a claimed real-world identity belongs to the applicant. The provider does that check during proofing and enrollment. Proofing is not "the password worked." Proofing also handles personal data. The privacy boundary habit therefore applies (Privacy vs security: why an encrypted database can still violate privacy).
Authenticator assurance (AAL themes, 63B) is 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) cover how strongly an application that accepts assertions can trust them. The assertions come from an identity provider or federation. The first question is whether the assertion is fresh. The second question is whether it was meant for this audience. The third question is whether it is bound to this session. Acceptance of a federation ticket does not finish 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. SP 800-63B-4 does not rank products. It is not a vendor list or a rollout plan.
A passkey rollout is not forever passwordless for every account. Recovery, fallback authenticators, and authenticator lifecycle still exist. The lifecycle covers enrollment, loss, replacement, and removal. Each one is part of the authenticator story. A help-desk reset can become the real front door (Identity, authentication, authorization, and recovery).
What SP 800-63 is not
It is not DIY MFA rollout homework. It is not an authenticator purchase list or an identity provider bake-off. It is not a Kerberos replacement. It is not a universal mandate on every private company. Coverage and adoption questions escalate to the owner.
Kerberos is a ticket protocol for network authentication (RFC 4120). A Kerberos ticket, or any SSO ticket, is not a specific assurance level.
Rewrite the one-blob claim
The one-blob claim "we are MFA, passkey, SSO, and 800-63 compliant" mixes separate objects. One example sentence is "We use SP 800-63-4 literacy to sort proofing (IAL themes), authenticators (AAL themes), and federation assertions." That assurance sort is different from a Kerberos ticket, an OAuth access token, an OIDC ID Token, or a SAML assertion.
At work, the team picks one login path that it touches. The team privately decides whether the live question is proofing, authenticator strength, or federation trust.
MFA is not AAL done, and a ticket is not proofing finished
| Phrase people use | Literacy correction |
|---|---|
| We turned on MFA, so AAL is done | MFA is a common pattern. AAL is an authenticator-assurance category under 63B themes. Activation of a second factor is not automatically "AAL done." Term: /reference/terms/mfa/. |
| We shipped passkeys, so we are forever passwordless | Passkeys are an example of a phishing-resistant authenticator category. Recovery, fallback authenticators, and lifecycle still matter. A passkey rollout is 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. These are different objects. Atlas card: /learn/explainers/kerberos/. |
| Federation SSO worked, so identity proofing is finished | Federation 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/. |
Common misconceptions
MFA on means AAL done.
AAL describes how strongly the claimant controls the bound authenticators (63B themes). Authenticator category and management still matter. A second factor alone is not 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. 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. Kerberos does not map to any specific level.
Federation sign-in finished identity proofing.
A federation assertion carries claims under federation trust. Proofing and enrollment (63A) is a separate job. That job 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. Law, contract, or program terms decide whether a private organization is obligated. The inequalities still describe different objects. The sort habit applies wherever a team uses the words MFA, passkey, or SSO.
A strong authenticator proves that the person is who they claim to be.
Authenticator assurance (63B) covers control of the authenticator at sign-in. Identity assurance (63A) covers whether the claimed identity belongs to the applicant. A strong authenticator on a weakly proofed identity is still a weak identity claim.
CHECK THE CATEGORY
Which sentence matches SP 800-63-4?
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.