Why password rotation policies died and auditors still ask

The ritual nobody could explain

Every ninety days, a message used to greet millions of office workers at login: Your password has expired. Please choose a new one. And every ninety days, those workers did the rational thing. They took last quarter's password, Summer2023!, and turned it into Autumn2023!. Or they bumped the trailing number by one. Or they cycled through a small stable of passwords they'd been reusing for years, waiting out the handful of remembered ones the system refused to let them repeat. Security teams knew this was happening. They enforced the rule anyway, because an auditor's checklist told them to, because the last auditor's checklist had told the last security team to, and because somewhere upstream a standard said passwords were supposed to expire. Almost nobody in the chain could say why ninety days, or what threat the ritual actually stopped. It was, for decades, one of the most widely enforced security practices on earth that essentially no evidence supported. That has now formally reversed. In July 2025, the U.S. National Institute of Standards and Technology (NIST) published the final version of its flagship identity standard, SP 800-63 Revision 4, and the language on password expiration is blunt: verifiers "SHALL NOT require subscribers to change passwords periodically." Not should not. Shall not. And yet, if you fill out a cyber-insurance questionnaire this month, or sit through a compliance audit, there's a good chance someone will still ask how often your users rotate their passwords. The practice is dead in the research and dead in the standard. It is very much alive in the paperwork. This is the story of that gap.

Where ninety days came from

The rotation habit was not arbitrary when it was born. It came from the mainframe era, when a small number of users shared an enormous, expensive machine and the operating system stored passwords in a way an attacker might eventually copy and crack offline. The logic was a race: how long would it take an adversary with a captured password file to brute-force a given password? If the answer was, roughly, a few months, then forcing everyone to change every few months meant that by the time an attacker cracked your password, it was already stale. Expiration was a hedge against slow cracking.

That threat model made sense in 1985. It made progressively less sense with every passing decade, and by the 2000s it had quietly detached from reality. The problem is that the assumptions underneath it all changed. Cracking got faster, so the "few months of safety" shrank toward zero. More importantly, the dominant way accounts actually get compromised stopped being slow offline cracking and became phishing, credential reuse, and malware that steals a password and uses it immediately. As Microsoft's security team put it when it later dismantled the policy, periodic expiration is "an ancient and obsolete mitigation of very low value," because when an attacker gets a credential they don't sit on it for ninety days. They log in now. A term worth pausing on: a hash is the scrambled form in which a well-built system stores your password, so that even someone who steals the database sees 5f4dcc3b... rather than password. An offline attack is when the attacker has that stolen hash file and can guess against it on their own hardware, as fast as their machines allow, with no server to slow them down. An online attack is when they must try guesses against the live login page, which can rate-limit them or lock the account. Rotation was designed for the offline case. Most modern breaches begin with something closer to the online case, or skip guessing entirely because the user typed their password into a fake page.

What happened when someone measured it

For years the case against expiration was intuition. Then researchers measured it. In 2010, a team at the University of North Carolina at Chapel Hill, Yinqian Zhang, Fabian Monrose, and Michael Reiter, got hold of a real trove: a set of defunct university accounts spanning a system that had forced password changes every three months. As summarized by the U.S. Federal Trade Commission, the dataset ran to more than 10,000 accounts and over 51,000 passwords, a rare chance to watch how people actually build the next password from the last one. The finding that should have ended the debate: the researchers built an algorithm that, given a user's old password, searched for likely successors, capitalizing a different letter, incrementing a number, swapping a symbol. For 17% of accounts, knowing one previous password let them guess the next one in fewer than five guesses. That is not an offline-cracking number. Five guesses is within reach of an online attacker who has not been locked out. The very policy meant to revoke a stolen password's usefulness was handing attackers a map to the replacement. The UNC study slotted into a wider body of work. Researchers at Carnegie Mellon found that users who were annoyed by password rules chose weaker passwords than users who weren't bothered, meaning the friction of the policy actively degraded the thing it was supposed to protect. A Carleton University analysis concluded that mandatory changes provided, at best, marginal protection against offline guessing, not nearly enough to justify the cost. The pattern across all of it was the same: nearly every constraint you pile onto human beings, forced length, forced symbols, forced changes, gets absorbed into predictable behavior that attackers already model. The rules don't add entropy. They add patterns.

