What’s New in 2025 (vs Prior NIST Guidance)
Here’s a look at the biggest shifts in NIST’s thinking about passwords and authenticators:
| Topic | Old Approach | New/Updated 2025 Direction* |
|---|---|---|
| Minimum Length | Earlier versions allowed 8-character minimums for many systems. | For single-factor passwords, verifiers shall require a minimum of 15 characters. (Multi-factor use can have minimum as low as 8 characters.) (NIST Pages) |
| Maximum Length & Allowed Characters | Systems sometimes limit length or restrict certain symbols. | Verifiers should allow up to 64 characters or more. Printable ASCII, space character, and Unicode should be accepted. (NIST Pages) |
| Composition Rules (Complexity) | Many policies forced uppercase, lowercase, digits, special characters, no repeats, etc. | Verifiers shall not impose arbitrary composition rules (e.g. “must include a digit or symbol”) beyond what is captured in blocklists or breached-password filtering. (NIST Pages) |
| Periodic Password Expiration (Forced Resets) | It was common to require password changes every 60–90 days, regardless of compromise. | Verifiers shall not require periodic resets. Instead, password changes should only be triggered when there is evidence of compromise. (NIST Pages) |
| Blocked/Password Screening | Some systems used weak blacklists or none at all. | Passwords must be checked against blocklists of commonly used, expected, or compromised passwords. Full password (not substrings) must be checked. (NIST Pages) |
| Password Hints/Security Questions | Many systems allow or require hints or knowledge-based fallback questions (e.g. “What is your pet’s name?”). | Verifiers shall not store password hints accessible to unauthenticated users, and shall not prompt users to use KBA (knowledge-based authentication). (NIST Pages) |
| "Show Password" Toggle | Some sites disable this by default for “security.” | NIST encourages offering a “show password” option (to reduce user input error without significantly increasing risk). (AuditBoard) |
| Multi-factor/Phishing-resistant authentication | MFA was already encouraged but adoption varied, and some weaker forms (e.g. SMS OTP) were still used. | NIST continues to strongly favor phishing-resistant MFA (e.g. hardware keys, authenticator apps or similar) as a core layer of protection. (pmmi.org) |
*The “shall / shall not / should / may” language is drawn from the formal NIST draft guidance (SP 800-63B-4 and related), which is intended to be adopted by federal agencies and optionally by private entities. (NIST Publications) Also note: some earlier public discussions or blog posts reference 12–16 character minimums; those appear to be transitional or advisory positions, but the formal draft now moves toward 15. (StrongDM)
Why These Changes Make Sense
To many, removing “must include a special character” might seem like relaxing the rules, but in fact, these changes reflect evolving threats, user psychology, and what actually thwarts attackers. Here’s why the shift makes sense:
1. Length Outperforms Forced Complexity
Attackers can precompute guesses for many “clever” rule-based passwords (e.g. Pa$$w0rd!1). Enforcing length gives a larger search space to defenders. Moreover, users burdened by too many constraints often use predictable patterns, which reduces real entropy.
2. Avoiding “Security Theater” Resets
Frequent forced resets lead to behavior like appending “1, 2, 3” to existing passwords. In practice, those changes give little added defense. NIST’s data suggests resets should be event-driven (e.g. after compromise) rather than calendar-driven.
3. Reducing Friction & Support Costs
Simpler rules mean fewer user complaints, fewer helpdesk tickets, and less likelihood that users will write passwords down or reuse them.
4. Defense in Depth Still Matters
Even very long passwords can be phished or exposed by credential stuffing, so strong MFA and breach screening remain essential.
5. Modern Authentication is Evolving
As passkeys, FIDO/WebAuthn, biometrics, and hardware tokens mature, the role of “memorized secrets” should gradually diminish. NIST is signaling that by making the password a piece, not the centerpiece, of authentication.
What You Should Do (Practical Implementation Steps)
Adopting the updated NIST guidance is not just theoretical, it requires alignment across policy, user experience, and technical enforcement. Here’s a roadmap:
1. Update your password policy specs / documentation
- Set a 15-character minimum for single-factor passwords; allow optional lower minimums (e.g. 8) if MFA is being used.
- Specify that composition rules are not required (unless justified by threat model).
- Enforce 64-character (or higher) maximum length to allow future flexibility.
- Document that periodic resets are not required, but resets must occur on detected compromise.
2. Implement password screening / blocklists
- Integrate a public or private list of known compromised passwords (e.g. via HaveIBeenPwned API or custom lists).
- When users attempt to choose a password in the blocklist, require them to pick another and show feedback explaining the rejection.
3. Support “show password” toggles
- Provide a UI control so users can reveal their typed password (especially useful for long passphrases).
- Consider small usability aids (e.g. toggling only after user opt-in).
4. Reject hints and security-question fallback
- Eliminate storage of password hints that could be exposed to unauthenticated users.
- Remove KBA-style fallback questions; use safer recovery flows (e.g. email verification plus MFA).
5. Upgrade MFA and authentication flows
- Encourage or require MFA everywhere feasible, especially for privileged or sensitive actions.
- Prefer phishing-resistant factors such as hardware tokens or app-based authenticators, instead of SMS where possible.
- Ensure recovery and onboarding flows do not weaken MFA protections.
6. User education and transition plans
- Communicate changes clearly to users: emphasize that the new rules are more user-friendly and more secure.
- Where legacy accounts exist under old policies, consider a phased migration, requiring users to update on their next login.
- Provide guidance on crafting strong passphrases (e.g. “four random words” or a sentence-based scheme).
7. Logging, detection, and response mechanisms
- Monitor for suspicious login attempts, anomalous behavior, or credential-stuffing attacks.
- When evidence of compromise appears, trigger immediate password resets (and notify users).
- Keep audit logs and alerts aligned with your access management and incident response plans.
Common Questions & Myths
Does this mean passwords are going away?
Not immediately. While NIST is making the environment more friendly to passkeys, hardware tokens, and passwordless flows, many systems still rely on memorized secrets. The 2025 guidance ensures passwords remain usable, secure, and integrated into a multi-layered identity strategy.
Is 15 characters enough?
For single-factor passwords, NIST mandates 15. But nothing stops users from going longer (up to the allowed maximum) or combining with MFA. Plus, passphrases even way beyond 15 characters are strongly okay, and encouraged.
What about special characters, emojis, non-English characters?
Verifiers should accept all printable ASCII (including space) and Unicode code points. Normalization (e.g. NFC) should be applied before hashing. (NIST Pages) Just ensure the UI and storage layers can handle the full range.
Doesn’t removing forced resets weaken security?
Not if resets are event-driven. The data shows that mandatory resets often cause weaker behavior (e.g. minimal variation). By focusing on breach signals instead, you avoid useless friction while still reacting when risk arises.
How do we handle legacy systems or third-party tools that enforce old rules (e.g. 8-character minimum, mandatory complexity)?
You may need to wrap or layer around them (e.g. in your identity broker, proxy, or SSO layer) or negotiate with vendors. For systems you control, start modernizing them. (In transition, you may need dual policies: one for legacy, one for new.)
The Bigger Picture: Identity Hygiene & Risk Posture
The 2025 NIST password design is not a silver bullet, but it is an invitation to adopt a more mature, threat-aligned approach to authentication. Especially in environments where identity is the frontline of defense, you’ll get the most leverage by:
- Using passkeys and hardware-backed authenticators where possible
- Streamlining user experience (less friction with more security)
- Monitoring for compromise signals continuously
- Applying layered controls (e.g. adaptive MFA, behavioral risk scoring)
At HIG, we believe that secure systems should work with human behavior, not against it. The 2025 NIST direction leans that way: smart, evidence-driven, and user-centric.
