NIST SP 800-63 Digital Identity Guidelines Guide: Assurance Levels in Practice

Most organisations cite NIST SP 800-63 for password rules and stop there, missing the risk process and assurance levels that actually decide how strong proofing, authentication and federation must be. Revision 4 of the Digital Identity Guidelines was published as final by NIST in July 2025, superseding SP 800-63-3, and it changes several practical requirements: phishing-resistant options at AAL2, rules for syncable authenticators such as synced passkeys, new identity proofing types and fraud controls, and stronger federation protections. This guide explains the four volumes, how to select IAL, AAL and FAL for a service, what each level requires in concrete terms, and how to implement and measure it. It is written for IAM architects, security engineers and assurance teams in government and in private organisations that use 800-63 as their benchmark.

Key takeaways

• Revision 4 is the current version. SP 800-63-4 and its companion volumes 63A-4, 63B-4 and 63C-4 were all finalised on 31 July 2025; references to 800-63-3 and 800-63B (2017 text) are out of date.
• Assurance levels are selected independently. The Digital Identity Risk Management (DIRM) process sets IAL, AAL and FAL separately per user group, then tailors them and records the result in a Digital Identity Acceptance Statement.
• AAL2 now means offering phishing resistance. Verifiers at AAL2 must offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for staff, contractors and partners.
• Synced passkeys are fine at AAL2, not at AAL3. Syncable authenticators have exportable keys by design, so AAL3 requires non-exportable keys held in hardware.
• Federation has its own risk. FAL2 requires injection protection and a pre-established trust agreement; FAL3 adds holder-of-key assertions or bound authenticators.

What SP 800-63-4 is and what changed

The Digital Identity Guidelines are a suite of four documents. NIST lists them on the Computer Security Resource Center (CSRC) as final, published July 2025:

Changes from revision 3 that matter most in practice, as described in the base volume:

• Risk process: control tailoring and continuous evaluation and improvement are now core concepts, not optional extras.
• IAL1 reinstated: IAL1 is repurposed as a real proofing level with validated core attributes, rather than meaning "no proofing".
• Phishing resistance: phishing-resistant options are added and threat models updated for newer attacks.
• Enrolment abuse: requirements are added to prevent automated attacks against enrolment.
• Digital credentials: the text prepares for mobile driving licences and verifiable credentials, introduces a subscriber-controlled wallet federation model, and uses the term "attribute bundle" to avoid confusion with "credentials".

The guidelines are written for US federal systems. Private organisations use them as a well-reasoned benchmark, and many regulations and contracts reference them; check whether a contract names a specific revision.

Selecting assurance levels with the DIRM process

SP 800-63-4 sets out five steps:

1. Define the online service: scope, user groups, transactions, data processed, legal and privacy obligations and everyone affected.
2. Conduct an initial impact assessment: rate each user group as Low, Moderate or High against at least five impact categories: degradation of mission delivery; damage to trust, standing or reputation; unauthorised access to information; financial loss or liability; and loss of life or danger to safety, health or the environment.
3. Select initial assurance levels: map the effective impact level to baseline IAL, AAL and FAL.
4. Tailor and document: assess effects on privacy, customer experience and threat resistance; adjust levels or add compensating or supplemental controls; record decisions in a Digital Identity Acceptance Statement.
5. Continuously evaluate and improve: collect performance data and watch for unintended harms such as people unable to access a service.

The levels do not have to match. A low-impact service that exposes personal information may need AAL2 while needing only IAL1 or no proofing at all; the base volume notes that proofing is unnecessary when the service needs no personal information or self-asserted attributes carry insignificant risk. Services can also be partitioned so that low-risk functions are available at lower assurance and high-risk functions (changing payment details, viewing records) require step-up.

Identity assurance levels (SP 800-63A-4)

