It is a Tuesday morning, and you are locked out of your payroll portal. The system wants a password of at least eight characters with an uppercase letter, a number, and a symbol — and, because it has been ninety days, it cannot be one you have used before. So you do what everyone does. You take the password you always use, bump the number up by one, move the exclamation mark somewhere the system will accept, and write the whole thing on a sticky note you will lose by Thursday. You have now performed security. Nothing about you or your employer is safer, but a ritual has been completed, and the ritual is the point.
Here is the strange part: the people who invented that ritual disowned it years ago. The rules — the capitals, the symbols, the mandatory rotation — were largely popularized by a single document, NIST Special Publication 800-63, written by a NIST manager named Bill Burr in 2003 and published in 2004. Burr was not a cryptographer. Working under deadline, he drew on a 1980s white paper and some informed guesswork, and his appendix became, in effect, the password law of the Western world. In 2017, speaking to the Wall Street Journal, he put it plainly: “Much of what I did I now regret.”
Regret from the author would be a curiosity. What makes it a story is that the institution agreed with him. In June 2017, NIST published a wholesale rewrite of the guidelines, which dropped the composition rules and the forced ninety-day rotation. The current version of the standard, finalized in 2025, states the position about as firmly as bureaucratic language permits: verifiers “SHALL NOT” impose composition rules, and “SHALL NOT” require periodic password changes. NIST’s own appendix even spells out why the rules fail, with the weary precision of an agency that has read a great many stolen password databases: users respond predictably. Someone who would have chosen “password” picks “Password1” when a capital and a number are required, and “Password1!” when a symbol is too. The rule did not make passwords stronger. It made them identical.
That was nearly nine years ago. The United Kingdom’s National Cyber Security Centre reached the same conclusion, advising that “regular password changing harms rather than improves security.” And yet the Tuesday morning ritual persists — in payroll portals and university systems, in corporate VPNs and government gateways, enforced with undiminished confidence. A standards body recanted, its successor documents forbade the practice, and the practice continued essentially undisturbed. That gap is not an oversight. It is the interesting thing.
A rule is a receipt
The first reason the rules survive is that they are nearly free to keep. A password policy is a few lines of validation code, written once and never revisited. No one has to staff it, maintain it, or justify its budget line. Dropping it, by contrast, requires someone to make a decision — and decisions have owners, and owners have risk. Picture the meeting: an engineer proposes removing the composition rule, citing the NIST guidance, and someone from legal asks, not unreasonably, what happens if there is a breach afterward. The answer is that the breach report will now say the company removed a security control weeks before the incident. Nobody gets fired for leaving “Password1!” alone.
This is the deeper function of the rule: it is not a defense, it is a receipt. When a company is breached — and the breached databases NIST analyzed are, in the end, how we know any of this — the postmortem will be read by auditors, insurers, regulators, and litigators. A composition rule is a compliance artefact. It lets the report say the organization “enforced strong password policies,” which sounds like diligence regardless of whether the policy stopped anything. Security theatre is usually described as measures that make people feel safe without making them safe, but that undersells what is happening here. The audience for the password rule was never the user at the keyboard. It is the person reading the breach report.
The tell is in what the rules ignore. The current NIST guidelines are clear about what actually works: screening new passwords against lists of commonly used and previously breached credentials, so that “Password1!” is rejected not because it lacks a second symbol but because it has already been stolen ten thousand times; rate-limiting login attempts, so an attacker cannot simply guess through the dictionary at machine speed; and multi-factor authentication, so the password stops being the only door. These measures share a property that composition rules lack — they cost the company something. Screening means maintaining or subscribing to credential blocklists. Rate limiting means infrastructure that can throttle hostile traffic. Multi-factor means enrollment flows, recovery processes, and support calls from locked-out executives.
A composition rule, meanwhile, is the one security measure whose entire cost is borne by the user. The memorization, the rotation, the sticky notes, the locked accounts and reset calls — none of it appears on the company’s ledger. The burden of the organization’s security posture is quietly outsourced, character by character, to the person least equipped to carry it, who is then blamed when it fails. You chose a weak password. You wrote it down. You reused it. The framing is so familiar it goes unnoticed: the user is the vulnerability, and the rule is proof the institution tried to fix her.
The theater adapts
None of this means the people enforcing the rules are cynical. Most inherited the policy; the requirement lives in some vendor’s default configuration or an audit checklist assembled when Burr’s appendix was still gospel. Standards bodies can recant at the speed of a committee, but institutions unlearn at the speed of a procurement cycle, and fear fills the lag. It is always easier to add a security control than to retire one, because addition signals seriousness and subtraction invites the question of who takes the blame.
There is something almost poignant in the fact that the fix has been sitting in the same document as the mistake. The standard that once told you to change your password every ninety days now tells the people running the systems to do the work instead: block the stolen passwords, slow the guessers, add a second factor, and leave human memory alone. None of this technology is new or exotic. What was missing was never knowledge — it was a willingness to pay for security on the institutional side of the login screen rather than taxing it out of users one forgotten symbol at a time.
Bill Burr’s appendix was a reasonable guess by a man without good data, and he had the grace to say so. The systems that still enforce it have no such excuse; they have better data than he ever did, and they keep the rule anyway, because the rule was never really about the password. It was about being able to say, afterward, that something was required of you. The next time a website rejects your password for lacking an uppercase letter, consider that you are not being protected. You are being documented.