NIST 2025 password recommendations: what's changed
By CaptainDNS
Published on February 20, 2026
- The NIST now prohibits periodic password expiration unless a confirmed breach has occurred
- Complexity rules (uppercase + digit + symbol) are dropped: they actually weaken security in practice
- Minimum of 8 characters required, 15 recommended, and systems must accept at least 64 characters
- Every password must be checked against a compromised secrets database (e.g., Have I Been Pwned) before acceptance
- Password hints and security questions are banned as recovery mechanisms
For years, corporate password policies followed the same recipe: 8 characters minimum, one uppercase letter, one digit, one symbol, and a mandatory change every 90 days. The result: users picking Spring2025! in January and Summer2025! in April. The NIST has officially acknowledged that this approach produces weaker passwords, not stronger ones.
Revision 4 of SP 800-63B, published in 2024 and effective in 2025, overturns most of these practices. This document is the U.S. federal standard for digital authentication, but its influence extends well beyond American borders: ANSSI, BSI, and OWASP are progressively aligning their own recommendations.
This article breaks down the concrete changes, explains the reasoning behind each NIST decision, and provides an action plan to bring your password policy into compliance. To immediately test a password's strength, use our password generator with its real-time strength indicator.
What NIST SP 800-63B-4 says
SP 800-63B is part of the NIST SP 800-63 suite (Digital Identity Guidelines), which covers the entire digital identity lifecycle. Revision 4 replaces the 2017 version 3 and introduces major changes to the "Memorized Secrets" section (passwords and passphrases).
Scope of the document
SP 800-63B targets authentication service providers (CSPs, Credential Service Providers) and verifiers. It defines three assurance levels (AAL1, AAL2, AAL3), each with increasing requirements. The password recommendations apply primarily to AAL1 (single-factor authentication) and serve as the baseline for higher levels.
The 8 major changes
The following table summarizes the rules that changed between version 3 (2017) and version 4 (2024/2025):
| Rule | SP 800-63B-3 (2017) | SP 800-63B-4 (2025) |
|---|---|---|
| Minimum length | 8 characters | 8 required, 15 recommended |
| Maximum length | Not specified | 64 characters minimum supported |
| Complexity rules | Discouraged | Prohibited (SHALL NOT) |
| Periodic rotation | Discouraged | Prohibited unless breached |
| Breach verification | Recommended | Required (SHALL) |
| Password hints | Not mentioned | Prohibited |
| Security questions | Discouraged | Prohibited |
| All Unicode characters | Recommended | Required |
The shift from "SHOULD NOT" (discouraged) to "SHALL NOT" (prohibited) is significant: this is no longer a recommendation, it's a compliance requirement.
Why the NIST is dropping mandatory rotation
Periodic password rotation is the most controversial rule in information security. The NIST now explicitly prohibits it, and the reasoning is empirical.
The documented problem
Studies conducted at the University of North Carolina (Chappell et al.) showed that when users are forced to change their password regularly, they adopt predictable patterns:
- Incrementing:
Password1→Password2→Password3 - Seasonal rotation:
Winter2024!→Spring2025! - Minimal changes:
MyCat$→MyCat$1→MyCat$12
An attacker who obtains an old password can guess the next one in fewer than 5 attempts in 41% of cases. Rotation doesn't add security: it encourages predictability.
The new rule
A password should only be changed in two cases:
- Confirmed breach: the password appears in a breached database
- User request: a voluntary change
Administrators must remove all automatic expiration policies (90-day, 180-day, annual). The system should, however, actively monitor breach databases and force a change if the current password appears in one.
Why complexity rules are counterproductive
Requiring "at least one uppercase letter, one digit, and one symbol" seems logical on paper. In practice, it produces the opposite effect.
The measured side effect
When a system enforces composition rules, users converge on the same strategies:
- Uppercase in the first position (95% of cases)
- Digits at the end (89% of cases)
- Symbol:
!or@(78% of cases)
Password1! satisfies every classic complexity rule. It's cracked in under a second by any brute-force tool that tests common patterns. The theoretical entropy of a constrained password is higher, but the actual entropy drops because humans are predictable.
What the NIST recommends instead
Length is the dominant factor. A 15-character random password with no composition constraints offers more entropy than an 8-character password that meets every complexity rule. The NIST requires systems to:
- Accept all printable ASCII and Unicode characters (including spaces)
- Not enforce composition rules
- Support a minimum of 64 characters (to allow passphrases)
- Normalize Unicode input (NFKC or NFKD) to prevent encoding issues
Verification against compromised password databases
This is the most technical change. Every password chosen by a user must be checked against a list of compromised secrets before being accepted.
How to implement verification
The NIST doesn't prescribe a specific implementation, but the most common method uses Troy Hunt's Have I Been Pwned (HIBP) service:
- The system computes the SHA-1 hash of the candidate password
- It sends the first 5 characters of the hash to the HIBP API (k-anonymity)
- The API returns all matching hashes
- The system checks locally whether the full hash is in the list
This mechanism preserves privacy: the password is never transmitted in plain text or as a complete hash. The HIBP API contains over 900 million unique passwords from real breaches.
When to verify
| Timing | Required | Recommended |
|---|---|---|
| Account creation | Yes | - |
| Password change | Yes | - |
| Login | - | Yes (periodic check) |
If the password is found in the breach database, the system must reject it with a clear message explaining why and inviting the user to choose a different one.
What the NIST explicitly prohibits
Beyond the major changes, several practices are now formally banned:
Password hints
Hint fields that display a reminder when a password is forgotten are prohibited. They expose information that helps an attacker guess the password. A hint like "my cat's name + year" reduces the search space to a few thousand combinations.
Security questions
"What is your mother's maiden name?" or "What city were you born in?": these knowledge-based authentication (KBA) questions are banned as the sole recovery factor. The answers are often findable on social media or in public databases.
Password truncation
A system must never truncate the password to a fixed length before hashing. If a user enters 40 characters, all 40 characters must be processed. Truncation silently reduces entropy and creates a false sense of security.
Hashing without salt
The NIST requires passwords to be stored with a resistant hashing function (bcrypt, scrypt, Argon2id, or PBKDF2) and a unique salt per user. SHA-256 alone is not acceptable: it's too fast and vulnerable to rainbow table attacks.
NIST, OWASP, and ANSSI compared
The NIST isn't the only reference. Here's how its recommendations compare to other major standards:
| Criterion | NIST SP 800-63B-4 | OWASP ASVS 4.0 | ANSSI (2021) |
|---|---|---|---|
| Min. length | 8 (15 recommended) | 12 | 12 (16 for admins) |
| Max. supported length | 64+ | 128 | Not specified |
| Complexity | Prohibited | Discouraged | Allowed with conditions |
| Rotation | Prohibited unless breached | Discouraged | 1 year max |
| Breach verification | Required | Recommended | Not mentioned |
| MFA | Required AAL2+ | Required level 2+ | Recommended |
| Security questions | Prohibited | Prohibited | Not mentioned |
The three frameworks converge on fundamental principles (length > complexity, no unnecessary rotation) but diverge on strictness. ANSSI remains more conservative on complexity and rotation. OWASP is stricter on minimum length.
🎯 Compliance action plan
For system administrators and CISOs who need to update their policy:
- Remove periodic expiration: disable 90/180-day change policies in Active Directory, LDAP, or your IAM. Set up breach monitoring instead
- Drop composition rules: remove "uppercase + digit + symbol" requirements. Increase the minimum length to 15 characters and the supported maximum to at least 64
- Integrate HIBP verification: implement k-anonymity verification at password creation and change. Use a hash generator to validate your SHA-1 implementations
- Accept all characters: full Unicode, including spaces. Apply NFKC normalization before hashing
- Deploy MFA: a password alone isn't enough. FIDO2/WebAuthn for critical accounts, TOTP at minimum for everything else
- Document your policy: create a written policy aligned with SP 800-63B-4 and communicate the changes to users. Explain why they will no longer need to change their password regularly
FAQ
What is NIST SP 800-63B?
NIST SP 800-63B is a reference document published by the U.S. National Institute of Standards and Technology (NIST). It's part of the Digital Identity Guidelines suite and specifically covers authentication and credential lifecycle management. Revision 4, published in 2024, is the current version and brings significant changes to password recommendations.
Do I still need to change my password regularly?
No. The NIST explicitly prohibits periodic password expiration (SHALL NOT). A password should only be changed if it's been compromised (found in a breached database) or if the user voluntarily requests a change. Studies show that mandatory rotation pushes users toward predictable, weaker passwords.
Are complexity rules still necessary?
No. The NIST prohibits composition rules ("at least one uppercase letter, one digit, one symbol"). These rules produce predictable patterns (uppercase at the start, digits at the end, ! as the symbol) that reduce actual entropy. Length is the dominant factor: a long, random password is more secure than a short "complex" one.
What's the minimum password length in 2025?
The NIST requires a minimum of 8 characters and recommends 15. OWASP and ANSSI recommend 12. In practice, aim for 15+ characters for user accounts and 20+ for administrator accounts. Systems must accept at least 64 characters to support passphrases.
How do I check if a password has been compromised?
Use the k-anonymity protocol with the Have I Been Pwned API: hash the password with SHA-1, send the first 5 characters of the hash to the API, and check whether the full hash appears in the results. The password is never transmitted in plain text. This verification should be performed at account creation and every password change.
Does the NIST apply outside the United States?
SP 800-63B is a U.S. federal standard, but its influence is global. OWASP draws directly from it, Germany's BSI and France's ANSSI are progressively aligning their recommendations. For international companies or those handling U.S. citizen data, following the NIST is a de facto standard, even without a direct legal obligation.
Which hashing algorithm should be used to store passwords?
The NIST recommends Argon2id, bcrypt, scrypt, or PBKDF2, with a unique salt per user. SHA-256 or MD5 alone are unacceptable: they're too fast and vulnerable to rainbow table attacks and GPU brute force. Argon2id is the OWASP-recommended choice in 2025, with memory and time parameters tuned to your infrastructure.
Glossary
- SP 800-63B: NIST Special Publication defining digital authentication requirements, Part B (Authentication and Lifecycle Management). Revision 4 (2024) is the current version.
- AAL (Authentication Assurance Level): authentication assurance level defined by the NIST, ranging from AAL1 (single factor) to AAL3 (phishing-resistant cryptographic hardware).
- k-anonymity: a cryptographic technique that lets you check whether a piece of data belongs to a set without revealing the data itself. Used by Have I Been Pwned for password verification.
- Salt: a unique random value added to a password before hashing, preventing precomputed table attacks (rainbow tables).
- Argon2id: the winning password hashing function from the Password Hashing Competition (2015), resistant to GPU and ASIC attacks thanks to its configurable memory consumption.
Check your password strength now: test whether your URLs are being exploited for phishing with our phishing URL detector, an essential complement to any solid password policy.
📚 Related password security guides
- Passkeys vs passwords: should you ditch your passwords in 2025?
- Passphrase vs password: which is actually more secure?
