TL;DR: NIST’s 2025 revision to SP 800‑63B shifts password hygiene away from fiddly composition rules and toward length, screening, and usability. Pair long passphrases with phishing‑resistant MFA, stop scheduled rotations, and make password managers first‑class citizens.
Who is NIST, and why this report matters
The National Institute of Standards and Technology (NIST) is a U.S. federal agency that publishes widely adopted technical guidance on security and technology. Its Digital Identity Guidelines (SP 800‑63) are referenced by government and industry alike; when NIST updates these, identity providers and compliance frameworks typically follow suit.
In 2025, NIST refreshed SP 800‑63B to reflect how passwords are actually attacked today. The big shift: emphasize length, screening against known‑compromised passwords, and usability—and pair passwords with phishing‑resistant MFA wherever possible. This reduces user friction while improving real‑world resistance to guessing and phishing.
For businesses, that means you can simplify rules (no more “1 uppercase, 1 symbol”), support long, natural passphrases, and rely on modern MFA like FIDO2/WebAuthn. You’ll get stronger credentials and fewer support tickets.
The essentials (policy you can adopt today)
1) Length over complexity
- Single‑factor accounts: minimum 15 characters.
- With MFA: minimum 8 characters.
- Max length: support ≥ 64 characters (do not truncate).
- Characters allowed: all printable ASCII, spaces, and Unicode. Allow spaces in passphrases.
- No composition rules. Don’t force symbols, caps, etc. Users can add them, but rules are not required.
Why: Length grows the search space exponentially without relying on brittle tricks. Long passphrases are harder to guess and easier to remember than short, decorated strings.
Length works because attackers start with common patterns and work upward. A short password—even with substitutions like @ for a—falls quickly to modern cracking rigs, while a natural‑language sentence or four random words often exceeds 20–30 characters and resists offline brute‑force for far longer.
Allowing spaces and Unicode lets people create secrets in the way they naturally think and type. Bilingual users can lean on multiple languages; everyone benefits from being able to include whitespace. Count each code point as a character and never truncate to avoid weakening long inputs.
Dropping composition rules eliminates predictable habits (capital first letter, symbol at the end). Instead of scolding for missing symbols, reward length with a passphrase‑centric meter and allow paste/autofill so password managers can generate long, unique secrets for every site.
2) Screening/blocklists at set/change time
When users create or change a password, automatically reject those found in:
- Known breach corpora (e.g., “Have I Been Pwned”‑style datasets)
- Common and expected choices (season+year, keyboard walks, service name, company name, product names)
- Contextually risky terms (e.g., the user’s username or email local‑part)
Why: Real attacks start with the most common strings. Screening prevents weak or previously‑compromised choices from ever being accepted.
Think of screening as a fraud check for passwords. If a candidate appears in breach dumps—or matches templates like Summer2025! or CompanyName123—you decline it before it’s stored. That single gate removes a disproportionate share of easy wins for attackers.
Use privacy‑preserving lookups (k‑anonymity or local hashed dictionaries) so the full password never leaves your control, and refresh your data frequently to keep pace with new spills. Compare the entire string, not substrings, or small tweaks to a known‑bad base will slip through.
Screening isn’t a silver bullet; determined adversaries can still target specific users. But when combined with rate‑limits and MFA, it raises the cost of guessing enough to stop most mass‑scale abuse.
3) Rotation and changes
- Do not require periodic resets on a schedule.
- Do force a reset on evidence of compromise (alerts, confirmed phishing, unusual sign‑ins) or at a role/risk change.
Why: Calendar‑based rotations push people into predictable variants and drive insecure workarounds. Event‑driven changes align effort with actual risk.
Forced rotations create sequences—Winter2025! → Spring2025!—that show up across breach corpora and are easy to guess. They also increase help‑desk load and encourage reuse elsewhere, raising organizational risk.
An event‑driven policy ties resets to meaningful signals: credential‑stuffing alerts, dark‑web hits, anomalous geo‑velocity, or confirmed phishing. When a trigger fires, require a change and screen the new password to prevent recycling of a compromised base.
Complement this with security notifications (new sign‑in, authenticator added, recovery initiated). Early visibility helps users spot fraud and limits resets to moments that matter.
4) Usability (security’s secret weapon)
- Allow paste and autofill to support password managers.
- Show passphrase meters that reward length, not just character classes.
- No password hints. Avoid knowledge‑based questions; use recovery codes or out‑of‑band links instead.
Why: Usable defenses get used. When people can rely on managers and clear UI cues, they create stronger secrets and make fewer mistakes.
Allow paste/autofill so managers can do what humans can’t: produce unique, 20+ character secrets for every account without typos. This cuts lockouts and eliminates cross‑site reuse—one of the top drivers of account takeovers after breaches.
Design the UI to reward length. A meter that improves as the passphrase grows (e.g., guitar raven candle subway planet) nudges users toward the property that matters most. Copy helps too—invite a memorable sentence or several random words instead of chasing symbols.
For recovery, ditch password hints and knowledge‑based questions, which are easily guessed or scraped from social media. Use one‑time recovery codes stored in the manager and time‑boxed reset links via verified channels. You’ll improve both usability and resilience under attack.
5) Verifier/engineering controls
- Store only salted, one‑way password hashes (e.g., Argon2id preferred; scrypt or PBKDF2 with strong parameters as alternatives).
- Rate‑limit online guesses and introduce progressive delays or temporary lockouts.
- Enforce TLS (and HSTS) for all auth endpoints. Protect logs and error messages from leaking verifier details.
Why: Even perfect user behavior can be undone by weak server‑side handling. Strong hashing, throttling, and secure transport keep secrets secret.
A stolen database of plaintext—or fast hashes like unsalted SHA‑1—is a catastrophe. Salted, slow, memory‑hard hashes make each offline guess expensive, especially with unique salts per account and modern parameters.
Online, enforce rate‑limits and stable error messages (e.g., “invalid username or password”) to blunt brute‑force and account enumeration. Progressive backoff or temporary lockouts raise the cost of indiscriminate guessing without harming legitimate users.
Transport security and log hygiene close the loop. Always require TLS and set HSTS to prevent downgrade/strip attacks. Keep authentication logs minimal and access‑controlled so secrets or precise failure reasons don’t leak.
6) MFA posture (prefer phishing‑resistant)
- Make MFA the default for workforce apps.
- Prefer FIDO2/WebAuthn authenticators (security keys or platform passkeys). Where passwords remain, they serve as one factor alongside a phishing‑resistant second factor whenever possible.
Why: Not all MFA is equal. Phishing‑resistant authenticators bind the login to the site’s origin, defeating look‑alike sites and man‑in‑the‑middle kits.
Codes from apps (TOTP) and SMS can be captured by phishing pages. FIDO2/WebAuthn prevents this by cryptographically tying authentication to the legitimate domain, so a token minted for example.com cannot be replayed at login‑example.com.
Start with your highest‑risk users and systems—administrators, finance, HR, production access—then expand as adoption grows. Most modern devices support platform passkeys, delivering strong security without extra hardware and reducing day‑one friction.
Plan for recovery without backsliding. Issue backup codes and define a clear, auditable re‑binding process for lost devices. Keep lower‑assurance methods (app codes, SMS) as backups, not primaries, to avoid “MFA fatigue” workarounds.
Final take
Stronger authentication in 2025 is about usability that scales security: long passphrases, smart screening, modern MFA, and fewer hoops. Update the policy, tune the IdP, train your team—and you’ll cut risk without adding friction.
