The New Password Rules

Picture a signup form with a red checklist under the password field. One uppercase letter. One number. One symbol. At least eight characters. Change it every 90 days. Each rule turns green as the user types Summer2026!.

That checklist is no longer best practice. Under the current federal standard, most of it is out of compliance.

NIST SP 800-63B Revision 4 was published as final on July 31, 2025, and superseded the previous version on August 1, 2025. (NIST CSRC) It is the US federal guideline for authentication, and it shapes what auditors, insurers, and enterprise customers expect from everyone else. It says verifiers shall not impose composition rules and shall not require periodic password changes. A change is required only on evidence of compromise, and new passwords must be screened against a blocklist of common and breached passwords. (NIST SP 800-63B-4, Section 3.1.1.2; summaries from Security Scientist and Enzoic)

What the standard actually says

NIST uses precise words. "SHALL" is a requirement. "SHOULD" is a strong recommendation. "SHALL NOT" is a prohibition. Here is the password section in its own terms, quoted from Section 3.1.1.2 of SP 800-63B-4:

Topic	NIST wording	Strength
Minimum length, password as the only factor	"a minimum of 15 characters in length"	SHALL
Minimum length, password as part of MFA	"a minimum of eight characters in length"	SHALL
Maximum length	"a maximum password length of at least 64 characters"	SHOULD permit
Composition	"SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types)"	SHALL NOT
Periodic change	"SHALL NOT require subscribers to change passwords periodically"	SHALL NOT
Change on compromise	"SHALL force a change if there is evidence that the authenticator has been compromised"	SHALL
Blocklist	"SHALL compare the prospective secret against a blocklist"	SHALL
Hints	"SHALL NOT permit the subscriber to store a hint" accessible to an unauthenticated claimant	SHALL NOT
Security questions	"SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) or security questions"	SHALL NOT
Password managers	"SHALL allow the use of password managers and autofill functionality"	SHALL
Paste	"SHOULD permit claimants to use the 'paste' function"	SHOULD
Truncation	"SHALL verify the entire submitted password (e.g., not truncate it)"	SHALL
Storage	"Passwords SHALL be salted and hashed using a suitable password hashing scheme"	SHALL

Two more requirements matter for your user experience. When a password is rejected by the blocklist, the CSP (credential service provider) "SHALL provide the reason for rejection." Verifiers also "SHALL offer guidance to the subscriber to help the subscriber choose a strong password." (NIST SP 800-63B-4)

On characters, NIST says verifiers "SHOULD accept all printing ASCII" characters, the space character, and Unicode. A passphrase with spaces, or a password in the user's own language, should just work.

The translation for product teams

Here is the same standard turned into shipping decisions.

Old habit	What NIST Rev 4 says	What to ship
Upper, lower, number, symbol	Shall not impose composition rules	Remove the rules and the red checklist
Rotate every 60 to 90 days	Shall not require periodic change	Force a reset only on breach evidence
8-character minimum	15 minimum when the password is the only factor; 8 when part of MFA; should allow at least 64	Encourage passphrases; never cap length low
Security questions and hints	Not allowed	Delete them
Block paste in password fields	Allow password managers	Let autofill and paste work
Strength meter only	Screen against breached and common lists	Check new passwords against breach data in real time

Length figures also covered in Startup Defense's NIST breakdown.

Why the old rules backfired

Complexity rules feel secure to auditors. In practice they produce Summer2026!, followed by a forgotten-password ticket a month later. Rotation produces Summer2026!!. An attacker who stole the first one guesses the second.

The mechanism is simple human behavior. When forced to include a capital, people capitalize the first letter. When forced to add a symbol, they add ! at the end. When forced to rotate, they increment a number. Attackers know this, and their guessing tools encode these patterns first. The rules shrink the space of real passwords while making each one harder to remember.

Length works differently. A four-word passphrase is long, easy to recall, and hard to guess, as long as it is not a famous phrase. Readers who want the math behind that can see my post on why words beat random letters.

The retail data confirms the cost. Baymard Institute's research found 82% of benchmarked e-commerce sites had very complex password requirements. Each of those sites is adding friction at account creation, the moment a new customer is deciding whether to trust you.

A before and after policy

Here is a typical legacy policy, the kind still found in many consumer apps, and a compliant replacement.

