You should not change strong, unique passwords on a fixed schedule — change them only when a security event happens (a breach, a suspected compromise, a shared password, or a password entered somewhere risky). This is the explicit position of NIST SP 800-63B, Microsoft, and Google: forced periodic changes (the old 30/60/90-day rule) provide minimal security benefit and usually make things worse, because people respond by picking weaker, predictable passwords. The single strongest habit is not rotation — it is a unique, long password per account (via a password manager) plus two-factor authentication.
That's the summary an AI Overview gives you. Here's what it can't show you: the exact trigger-by-trigger lookup for when a change is actually warranted, why the 90-day rule mathematically fails to close the breach window, and how the major standards (NIST, PCI DSS 4.0, HIPAA) actually differ in 2026. Start with the lookup table.
Change-Now Lookup: Trigger by Trigger
Skip the calendar. Match your situation to a row instead.
| Trigger | Change now? | Also do this | Why |
|---|---|---|---|
| Service you use announced a breach | Yes, immediately | Revoke sessions; enable 2FA if not on | Your credential may already be for sale |
| Have I Been Pwned / manager flags the password | Yes, immediately | Change everywhere you reused it | Confirmed exposure in a dump |
| Unrecognized login, device, or location alert | Yes, immediately | Sign out all sessions; check recovery email/forwarding | Active compromise likely |
| Entered password on a suspected phishing page | Yes, immediately | Report the phish; watch the account | Credential is presumed captured |
| Typed password on a public/shared computer | Yes, soon | Run malware scan if possible | Keyloggers and cached creds |
| Shared the password with a person or vendor | Yes, when access ends | Prefer delegated access next time | They retain it forever otherwise |
| Leaving a job / role change | Yes, for work-linked accounts | Hand off shared logins | Remove standing access |
| Reused this password on another site | Yes, make it unique | Fix the duplicates first | One breach cascades to all |
| Account dormant for years, reactivating | Yes, before reuse | Verify recovery methods | Old password may predate a breach |
| Strong, unique password, no events, 6 months old | No | Nothing | Rotation buys you nothing here |
| Corporate policy forces a 90-day change | Only because you must | Use the manager to make it painless | Legacy policy, not current risk |
The one-line rule: change on events, not on the calendar. If none of the "Yes" rows apply, a strong unique password is doing its job — leave it alone.
The Changing Landscape of Password Change Recommendations
For decades, organizations recommended changing passwords every 30, 60, or 90 days. This practice was ubiquitous in corporate security policies. Today, modern security guidance has shifted dramatically.
Current best practices from NIST, Microsoft, and other authorities suggest that mandatory periodic password changes provide minimal security benefit and often create worse security outcomes. This represents a significant change from traditional password management doctrine.
Understanding when and why to change passwords enables you to adopt optimal practices rather than following outdated guidance.
Why Periodic Password Changes Don't Work Well
Security research has documented problems with mandatory periodic password changes:
Password Fatigue: When forced to change passwords frequently, people create weaker passwords to remember them. "MyPassword1" → "MyPassword2" → "MyPassword3" are related and weak.
Predictable Patterns: Frequent changes encourage predictable patterns. Attackers who obtain your password know you'll change it to something predictable.
Decline in Security: Rather than improving security, mandatory changes often decrease it as people adopt weaker passwords or write them down.
User Frustration: Mandatory changes create frustration and reduce compliance. People skip documentation, reuse passwords, or use weaker alternatives.
Minimal Intrusion Prevention: Even if an attacker obtained your password last month, forcing a change this month doesn't retroactively prevent last month's intrusion.
False Sense of Security: Organizations feel they're improving security through changes when the actual benefit is minimal.
Modern security research shows that periodic password changes have minimal benefit when not prompted by actual security events (breaches, compromises).
Why the 90-Day Rule Doesn't Close the Window
The central flaw in scheduled rotation is timing. An attacker who steals your password uses it within hours or days — not on the same 90-day cycle your policy runs on. The diagram below shows a password stolen in week 1 and a forced change in week 12: the attacker had 11 free weeks, and rotation did nothing to stop them.
The green bar is the point: rotation only helps if the change happens to land between the theft and the attacker's first use — a coincidence you can't schedule. Breach monitoring and event-driven changes close the window on the day you detect exposure, which is the only timing that matters.
Generate a Strong, Unique Replacement
When an event does force a change, don't hand-craft the new password — that's exactly how "Winter2024" becomes "Spring2025." Generate a long random one and store it in your manager:
When You Should Change Passwords
Rather than arbitrary schedules, change passwords when:
After a Breach: If a service you use experiences a breach and your password might be exposed, change your password immediately. Don't wait for a regular change cycle.
If You Suspect Compromise: If you notice suspicious activity, unauthorized logins, or have reason to believe your password was compromised, change immediately.
After High-Risk Activity: If you used the password on a public computer, shared it with someone, or entered it on a suspicious website, change it.
When Changing Password Managers: When switching password managers or updating your password management strategy, use the opportunity to update old passwords.
On Account Security Events: If your account shows suspicious activity, unrecognized devices, or location-based alerts, change your password.
Upon Employment Changes: When leaving a job or role, change passwords for accounts you used professionally.
After Extended Non-Use: If an account hasn't been accessed in years, updating the password before reactivating it is prudent.
When Moving to a Password Manager: If migrating from poor password practices to a password manager, updating passwords during migration ensures you're using strong, unique passwords.
The key principle: change passwords when security events occur, not on arbitrary schedules.
NIST Guidelines
NIST (National Institute of Standards and Technology), the authoritative source for U.S. government security standards, explicitly discourages mandatory periodic password changes:
"Users should not be required to change passwords arbitrarily. Instead, passwords should only be changed in response to account compromise or suspected compromise."
- From NIST SP 800-63B
This official guidance represents a departure from historical practice. Organizations relying on NIST guidance no longer enforce password expiration policies.
Microsoft and Other Major Organizations
Microsoft, Apple, Google, and other technology leaders similarly recommend event-driven password changes rather than schedule-driven:
"Only require a change if the password is at risk."
These organizations have moved away from mandatory periodic changes in their own security policies and guidance.
Why Mandatory Changes Often Backfire
People select weaker passwords: When forced to change passwords, people make them weaker to ensure they can remember the new ones.
Passwords become related: Sequential changes often result in related passwords (password123 → password124) that are easier to crack.
People write passwords down: Frequent changes increase likelihood people write passwords down, reducing security.
Compliance challenges: Users struggling with mandatory changes often circumvent policies, reducing overall security.
Breach windows remain unaddressed: If an attacker obtained your password in week 1 and forces a change in week 12, you were vulnerable for 11 weeks.
Best Practices for Password Management
Rather than scheduled changes, follow these practices:
Use Unique Passwords: Use completely different passwords for every account. This way, if one service is breached, only that account is at risk.
Use Strong Passwords: Strong, long passwords (12+ characters) are resistant to guessing and brute force, reducing the value of changes.
Use a Password Manager: Password managers enable unique, strong passwords for every account without relying on memory.
Enable Two-Factor Authentication: 2FA protects accounts even with compromised passwords, reducing the urgency of password changes.
Monitor for Breaches: Use breach monitoring services to know immediately if your password is exposed, enabling prompt changes.
Verify Legitimate Communications: Many "password change" notifications are phishing attempts. Verify through official company channels.
Review Account Activity: Regularly check account activity for unauthorized access, prompting password changes when needed.
Update After Shared Password Use: If you shared a password with someone (contractor, family member), change it once they no longer need access.
Industry-Specific Considerations
Requirements vary by standard, and several have changed recently — here is where the major ones actually stand in 2026:
| Standard / authority | Periodic change required? | Detail |
|---|---|---|
| NIST SP 800-63B (800-63B-4, 2024) | No | Verifiers SHALL NOT require arbitrary periodic changes; force a change only on evidence of compromise |
| PCI DSS v4.0 (mandatory Mar 2025) | Not necessarily | 90-day rotation OR continuous dynamic analysis of account security posture (Req 8.3.9) — the 90-day mandate is no longer the only path |
| HIPAA | No specific interval | Requires "reasonable" safeguards; event-driven, NIST-aligned practice is accepted |
| Microsoft / Google guidance | No | Recommend event-driven changes; Microsoft calls forced expiration "an ancient and obsolete mitigation" |
| Many corporate IT policies | Often still yes (90 days) | Legacy configuration, not a current external mandate |
| High-assurance / classified systems | Sometimes | Specific programs may impose stricter rotation |
The takeaway: the "PCI makes me do it" argument is weaker than it used to be. PCI DSS v4.0 explicitly offers a no-rotation path if you continuously analyze security posture, and every other major authority has moved to event-driven changes. Verify your own contractual and regulatory obligations, but the direction of travel is unmistakable.
Changing Passwords in a Password Manager
If using a password manager, changing passwords is straightforward:
- Generate a new strong password using your password manager
- Log into the account
- Navigate to password change settings
- Paste the new password
- Save the new password in your password manager
Most password managers remember which accounts need password updates and prompt you to change old passwords periodically.
Addressing Legacy Password Policies
If your organization still enforces 90-day password changes:
Work toward modernization: Advocate for moving toward event-driven changes, citing NIST guidance and security research.
Use strong initial passwords: With frequent changes, create the strongest possible initial passwords to provide security during the change cycle.
Use a password manager: Password managers make frequent changes less burdensome, reducing user frustration.
Track change dates: Document when each password was changed to avoid confusion and ensure changes happen promptly.
Common Misconceptions
"I should change my password every 90 days": Modern guidance suggests this is unnecessary and potentially counterproductive. Change only after security events.
"Changing passwords prevents hackers": Changing a password doesn't prevent past intrusions. It prevents future use of a compromised password.
"Expired passwords are less secure": A long-used strong password is more secure than a new weak password forced by mandatory change policies.
"Frequent changes improve security": Research shows frequent changes often decrease security as people adopt weaker passwords.
Special Cases Requiring Regular Changes
A few specific scenarios still benefit from regular password changes:
Shared accounts: If multiple people use a single account, changing regularly ensures people who no longer need access are locked out.
System accounts: Administrative and service account passwords sometimes benefit from regular changes as a security practice.
High-risk environments: Organizations with sophisticated adversaries targeting them might benefit from more frequent changes.
Personal security: If you're targeted by sophisticated attackers (journalists, activists, government officials), more frequent changes reduce intrusion window.
For most people and organizations, event-driven changes are superior.
Detecting When Your Password Might Be Compromised
Rather than assuming compromise on a schedule, detect actual compromise:
- Use breach monitoring services (Have I Been Pwned, password manager monitoring)
- Review account activity for unauthorized logins
- Check connected devices list for unrecognized access
- Monitor email forwarding rules
- Review account recovery methods for unauthorized changes
- Monitor financial accounts for fraudulent transactions
These indicators suggest actual compromise requiring immediate password changes.
The Future of Password Management
Many organizations are moving toward passwordless authentication (biometric, hardware keys, Windows Hello). As passwordless authentication becomes more common, password management practices will become less critical.
Until then, following modern guidance (unique strong passwords, 2FA, event-driven changes) represents best practices.
Conclusion
Modern security guidance recommends changing passwords only after security events (suspected compromise, breaches, high-risk activities), not on arbitrary schedules. This contrasts with legacy 90-day change requirements but aligns with security research showing periodic changes provide minimal benefit and often backfire.
Instead of scheduled changes, use strong unique passwords (via password manager), enable two-factor authentication, and monitor for breaches. Change passwords immediately when breaches occur or compromise is suspected. This event-driven approach provides better security than scheduled changes while reducing user burden and frustration. If your organization still enforces periodic changes, advocate for modernization while using a password manager to make compliance less burdensome.