Dropping Forced Password Resets Across a Workforce? Where the Money Actually Goes

The bill for an organization's password policy is almost never a line item anyone approved. It is spread across a help desk queue, a directory team's overtime, a per-seat license somebody renewed without reading, and the hours employees spend locked out of a system they need at eight in the morning. Retiring scheduled expiry looks like a policy edit, a single toggle in a group policy object or an identity provider console. The toggle takes a minute. The work around it, done in the wrong order, costs more than the old policy did.

Find the running cost before you touch anything

Password spending behaves like an energy bill: it is a continuous draw, and nobody notices it until they meter it. The draw here is reset volume. Pull twelve months of ticket data, separate forced-expiry resets from genuine lockouts and forgotten credentials, and attach your loaded cost per contact, whether that is an internal tier-one rate or a contracted per-ticket price. Note the seasonality, because expiry policies cluster resets into predictable waves after holidays and at quarter boundaries. Do this before the policy changes. Once expiry is off, the baseline is gone, and you cannot reconstruct it from memory or from a vendor's generic claim.

The second figure is the employee side, which rarely appears in any system of record. Estimate it honestly: minutes lost per reset, multiplied by volume, multiplied by an average fully loaded hourly rate. It will be a larger number than the help desk cost, and it is the number that makes the project defensible to a finance team that has already heard three security pitches this year. Keep the arithmetic visible and conservative. A payback case built on a plausible estimate you can show survives scrutiny; one built on a vendor's figure does not.

The prerequisites that have to land first

Scheduled expiry was doing something, badly. It limited how long a stolen credential stayed useful. Remove it without replacing that function and you have cut cost by lowering the floor, which is a trade nobody will defend after an incident. The replacement has three parts, and they are sequenced. First, screening every new and changed password against a corpus of known-compromised credentials, so that weak and breached choices are rejected at the moment of setting rather than tolerated for ninety days. Second, multifactor coverage broad enough that a single stolen password is not sufficient on its own. Third, detection that notices credential stuffing and anomalous sign-ins quickly.

The National Institute of Standards and Technology is responsible for the federal digital identity guidelines that most large American employers map their authentication policy to, and the modern shape of that guidance is screening and length rather than composition rules and expiry. The practical consequence for budgeting is that the cheap half of the change (turning expiry off, dropping the character-class requirements) is useless without the expensive half. Screening and multifactor are the cost. Order matters: turn screening on first, in audit mode, so you learn how many existing passwords would fail before you force anyone to change one.

What actually drives the per-seat number

Licensing is the smallest variable and the one that gets all the attention. Identity platforms price multifactor and credential screening by tier, and the jump is usually from a base directory license to a premium identity tier applied to every covered account, including service desk accounts, contractors, and seasonal staff nobody counted. Count the accounts, not the headcount. The second driver is hardware, if you are issuing security keys to privileged users or to roles where phone-based factors are impractical, and the rule there is that you buy two per person, because a single key with no registered backup produces a recovery event that costs more than the spare.

The largest driver is enrollment labor. Every account that moves to a new second factor needs a verified enrollment, and verification is where the money goes, particularly for remote staff, field crews, and anyone whose identity cannot be confirmed by walking them to a desk. Decide early whether enrollment happens at a scheduled event, through a manager-attested workflow, or during a normal ticket, and price all three. The fourth driver is the help desk's own procedure for resetting a lost factor, which has to be written and tested before enrollment begins, because that procedure is the new attack surface.

Where the payback shows up, and when

The ticket reduction is real and it arrives on a lag. Resets do not stop the day expiry is disabled; they decline as the last expiry wave clears and the population settles into credentials they are not being forced to churn. Expect the curve to flatten over a quarter or two, and expect a temporary spike during enrollment that will be read as failure if you have not warned anyone it is coming. Report the spike in advance, with its expected shape and duration. That single piece of communication protects the program through the only period where the numbers look bad.

Against that saving, carry the new recurring costs honestly: the premium license, factor replacement for lost phones and keys, and the screening service if it is billed separately. The net is usually favorable at scale, and it improves as the enrollment hump passes into pure run-rate. Measure it the same way you measured the baseline, from the same ticket categories, so the comparison holds up a year later when someone asks whether the spend did anything.

Two steps cannot be redone later. Capturing the reset baseline has to happen before the policy changes, and the screening audit has to happen before anyone is forced to rotate. Get those two in the right order and the rest of the program is ordinary procurement, phased at whatever pace the help desk can absorb.