The reference document is NIST Special Publication 800-63B, the United States federal guidelines for digital authentication. It is not a law, but it shapes policy far beyond government, because auditors, compliance frameworks, and corporate IT departments treat it as the baseline. When NIST changed its position on password rotation, it changed the conversation everywhere.
The headline guidance is direct: do not require people to change their passwords on a fixed schedule. Force a change only when there is evidence the password has been compromised. That single sentence undoes a control that has been baked into enterprise policy for decades.
Where the 90-day rule came from
The logic behind periodic rotation was reasonable on paper. If an attacker steals a password and you have not noticed, a forced change eventually locks them out. Shorten the window between changes and you shorten how long a stolen credential stays useful. In an era of slow offline cracking and infrequent breaches, that trade had some merit.
The problem is that the threat model moved and the rule did not. Modern credential theft is not a patient attacker slowly grinding a hash over months. It is credential stuffing from a fresh breach dump, or a phishing page that captures the password and uses it within minutes. A 90-day rotation does nothing against an attacker who logs in the same afternoon they steal the credential. The window the rule was designed to shrink is one most real attacks never use.
How forced rotation backfires
The deeper issue is behavioral. Passwords are remembered by humans, and humans under a recurring deadline optimize for the least painful path. Researchers studying organizations with mandatory expiration found that people do not invent a fresh, strong password every cycle. They transform the old one in predictable ways.
Frequent password changes are likely to do more harm than good, because they make passwords harder to remember and drive users toward weaker choices and predictable patterns. Paraphrasing the FTC's "Time to rethink mandatory password changes," 2016
The patterns are well documented. Spring2026! becomes Summer2026!. Falcon7 becomes Falcon8. A trailing number increments, a season name advances, an exclamation mark migrates. An attacker who has captured one historical password can often guess the current one because the transformation rule is so common. Forced rotation does not just fail to add security against the modern threat, it actively pushes users toward a smaller, more guessable space of passwords and toward writing them down where they can be found.
A control that assumes humans behave like ideal random generators will fail in exactly the ways humans differ from random generators. Rotation assumed each change produced an independent secret. In practice each change produced a small, predictable edit of the last one.
What NIST recommends instead
The replacement guidance shifts effort away from the user's memory and toward the verifier doing useful work. The current recommendations from SP 800-63B, in plain terms:
| Do | Do not |
|---|---|
| Allow long passwords and passphrases (support at least 64 characters) | Cap length at something short like 16 |
| Check new passwords against lists of known-breached and common passwords | Impose composition rules like one-uppercase-one-symbol |
| Change a password only on evidence of compromise | Require a change every 30, 60, or 90 days |
| Accept all printable characters, including spaces and unicode | Use password hints or knowledge-based questions like mother's maiden name |
The replacement for periodic rotation is the breach check. Rather than assuming every password becomes stale on a timer, screen each chosen password against the enormous corpus of passwords already exposed in public breaches. A password that appears in a breach list is compromised regardless of how new it is, and one that does not is not made safer by being changed on schedule. The screening can be done privately, without sending the password anywhere, using k-anonymity range queries that reveal only a short hash prefix.
What this means for you in practice
If you run authentication for an organization, the modern posture is fewer arbitrary rules and more meaningful screening: drop scheduled expiration, drop composition requirements, raise the length ceiling, and add a breach-list check at the point a password is set. Reserve forced resets for accounts you have specific reason to believe are exposed.
As an individual, the same evidence points to a simple stack. Use a password manager so that every account has a unique, high-entropy password you never have to remember or rotate. Use long passphrases for the few secrets you do memorize, like the manager's master password. Turn on phishing-resistant second factors wherever they are offered, because a second factor protects you against the fast credential theft that rotation never addressed. Change a password when there is a reason to, not because a calendar said so.
The lesson generalizes past passwords. Security controls earn their place by measurably reducing risk against the threats people actually face, not by feeling diligent. The 90-day change felt like effort, and effort got mistaken for protection for a very long time. The honest position is to keep the controls that survive contact with how humans really behave, and retire the ones that only ever moved the burden around.