Your email password is the key to every account you own, because every password reset flows through your inbox. I run AliasFleet, an email-alias service: one forwarding address per site, so a leaked password at one site never doubles as your inbox key. And here is the belief this piece argues: the calendar reminder is the security ritual that makes you less secure.
The three-month rule is still everywhere
Ask the internet how often to change your email password and the answer from 2009 still wins. One Gmail guide, published in 2024, says it plainly: "Every 3-6 months is a good practice." A credit union's security centre says some experts recommend every three months, then immediately hedges that others say a strong password only needs changing if compromised. Computerworld was telling readers in 2009, on a professor's authority, to rotate roughly every one to three months.
It sounds like diligence, which is why it survives. Nobody asked whether the diligence did anything. The full Gmail how-to with the 3-6-month rule is here, quoted in its own words.
Why the calendar makes weaker passwords
When you know the change is coming in 90 days, you do not invent a strong random password four times a year. You build one you can mutate. Summer2024 becomes Summer2025. The exclamation mark moves to January, a different one takes over in April. The pattern is easy for you to continue, which is exactly what makes it easy for an attacker to guess. The policy is not violated. It is obeyed in the cheapest possible way, and the cheapest way is the predictable way.
NIST put the whole position in one sentence, in SP 800-63B, section 5.1.1.2: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator." The official text is here. No calendar. A reason.
Then there is the failure mode nobody plans for: a schedule that forces new complex passwords teaches people to write them down, save them in notes files, or reuse one password across sites with small variations. Each of those is worse than the threat rotation was meant to stop: the rare case of a password stolen silently and used months later. The old rule traded that rare threat for weak, reused, written-down passwords everywhere. It lost.
Microsoft called the policy ancient and obsolete
In April 2019 Microsoft dropped periodic password expiration from the draft security baselines for Windows 10 version 1903 and Windows Server 1903. The old baseline had recommended expiry every 60 days (and before that, 90); the Windows default was 42. All of it went. Principal consultant Aaron Margosis wrote: "Periodic password expiration is an ancient and obsolete mitigation of very low value." Then the line that ends the argument: "If a password is never stolen, there's no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem." BetaNews covered the announcement here.
Microsoft's case was the human one. People forced to change passwords "just predictably alter their passwords when they are compelled to regularly change them", Redmondmag reported. The company pointed at better alternatives instead: banned-password lists and multi-factor authentication. Organisations were even getting "dinged in an audit" for dropping expiration while running stronger protections, which shows how deep the old rule had sunk. CISA agrees: a 2025 U.S. Naval Institute article quoting its guidance notes that CISA recommends organisations discourage frequent forced rotation because it pushes users toward weak, repetitive patterns, and emphasises multi-factor authentication.
| The old advice | Who still publishes it | What the current guidance says |
|---|---|---|
| Change your password every 3 to 6 months | Gmail guides, 2024 | Change it on evidence of compromise, per NIST SP 800-63B section 5.1.1.2 (linked above) |
| Force password expiry every 60 to 90 days | Old Microsoft baselines, many corporate policies | Microsoft removed expiry from its baselines in April 2019 |
| Rotate every 1 to 3 months "just in case" | Advice columns from the 2000s | CISA: discourage frequent forced rotation; use MFA instead |
Put the effort where it actually works
Drop the calendar and spend the energy on the things that decide whether your email account survives an attack.
First, make the email password unique to email. Google's own Password Checkup flags passwords that are compromised, weak, or reused, and says it plainly: "We recommend that you change any compromised passwords as soon as you can." On reuse: "We strongly recommend you use a unique password for every account." The Password Checkup page is here. Forty distinct passwords is not a memory task. A password manager is the way to admit that.
Second, add the second factor, and pick the strong kind. App-based authenticator codes beat SMS codes. Passkeys beat both: they are FIDO credentials for passwordless sign-in, phishing-resistant by design with no shared secrets, and there is nothing for a fake login page to steal. Where your provider offers a passkey, take it.
Third, watch the breach data instead of the calendar. Have I Been Pwned lists every known breach that named your address, and its notifications email you the moment your address shows up in a new one. My walkthrough of reading an HIBP result is here. The notification is the new calendar reminder, and it fires for a reason.
Fourth, shrink what a single breach can take. This is the AliasFleet angle, and it sits here rather than in the closing. If you use one email alias per site, forwarding to your real inbox, then a site's breach exposes that site's alias and nothing else. The password at risk is the one you used there, your inbox address was never in the dump, and an arriving alias names its source before you open the mail, as the leak-tracing guide explains. The whole setup takes a couple of minutes, covered in the set-up guide. Aliases do not replace a unique password or 2FA. They contain the blast radius when the password side fails.
Change your password for three reasons, never for the calendar
1. A breach named your account. If Have I Been Pwned lists a breach that included your email, and especially if passwords were in the dump, change the password on the breached service first, then on every other service where you reused it. Attackers feed leaked pairs into credential-stuffing software that tries them site by site. The reuse half is the one people skip. It is the half attackers count on. The breach-response order of operations walks through this in sequence.
What if the breach was years ago?
Change it anyway if the password is still in use anywhere. Old dumps circulate for years. A breach from 2021 with a password you reused in 2026 is a 2026 problem. The date on the breach does not retire the password.
2. You see something suspicious. A sign-in from a device you do not recognise, a reset email you did not request, mail in Sent you did not send, recovery details changed. Google will prompt you directly if it believes your Google Account password "might be unsafe". Treat any of these as evidence of compromise and move immediately: change the password, review sessions and recovery info, then switch on 2FA if it was off.
3. You reused it somewhere that got breached. This is the sneaky one. Your email password might be fine, but if the same password went into a forum, a shop, or an app whose database later leaked, your inbox is exposed too. Attackers try the pair on your inbox first, because your inbox is the highest-value target on the list. One password per site is the fix. A password manager is how you keep it.
Every password reset for your other accounts flows through your inbox. If your email password leaks and you reused it elsewhere, attackers own the reset path to everything. Change it the moment any account sharing it is breached, and never share it again.
Retire the calendar reminder. Change your email password on breach, on suspicion, or on reuse. Spend the freed effort on a unique password, app-based 2FA or a passkey, and one alias per site. The whole policy fits in one sentence. The old one needed a schedule to hide that it never worked.
Top comments (0)