A practical guide to NIST SP 800-63B-4, including authentication assurance levels, modern password rules, phishing resistance, and account recovery.
NIST SP 800-63B-4, published on July 31, 2025, is the current US National Institute of Standards and Technology guidance for authentication and authenticator management. It replaces the idea that every service should apply the same login rules with an approach based on impact, risk, and the strength of the evidence presented by the subscriber.
The document is technical guidance, not a universal law. Organizations still need to map applicable regulations, threats, and user populations to their implementation.
Authentication Assurance Levels
AAL1
AAL1 provides basic confidence that the person accessing an account controls an authenticator bound to it. Single-factor authentication is permitted. A password can satisfy this level when it is implemented according to the verifier requirements, although higher-risk services should not assume AAL1 is sufficient.
AAL2
AAL2 requires two distinct authentication factors. A service must offer at least one phishing-resistant option. A password plus an authenticator-app code can provide two factors, but a manually entered one-time code is not itself phishing-resistant because a convincing proxy site can relay it. Passkeys bound to an appropriate device or FIDO security keys can provide stronger phishing resistance.
AAL3
AAL3 provides very high confidence and requires phishing-resistant authentication using a non-exportable cryptographic key. The protocol and authenticator must resist verifier impersonation, and the authentication process uses two distinct factors. Hardware-backed cryptographic authenticators are typical for this level.
Modern password requirements
NIST's password guidance is designed around how people and attackers actually behave:
Length: a password used as a single authentication factor must be at least 15 characters. A password used only as part of multi-factor authentication may be at least eight characters. Verifiers should permit a maximum length of at least 64 characters.
No arbitrary composition rules: services should not require a mixture of uppercase letters, numbers, and symbols. Such rules tend to produce predictable patterns.
No routine forced rotation: passwords should not be changed on a fixed schedule unless there is evidence that the authenticator has been compromised.
Compromised-value screening: the complete candidate password must be compared with a blocklist that includes common, expected, or compromised values.
Usability: password managers, autofill, and paste should be allowed. Spaces and a broad range of characters should be accepted.
Online guessing resistance: verifiers must rate-limit failed attempts.
A privacy-preserving breach check can support the blocklist requirement. The candidate should be checked in a way that does not disclose the plaintext password or complete hash to the lookup provider.
Authenticator lifecycle and recovery
Authentication security includes more than the login screen. A service needs controlled processes to bind a new authenticator, replace a lost device, revoke a stolen authenticator, issue recovery codes, and restore access without turning support staff into an easy bypass. Recovery events should generate notifications and high-risk changes should receive additional scrutiny.
Session management
After authentication, the session becomes the credential. Services should protect session secrets, use appropriate inactivity and overall timeouts, reauthenticate for sensitive actions, and terminate sessions when compromise or authenticator loss is reported. A strong login cannot compensate for an exposed, long-lived session token.
What organizations should change
Replace composition rules and routine rotation with length, compromised-password screening, and rate limiting.
Offer phishing-resistant authentication and prioritize it for administrators and high-impact transactions.
Review recovery, authenticator replacement, and session revocation as part of the same assurance design.
Document which AAL is required for each service and why; do not label every password-plus-code flow as phishing-resistant.
The full normative requirements and implementation notes are available in the official SP 800-63B-4 publication.