When should organisations change passwords instead of relying on longer rotation cycles?

Why fixed password rotation is the wrong trigger

Longer rotation cycles are useful only when they are tied to the actual state of the credential, not to an arbitrary calendar. Passwords should be changed when there is credible evidence they may have been exposed, reused, guessed, or harvested, because the security question is whether the secret still has value to an attacker. Calendar-only resets can create churn without improving safety.

What matters is the trigger, not the interval. If a password has not been exposed and the organisation has stronger controls such as phishing-resistant authentication, forced change-on-a-date can do more harm than good by encouraging predictable patterns, reuse, and weak suffix changes. That is why many modern guidance models treat password rotation as an incident response action, not a routine hygiene ritual.

For teams managing large secrets inventories, the broader lesson is the same one seen in The State of Secrets in AppSec: time-to-remediate often matters more than the existence of a nominal policy. When a password is suspected to be exposed, the clock starts at detection, not at the next scheduled reset window.

What should trigger an immediate password change

The most defensible triggers are evidence-based. A password should be changed when there is breach exposure, fraud or anomalous login activity, password manager or breach-monitoring alerts, or any confirmed sign that the credential may already be in an attacker’s hands. The goal is to reset authority before the secret can be replayed elsewhere.

• Confirmed or likely breach exposure involving the account or the system where the password was used.
• Impossible travel, unfamiliar device, or other suspicious authentication signals tied to the account.
• Password manager, breach notification, or monitoring alert showing the password appears in known leaked data.
• Shared-password environments where one compromise can affect multiple accounts or services.
• Any situation where a password was entered into an untrusted site, script, or channel.

That logic is especially important for secret material that behaves like a password, including API keys, tokens, and signing credentials. Rotation should be immediate when the secret has crossed a trust boundary or may have been copied outside the intended control plane. The lifecycle and cryptoperiod logic in NIST SP 800-57 Key Management reinforces that principle for cryptographic material, where exposure and expected lifetime must be managed together.

Practitioner Guidance

What to prioritise: Build password change decisions around detection, not calendar cadence. If a credential is credibly exposed, treat rotation as containment and recovery work, not housekeeping.

What to verify: Confirm whether the account is still active, whether the password is reused anywhere else, and whether the suspicious signal is limited to one system or suggests broader credential compromise. For shared or high-value credentials, verify downstream access paths before changing only the visible password.

Common mistake: Replacing evidence-based rotation with frequent forced resets. That usually shifts risk into user behaviour, weak variants, and poor reuse discipline, while leaving exposed credentials undiscovered for too long.

What good looks like: The organisation changes passwords quickly after a credible trigger, preserves evidence of the event, and pairs the reset with session revocation or access review where needed. The process should be fast enough that the password change actually removes attacker utility.

Practitioner takeaway: Use rotation as a response to compromise signals, not as a substitute for them. The right question is whether the password is still trustworthy, not whether the calendar says it is time to reset it.

Related resources from NHI Mgmt Group

• When should organisations automate credential rotation instead of relying on manual resets?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?