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

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; 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: 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 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.

Photo by Hatice Baran · Pexels

← Back to the blog