Every other post on this site that mentions password rotation states the same conclusion: NIST recommends against it, forced rotation produces predictable successors, don't do it. All true — but stated as a verdict, never argued as a debate. Nothing here has actually made the case for rotation before knocking it down, and the honest answer to "good or bad" has a real exception the verdict-only version skips entirely. This is the debate, both sides, plus the exception.
The case for rotation, made honestly
Scheduled rotation has one genuine property that "rotate only on evidence of compromise" doesn't: it's a hedge against compromise you don't know about. If an attacker has quietly had a valid credential for months — no alert, no detected anomaly, nothing that would ever trigger an evidence-of-compromise response — scheduled rotation eventually locks them out anyway, on a fixed timeline, without ever needing to detect anything. That's not nothing. In 2003, when the original NIST guidance was written, there was no practical, scalable way to check a password against a corpus of known-compromised credentials — rotation was one of the few tools available at all for bounding an undetected exposure window. It's also easy to audit: "did every account rotate on schedule" is a clean yes/no compliance check, which is exactly why it survived so long in frameworks built around checklist audits.
Why it falls apart for a human-memorized password
The hedge above only works if each rotation actually produces an independent, unpredictable new secret — otherwise you're not closing the exposure window, you're giving an attacker who already has one password in the sequence a significant head start on the next one. What Makes a Strong Password Policy? covers the research behind this in detail — people told to change a password they already know make the smallest edit that satisfies the requirement, not a genuinely fresh choice. The theoretical model behind "rotation bounds the exposure window" assumes independence that real human behavior doesn't provide, while the cost — help-desk password-reset load, people writing the new one down, reusing a password from a different rotation cycle — is real and measured.
The reversal isn't "the goal was wrong." Bounding the exposure window of a compromised credential is still exactly the right goal — it's that breach-checking (comparing every new password against a corpus of known-compromised values, now genuinely practical at scale via services like Have I Been Pwned's Pwned Passwords) achieves the same goal without the predictable-successor cost. NIST didn't abandon the problem scheduled rotation was trying to solve; it replaced the tool. See NIST Password Guidelines Explained for exactly where that requirement sits in the standard's own language.
Where rotation still genuinely makes sense
The research above is specifically about secrets a human has to think up and remember. That scope matters — it's the actual dividing line, not "rotation" as a blanket concept:
- Machine-generated credentials — API keys, database service-account passwords, SSH keys, cloud IAM access keys. Nobody memorizes these, so "rotate it" means regenerating a new random value with a CSPRNG, not asking a person to think of a fresh one. None of the predictable-successor problem applies, because there's no human pattern to exploit in the first place. AWS explicitly recommends regular IAM access key rotation and provides tooling for it, for exactly this reason — a rotated access key is just as random as the one it replaced.
- Certificates. TLS certificate lifetimes have been repeatedly shortened industry-wide over the past decade specifically to force more frequent rotation — a policy that makes sense for machine-verified cryptographic material in a way it never did for human memorized secrets, since a certificate's "new value" is generated by a key pair, not typed by a person under deadline pressure.
- Shared or non-attributable accounts. A shared admin login or a service account with no per-user login trail makes "detect who was compromised and reset just theirs" impossible by construction — scheduled rotation is one of the few remaining tools when individual attribution isn't available at all.
- Confirmed or suspected compromise — universally agreed, human or machine credential either way. See Password Hash Migration Strategies for forced reset specifically, and What Makes a Strong Password Policy? for handling a compliance framework that still mandates scheduled rotation regardless.
The actual dividing line
Not "rotation, good or bad" as a single blanket rule — the question that actually decides it is whether the new value gets generated or remembered. A machine-generated secret rotates cleanly, on a schedule, with no downside, because there's no human pattern for an attacker to exploit between one value and the next. A human-memorized one degrades under the same schedule, because the person choosing it is the predictable part — which is exactly why NIST's reversal applies specifically to memorized secrets, and was never a claim that rotation is universally the wrong idea.
FAQ
So is 90-day rotation always wrong for user passwords?
As a blanket, unconditional policy — yes, per current NIST guidance. As a response to actual evidence of compromise, rotation (immediate, not on a 90-day schedule) is still exactly the right call.
Does this apply to MFA/TOTP secrets too?
The same generated-vs-remembered logic applies: a TOTP seed is machine-generated and never typed by a human during normal use, so rotating it on suspicion of compromise carries none of the predictable-successor problem — the same reasoning that applies to API keys and certificates.
What should I actually tell a compliance team that still requires periodic rotation?
That the requirement, where it's contractually or legally binding, still has to be satisfied — but nothing about satisfying it prevents also adopting breach-checking, MFA, and the rest of current guidance on top of it. What Makes a Strong Password Policy? covers this specific situation in more depth.
Try it yourself
Password Policy Generator and Password Policy Validator check a policy's rotation setting (and everything else) against current NIST guidance from either direction — settings in, or free text in. Both run entirely in your browser.