Your mass credential reset covers 4,000 accounts but the helpdesk can re-verify 400 a day. How do you scope it?

## Why this is a decision and not a schedule With four thousand accounts and four hundred verifications a day, the reset takes about ten working days. That is not an operational detail, it is a statement that some population remains reachable with credentials the adversary may hold for up to ten days. Treating it as a queue to be worked alphabetically converts a security decision into an accident of surname ordering. The job is to choose who is exposed for how long, put compensating controls under them, and have the right person accept that. ## Tiering the population Build the order from the investigation, not from the org chart: 1. **Identities with evidence of adversary use** in the audit trail, plus any identity whose credential material was in reach of what they accessed. 2. **Privileged identities**, including administrative accounts, break-glass accounts and anything holding directory or cloud control-plane rights. 3. **Service and application identities**, which need separate handling because rotating them breaks software, so app owners must be lined up first. 4. **The business functions the intrusion touched**, where lateral movement is most plausible. 5. **Everyone else**, on the assumption that the estate-wide reset is precautionary. A common political failure is executives first regardless of exposure. Seniority is not exposure, and a VIP-first queue delays the accounts that actually carry risk. ## Fix the verification path before the volume Re-verification is the step the adversary will attack, because it is the moment credentials are handed out over the phone. If the helpdesk verifies by knowledge (employee number, manager's name, recent activity), the adversary who has been reading a mailbox for weeks answers better than the real employee. During an active intrusion the verification must be out-of-band relative to anything they control: a manager confirming on a video call they initiate, an in-person check for the highest tier, or a code delivered through a channel that is not the compromised platform. Self-service reset is a throughput multiplier and worth using, but only where the factors it relies on are ones you have already audited for adversary-registered devices. Warn the helpdesk explicitly that a surge of urgent reset calls is an expected adversary behaviour during a mass reset, and give them an escalation path rather than a target handle time. ## Compensating controls for the tail The un-reset population is not safe, but it can be made less useful. Block legacy authentication protocols that bypass modern policy; tighten conditional access to compliant devices or known networks for the highest-risk applications; force sign-in frequency down so tokens have to be re-issued; disable dormant accounts outright rather than resetting them, which costs nothing and shrinks the queue; and run a detection specifically for authentication using pre-reset material or from the infrastructure attributed to the intrusion. Disabling the long tail of unused accounts is often the single biggest reduction available, and it needs no helpdesk time at all. ## The decision that is not yours Someone has to accept that the estate carries known residual adversary access for the duration. That is an executive risk acceptance, documented, with the numbers in it: how many accounts, for how long, with which compensating controls, and what would change the plan. The alternative options should be priced rather than assumed away: surging capacity with contractors or by deputising team leads as verifiers, accepting a partial outage by disabling rather than resetting a tranche, or extending the window. Present the trade-off as availability against dwell time, give a recommendation, and let the accountable owner choose. Where a regulator or a contractual notification clock is running, that constraint belongs in the same paper. ## Knowing when it is actually done Completion is not tickets closed. The measure is per-account: each identity has authenticated at least once with post-reset credentials, and nothing has authenticated with pre-reset material since. Accounts that never come back are a finding in their own right, because an account nobody claims is either dormant, which means disable it, or belongs to someone who is not the person you think. Report the two numbers separately and keep the detection running after the incident closes.