Why the 90-Day Password Rotation Policy Needs to Die

Forcing users to change passwords every quarter feels responsible. In practice it manufactures weaker, more predictable passwords — and the standards bodies have said so for years.

Mandatory password rotation is security theater that actively makes you less safe. It is time we stopped shipping it by default.

Where the rule came from

The 90-day rotation habit dates to an era when password hashes leaked slowly and cracking was expensive. The logic was: if a password is stolen, expiring it limits how long the attacker can use it. Reasonable — in 2004.

What actually happens

Humans are predictable under constraint. Force a change every quarter and people do the minimum the policy allows:

• They increment: Spring2026! becomes Summer2026! becomes Autumn2026!.
• They reuse a base password across sites with a rotating suffix.
• They write the new one on a sticky note because they can no longer remember it.

Forced rotation does not produce strong passwords. It produces Spring2026! becoming Summer2026!.

What the guidance says now

• Only force a reset on evidence of compromise, not on a calendar.
• Screen new passwords against known-breached lists (Have I Been Pwned style).
• Allow long passphrases and paste — help password managers, do not fight them.
• Add phishing-resistant MFA; that is where the real risk reduction lives.

What to do instead

Drop the timer. Check passwords against breach corpora at set time, add a real second factor, and reserve forced resets for the moment you actually detect exposure. You will get stronger credentials and fewer sticky notes — and your support queue will thank you.

Making the switch without a big rollout

You don't need a new auth system to fix this — it's mostly a policy and config change:

• Turn off scheduled expiration in whatever handles auth (your IdP, Cognito/Auth0/Clerk config, or your own login code) and stop nagging users to rotate on a timer.
• Screen new and existing passwords against a breach list. The Have I Been Pwned Pwned Passwords API is free to query and doesn't require sending the plaintext password — it's built around k-anonymity hashing.
• Turn on MFA, prioritizing app-based or hardware options over SMS, which is phishable and SIM-swappable.
• Keep forced resets, but trigger them only on a real signal: a breach-list hit, a suspicious login, or a support ticket reporting compromise.

For a small team, this is usually a config change plus one clear internal email, not a project. If you're not sure whether your current login flow does any of this, that's exactly the kind of thing worth a second pair of eyes — see how I approach security-minded development or get in touch if you want a specific opinion on your setup.