Rotate passwords when risk changes, not when the calendar says so. The strongest triggers are breach exposure, suspicious authentication activity, role changes that cross privilege boundaries, and offboarding. Those events change the trust state of the credential, while fixed rotation often just creates new patterns that are only slightly different from the old one.
When does a password belong in the rotation queue?
A password should be queued for rotation when its trust state changes, meaning the organisation has new reason to believe it may be known, shared, misused, or too broadly exposed. For IAM teams, that usually means an incident signal, a privilege transition, or an offboarding event. The question is not how old the password is, but whether its assurance is still intact.
The practical test is whether the credential still matches the access it was originally allowed to carry. If the answer is no, the credential has already become a governance problem even before any confirmed abuse. That is why event-driven rotation is usually more defensible than fixed-interval rotation for high-value accounts, service accounts, and shared credentials.
Rotation should also be treated as part of a broader credential lifecycle, not as an isolated reset action. If the same account, secret store, or dependency chain keeps the password reusable across systems, then rotating one value without fixing the wider path only reduces exposure temporarily. The control works best when rotation is paired with inventory, ownership, and revocation discipline.
Which events are strong rotation triggers?
Breached exposure, suspicious authentication activity, role changes across privilege boundaries, and offboarding are the clearest triggers because each one changes the attacker or user trust relationship to the credential. A breach may reveal the secret, anomalous login patterns may indicate compromise, a role change may expand or shrink the intended authority, and offboarding means the credential should no longer be usable by that person or process.
Other strong triggers include evidence of secret sharing, hardcoded credential discovery, environment movement, or any sign that the password has escaped the control plane that is supposed to govern it. When a password is embedded in scripts, copied into chat, reused across systems, or stored outside managed tooling, rotation becomes a containment step as much as a hygiene step.
For teams managing machine and service credentials, the same logic applies when the dependency graph changes. If a password supports an integration that is being retired, replatformed, or permissioned differently, rotation should be considered alongside decommissioning and access revalidation, not after them.
Why calendar rotation often fails in real IAM programmes
Calendar-based rotation sounds disciplined, but it often creates work without reducing actual risk. It can force users and admins into predictable change cycles, encourage small mutations that are easy to infer, and consume operational attention that would be better spent on discovery, privilege reduction, and revocation of stale access. When passwords are changed on a timer rather than because risk changed, teams may be measuring compliance instead of security.
Fixed schedules also break down when the environment is uneven. A low-risk internal account, a privileged admin credential, and an externally exposed integration secret do not have the same urgency or blast radius. Uniform rotation intervals can therefore obscure where the real exposure sits and delay response where it matters most.
That said, time-based rotation can still be useful for exceptional cases such as regulatory requirements, legacy systems with weak monitoring, or credentials that cannot be reliably watched for exposure. In those cases, the schedule is a compensating control, not the primary decision rule.
Risk and Threat Considerations
Password rotation is really a response to exposure, persistence, and misuse risk. If teams rotate too late, an attacker can keep using a stolen or shared password for as long as it remains valid. If teams rotate on a rigid timer, they may miss the real compromise event and leave the most dangerous credentials untouched.
Failure mechanism: The control fails when teams treat expiry dates as a proxy for trust, or when they rotate a password without removing the condition that made it risky, such as leaked storage, broad reuse, or continued privilege.
Impact: Compromised access can persist, credential reuse can widen blast radius, and incident response can become slower because the organisation has no clear event-based trigger for action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding is a primary trigger for password rotation when access should end. |
| NHI-02 — Secret Leakage | Exposure or leakage is a direct trigger for rotating the password. | |
| NHI-07 — Long-Lived Secrets | The question contrasts event-driven rotation with fixed calendar rotation for long-lived credentials. | |
| Recommendation — Rotate and revoke credentials immediately when ownership ends or staff leave. Rotate any password or secret after suspected leakage or exposure. Shorten secret lifetime and rotate on risk events rather than fixed dates. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password rotation is an authenticator lifecycle decision governed by IA-5. |
| AC-2 — Account Management | Role changes and offboarding require account and credential lifecycle action. | |
| IA-2 — Identification and Authentication (Organizational Users) | User password rotation affects organizational user authentication assurance. | |
| Recommendation — Manage authenticator lifetime, renewal, and revocation based on risk and usage. Tie credential rotation to account changes, transfers, and separations. Reissue user authenticators when compromise or role change reduces trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | Rotation decisions are driven by account lifecycle events such as offboarding and role change. |
| Recommendation — Use account lifecycle events to trigger credential reset and access removal. | ||
Practitioner Guidance
What to prioritise: Put rotation rules behind concrete triggers, starting with confirmed exposure, suspicious sign-in signals, privilege boundary changes, and offboarding. Those are the moments when the credential’s risk profile has actually changed.
What to verify: Confirm that the rotation event also updates dependent systems, stored copies, and downstream integrations. A password that changes in the directory but not in scripts, vaults, or third-party connectors is not fully rotated in practice.
Common mistake: Do not let “rotate every 90 days” stand in for credential governance. For valuable accounts, the better question is whether the account is still appropriately owned, scoped, and monitored.
Practitioner takeaway: Rotate passwords when the credential’s trust changes, then use that event to decide whether the real fix is revocation, privilege reduction, or retirement rather than another routine reset.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org