The Great Password Myth: Why Forced Rotation Made Things Worse

For about twenty years, the 90-day password change was one of the least controversial things in enterprise IT. It appeared in every hardening guide, every audit checklist, every onboarding deck. Nobody had to defend it, because nobody attacked it.

Then, over the course of a few years in the mid-2010s, the security community quietly concluded it had been counterproductive. Not merely useless — actively harmful in a measurable way. NIST revised its guidance. The UK's NCSC published a piece arguing rotation caused more problems than it solved. Microsoft dropped the expiration setting from its Windows security baselines and described it as a low-value control.

It's tempting to read that as a story about a dumb policy finally dying. It isn't. The policy was a reasonable response to the constraints of its era, and understanding which constraints made it reasonable is the useful part — because that's the reasoning you'll need the next time a control outlives its assumptions.

Why it made sense when it was written

Put yourself in a 2003 enterprise. Here is what you did not have.

You did not have decent password storage. Windows environments were still carrying LM hashes, which upcased the password, truncated it to fourteen characters, split it into two seven-character halves, and hashed each half independently without a salt. That is not a fourteen-character password; it's two seven-character passwords in a trench coat, and it was tractable to precomputation. Elsewhere, unsalted MD5 and SHA-1 were normal in application databases. An attacker with a copy of your hash table was doing arithmetic, not cryptanalysis.

You did not have breach detection. No EDR worth the name, no centralized log aggregation, no behavioral analytics. If someone exfiltrated your SAM database or your user table, the realistic expectation was that you would never find out. Studies through the 2010s still put median attacker dwell time in the hundreds of days; in 2003 the honest number was "unknown, and probably worse."

You did not have breach-corpus checking. There was no way to ask whether a specific password had appeared in a public dump, because there were no large public dumps and no infrastructure for querying them privately.

Given those three facts, forced rotation is a defensible hedge. The threat model is: an attacker has a copy of your hashes, is cracking them offline at their leisure, and you will never know. Under that model, the only variable you control is how long a cracked credential stays useful. Expiring passwords every 90 days imposes a deadline on an attacker you cannot see. It's a time-bound on undetectable compromise, which is exactly the kind of control you reach for when you have no detection at all.

That is not stupid. That is people making a sensible trade with the instruments available. The mistake wasn't adopting it in 2003; it was that the assumptions changed and the control didn't.

What users actually did

The policy assumed a new password each cycle. What it got was a transformation of the old one.

This is the empirical heart of the case against rotation, and it's stronger than the intuition suggests. Researchers at UNC Chapel Hill obtained a set of historical password hashes for real university accounts spanning multiple forced changes — a rare dataset, because it contained sequences per user rather than one password per user. They built a transformation model: capitalization shifts, character substitutions, appended or incremented digits, keyboard-adjacent movement. Given one of a user's old passwords, a meaningful fraction of the successors fell within a few guesses. In the offline case, where the attacker can grind, the numbers were bad enough that the authors explicitly questioned whether expiration was worth its cost.

The generalization: a rotated password derived from its predecessor contributes far less new entropy than the policy's arithmetic assumes. The policy models each cycle as an independent draw. It isn't. It's a short walk from the previous point.

That last row is the general principle. A control that imposes recurring friction without visible benefit doesn't produce diligence; it produces the cheapest behavior that clears the check.

The second-order costs

The direct entropy argument is only part of it. Rotation also produced costs that landed somewhere other than the security team's ledger.

Helpdesk volume. Password resets are perennially among the highest-frequency ticket categories in enterprise support, and forced expiration is a substantial driver — particularly for people returning from leave. Each of those calls is a human being verifying identity over a phone line under time pressure, which is to say: each one is a social-engineering opportunity you manufactured on a schedule. Several high-profile intrusions in recent years began at exactly that desk.

Written-down and reused credentials. Remembering one strong password is achievable. Remembering fifteen, each mutating quarterly on a different calendar, is not. People resolve the impossibility by writing them down or by collapsing them onto one root string, which converts an isolated breach into a lateral movement kit.

And the subtle one: rotation trains the reflex phishing depends on. A policy of mandatory periodic change normalizes an unexpected message telling you your password must be changed now, along with a link. You spend years conditioning your users to comply with exactly that stimulus, then run awareness training telling them to be suspicious of it.

What changed

Four things, roughly in order of importance.

Storage got good. Slow, salted, memory-hard hashing — bcrypt, scrypt, Argon2 — changed the offline-cracking economics that rotation was hedging against. I've written about the mechanics elsewhere; the relevant point here is that the "attacker is slowly grinding your hashes" scenario is no longer a near-certainty on a predictable timeline.

