Should organisations still require mandatory password changes every 90 days?

Why 90-Day Password Expiration Usually Fails Practically

Mandatory 90-day changes usually target the wrong problem. Most ordinary users respond by making predictable variations, reusing patterns across systems, or writing passwords down, so the policy adds friction without reliably reducing compromise risk. It also increases help desk load and can push people toward weaker behaviour at exactly the point where consistent password quality matters most.

What makes the policy ineffective is not the idea of changing passwords, but the fact that timing alone is a poor signal for risk. If an account is protected by strong, unique credentials and modern detection, an arbitrary expiry cycle often produces busywork rather than meaningful security improvement. The better question is whether the account has evidence of exposure, reuse, or suspicious access.

That distinction matters because password expiry is only one control among several. If you still depend on passwords, the real security gain comes from preventing reuse, catching exposure early, and making compromise visible quickly. For practical comparison, What to Do After a Data Breach Guide covers the response pattern organisations should care about after credentials may already have been exposed.

When Password Changes Are Worth Requiring

There are still situations where a reset is the right action. If there is evidence of phishing, malware, infostealer activity, password reuse on another site, credential stuffing, or an account takeover attempt, the change is no longer routine maintenance, it is containment. In those cases, forcing a reset is a response to a concrete exposure, not a calendar event.

The same logic applies when password material may have been stored, synced, or reused in ways that increase blast radius. If one password unlocks multiple services, then a single compromise can become multiple compromises, which is exactly why exposure-based resets outperform blanket expiry. The control should follow the risk, not the date.

Operationally, that means the password policy should be paired with leak monitoring, suspicious sign-in detection, and a clear trigger for forced reset. When a reset is required, it should be coupled with session invalidation and review of recent account activity, because changing the password alone does not always remove an attacker who already has an active session or a copied token.

For environments where password exposure is a recurring concern, Infostealer Logs Monitoring and Response Guide is the most relevant internal companion because it focuses on triaging exposed credentials and revoking sessions before misuse continues.

What a Better Password Policy Looks Like

A stronger policy sets long minimum passphrases, blocks common and breached passwords, discourages reuse, and requires change only when risk changes. It should also define how exposure is detected and who can force a reset, so the organisation does not rely on ad hoc judgement when compromise is suspected. In practice, that is a more defensible model than rotating every 90 days for everyone.

The supporting controls matter as much as the password rule itself. MFA reduces the value of a stolen password, while rate limiting, anomaly detection, and alerting on impossible travel or unusual sign-in patterns help catch abuse before it spreads. Where password use remains necessary, the policy should be built around detection and containment, not ritual expiration.

Good policy also distinguishes user populations. High-value administrative accounts, shared accounts, and externally exposed credentials deserve tighter review than low-risk internal accounts, but the answer is still not automatic expiry for its own sake. The control objective is to shorten the time an exposed secret remains useful to an attacker.

If the organisation also manages credentials for devices, routers, or home networks, Securing Your Home Router Guide and Securing Your Wi-Fi Network Guide reinforce the same principle: change default or exposed passwords when the risk changes, not because a date on the calendar arrived.

Practitioner Guidance

What to verify: Confirm whether the account is protected by unique passwords, MFA, and breached-password screening before changing policy. If those controls are weak or absent, a reset schedule will not compensate for the underlying exposure.

Decision rule: If there is no evidence of compromise, reuse, or exposure, do not force a routine 90-day change. If there is evidence of exposure, require reset immediately and invalidate active sessions or related access where possible.

What to measure: Track password reset volume, help desk calls, reuse detections, and exposure-driven resets separately. A rising routine reset rate with no corresponding drop in compromise is a sign that the policy is adding friction rather than security.

Practitioner takeaway: The best password policy is event-driven, not calendar-driven, because security improves when you react to exposure and abuse signals rather than forcing predictable user behaviour on a fixed schedule.

Related resources from NHI Mgmt Group

• Why do privacy laws still require data mapping and assessment even when they do not mandate every control?
• Why do password changes for service accounts require extra care in Active Directory and Windows environments?
• Why do AI-generated malware techniques still create risk even when the code changes on every run?
• How should teams govern AI agent access when downstream systems still require secrets?