Every Active Directory environment I have inherited in the last several years had a 90-day password expiration policy set by default. Sometimes 60 days. Occasionally 45, paired with complexity rules requiring uppercase letters, numbers, and symbols. The admins who built those environments were following the advice of their time: rotate credentials often, force complexity, reduce your attack surface.
The problem is that advice was wrong. And the evidence saying so has been public for nearly a decade.
What NIST Actually Says
NIST (the National Institute of Standards and Technology) published Special Publication 800-63B in 2017 and has refined it since. The relevant section is unambiguous. Verifiers should not require users to change memorized secrets arbitrarily, for example on a fixed periodic schedule. The exception is when there is actual evidence of compromise. Not every quarter. Not every 90 days. Only when you have reason to believe the credential has been exposed.
That same guidance advises against complexity requirements that specify exactly which character types must appear and in what positions. Not because complexity is bad, but because those specific rules produce predictable outputs. They train people to game the system in ways attackers already anticipate.
The guidance is at pages.nist.gov/800-63-3/sp800-63b.html. It is not a buried footnote. Microsoft removed periodic password expiration from their Windows security baseline a few years after NIST published 800-63B, citing the same reasoning. The UK National Cyber Security Centre published guidance consistent with this position as well.
The evidence is settled. The policy change has been slow.
The Psychology of Forced Rotation
When someone is told their password expires in 14 days, they do not sit down and generate a strong, randomly constructed credential. They take what they already have and increment it.
Summer2024! becomes Fall2024!, which becomes Winter2025!, which becomes Spring2025!. The underlying pattern is a dictionary word plus a season plus a year plus a single special character. This is not a strong password. It is a formula, and automated credential stuffing tools are built to probe common formulas first because so many organizations train their users to produce exactly this pattern.
Complexity requirements reinforce this behavior rather than correcting it. "You need an uppercase letter, a number, and a special character" reliably produces passwords with a capital at the start, a digit somewhere in the middle, and an exclamation mark or number sign at the end. Password1! has never stopped a breach. It has made IT help desks busy.
The rotation policy is not teaching users to create strong credentials. It is teaching them to create credentials that satisfy the validator while changing as little as possible.
The Case for Rotation, Stated Fairly
Before arguing against something, I want to state the other side properly. The strongest argument for mandatory rotation is this: if a credential is compromised and neither the user nor the IT team knows it, periodic rotation limits the window of that exposure. An attacker who harvested a password in January can only use it until the March forced reset. That is a real and non-trivial benefit, particularly in environments without breach detection or robust monitoring.
The compliance argument is also real. PCI DSS, HIPAA, and a number of sector-specific frameworks have historically referenced password change intervals in their requirements. If you are in a regulated environment and your auditor expects to see a 90-day policy configured, removing it opens a conversation that takes time and documentation to resolve. That overhead is a legitimate cost.
Both arguments are genuine. Neither, in my view, outweighs the tradeoff when you look at what the research on credential compromise actually shows and what measures have demonstrated results.
What Actually Reduces Account Compromise Risk
The security measures that consistently appear in post-breach analysis as what-would-have-stopped-this are not calendar-based password rotation. They are:
- MFA on every account that matters. Microsoft's own Entra ID telemetry consistently shows that MFA blocks the overwhelming majority of automated account takeover attempts even when the underlying password is known. A rotated password without MFA is far weaker than an unchanged password with it.
- Long passphrases over short complex passwords. Length adds entropy faster than complexity does. Three unrelated words strung together (something like PurpleBucketSandwich) carry more entropy than a complex 8-character string with substitutions. NIST recommends allowing passphrases up to 64 characters rather than capping length at 12.
- A password manager for every employee. People cannot reliably memorize unique credentials for 20 or 30 systems, so they reuse them. A password manager removes that tradeoff. Bitwarden has a free tier and an enterprise plan that costs a fraction of a single breach's remediation costs.
- Breach monitoring and credential exposure alerting. Tools like Microsoft Entra ID Protection and similar services can flag when credentials appear in known breach datasets. This lets you act on actual evidence of exposure rather than a fixed schedule.
- Privileged account hygiene. Admin accounts should be separate from daily-use accounts, used only for administrative tasks, and protected with hardware MFA where the risk justifies the cost. Most of the breaches I have read post-mortems on had admin credential theft as either the entry point or the lateral movement mechanism.
None of these five things depend on 90-day rotation. Each of them has more evidence behind it as a genuine risk reduction measure.
What I Do When I Inherit the Policy
When I take over an environment running a quarterly password expiration policy, my first step is not to disable it immediately. My first step is to audit who is actually compliant with it. More often than not, a mandatory rotation policy that nobody follows closely produces post-it notes with passwords on monitors and a surge in help desk tickets every 90 days. A policy that generates that outcome is not providing security; it is providing paperwork.
From there, MFA goes on first. Email, VPN, admin consoles, and the identity provider login are the priority, roughly in that order. Once MFA coverage reaches a meaningful threshold across accounts, the argument for rotation weakens considerably because a compromised password alone no longer grants access.
If I have leadership buy-in to revise the password policy, I shift it toward longer minimum lengths (14 characters or more), remove arbitrary rotation, and replace it with breach-exposure monitoring so we act on evidence rather than a calendar. If I cannot get that buy-in yet, extending the window to 365 days and layering MFA on top gives most of the practical benefit while leaving the policy in place on paper.
The Compliance Conversation
For organizations under PCI DSS 4.0 or HIPAA: yes, there are still requirements to navigate. PCI DSS 4.0, released in 2022 and in full effect since 2024, actually gave organizations more flexibility here than previous versions. When MFA is in place on all access to cardholder data environments, the periodic password change requirement is satisfied through alternative means. That is not a loophole; it is an explicit provision.
NIST 800-63B is increasingly cited as an acceptable compensating framework when organizations can demonstrate MFA coverage and breach monitoring. Your compliance officer and your QSA need to be part of this conversation, not just your IT team. The argument is easier to make when it is grounded in published federal guidance and you can show the compensating controls in place.
If you are running a 90-day rotation policy purely because no one has ever proposed changing it, and not because a specific compliance requirement mandates it in your environment, you may be adding friction for no measurable security gain.
The Part Where I Invite Pushback
This is an opinion, and I hold it with some confidence, but I also know that security environments vary enormously. If you are running a rotation policy for a specific reason I have not addressed here, or if you have found it genuinely effective in a way the literature does not predict, I want to hear it. The most useful counterarguments I encounter come from people managing regulated environments where the auditor's expectations and the published NIST guidance have not yet aligned in practice.
Drop a message through the contact form below. I read all of them.
Sources
- NIST Special Publication 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management
- NCSC (UK): Password administration for system owners, guidance on forced regular resets
Questions about your own password policy or identity setup? Get in touch.
Comments