Before

• Minimum 8 characters, maximum 16
• At least one uppercase, one lowercase, one number, one special character
• Password expires every 90 days; cannot reuse the last 5
• Three security questions at signup
• Optional password hint
• Paste disabled in the password field "for security"
• Lock the account for 24 hours after 3 failed attempts

After

• Minimum 8 characters when a second factor is required at sign-in; 15 when the password is the only factor
• Maximum of at least 64 characters; all printable characters, spaces, and Unicode accepted
• No composition rules
• No scheduled expiry; forced reset only on evidence of compromise
• New passwords checked against a blocklist of breached, common, and context-specific passwords, with a plain-language reason when one is rejected
• No security questions, no hints
• Paste and password manager autofill work everywhere
• Failed attempts throttled with increasing delays and risk signals, rather than a hard lockout that attackers can trigger on purpose
• Passwords stored salted and hashed with a modern password hashing scheme

The rejection message matters as much as the rule. Compare these:

• Before: "Password does not meet requirements."
• After: "This password has appeared in a data breach, so attackers will try it first. Try a longer phrase, like four unrelated words."

The second one tells the user why and what to do next. It meets NIST's requirement to give a reason, and it teaches a better habit in one line.

Building the blocklist

NIST does not publish a single list. It requires a blocklist that "contains known commonly used, expected, or compromised passwords," and names three kinds of entries. (NIST SP 800-63B-4) In practice that means three layers:

1. Breached passwords. Large corpora of passwords exposed in past breaches. Many identity platforms check these for you at password creation and reset.
2. Dictionary words and common passwords. The usual top lists: 123456, password, keyboard walks.
3. Context-specific words. NIST's examples are "the name of the service, the username, and derivatives thereof." Add product names too. Acme2026 is a terrible password for an Acme customer.

NIST is explicit that the entire password is compared, "not substrings or words that might be contained therein." (NIST SP 800-63B-4) Do not reject correct horse battery staple just because it contains the word horse.

To see how a breach check feels from the user side, try the password breach check on this site.

Re-check at sign-in, not only at creation

Screening at creation protects new passwords. Most of your existing customers set theirs years ago. When a customer signs in with a password that has since appeared in a breach, treat it as evidence of compromise. That is the trigger NIST names for a forced change, and it is also a high-value signal for the risk model in Chapter 2.

Storing passwords properly

The storage rule is short and absolute: salted and hashed with a suitable password hashing scheme. Fast general-purpose hashes are not suitable, because attackers with a stolen database can test guesses against them at enormous speed on ordinary graphics cards. Use a deliberately slow password hashing algorithm. The Hashing Foundation chapter of my enterprise passkeys ebook walks through the choice, and the Hash Lab has a reference for each algorithm.

If you use a hosted identity platform, ask the vendor which scheme they use and how they migrate old hashes. Chapter 9 includes this in the vendor questions.

Common mistakes during the switch

• Removing rotation but leaving the expiry email template live. Users keep getting "your password expires soon" messages from a forgotten scheduler.
• Keeping a strength meter that still rewards symbols. A meter that turns green for P@ssw0rd! contradicts your new policy. Base it on length and blocklist results.
• Low maximum length. A 16 or 20 character cap breaks password manager output and blocks passphrases.
• Forgetting mobile apps. Native fields sometimes disable paste or autofill by default. Test both platforms.
• Not telling support. Agents need a one-line script for "why did you stop making me change my password?" The answer: forced rotation made passwords weaker, and the current federal guideline prohibits it.

The real goal

The best password policy is the one your users rarely touch. Treat every rule in this chapter as harm reduction while you move people to passkeys. Passwords should become a fallback, then an option, then gone.

Chapter 4 explains passkeys for decision makers. Chapter 12's scorecard opens with five password checks drawn from this chapter.

Key takeaways

• NIST SP 800-63B Revision 4, final since July 2025, prohibits composition rules, scheduled rotation, hints, and security questions.
• It requires blocklist screening, support for password managers and autofill, full-length verification, and salted, slow hashing.
• The 15-character minimum applies only when a password is the only factor. With MFA, 8 is the floor.
• Old complexity rules produced predictable passwords and more resets. Length and breach screening do better with less friction.
• Every password rule is harm reduction on the way to passkeys, not the destination.