• Evidence strength: evidence is graded FAIR, STRONG or SUPERIOR. SUPERIOR evidence carries cryptographically protected data verified through the issuer's digital signature.
• Four proofing types: remote unattended, remote attended, on-site unattended and on-site attended. CSPs should offer the combination that fits their population and relying parties' risk.
• No knowledge-based verification: KBV "SHALL NOT be used for identity verification", although it may support fraud management.
• Trusted referees and applicant references: trained, certified referees help people who lack standard evidence, with each session recorded; applicant references must themselves be proofed to the same or a higher IAL.
• Fraud management: CSPs must run a fraud management programme, assess its privacy impact first and perform a death records check; SIM swap detection, device fingerprinting and transaction analytics are recommended.
• Biometric performance: one-to-one verification needs a false match rate of 1 in 10,000 or better and a false non-match rate of 1 in 100 or better, and performance results must be made public.

Proofing is increasingly targeted by synthetic identities and deepfakes. See the Identity Proofing and KYC Guide and the Deepfake-Resistant Identity Verification Guide.

Authenticator assurance levels (SP 800-63B-4)

In practice, FIDO2/WebAuthn passkeys and PIV or CAC smart cards are the main phishing-resistant options. Synced passkeys meet AAL2; device-bound credentials on security keys or smart cards with non-exportable keys are the route to AAL3. In federal enterprise systems, 63B-4 says verifiers should use attestation to confirm authenticator capabilities and provenance. See the Phishing-Resistant MFA Guide, the Passwordless and Passkeys Guide and the Smart Card and PIV/CAC Authentication Guide.

Other authenticator rules worth knowing

• Passwords: at least 15 characters when used alone, at least 8 when part of MFA, no composition rules, no forced periodic change and a blocklist check. The full rule set and how to configure it is in the Password Policy Guide (NIST-aligned).
• Failed attempts: consecutive failures on one authenticator must be limited to no more than 100 before the authenticator is disabled; organisations may set lower limits.
• Restricted authenticators: using the telephone network (SMS or voice) for out-of-band authentication is the only restricted authenticator. Using it requires an unrestricted alternative, meaningful notice to users of the risks, a risk assessment and a migration plan. Email must not be used for out-of-band authentication.
• Out-of-band secrets: at least six decimal digits, valid for no more than 10 minutes and accepted once.
• Biometrics: only alongside a physical authenticator, never voice comparison, with presentation attack detection for facial recognition and a non-biometric alternative always available.

Federation assurance levels (SP 800-63C-4)

• Trust agreements: must define the subscriber population, acceptable IAL, AAL and FAL, retention and redress, and be available to subscribers in clear language.
• Injection defences: back-channel presentation (the RP fetches the assertion directly from the IdP, as in the OpenID Connect authorisation code flow) is the first listed mitigation; front-channel responses can be bound to an RP-supplied nonce.
• Account lifecycle: the IdP must deprovision RP accounts when a subscriber account is terminated, and both sides exchange only the minimum attributes needed.

Forged or stolen assertions are a real attack path (MITRE ATT&CK T1606.002 SAML Tokens), so FAL2 is the practical minimum for workforce single sign-on into sensitive applications. See the Federation and Trust Relationships Guide and the OAuth 2.0 and OpenID Connect Guide.

Workforce, customer and non-human identities

• Workforce: aim for AAL2 with phishing-resistant authenticators for all staff, and AAL3 (device-bound, hardware keys) for administrators and privileged roles. Proof new hires at IAL2 before credentials are issued, and treat help-desk recovery as a proofing event. See the Workforce Identity Security Guide.
• Customers: the DIRM tailoring step is where usability and inclusion are weighed. Offer synced passkeys widely, keep an accessible fallback, and step up for high-risk transactions rather than forcing high assurance at every sign-in.
• Small organisations: a single identity provider with passkeys or security keys, OIDC federation to SaaS and a documented acceptance statement covers most of the intent without a formal federal assessment.
• Non-human identities: 800-63 is about people (subscribers). Service accounts, API keys and workload credentials are outside its scope; govern them with workload identity, secrets management and the controls in the Workload Identity Federation Guide.

Implementing 800-63-4: a phased approach

