Password Policy: What NIST Actually Recommends

Ask most organisations about their password policy and you will hear the same familiar rules: at least one uppercase letter, one number, one symbol, changed every ninety days. Those requirements were reasonable guesses decades ago. Current guidance from NIST recommends against several of them, because evidence showed they push users toward predictable behaviour.

What changed and why

The reasoning behind the older rules was intuitive: force variety and frequent change, and passwords become harder to guess. In practice users optimise for compliance rather than security.

Complexity requirements produce recognisable patterns — a capital at the start, a number and an exclamation mark at the end. Forced rotation produces incremental variations, so a compromised password reveals the next one. Both rules also increase reliance on reuse and on writing passwords down, which is why guidance moved away from them.

What current guidance recommends

• Favour length over composition. Set a reasonable minimum and permit long passphrases, including spaces and any printable characters.
• Do not impose composition rules. Requiring specific character classes has not been shown to improve outcomes and predictably degrades usability.
• Do not force periodic rotation without cause. Change credentials when there is evidence of compromise, not on an arbitrary schedule.
• Screen against known-compromised passwords. Checking new passwords against breach corpora is one of the highest-value controls available, because it blocks exactly what credential-stuffing attacks use.
• Allow paste and password managers. Blocking paste actively discourages the strongest practical user behaviour.
• Avoid knowledge-based recovery questions. The answers are frequently discoverable or guessable.
• Rate-limit and monitor authentication attempts rather than relying on password rules alone.

Why breach screening matters most

Credential stuffing does not guess passwords — it replays credentials already exposed in other breaches. Against that attack, complexity rules are irrelevant: a password can satisfy every composition requirement and still appear in a public corpus.

Screening new and changed passwords against known-compromised lists directly addresses the actual attack. It is a modest engineering effort with a disproportionate effect, and it can be done without transmitting the password itself using well-established range-query techniques.

Updating a policy in practice

1. Remove composition requirements and raise the minimum length, permitting long passphrases.
2. Remove scheduled expiry, keeping forced change for confirmed or suspected compromise.
3. Introduce screening against known-breached passwords at set and reset time.
4. Explicitly permit and encourage password managers, and stop blocking paste.
5. Replace security questions with stronger recovery paths.
6. Ensure MFA is in place, since it does more for account security than any password rule.
7. Document the change and explain the reasoning — users who understand why a rule changed are far more likely to follow it.

The compliance conversation

A frequent objection is that an auditor or framework demands ninety-day rotation. That is worth checking rather than assuming, because several major frameworks have modernised their guidance and now accept alternative controls.

Where an obligation genuinely persists, comply with it — but document the compensating controls you have added. Being able to show breach screening, MFA and monitoring alongside the required rule is a stronger position than either the old rule or the new approach alone.

Related from TechBiz Security

• Security awareness training
• Compliance consulting
• Security audits

Sources & further reading

• NIST SP 800-63B — Digital Identity Guidelines, Authentication
• NIST — Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• CISA — Require Strong Passwords

Frequently asked questions