For a 2026 identity project, start with final NIST SP 800-63 revision 4 rather than an old draft or a headline about "new 2026 password rules." NIST's publication record identifies revision 4 as a 2025 publication. This article concerns applying that guidance in 2026; it does not announce a new edition.
The series covers identity proofing, authentication, and federation. Buying a product with relevant features does not establish that the whole implementation meets an assurance level.
Use the password rules with their conditions
NIST SP 800-63B-4, section 3.1.1.2, requires at least 15 characters for a password used as a single factor. Passwords used only within MFA may be shorter, but must have at least eight characters. It recommends allowing a maximum of at least 64 characters.
The section prohibits arbitrary character-mixture rules and routine forced password changes. Evidence of compromise still requires a change. It also calls for blocking commonly used, expected, or compromised choices.
Do not summarize that as "passwords never expire" or "eight characters is enough for everyone." Preserve the conditions when writing policy and testing the actual verifier.
Separate a minimum rule from your implementation decision
A security team may choose a longer password minimum or another operational control for a particular system. Record why, and check the effect on legitimate users and recovery workload.
For a proposed test, try a long passphrase, a known blocked choice, a rejected choice, and a supported password manager. Observe what each connected target actually accepts. A reset portal can look consistent while downstream systems enforce different rules.
Do not claim every recommendation is new in revision 4. Some principles were already present in earlier guidance.
Check phishing resistance and recovery separately
The AAL2 guidance requires verifiers to offer a phishing-resistant authentication option. Offering that option is different from requiring every user to use it. Determine the assurance level and obligations that apply to your service before turning the statement into a universal company rule.
Recovery is a separate design task. Walk through what happens when a user loses their normal authenticator. Record who can authorize a replacement, how the person is verified, and which sessions or credentials need attention after suspected compromise.
Turn the review into evidence
Create a short register with the relevant requirement, affected service, configured control, test result, and unresolved gap. Assign an owner to every exception. Keep authentication, provisioning, and access review responsibilities distinct.
If NIM handles onboarding or reset, use the onboarding guide and reset evaluation to identify operational tests. Validate the full path through each verifier rather than labeling a workflow "NIST compliant" because it has a password field and verification code.
For governance context from an earlier period, see the 2025 identity planning retrospective.