# How often should you change your password? Only when there's a reason

> The answer almost nobody gives is that you should never change it on a schedule. You change it when something happens. Here is what counts as «something», and what to do the rest of the time, which is most of the time.

2026-09-02 · David Carrero · password.es
Original: https://password.es/en/blog/how-often-should-you-change-your-password/

---

Let's start at the end, because the answer is short and hardly anyone gives it in
full: **when there's a reason. Not every ninety days.**

The habit of rotating by the calendar is so deeply ingrained that it feels like
hygiene, like brushing your teeth. But it was a recommendation with an expiry
date, and it expired: the US NIST wrote it in 2003, withdrew it in 2017, and the
author of that document apologised in public the same year. We tell that story in
full in [what a password is](/en/blog/what-is-a-password/); what matters here is
the part almost nobody explains: **what you should do, today, with your
passwords.**

## A calendar doesn't know whether anything was stolen

The trouble with rotating on a date is that the date carries no information.

If somebody got hold of your password on a Tuesday in February, changing it on
1 April because it's due hands them six weeks of free access. And if nobody has
touched it, changing it protected you from nothing: you've swapped a good
password for one that is probably worse, because passwords written under duress
are written carelessly.

That is the whole mechanism of the failure. **Forced rotation doesn't produce new
passwords, it produces variations.** `Summer2026!` becomes `Autumn2026!` and then
`Winter2026!`, and your attacker knows it, because that series is as predictable
as the wall calendar it came from. The system is satisfied — the password "has
changed" — and real security has gone down, not up.

That's why NIST, in **SP 800-63B**, says both halves together: no arbitrary
changes on a timer, and **force a change the moment there is evidence of
compromise**. It isn't that changing doesn't matter. It's that the trigger has to
be a fact, not a date.

## The reasons that do count

Here's the list. If any of these happens, the password gets changed today, not
next month:

- **It turned up in a breach.** Of that service, or of any other where you used
  the same one.
- **You reused it.** If `X` leaked and it's also on four other sites, that's five
  passwords to change, not one.
- **You typed it into a site that turned out not to be the site.** A rushed
  email, a link, a form that looked right. It doesn't matter that you noticed two
  seconds later: you'd already sent it.
- **You shared it.** With your partner, a colleague, in a work chat, on a bit of
  paper. A password that has passed through a channel where you don't control who
  reads is no longer yours.
- **You see odd activity.** A sign-in from somewhere you've never been, reset
  emails you didn't ask for, a message sent that you didn't write.
- **The device was compromised.** A computer with malware, a lost phone, a laptop
  that went through a repair shop you don't know.
- **The service warns you.** When a company sends that email, act on it the same
  day. It is literally the case SP 800-63B has in mind.
- **A living arrangement ended.** An ex-partner, a flatshare, a business partner.
  Accounts that used to be two people and are now one.

Notice what they all have in common: **they are all events**. None of them is
"ninety days have passed".

For the first one there's a tool. If you want to know whether a specific password
is on the lists already in circulation, and how long it would hold up, run it
through the [checker](/en/checker/): it's analysed in your browser and never
leaves it.

## When there is a reason, the order matters

Changing the password is the obvious step, and often it isn't the first one. This
is the order that saves you doing the work twice:

**First, the device.** If you suspect something is installed reading what you
type, changing your password from that same machine amounts to handing over the
new one. Clean it, or use a different device first.

**Then, your email.** Your email account isn't just another account: it's the one
that receives the "forgot my password" links for all the others. Whoever controls
the email controls the rest through the front door. If there is one password to
start with, it's that one.

**Next, end the open sessions.** Changing the password doesn't always evict
whoever is already inside. Look in the account settings for the option to sign
out of all devices and use it — otherwise the intruder stays connected on a
session that no longer needs your password at all.

**And last, check what they left behind.** This is the step most people skip.
Someone who gets into an account doesn't just look: they change the recovery
email, add a phone number, turn on a second factor of their own, connect an app,
add a forwarding rule to the mailbox. **If you change the password and don't
check that, they walk back in tomorrow through a door that's still open.** Go
through recovery methods, authorised devices, connected apps and forwarding
rules.

One more thing, obvious and therefore the most ignored: when you change it, the
new one has to be **new**. Not the usual one with a different number. Generate it
in the [generator](/en/) and store it somewhere that doesn't depend on your
memory.

## What you do the other three hundred and sixty days

If the trigger is an event, and events are rare, the question becomes a different
one: so there's nothing to do? On the contrary. What rotation was trying to solve
badly is solved properly by four things, and all of them are one-offs.

**Make them long.** SP 800-63B puts length ahead of contortion: a long password
beats a short one stuffed with symbols. That's where most of the work is.

**Make them different on every site.** This is the one that turns somebody else's
breach into a small incident instead of a fire. If every account has its own,
one leaking doesn't touch the rest; if you share a password, some service you
don't even remember using gets to decide how safe your bank is.

**Have them checked against breach lists.** That's the exact swap NIST made:
instead of demanding a symbol, check that your password isn't already in
circulation. That check really does expire — a password that isn't on the lists
today may be on them next year — which is why good managers repeat it on their
own and tell you.

**Turn on a second factor wherever you can.** With a second factor in place, a
stolen password stops being a key and becomes half a key.

Together, those four do something rotation never did: **they change the password
exactly when there's a reason, because you find out that there is one.** A
manager watching the lists is a warning system; a calendar warns you of nothing,
it just passes.

## And if your employer forces it every ninety days

It happens, a lot, because there are policies written fifteen years ago that
nobody has looked at since. Two things.

First, practically: if you have to change it, **change it properly**. Generate a
whole new one and put it in the manager. The seasonal variation is the only thing
worse than not changing it, because it gives you the feeling of having done
something.

Second, for anyone in a position to move the policy: you don't have to invent the
argument. It's in **SP 800-63B**, it's NIST's official guidance, and it says in
so many words that periodic password changes should not be required, and that a
change should be forced when there is evidence of compromise. Anyone keeping the
ninety-day rule today is following a document the very body that published it
replaced years ago.

## The short answer, once more

How often should you change your password? **When something happens.**

And because "when something happens" only works if you find out that it has, the
long answer is: make every password long, unique and monitored, so that on the
day one needs changing you'll know, it'll be one password, and it'll take you two
minutes.

Everything else is ticking a box on a calendar to feel safe.

---

*Sources: NIST SP 800-63, "Electronic Authentication Guideline" (2003), where the
composition rules and periodic change appear · NIST SP 800-63B, "Digital Identity
Guidelines: Authentication and Lifecycle Management" (2017): length over
complexity, no arbitrary periodic change, forced change on evidence of
compromise, and checking against lists of compromised passwords · statements by
Bill Burr, author of the 2003 guideline, to the Wall Street Journal in August
2017.*