Your Password Policy Is Probably Against NIST Guidance

Every company has one. The security page that says: "Your password must be changed every 90 days, and it must contain at least one uppercase letter, one lowercase letter, one number, and one special character." I've written that policy. You've probably written it too. And according to the current NIST guidance, both of us got it backwards.

Here's the uncomfortable part: the National Institute of Standards and Technology — the same body whose recommendations your compliance checklist is based on — explicitly tells you not to do the two things that make up most of that policy. If your policy reads like the paragraph above, it is, almost by the book, contrary to the guidance.

What NIST actually says

The relevant standard is NIST SP 800-63B — the Digital Identity Guidelines volume on authentication, currently Revision 4 (final version published July 2025, superseding the 2017 edition). Read the two clauses that everyone skips:

"Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

That's the sentence that kills "must contain uppercase, lowercase, number, and symbol." Forcing a blend of character types is explicitly prohibited.

And the second one, about the ever-popular forced rotation:

"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."

No more forced 90-day rotation "just because." A change is only mandated when there's actual evidence of compromise — the opposite direction from what most policies assume.

So the policy that most organizations run on — "change it often, and make it a complex word soup" — runs directly into both of those SHALL NOTs. If you rolled out that policy, you're not ahead of the guidance. You're behind it.

And those two aren't the only clauses that get ignored. The same standard also tells verifiers to allow passwords up to at least 64 characters, to use known-breach lists as a screen, to avoid password-hint and security-question gates, and to let users type long passphrases with spaces instead of forcing short dense ones. If your registration form truncates at 16 characters or bans the space character, you're fighting the guidance on the page itself.

Why forcing complexity actually makes it worse

The reason NIST drops the rules isn't that they're lazy — it's that the rules have a predictable, measurable downside: they make passwords easier to guess, not harder.

Here's the reality of human behavior under a complexity mandate. A user picks a base word and then hacks it into compliance: Password1!, then Password2! next quarter, Password3! the quarter after. The complexity requirement gives them a script, and the rotation requirement gives them a rhythm. An attacker who knows the policy (and everyone reads the same password-policy email) can build a wordlist that walks exactly that progression. Forced complexity + forced rotation is essentially a password generation algorithm — and it's the same algorithm for the whole company.

Compare that to the alternative NIST points at: length. A long passphrase like correct-horse-battery-staple is, from the attacker's perspective, an enormous search space — far bigger than a short jumble of P@ss1 even if that short jumble "has everything." Length multiplies the difficulty. Composition rules add little or nothing on top of it.

Here's a concrete way to feel the difference. P@ssw0rd has the uppercase, the symbol, the number — it checks every box the old policy asks for. But the attacker's wordlist and a "add a digit, swap some letters" rule set find it almost instantly. Then take purple-falcon-runs-north-at-dusk: a mouthful, not a single word, and finding it forces the attacker to search a far larger space — with none of the "complexity" the old rules demanded. Same intention, opposite outcomes, all because one is short and guessable and the other is long.

What you should do instead

If the guidance is "stop forcing rotation and stop mandating character soup," what does a good policy actually look like? A practical version, aligned with SP 800-63B:

1. Length is the priority. The current guidance sets a minimum of 15 characters for passwords used as a single factor (8 is only acceptable when a second factor is always required), and suggests allowing at least 64. Longer passphrases shouldn't just be permitted — encourage them.
2. Drop the composition mandate. Don't require uppercase-lowercase-number-symbol. Let a longer passphrase be the acceptable form.
3. Check against a breach database. This isn't optional nice-to-have advice — the standard requires verifiers to screen every new password against a list of commonly used, expected, or compromised values.
4. Use MFA. A strong second factor doesn't just help when the password leaks; it weakens the value of the password itself, which is why it deserves to be the centerpiece instead of a footnote.
5. Keep a rotation for the right reason. Don't rotate on a schedule. Rotate when there's evidence of compromise — that's exactly what NIST says.

The short version of the mental flip: you can't make passwords strong by making them annoying; you make them strong by making them long and checking them against what's already known.

A tool for the long-and-random part

Once you drop the composition rule, your new constraint is "make it long and unpredictable." That's a job a machine does better than a human. I built a password generator that produces long, mixed passphrases or random strings and tells you the estimated strength — handy when you actually need a throwaway or a service credential and want it long rather than clever.

For a fuller walkthrough of the NIST argument, why composition is weaker, and a worked policy you can hand your security team, I've put the whole thing in my password security guide.

The next time someone drafts a security email that says "change it every 90 days, and make it a word soup," you can do them a favor and point them at the actual standard. You're not weakening the policy — you're removing the rules that were making it easier to guess in the first place.