Entropy, here, is just a measure of how unpredictable a secret is, how many guesses an attacker would need on average. A password that looks complicated to a human (P@ssw0rd!) can have very little of it, because the substitutions are exactly the ones everybody makes. A random four-word phrase looks simple and has a great deal of it. That inversion, complexity theater versus actual unpredictability, is the joke at the heart of the famous xkcd "correct horse battery staple" comic, and it is also the thing the research kept confirming.

The man who wrote the rules says sorry

Much of the complexity orthodoxy traced back to a single document: NIST's original Appendix A password guidance, written in 2003 by a NIST manager named Bill Burr. It was Burr's guidance that popularized mixing uppercase, lowercase, numbers, and symbols, and recommending periodic changes. For over a decade it was the template that corporate IT, and the auditors checking corporate IT, treated as gospel. In 2017, Burr told the Wall Street Journal that he regretted much of it. As widely reported, he said the advice was "barking up the wrong tree", the complexity rules were too fiddly for people to follow well, and the forced-rotation recommendation generated enormous busywork while accomplishing little. Part of the reason the 2003 guidance was so thin, he noted, was that there simply wasn't good real-world password data to draw on at the time. By 2017 there was, and it pointed the other way. It's worth being fair to Burr and to the original policy. Given the mainframe threat model and the absence of data, the 2003 advice was defensible for its moment. The failure wasn't writing it. The failure was that it hardened into a compliance requirement and then outlived, by fifteen years, the conditions that justified it.

How the standards turned

Once the evidence was in, the official reversals came in a fairly tight sequence, and it's worth watching who moved and when, because the lag between them is the whole point. The FTC's then Chief Technologist, Lorrie Cranor, published "Time to rethink mandatory password changes" in March 2016, laying out the research for a policy audience and warning companies that "what was reasonable in 2006 may not be reasonable in 2016." NIST moved next. Its 2017 rewrite, SP 800-63B Revision 3, told verifiers they "SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)." In standards language, SHOULD NOT is a strong recommendation you can deviate from with justification. It was permission to stop, not an order to. Microsoft made it concrete for the largest install base on earth. In 2019 it removed the password-expiration setting from the security baseline it ships for Windows, arguing that if a password is never stolen there's no need to expire it, and if you have evidence it was stolen, you should act immediately rather than wait for a scheduled rotation. Microsoft's own password guidance had already recommended banning common and breached passwords, requiring multi-factor authentication, and dropping both mandatory complexity and mandatory expiration.

Then the final SP 800-63 Revision 4 arrived in July 2025, the first full overhaul of the suite since 2017 and the product of a nearly four-year process and some 6,000 public comments. It hardened SHOULD NOT into SHALL NOT. What NIST now asks for instead is a coherent package: a minimum length of at least 8 characters, with at least 15 recommended; support for passwords up to 64 characters and the full range of characters including spaces and emoji; no forced composition rules; and, crucially, screening new passwords against a blocklist of known-breached and common passwords so that Password1 is rejected the moment a user tries it. The one time you must force a change is when there's actual evidence the credential was compromised. Rotation on suspicion, not rotation on the calendar. Layered on top is a push toward authentication that doesn't rely on a memorized secret at all: multi-factor authentication (requiring a second proof, like a code or a tap on your phone) and passkeys (cryptographic credentials stored on your device that can't be phished or reused, since there's no shared secret to steal). Rev 4 explicitly embraces phishing-resistant authenticators and passkeys, the FIDO2 hardware-key lineage among them. The strategic bet is clear: stop asking humans to be random number generators, and move the security into cryptography and risk signals.

So why does the auditor still ask?

