Making strong secrets · 5 min read

Should you change passwords regularly?

Changing a password on a timer rarely stops an attacker and tends to produce predictable passwords. NIST now forbids scheduled changes but requires a change when there is evidence of compromise.

Many workplaces once required a new password every 30, 60 or 90 days. The idea was intuitive: if a password leaks, a change will eventually lock the attacker out. Current guidance says this rarely works and often makes things worse. The case rests on how attacks actually unfold and on what people do when forced to change.

What NIST says now

SP 800-63B-4 (2025) is direct:

“Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.”

Its usability section restates it: “Do not require that passwords be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.” The earlier 2017 revision, SP 800-63B, was the first edition of NIST’s guidelines to drop scheduled changes; the 2025 version keeps that position.

So the rule has two halves: no timer, but a mandatory change when there’s reason to think the password is known to someone else.

Why a timer doesn’t help much

Think about the ways a password gets into the wrong hands and how fast each is used.

• Phishing, malware, or a password reused on a breached site. The attacker has the actual password. They can use it in minutes. A change scheduled weeks away comes far too late, and if the attacker set up persistent access in the meantime, changing the password may not remove it.
• A stolen database of hashes. The attacker has to crack the hash first. Here, rotation can matter only if cracking takes longer than the rotation period, and the numbers below show that is the rare middle case.
• Online guessing. Rate limits and lockouts are the defense. Rotation doesn’t change the odds of any single guess.

Worked example: a 90-day rotation against offline cracking

Suppose a service’s hash database leaks and the attacker starts guessing at once. Using this site’s illustrative attack rates:

8 random lowercase letters, slow hash. 26^8 = 208,827,064,576 possibilities. At 10,000 guesses per second the full search takes 20.9 million seconds, about 242 days. If the next scheduled change falls 90 days after the leak, the chance the attacker found it first is 90 ÷ 242 ≈ 37%. (If the leak happens later in the cycle, the window is shorter and the chance lower.) So even in the case rotation is meant for, it can leave better than one-in-three odds of the attacker getting there first.

The same password, fast hash. At 10^11 guesses per second the full search takes about 2.1 seconds. Rotation is irrelevant.

8 random printable characters, slow hash. 94^8 possibilities take about 7.06 million days for a full search, so the chance of a hit within 90 days is about 0.0013%. Rotation adds almost nothing because the password was strong enough already.

The pattern holds generally. A password weak enough to crack quickly falls well before the change; one strong enough to resist cracking doesn’t need the change. Only a narrow band in between benefits, and the better fix for that band is a longer password from the start. Sixteen random printable characters (104.87 bits) would take, on average, around 5.9 × 10^19 years at the slow-hash rate.

Why a timer often makes things worse

Ask people to invent a new password every quarter and they need a way to remember each one. The easiest way is a small, systematic change to the last: Harbor2024! becomes Harbor2025!, or Spring1 becomes Summer1. NIST’s Appendix A describes the general effect of extra requirements: they “significantly increase user frustration,” and “users often work around these restrictions counterproductively.”

An attacker who has one old password from an earlier breach can try those transformations first. Incrementing a trailing number or changing a season is a handful of guesses, not millions. The new password protects only against attackers who never saw the old one.

Forced changes also lead to writing passwords on notes near the computer, reusing a rotated password elsewhere, and cycling between two passwords when the system only remembers the previous one.

When a change is the right move

NIST requires the service to force a change when there is “evidence that the authenticator has been compromised.” From the user’s side, the same logic applies. Situations where a change makes sense include:

• the service reports a breach that included passwords or password hashes;
• the password appears in a public breach collection (checking this without revealing the password is explained in checking breached passwords with k-anonymity);
• the password was typed into a page that turned out to be fake (phishing and passwords);
• the password was used on another site that was breached, since attackers try leaked pairs elsewhere (credential stuffing);
• it was shared with someone who should no longer have it.

When changing for one of these reasons, the new password should be unrelated to the old. A fresh random password from the password generator or a new random passphrase avoids the “increment the number” trap entirely.

What does the work instead

Guidance has moved the effort from rotation to measures that address the actual attacks:

Note: Some organizations still require scheduled changes, often because of older policies or audit checklists. If yours does, the most useful habit within that rule is making each new password unrelated to the last, which a generator does automatically.

For the full picture of how passwords leak in the first place, see how breaches expose passwords.

General explanation, not advice for a particular situation. Updated 2026-10-31.