NIST SP 800-63-3 was superseded on 1 August 2025, but most identity programmes, audit criteria and vendor contracts still quote its numbers: eight-character passwords, 30-minute AAL2 timeouts and an IAL1 that needed no proofing. Revision 4 changes enough of those numbers, and adds enough new obligations, that "we follow NIST 800-63" now needs a version and a gap analysis behind it. This guide works change by change, from risk management through proofing, authentication and federation, and then sets out a transition plan with inventory, testing and rollback. It is for IAM architects, identity product owners and assurance teams in government and in organisations that use 800-63 as their benchmark. What Revision 4 says in full is covered in the NIST SP 800-63 Digital Identity Guidelines Guide and the three volume guides; this page is about the delta.
Key takeaways
- Revision 4 is final and current. NIST published SP 800-63-4 and volumes 63A-4, 63B-4 and 63C-4 on 31 July 2025, superseding 800-63-3; NIST's publication page states no transition period.
- Several "SHOULD NOT"s became "SHALL NOT"s. Password composition rules and forced periodic changes are now prohibited, and the single-factor password minimum rose from 8 to 15 characters.
- Phishing resistance moves down to AAL2. Verifiers must offer at least one phishing-resistant option at AAL2, and federal agencies must require it for staff, contractors and partners.
- Synced passkeys are explicitly allowed at AAL2, never at AAL3. Appendix B of 63B-4 sets requirements for the sync fabric; AAL3 now requires a non-exportable key.
- Proofing and federation got stricter. IAL1 now involves proofing, KBV is banned for identity verification, CSPs need a fraud management programme, and FAL2 now means injection protection and single-RP assertions rather than encryption.
What is changing and why
NIST frames Revision 4 around fraud and customer experience: it repurposes IAL1, updates authentication threat models for newer attacks, adds phishing-resistant options, introduces controls against automated attacks on enrolment, and prepares for mobile driver's licences and verifiable credentials. It also replaces a largely checkbox selection of assurance levels with a Digital Identity Risk Management (DIRM) process, adds control tailoring, and asks for continuous evaluation with metrics and redress. The table below lists the changes most likely to require work.
| Area | SP 800-63-3 | SP 800-63-4 | Migration impact |
|---|---|---|---|
| Assurance level selection | Impact-based selection of IAL, AAL and FAL | Five-step DIRM; tailoring with compensating or supplemental controls, documented in a Digital Identity Acceptance Statement (63-4 Sec. 3.4.4); continuous evaluation with metrics and redress | Re-run selection per service; produce acceptance statements |
| Password length | Minimum 8 characters (63B Sec. 5.1.1.2) | Minimum 15 when used as a single factor; 8 when only used within MFA (63B-4 Sec. 3.1.1.2) | Policy change for any password-only service |
| Composition and rotation | SHOULD NOT | SHALL NOT; blocklist check on the full password; password managers SHALL be allowed, paste SHOULD be | Remove complexity and expiry settings |
| Phishing resistance | Verifier impersonation resistance required only at AAL3 | SHALL be offered at AAL2; required for federal staff, contractors and partners; required at AAL3 | Add FIDO2 or PKI options at AAL2 |
| Syncable authenticators | Not addressed | Permitted at AAL2 under Appendix B; SHALL NOT be used at AAL3 | Decide passkey policy per AAL |
| AAL3 keys | Verifier impersonation resistant cryptographic authenticator | Phishing resistant and non-exportable private key | Confirm AAL3 tokens are hardware-bound |
| AAL2 reauthentication | 12 hours overall; 30 minutes inactivity (63B Sec. 4.2.3) | SHOULD be no more than 24 hours overall and 1 hour inactivity | Session settings can be relaxed if risk allows |
| Out-of-band push | Approve-only flows widely used | Compare-and-approve without transferring a secret "no longer considered acceptable" (63B-4 Sec. 3.1.3) | Move push MFA to number matching or code entry |
| Rate limiting | 100 consecutive failures per account | 100 per authenticator, after which it is disabled and must be rebound | Check lockout logic per factor |
| IAL1 | No identity proofing required | Repurposed: core attributes validated | Low-assurance services may need proofing |
| Proofing methods | Remote and in-person | Four types: remote unattended, remote attended, on-site unattended, on-site attended (63A-4 Sec. 2.1.3); trusted referees and applicant references | Re-document each proofing channel |
| KBV | Permitted in limited cases | SHALL NOT be used for identity verification (63A-4 Sec. 2.5.1); allowed only within fraud management | Remove KBV from verification flows |
| Fraud | Limited requirements | Fraud management programme SHALL exist; death records check SHALL be run; injection attack controls (63A-4 Sec. 3.2, 3.14) | New programme and controls for CSPs |
| FAL2 | Assertion encrypted to the RP | Injection protection, RP-initiated, single-RP audience, trust agreement | Review IdP-initiated SSO and multi-audience tokens |
| FAL3 | Holder-of-key assertion | Holder-of-key assertion or a bound authenticator (63C-4 Sec. 3.15, 3.16) | New implementation route for FAL3 |
Official timeline and current status
| Date | Event |
|---|---|
| 2 March 2020 | Final update of SP 800-63-3 (the version Revision 4 supersedes) |
| 8 June 2020 | First Revision 4 milestone on NIST's document history |
| 16 December 2022 | Initial public draft |
| 21 August 2024 | Second public draft |
| 31 July 2025 | SP 800-63-4, 63A-4, 63B-4 and 63C-4 published as final |
| 1 August 2025 | SP 800-63-3 shown by NIST as superseded |
| October 2026 | NIST announces an Implementation Resource Hub for SP 800-63-4 |
NIST's publication page lists no withdrawal grace period for 800-63-3, and none is needed for a guideline: the practical deadline comes from whoever references it. Federal agencies, auditors, sector regulators and contracts set their own adoption dates. Status as checked on 8 November 2026; watch the NIST publication page for errata.
Who and what is affected
- Federal agencies and their contractors: the most direct audience. 63B-4 Sec. 2.2 requires agencies to mandate phishing-resistant authentication for staff, contractors and partners, and Appendix B sets federal-specific sync fabric controls (FISMA moderate fabric, device management to block unauthorised sync, agency-managed accounts).
- Credential service providers and identity proofing vendors: IAL changes, fraud programme, death records checks, injection attack controls and biometric performance rules land here first.
- Relying parties and identity providers: FAL2 and FAL3 changes, trust agreements that state expected IAL, AAL and FAL plus redress and retention terms, and proxy rules (effective FAL is the lowest on the path).
- Private sector programmes using 800-63 as a benchmark: password policies, MFA standards and customer authentication designs written against Revision 3.
- Auditors and assessors: test procedures and evidence requests that still quote Revision 3 section numbers (Sec. 5.1.1 in 63B became Sec. 3.1.1 in 63B-4).
Finding affected systems and identities
Build a service inventory before changing anything. For each online service, record the current xAL claim, the authenticators offered, session settings, proofing channel and federation pattern. Then search for the configuration that encodes Revision 3.
- Policy text: search security standards, password policies and contracts for "800-63-3", "800-63B" without "-4", "8 characters", "90 days" and "complexity".
- Directory and IdP password settings: minimum length, complexity flags, maximum age and history in Active Directory fine-grained password policies, Entra ID, Okta or customer identity platforms. Any service where a password alone grants access needs the 15-character minimum.
- MFA methods by AAL: report which users can authenticate with SMS, voice, email codes or approve-only push. Email is still prohibited for out-of-band authentication; approve-only push now fails 63B-4.
- Passkey telemetry: WebAuthn responses carry Backup Eligible (BE) and Backup State (BS) flags. Logging them shows how many credentials are syncable, which matters for any service claiming AAL3. 63B-4 says verifiers SHALL check the User Verified flag.
- Session policies: idle and absolute timeouts per application and AAL.
- Proofing flows: any step that uses knowledge-based questions to verify identity, and whether enrolment has injection and automation controls.
- Federation: IdP-initiated SAML flows, assertions with multiple audiences, and proxies or brokers in the path, since each lowers the effective FAL.
Where identity fits for non-human identities: 800-63 is written for human subscribers, and Revision 4 does not create assurance levels for workloads or AI agents. Do not stretch AAL claims to service accounts or API keys during migration; manage them under separate machine identity controls. See the Service Account Security Guide.
Migration options
There are three realistic approaches, and the right one depends on scale and obligation.
| Approach | How it works | Fits | Risk |
|---|---|---|---|
| Big-bang re-baseline | Re-run DIRM for every service, adopt all Revision 4 requirements at once | Small portfolios; new programmes | Change fatigue; user disruption from password and MFA changes together |
| Prioritised by change type | Quick wins first (remove rotation and complexity, add phishing-resistant options), then proofing and federation | Most organisations | Mixed-version period needs clear documentation |
| Service by service | Migrate each service fully when it is next changed, starting with the highest impact | Large federal or enterprise estates | Long tail of Revision 3 services; requires a tracker |
Recommended sequence
- Policy first: update the identity standard to cite 800-63-4 and record any tailoring in Digital Identity Acceptance Statements per service.
- Passwords: remove composition and expiry rules, raise single-factor minimums to 15, allow paste and password managers, and keep blocklist checks. Removing expiry is low risk only when compromise detection and forced reset on evidence of compromise are in place.
- Authenticators: offer a phishing-resistant option at every AAL2 service (FIDO2 passkeys or PKI smart cards), convert push MFA to number matching or code entry, and set policy on synced versus device-bound passkeys. See the Phishing-Resistant MFA Guide.
- AAL3 review: confirm AAL3 services accept only non-exportable keys; use attestation or the BE flag to reject syncable credentials there.
- Proofing: remove KBV from verification, stand up or document the fraud management programme, and add injection attack controls for remote proofing. See the NIST SP 800-63A-4 Identity Proofing (IAL) Guide.
- Federation: move FAL2 services to RP-initiated flows with single-audience assertions and injection protection, and write trust agreements that state xAL expectations. See the NIST SP 800-63C-4 Federation Assurance Levels Guide.
- Continuous evaluation: define the metrics DIRM Step 5 expects and a redress route for users who are wrongly blocked.
Small versus large: a small organisation with one IdP can complete steps 1 to 4 in a quarter through IdP policy alone. A federal agency or large CSP will need a programme with service-level acceptance statements, procurement changes for proofing vendors and a federation trust agreement refresh.
Testing and rollback
- Password policy pilots: apply the new policy to a pilot group, measure reset tickets and blocklist rejections, then expand. Rollback is reverting the policy object, but do not reintroduce rotation: it is now a SHALL NOT.
- Authenticator rollout: run phishing-resistant enrolment as opt-in first, then make it the default for privileged and remote access. Keep a recovery path that meets the AAL, as 63B-4 Sec. 4.2 requires, and bind at least two authenticators per user. See the Account Recovery and Help Desk Security Guide.
- Push changes: switch number matching on for a pilot ring and watch failed sign-ins and help desk volume before enforcing.
- Session timeouts: lengthening AAL2 timeouts to the Revision 4 ceilings is optional; do it per service after DIRM, not globally.
- Federation: test RP-initiated flows and audience restriction in staging with each relying party; keep the old configuration available until each RP signs off.
| Metric | What it shows |
|---|---|
| Percentage of AAL2 services offering a phishing-resistant option | Core 63B-4 Sec. 2.2 obligation |
| Percentage of workforce sign-ins using phishing-resistant methods | Real adoption, not availability |
| Services with a current Digital Identity Acceptance Statement | DIRM completion |
| Users able to authenticate only with SMS, voice or approve-only push | Residual weak factors |
| Syncable credentials (BE flag set) on AAL3 services | Should be zero |
| Proofing flows still using KBV | Should be zero |
| Framework | Reference | Link to the migration |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2, IA-5, IA-5(1), IA-8, IA-11, IA-12 | Authentication, password rules, non-organisational users, reauthentication, proofing |
| NIST CSF 2.0 | PR.AA-01, PR.AA-02, PR.AA-03; GV.PO-02 | Identity management, proofing, authentication; policy updated for changed requirements |
| MITRE ATT&CK v20 | T1110 Brute Force; T1621 Multi-Factor Authentication Request Generation; T1111 Multi-Factor Authentication Interception; T1606.002 SAML Tokens | Threats the password, push, phishing-resistance and FAL changes address |
Risks of doing nothing
- Audit findings on a superseded baseline: claiming conformance to a document NIST lists as superseded invites findings and weakens contractual assurances.
- Push fatigue stays open: approve-only push is the pattern abused in the Uber breach, where repeated MFA prompts and a contractor's password led to access; Revision 4 no longer accepts it.
- Phishable AAL2: without a phishing-resistant option, AAL2 services remain exposed to adversary-in-the-middle kits that relay OTPs (T1111).
- Overstated AAL3: accepting synced passkeys on an AAL3 service is a conformance failure under 63B-4 Sec. 2.3.
- Proofing fraud: KBV answers are widely available from past breaches, and remote proofing without injection controls is open to deepfake and replay attacks.
- User friction for nothing: keeping forced rotation and complexity rules imposes cost that NIST now says delivers no benefit.
Practitioner checklist
- Update identity standards, contracts and audit criteria to cite SP 800-63-4 and its volume section numbers.
- Inventory every service with its current IAL, AAL, FAL, authenticators, session settings and federation pattern.
- Re-run DIRM per service and record tailoring in a Digital Identity Acceptance Statement.
- Remove password composition and expiry rules; set a 15-character minimum for single-factor passwords.
- Offer a phishing-resistant option on every AAL2 service and require it for federal workforce users.
- Replace approve-only push with number matching or code transfer.
- Set passkey policy: synced allowed at AAL2 under Appendix B, device-bound non-exportable keys only at AAL3.
- Remove KBV from identity verification and document the fraud management programme.
- Move FAL2 relying parties to RP-initiated, single-audience assertions with injection protection.
- Report the migration metrics monthly until every service is on Revision 4.
Standards and references
- NIST: SP 800-63-4 Digital Identity Guidelines (publication page)
- NIST: SP 800-63-4 Digital Identity Guidelines, base volume
- NIST: SP 800-63A-4 Identity Proofing and Enrollment
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-63B-4 Appendix B, Syncable Authenticators
- NIST: SP 800-63C-4 Federation and Assertions
- NIST: SP 800-63B (Revision 3, superseded)
Related NHI Mgmt Group resources: NIST SP 800-63 Digital Identity Guidelines Guide · NIST SP 800-63B-4 Authenticator Assurance Levels Guide · Password Policy Guide (NIST-aligned) · Passwordless and Passkeys Guide · MFA Fatigue and Bypass Guide