NIST Special Publication 800-63, the Digital Identity Guidelines, is a US National Institute of Standards and Technology publication that sets requirements and recommendations for proving who someone is online. It covers identity proofing (checking a person’s identity when they enroll), authentication (how they sign in) and federation (how one system passes a sign-in result to another). The current version, SP 800-63-4, was finalized in July 2025. It is written for US federal agencies but is widely used as a reference for identity and access decisions elsewhere.
At a glance
- It defines three types of assurance level: identity (IAL), authentication (AAL) and federation (FAL), each with three levels.
- Organizations choose levels per application and user group based on a risk assessment, then tailor them.
- AAL2 requires multi-factor authentication; AAL3 requires phishing-resistant, hardware-bound cryptographic authentication.
- The current version allows syncable authenticators, such as many passkeys, at up to AAL2 under conditions.
- It is a suite: a base volume plus SP 800-63A, 63B and 63C.
What problem it solves
Organizations constantly decide how much proof to ask for: whether a password is enough, when to require multi-factor authentication, whether a phone prompt is good enough for administrators, how carefully to verify a new customer or contractor. Without a shared yardstick, those decisions vary by team and vendor, and attackers aim for the weakest one.
SP 800-63 gives a consistent way to match the strength of identity checks to the harm a mistake could cause. It also gives buyers precise language. Asking a provider “which authentication assurance level do you support for administrators?” is more useful than “do you have MFA?”, because it separates methods that can be phished from those designed to resist it.
How it works
Risk first. The base volume describes a digital identity risk management process. An organization identifies the online service and its user groups, assesses the impact of identity errors such as letting the wrong person in, selects an initial assurance level for each function, then tailors and documents the result. Initial selection maps low, moderate and high impact to levels 1, 2 and 3, with room to adjust.
Identity proofing (SP 800-63A). Requirements for enrolling a person and establishing that they are who they claim to be, remotely or in person.
Authentication (SP 800-63B). Requirements for sign-in at each AAL, including which kinds of authenticator qualify, how they are managed, and what happens when one is lost or stolen.
Federation (SP 800-63C). Requirements for passing identity and authentication results between an identity provider (IdP) and an application, as in single sign-on (SSO), and for protecting those assertions.
Assurance levels
The guidelines define three assurance types, each with three levels. The table summarizes them in general terms; the volumes contain the full requirements.
| Level | What it means in general | Typical way it is met | What a buyer can ask to see |
|---|---|---|---|
| IAL1 | Some assurance that the person is linked to the claimed identity, with core attributes validated | Remote proofing against evidence and authoritative sources | Proofing method and data sources |
| IAL2 | More evidence and more rigorous validation and verification | Stronger remote or in-person proofing | Proofing process and any certification |
| IAL3 | Adds an attended, on-site session with a trained proofing agent and at least one biometric | In-person proofing | Proofing site and procedures |
| AAL1 | Single-factor or multi-factor sign-in; MFA should be offered | Password or one authenticator | Supported methods |
| AAL2 | Multi-factor sign-in with a replay-resistant authenticator; a phishing-resistant option must be offered | Authenticator app, passkey, security key or similar | Which methods meet AAL2, including phishing-resistant ones |
| AAL3 | Phishing-resistant, cryptographic authentication with a non-exportable key | Hardware security key, smart card or similar | Which hardware authenticators qualify |
| FAL1 to FAL3 | Increasing protection for identity assertions passed between systems, including against injected assertions at FAL2 and above | Federation protocol configuration at the IdP and application | Supported FAL and how assertions are protected |
These levels are not a certification from NIST. A provider claiming a level is describing its own design or an assessor’s review; ask to see it. This is general information, not legal advice.
When it matters for buyers
- When selecting an identity platform or IdP. Ask which AALs and FALs it supports and how it is configured to reach them.
- When setting MFA policy. The AAL definitions help decide where phishing-resistant MFA is warranted, such as for administrators.
- When rolling out passkeys. Know whether synced or device-bound passkeys fit each user group.
- When onboarding customers, patients or contractors remotely. IAL guides how much identity proofing to require.
- When a federal agency or contract names a level. Confirm the exact level and whether the provider’s service meets it.
Our access management overview covers identity, single sign-on and MFA services that implement these guidelines.
Questions to ask vendors
- Which AAL does your product support for our users, and for administrators?
- Which of your sign-in methods are phishing-resistant, and can we require them for specific groups?
- Do you support syncable passkeys, device-bound passkeys or both, and can we choose by policy?
- Which FAL can your federation configuration reach with our applications?
- If you provide identity proofing, which IAL does it meet and has it been independently reviewed?
- Which version of SP 800-63 does your documentation map to?
How it differs from multi-factor authentication
Multi-factor authentication (MFA) is a sign-in method that asks for two or more independent proofs of identity. NIST SP 800-63 is a set of guidelines that, among other things, defines when MFA is required and which kinds count at each assurance level. MFA is what you deploy; SP 800-63 helps decide how strong it needs to be for each application and group, and also covers identity proofing and federation, which MFA alone does not address. For the broader access model these sign-ins feed, see NIST SP 800-207 and identity and access management (IAM).
Problems this helps with
- Not sure how strong our sign-in and identity checks need to be
- A customer or agency asks which authentication assurance level we meet
- Deciding whether passkeys or security keys are acceptable for admins
- Password rules feel arbitrary and users hate them