Here is the uncomfortable part. Every actor above reversed course, and the person auditing your environment in 2026 may still write a finding if your passwords don't expire. Several distinct forces keep the ghost walking. Not every standard actually turned. The most-cited holdout is the payment-card standard, PCI DSS. Its current version, 4.0, still contains requirement 8.3.9: for accounts protected by a password and nothing else, you must either change that password at least every 90 days or dynamically analyze the account's security posture in real time. PCI did modernize, the 90-day rule now applies only to single-factor accounts, and adding MFA lifts it entirely, but a business reading the standard literally still sees "90 days" on the page. If you take card payments, an auditor pointing at 8.3.9 isn't behind the times. They're citing a live control. Some standards say nothing, and get read as saying the old thing. ISO/IEC 27001:2022, the dominant international security-management standard, is deliberately outcome-based. Its authentication control, Annex A 5.17, prescribes no interval, no length, no complexity formula. It asks that you have a documented, risk-based policy, that people know their obligations, and that you can show the policy actually operating. That means a NIST-aligned "no periodic rotation" policy is fully compliant, an auditor should accept "we follow current NIST guidance" as a defensible answer. But a checklist-minded auditor, or an internal policy template written in 2015 and never revised, can still treat expiration as the presumed default and flag its absence. The standard didn't require rotation. The habit filled the silence. Cyber-insurance questionnaires lag hardest of all. Insurers assess risk with standardized forms, and those forms are updated slowly, copied between carriers, and optimized for easy scoring rather than current science. A yes/no box asking "Do you enforce periodic password changes?" is trivial to grade and hard to dislodge, so it persists on renewal forms long after the practice it encodes was discredited. Answering "no, per NIST" can still cost an applicant points against a rubric nobody has rewritten. And plain inertia does the rest. Policies get cloned. Group Policy templates get inherited. An organization's internal standard cites a framework version from years ago; the auditor tests against the internal standard, not against the latest research; the finding gets written; next year's auditor sees last year's control and preserves it. The mechanism that once propagated the rule downstream from a 2003 NIST appendix is the same mechanism now keeping it alive downstream from documents that have since been rewritten. Standards changed at the top faster than the sediment of templates, checklists, and forms beneath them.

The misconception worth naming

The deepest confusion underneath all of this is the belief that changing a password is itself a security act, that rotation is a form of hygiene, like washing your hands. It isn't. A password change accomplishes exactly one thing: it revokes whatever value a previously captured password had. If the password was never captured, the change protects against nothing and merely spends the user's goodwill, which they recoup by making the next password more predictable. If the password was captured, waiting up to ninety days to rotate it is far too slow, the attacker used it in minutes. Scheduled rotation is the wrong tool in both cases. It's either unnecessary or too late. What actually contains a compromise is the combination NIST now points to: a second factor the attacker doesn't have, so a stolen password alone is useless; screening that keeps known-breached passwords out of the pool in the first place; monitoring that forces a change the moment there's evidence of compromise rather than on a fixed clock; and, increasingly, authenticators with no shared secret to steal at all.

What to watch

The interesting question now isn't whether periodic rotation is defensible. That argument is over, and it lost. The interesting question is how long the paperwork takes to catch up, and what that lag teaches us about how security actually changes. It took NIST from 2017 to 2025 to move from should not to shall not, and it will take an unknown number of years more for the last insurance questionnaire, internal policy template, and audit checklist to stop asking. The evidence updated in 2010. The behavior may not fully update until the 2030s. Watch two things. First, whether PCI DSS drops its single-factor 90-day clause entirely in a future revision, which would remove the last major standard still mandating the practice by name. Second, whether passkeys reach enough of the population that the whole question becomes moot, that we stop arguing about how to manage a secret humans have to remember because there's no such secret left to manage. When the expiration prompt finally disappears for good, it probably won't be because a committee killed it. It'll be because there was nothing left for it to expire.

---

Sources

1. National Institute of Standards and Technology, SP 800-63B: Digital Identity Guidelines, Revision 4 (2025).
2. National Institute of Standards and Technology, NIST SP 800-63-4: Digital Identity Guidelines (publication record, finalized 31 July 2025) (2025).
3. Yinqian Zhang, Fabian Monrose, and Michael K. Reiter, "The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis," ACM CCS (2010).
4. Lorrie Cranor, U.S. Federal Trade Commission, "Time to rethink mandatory password changes" (2016).
5. Lorrie Cranor, "Time to rethink mandatory password changes" (personal blog) (2016).
6. Microsoft, "Password policy recommendations for Microsoft 365" (accessed 2026).
7. Robyn Hicock, Microsoft, Microsoft Password Guidance (2016).
8. Sophos Naked Security, "Why NIST's Bill Burr shouldn't regret his 2003 password advice", reporting on the Wall Street Journal interview with Bill Burr (2017).
9. SecurityMetrics, "Password Updates and Requirements in PCI DSS 4.0" (accessed 2026).
10. ISMS.online, "ISO 27001:2022 Annex A Control 5.17, Authentication Information" (accessed 2026).
11. Randall Munroe, "Password Strength," xkcd #936.