In short. Scheduled rotation is no longer recommended — NIST dropped it because forced changes push people toward predictable variations. Change on evidence instead: a breach, a shared credential, a device you no longer control. A strong unique password with no sign of exposure does not need replacing.
Everyone remembers the rule: change your password every 90 days. It entered corporate policy from NIST guidance, survived two decades — and was removed by NIST itself in 2017. The reason is straightforward: scheduled rotation makes passwords worse rather than better. Here is where the rule came from, why it was dropped, and when a password genuinely must be changed.
Where the 90-day rule came from
It was born when password hashes lived on slow systems and a breach meant physical access to a machine or a tape. The logic: if an attacker steals the hashes, cracking takes time, so the password should expire before the cracking finishes.
That arithmetic rested on the hardware of the day. A GPU cluster now tries billions of candidates per second, and a weak password falls in hours rather than months. Ninety days does not save you from cracking: a bad password falls long before the deadline, and a good one does not need it.
What NIST said, and why
In 2017 NIST published SP 800-63B, stating plainly that verifiers SHOULD NOT require memorized secrets to be changed arbitrarily, and should force a change only on evidence of compromise.
The reason is not that changing a password is harmful in itself. It is that people forced to change one every quarter choose predictable passwords — and that harms more than regular rotation helps.
Microsoft followed, dropping the expiry requirement from Windows security baselines in 2019, as did the UK's NCSC and most modern guidance.
What actually happens when people are forced to rotate
Studies of corporate policies found a consistent pattern. Someone required to invent a new password four times a year does not invent four independent passwords. They build a sequence.
| Quarter | What gets typed |
|---|---|
| First | Winter2024! |
| Second | Spring2024! |
| Third | Summer2024! |
| Fourth | Autumn2024! |
Cracking tools apply exactly these transformations: knowing one password in the chain, the next is guessed in one or two attempts. Scheduled rotation here does not create a new secret — it publishes the rule by which the secret is built.
The second effect is worse: a password that must be changed stops being memorised and starts being written down. On a sticky note, in phone notes, in a file on the desktop. A requirement invented to protect the vault moves the password out of the vault.
When a password must be changed
- It appeared in a breach. The one unambiguous reason. Checkable against breach databases in a way that never transmits the password.
- You typed it on someone else's device. A hotel computer, a colleague's laptop, a public terminal — treat it as compromised.
- You gave it to someone. A contractor, a former employee, a family member. Access is revoked by changing it, not by agreement.
- The service reported a breach. Even when the notice says passwords were encrypted: in incident emails that often means hashed with an outdated algorithm.
- You reused it somewhere. Reuse turns someone else's breach into yours.
- The device had malware. A keylogger captures the password as it is typed, and no amount of strength helps.
What about workplace policies that still mandate rotation
If the rule comes from an employer or a regulator, arguing inside the work account is pointless. But rotation can be made harmless: generate each new password at random and keep it in a manager rather than deriving it from the previous one. The requirement then stops being a source of predictability and becomes paperwork.
What helps more than a calendar
- Length. Each added character multiplies the possibilities. Twenty-four random characters will not be cracked by any cluster in any meaningful timeframe.
- Uniqueness. Different passwords per service break the chain that turns one breach into access everywhere.
- A second factor. It protects even when the password is already stolen.
- Breach checking. It answers the real question — not "how many days have passed" but "do attackers already have this password".
Any specific password can be measured for length, composition and dictionary matches in the password generator: it shows entropy, guessing time across four attacker models, and checks against breach databases without sending the password anywhere.
Frequently asked questions
So passwords never need changing?
They do, but on evidence rather than on a calendar. A breach, another person's device, shared access, an incident at the service — those are reasons. "Ninety days have passed" is not.
Why does my bank still require it?
Usually an industry regulation written before 2017 and not revisited since. It is a compliance matter. Your job in that situation is to avoid building the new password from the old one.
How do I find out whether a password leaked?
Through breach databases using k-anonymity: the first five characters of a SHA-1 hash are sent, the password cannot be reconstructed from them, and the match is found on your device.
How often should the manager's master password change?
By the same rule — on suspicion of compromise. It is also changed rarely because it must be remembered: frequent rotation guarantees it ends up written down next to the computer.
In short
- The 90-day rule was withdrawn by NIST itself in 2017: scheduled rotation makes passwords more predictable.
- People rotating on a schedule build chains like Winter2024 → Spring2024, and cracking tools handle exactly that.
- Change on events: a breach, another device, shared access, a service incident, malware.
- If rotation is mandated, generate randomly and store in a manager — never derive the new from the old.
- Length, uniqueness, a second factor and breach checking all beat any calendar.