Mandatory periodic changes can reduce overall security
Aliases: event-triggered password reset · password expiration · compromise-driven change
What it is
Risk-triggered password change ties replacement to evidence of compromise, anomalous takeover, or credential recovery instead of expiring every account on a fixed calendar. Time-based expiry without a risk signal adds memory and support costs and encourages predictable edits such as incrementing a digit or changing a season, without necessarily reducing an attacker's usable window.
Why it happens
Forced change interrupts work without supplying a new memory strategy, so people preserve the old secret through minimal edits or compensate by recording and reusing it. Security benefit is also overstated when the service changes only the login string while stolen sessions, app passwords, or recovery tokens remain valid. Risk-triggering concentrates disruption where evidence exists and treats the full authentication state, not a calendar checkbox.
Studying it
Compare periodic and event-triggered policies longitudinally using privacy-preserving derived measures of reset completion, support demand, lockout, manager adoption, and predictable mutation. In a controlled takeover exercise, plant known sessions and tokens and test whether detection, notification, reset, and revocation jointly stop access. A count of password changes is not evidence of security; report exposure window, recovery success, and false-trigger cost separately.
Where it stops holding
Require change when a password is known to be breached, phished, cracked, or implicated by credible takeover evidence. Administrator initialization, departure from a shared secret, or high-risk recovery may also justify a one-time reset. External expiry mandates can apply, but the design should still reduce predictable mutation and address other sessions. Removing arbitrary expiry does not make a password permanently trustworthy or replace monitoring, MFA, and secure recovery.
Applying it
- Define triggers such as breach matches, anomalous access, completed recovery, and human investigation, and retain the basis for each trigger.
- Rotate the password, revoke relevant sessions and tokens, inspect recovery channels, and show the account owner what was done in one response flow.
- Support manager-generated replacements and compare each candidate as a complete value against a list of common, expected, and compromised passwords; after rejection, guide the user away from trivial edits. Any separate similarity rule needs its own threat rationale and false-rejection testing for long passphrases.
- Monitor false positives, incomplete resets, support burden, and post-response access; enable fixed expiry only where an applicable external requirement demands it.