Password Rotation Calculator

resets per year = users × 365 ÷ interval; cost = resets × (1 − self-service share) × minutes ÷ 60 × hourly cost. Rotation cost scales linearly with the number of users and inversely with the interval, so halving the interval doubles the bill. The only security benefit is bounding how long a silently stolen password stays valid, and because a theft can happen at any point in the cycle, the average remaining validity is half the interval.

It puts a number on both sides of an argument that is usually held on instinct: 90-day rotation for 5000 users costs real money and shortens the exposure window from indefinite to 45 days on average — nothing at all if the attacker uses the credential immediately.

This calculator takes 5 inputs: Rotation interval, Users in scope, Time per assisted reset, Resets handled by self-service, Loaded helpdesk cost. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

SP 800-63B says do not require arbitrary periodic changes, and change a password only on evidence of compromise. The reasoning is behavioural: forced rotation produces predictable increments such as Spring2024 then Summer2024, so it weakens passwords while costing money. Rotation still applies to shared and service credentials.

Continuous breach-list monitoring plus MFA. Both detect or contain the actual compromise, which is what rotation was a blunt proxy for, without any user friction.