1. Inventory and assess: list online services and user groups, run the impact assessment per group and record target IAL, AAL and FAL. Note where contracts or regulations set a minimum.
2. Gap analysis: compare current proofing, authenticators, session timeouts and federation settings to the targets. Typical gaps are SMS-only MFA, KBV in recovery flows, 90-day password expiry and front-channel SAML without injection protection.
3. Pilot phishing-resistant authentication: enrol a pilot ring (IT and security staff) with passkeys or security keys, run alongside existing MFA, and measure enrolment success and help-desk calls.
4. Enforce by ring: use conditional access or authentication strength policies in report-only or audit mode first, then enforce for privileged roles, then all staff. Keep the previous method available to a named exception group so you can roll back a ring if enrolment fails.
5. Fix recovery and proofing: replace KBV with evidence-based or in-person verification, add trusted referee or manager-verified routes, and make recovery as strong as the AAL it restores.
6. Tighten federation: move applications to back-channel flows, single-audience assertions and documented trust agreements; set session lifetimes per AAL.
7. Document and review: publish the Digital Identity Acceptance Statement, including compensating controls, and review it at least annually or after incidents.

Detection and measurement

Log enrolment, authenticator binding and removal, recovery events, authentication method per sign-in, failed attempts and lockouts, and assertion validation failures at RPs. Watch for repeated push prompts (ATT&CK T1621 Multi-Factor Authentication Request Generation), spraying patterns (T1110.003 Password Spraying) and session cookie theft after sign-in (T1539 Steal Web Session Cookie).

• Phishing-resistant coverage: percentage of workforce sign-ins using phishing-resistant authenticators, target 100% for privileged roles.
• Restricted authenticator use: number of accounts still relying on SMS or voice, trending to zero under a migration plan.
• Recovery assurance: share of account recoveries completed through an IAL-matched process rather than KBV or caller assertion.
• Proofing outcomes: completion rate, abandonment, referee use and confirmed fraud rate per proofing channel.
• Session compliance: applications whose reauthentication and inactivity timeouts match their AAL.
• Federation hygiene: RPs on back-channel flows with signed, single-audience assertions and a current trust agreement.

Framework mapping

In CIS Controls v8.1, Safeguards 6.3 to 6.5 require MFA for externally exposed applications, remote network access and administrative access. In ISO/IEC 27001:2022 Annex A, the closest controls are 5.16 Identity management, 5.17 Authentication information and 8.5 Secure authentication.

Common failure patterns

• Claiming AAL2 with push or SMS MFA alone: two factors that can both be phished or fatigued. The Uber breach began with a contractor's stolen password and repeated push prompts until one was accepted, exactly the gap a phishing-resistant option closes.
• Recovery weaker than sign-in: passkeys at the front door, while the help desk resets accounts after a caller answers security questions that 63A-4 forbids for verification. See the Account Recovery and Help Desk Security Guide.
• One level for everything: forcing IAL3-style proofing on every user, or AAL1 on every application, instead of assessing user groups and partitioning functions.
• Citing revision 3: policies and audit evidence that still reference 800-63-3, missing the AAL2 phishing-resistant offer, syncable authenticator limits and new fraud requirements.
• Synced passkeys for administrators: treating synced passkeys as AAL3; they are permitted only up to AAL2.
• Front-channel bearer assertions without injection protection: leaving SAML or implicit flows in place for sensitive applications, below FAL2.

Practitioner checklist

• Update policies, standards and audit evidence to reference SP 800-63-4 and its July 2025 companion volumes.
• Run the DIRM impact assessment per user group and record IAL, AAL and FAL separately for each service.
• Publish a Digital Identity Acceptance Statement covering tailoring and compensating controls.
• Offer at least one phishing-resistant authenticator everywhere AAL2 applies, and require it for privileged users.
• Use non-exportable, hardware-backed keys for AAL3; do not count synced passkeys towards it.
• Remove KBV from identity verification and recovery; make recovery match the AAL it restores.
• Plan migration away from SMS and voice one-time codes, keeping an unrestricted alternative available.
• Set reauthentication and inactivity timeouts per AAL in the identity provider and applications.
• Move sensitive applications to FAL2: back-channel or nonce-bound assertions, single audience, documented trust agreements.
• Track the six metrics above and review the assessment at least annually.

Standards and references

• NIST: SP 800-63-4 Digital Identity Guidelines
• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-63C-4 Federation and Assertions
• NIST: Digital Identity Guidelines, SP 800-63-4 online edition
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Multi-Factor Authentication Request Generation

Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Phishing-Resistant MFA Guide · Passwordless and Passkeys Guide · Identity Proofing and KYC Guide · Zero Trust Identity Guide