Preview draft. Copy and visuals are pending review and may change before launch.

Incident response

Revocation and incident containment

The gap between 'we noticed something is wrong' and 'the affected access no longer works' is where most of the damage in a credential-compromise incident actually happens.

← Back to the library

Governance, Incident Response, and Resilience · Published 2026-09-05

Detection is not containment

Noticing that an identity is behaving suspiciously and actually cutting off its access are two different capabilities, and organizations often invest heavily in the first while underbuilding the second. A detection system that flags a compromised credential accurately, twenty minutes before anyone can act on the alert, has bought only twenty minutes of head start for whoever is misusing it.

Containment has to be fast enough to matter relative to how quickly damage can be done, which for an automated attacker or a misbehaving agent can be seconds, not the hours a manual incident-response process might assume.

Containment as a designed capability, not an afterthought

Effective containment usually combines a few things designed in advance: revocation that propagates quickly rather than waiting for caches to expire, quarantine as an intermediate option when outright revocation would be too disruptive before the investigation is complete, and blast-radius limits — narrow permissions, network segmentation — that bound the damage during the window before containment takes effect, however short that window is.

None of this can be assembled during the incident itself. It has to already exist, tested, before it's needed — an incident is a poor time to discover that revoking a credential takes longer than expected, or that nobody is sure which system owns the decision to do it.