Finance wants to cut broker headroom that is only used when a stolen-credential incident forces a mass revocation — what do you argue, and what disconnect time do you sign for?

## Reframe the line item The request on the table is "why are we paying for capacity that sits idle". Answering with utilisation graphs loses, because the graphs prove finance's point: on an ordinary Tuesday the headroom is unused. The honest framing is different — this capacity is not for serving traffic, it is for **surviving the response**. The scenario it exists for: a credential compromise forces a broad revocation. Across a workforce with no office at all, every one of those users is on home broadband, hotel wifi or a tethered phone, and every application they use is reached through the same broker. Cut them all, and they all come back inside the same minute — a simultaneous re-authentication wave against the broker's front end and the identity provider behind it, plus a support call from every person whose work was interrupted. If the platform cannot serve that minute, re-admission stalls, the wave retries, and you have converted a security action into an outage. ## The cost finance has not been shown What gets bought with the headroom is not comfort — it is the willingness to use the control. The failure mode of an under-provisioned broker is not a slow morning; it is a conversation during an incident where the security lead says "we should revoke everyone" and the platform owner says "that will take us down", and the organisation settles for a narrower revocation that leaves the adversary a session. The cost of that outcome is the cost of the incident continuing, and that is a number the business already knows how to reason about. So the argument is: *this line item is what makes our stated containment action executable. Remove it and we should also remove the containment action from the incident plan, because we will not run it.* Whoever cuts the budget is then explicitly accepting that. ## Offer the cheaper options, because they exist An argument that only says "pay more" is weak. Put alternatives on the table and let the owner choose: - **Spread the peak.** Re-admission with jitter turns one impossible minute into several manageable ones. It costs recovery time, not money — but that recovery time is the thing you would otherwise be committing to. - **Burst rather than standing capacity.** Front-end capacity that is provisioned when the revocation fires costs far less than permanent N+1, at the price of a warm-up delay and a dependency on that expansion working under stress — which means it must be exercised, or it is a plan rather than a capability. - **Scope the predicate.** If revocation can cut a cohort — one region, one device class, one application tier — you rarely need the whole-population wave at all. This is the cheapest option and the one that needs the most design work up front. - **Prioritise re-admission.** Bring back the flows the business cannot run without before the rest. This requires somebody outside security to say which ones those are. ## Signing for a number The second half of the question is the harder one, because a committed number is held against you. Commit only to what you can evidence, and state the exclusions plainly: - A **stated share** of live sessions terminated within a **stated window** of the revocation being issued — a share and a window, never "all sessions immediately". - Measured by a **scheduled exercise**, not by design intent: a synthetic revocation through the real path, timed to last byte. - **Devices that are offline or asleep are excluded**, explicitly, because you cannot disconnect what you cannot reach; the guarantee for those is that they cannot re-admit, not that their existing flow is dead. - A separate **re-admission** commitment, because the business cares more about being back than about being cut off, and it is a different number with different owners. ## Who actually signs This is what makes it a leadership question rather than a capacity question. The broker owner commits the disconnect window. The service-desk owner commits the staffing to absorb the calls, or the window is fiction. The incident owner accepts the residual — the offline tail and the traffic no enforcement point reaches. And finance owns whichever capacity model was chosen. If any of those four has not signed, you do not have a commitment; you have an intention that will be re-litigated in the middle of an incident, which is the worst possible time to discover it.