Should organisations still require mandatory password changes every 90 days?

Generally no. Forced password expiration often drives weaker choices, repeated patterns, and more help desk resets without materially improving security for well protected accounts. A better policy is to require strong, unique passwords, monitor for exposure in leaks, and change credentials only when there is evidence of compromise or reuse elsewhere.

Why fixed 90-day password expiry usually underperforms

Mandatory rotation sounds disciplined, but in practice it often optimises for compliance theatre rather than security outcome. If users are forced to change passwords on a schedule, they tend to choose predictable variants, reuse familiar patterns, or store the result insecurely, which can make the next credential easier, not harder, to guess or phish.

For well protected accounts, a routine expiry does little to stop modern attack paths. If an attacker has already captured a password, they often move quickly, and if the account is protected with phishing-resistant authentication or strong detection, the calendar alone is not the control that materially changes risk.

What matters more is whether passwords are unique, whether known-compromised credentials are blocked, and whether the organisation can detect abnormal authentication behaviour. The NIST SP 800-63 Digital Identity Guidelines support this direction by emphasising phishing-resistant authentication and better authenticator management over arbitrary expiry cycles.

When password changes should still be required

A forced change still makes sense when there is evidence of compromise, suspected reuse across services, shared access that cannot yet be eliminated, or a security event that could have exposed credentials. In those cases, the decision is driven by the incident or exposure, not by the passage of time.

This is also where account type matters. Administrative, service, and legacy interactive accounts deserve closer scrutiny than ordinary user accounts because the impact of credential abuse is higher and the likelihood of hidden reuse is often greater. The real question is whether the credential has a plausible path to abuse, not whether it has been 90 days since the last reset.

Modern policy should therefore separate routine password hygiene from event-driven response. Scheduled expiry can still exist for narrow exceptions, but it should not be the primary control for accounts that already have strong authentication, strong monitoring, and rapid compromise response.

What a better password policy should optimise for

A stronger policy focuses on resistance to guessing, reuse, phishing, and exposure rather than forcing calendar-driven churn. That means requiring long, unique passwords, checking against breached-password lists, and using authentication methods that reduce reliance on memorised secrets where possible.

It also means measuring whether the control actually improves security outcomes. If password rotation is causing more resets, more help-desk load, and more predictable password patterns without reducing compromise, the policy is misaligned with the risk. A policy that users can follow consistently is usually stronger than one they routinely work around.

For organisations that need a broader control baseline, the NIST SP 800-53 Rev 5 Security and Privacy Controls provide a useful reference point for access control, identification and authentication, and credential management.

Risk and Threat Considerations

Rigid expiry rules can create a false sense of safety while leaving the real abuse paths untouched. The main risk is that organisations spend effort on scheduled resets but still fail to detect compromise, reuse, phishing, or password stuffing against exposed accounts.

Failure mechanism: Predictable rotation patterns, user frustration, and help-desk workarounds weaken secret quality, while an undetected breach or reused credential can remain active long enough to be exploited before the next forced change.

Impact: Higher support cost, lower user compliance, weaker password choices, and a control that may not reduce the likelihood or blast radius of actual account compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Password expiry and stronger authentication are directly governed by digital identity guidance.
Recommendation — Adopt phishing-resistant authentication and avoid arbitrary password rotation for well-protected accounts.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Credential lifecycle and rotation are central to the question of password change frequency.
	IA-2 — Identification and Authentication (Organizational Users)	The policy concerns user authentication assurance for organisational accounts.
	IA-9 — Identification and Authentication (Service Organizations / NHI)	The policy logic extends to non-human and service credentials that should not rely on routine expiry.
Recommendation — Use IA-5 to manage authenticators based on compromise risk rather than fixed expiry alone. Apply IA-2 to strengthen login assurance with stronger authenticators and account controls. Apply IA-9 where machine or service credentials need stronger lifecycle and compromise-based rotation.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	The subject is about access control and authentication policy effectiveness.
Recommendation — Set authentication policy around least privilege, strong authenticators, and compromise-driven resets.
OWASP ASVS	V6 — Authentication	Password policy, rotation, and authenticator strength are core authentication verification concerns.
Recommendation — Verify authentication controls by testing password policy, breach checks, and reset handling.

Practitioner Guidance

What to prioritise: Treat forced expiry as an exception, not the default. Prioritise unique-password enforcement, breached-password screening, and stronger authentication for any account that can reach sensitive systems or data.

Decision rule: If there is no evidence of compromise or reuse, do not reset credentials just because a timer expired; if there is exposure, reset immediately and investigate whether the same secret is used elsewhere.

What to verify: Confirm that password policy changes are reducing real incidents, not just increasing reset volume. If users are choosing simpler patterns after every expiry, the policy is degrading the control rather than improving it.

Practitioner takeaway: The best password policy is the one that interrupts compromise, not the one that merely forces regular inconvenience.