Password policy that works

Priya's company runs the classic policy. Passwords need 8 characters, a capital letter, a number and a symbol. They change every 90 days. Accounts lock after 3 wrong tries. People end up with Winter2025!, then Spring2026!, and a sticky note under the keyboard. Your goal: write a password policy that follows NIST and stops real attacks.

The old rules, and what people really did

You already know how a site should store passwords. A password policy is the other half: the rules people follow when they choose one.

• Composition rules ("one capital, one digit, one symbol"). People add them in the same places. They turn password into Password1!. Attackers' guess lists know this.
• Forced expiry every 60 or 90 days. People make a small change: the next season, the next number. In 2019 Microsoft dropped expiry from its Windows security baseline.
• Security questions. The answers are often easy to find. They are a weak back door.
• Blocking paste and capping length. Both break password managers and long passphrases.

What NIST SP 800-63B-4 says

Most organizations follow the NIST digital identity guideline, NIST SP 800-63. Its authentication part, SP 800-63B-4, was finalized in July 2025. The key rules:

• At least 15 characters when the password is the only factor. A password that is only one part of multi-factor sign-in may be as short as 8.
• Allow at least 64 characters.
• No composition rules. No scheduled changes. Force a change only if there is evidence of compromise.
• Check new passwords against a password blocklist of breached passwords, dictionary words and your own company words.
• Welcome password managers. No hints, no security questions.
• Limit failed attempts, with a ceiling of 100 in a row, not 3.

NIST also says plainly that passwords are not phishing-resistant. No policy changes that. So shrink the password's job: use MFA everywhere, and phishing-resistant passkeys where you can. Give service accounts long random secrets that a tool rotates (the Kerberos lesson).

How passwords fall

In password spraying, an attacker tries one or a few very common passwords against many accounts, slowly. No account sees many failures, so no lockout trips. A blocklist stops it, because a common password such as Summer2026! is never allowed in the first place.

In credential stuffing, the attacker replays leaked username and password pairs, betting on reuse. Phishing tricks the user into typing the password into a fake page. Only phishing-resistant sign-in helps (adversary-in-the-middle, passkeys). The bot attacks have their own lesson: credential stuffing, password spraying and bots.

Throttling, not a quick-to-lock lockout

Locking an account after 3 wrong tries cuts both ways. Anyone who knows a username can lock that person out on purpose. That is a cheap denial of service. Every lockout becomes a help-desk reset, and that desk is a target for social engineering. A patient spray never trips the lockout at all.

NIST prefers throttling. Slow attackers down, with waits that grow as failures pile up. Add a bot challenge and risk signals such as an unfamiliar device (adaptive MFA). Add detection across accounts and feed it to your SIEM. The real owner can still sign in.