Breach-corpus checking became possible. You can now ask a far better question than "is this password 90 days old?" You can ask "has this exact password appeared in a known breach?" One is a proxy so weak it's nearly noise; the other is direct evidence about the specific credential. This is the single biggest upgrade in the whole picture, and it's the reason the calendar became indefensible: a better signal exists.

Detection improved. Impossible-travel checks, device fingerprinting, session anomaly scoring. Not perfect, but the premise that compromise is inherently invisible no longer holds by default.

MFA became normal. A single stolen factor stopped being sufficient in most environments.

The guidance moved to match. NIST's SP 800-63B revision in 2017 advised against arbitrary periodic expiration for memorized secrets, pairing that with a requirement to check candidate passwords against known-compromised lists and to force a change when there's evidence of compromise. Subsequent revisions sharpened the direction rather than reversing it. NCSC and Microsoft arrived independently at the same conclusion. I'd encourage reading the current text yourself rather than trusting anyone's paraphrase of the exact modal verbs — the framing has shifted across drafts, but the direction has been consistent for the better part of a decade.

When rotation is still correct

The argument is against the calendar, not against rotation. There are cases where changing a password immediately is the only defensible action.

On known or suspected compromise. Non-negotiable, and it should be fast and scriptable — for one account or for the whole directory. Many organizations that abolished expiration never built the capability to force a mass reset, which is the wrong half of the change to implement.

On a breach-corpus match. If a password shows up in a dump, its age is irrelevant. Check at set-time and re-check periodically against the current corpus, because a password that was clean when chosen may not stay clean.

On shared and service credentials. Where you can't attribute use to an individual, you've lost the property that makes evidence-based rotation work. A shared account has no meaningful owner to alert and no behavioral baseline. Periodic rotation is a legitimate compensating control here — though the better move is usually to eliminate the shared credential rather than to rotate it forever.

On offboarding-adjacent shared accounts. Someone leaves; every shared secret they knew is now outside your boundary. Individual accounts get disabled. Shared ones have to be rotated, and this is where most organizations leak.

On credential type or scope change. Migrating hash algorithms, changing a key's privilege scope, moving a secret between trust boundaries — rotate at the transition.

The unifying principle is that every one of these is triggered by an event. Something happened. The rotation is a response to information.

What to do instead

Length over composition. Composition rules shrink the practical search space by making passwords predictable — everyone puts the capital first and the digit-then-punctuation last, and cracking rules encode that. Set a real minimum length, allow long passphrases, and stop the character-class theater.

Check against breach corpora at set-time, using a private lookup so you aren't shipping candidate passwords anywhere. Re-check periodically.

MFA, weighted toward phishing-resistant factors where you can get them.

Anomaly detection with an actual response path. A signal nobody acts on is a log line.

Allow paste. This is genuinely underrated. Blocking paste in a password field breaks password managers, which are the single most effective tool for getting users onto long, unique, per-site credentials. A control introduced to frustrate automated attacks ends up frustrating only the defenders' best tool.

The honest counterargument

None of this may help you, because your auditor doesn't read research.

Plenty of frameworks, customer security questionnaires, and cyber-insurance forms still specify periodic rotation, sometimes with a hard number. PCI DSS carried a 90-day requirement for years and only relatively recently opened a path to dynamic analysis of account posture as an alternative. Your customer's vendor questionnaire may have been written by someone copying a checklist from 2011. The auditor enforces the framework, not the literature.

So the realistic position for most engineers is not "stop rotating." It's:

1. Find out whether the requirement is actually binding, or whether it's an internal policy that ossified and nobody has reread. This is more often the case than people expect.
2. Where the framework allows compensating controls, document them properly — breach-corpus checking, MFA coverage, anomaly detection with response times — and map each explicitly to the risk the rotation clause was addressing. Auditors respond to a mapped argument far better than to a citation of NIST.
3. Where it's genuinely mandatory, lengthen the interval to the maximum permitted, drop composition rules (rarely mandated as tightly as rotation), and build the event-driven rotation capability anyway. You want the ability to force a reset in minutes far more than you want a quarterly one.

Losing this argument to an auditor isn't a defeat, provided you've built the controls that actually work alongside the one you're required to keep.

The line worth keeping

Forced rotation was a reasonable answer to a real problem: undetectable compromise of badly-stored credentials in an environment with no telemetry. That problem largely got solved by other means, and the control stayed on, drawing a fixed cost from every employee every quarter in exchange for entropy that users had already optimized away.

The lesson generalizes past passwords. Controls encode assumptions about the environment. When the environment changes, the assumptions expire silently — and the control keeps running, because nothing about a control announces that its premise is gone.

Rotate on evidence, not on a calendar.