Identity threat response

Identity threat response is the set of actions taken after an identity compromise signal fires: revoking sessions and credentials, downgrading trust, forcing re-verification, and notifying downstream systems. It is distinct from identity threat detection, which observes and classifies the signal but changes nothing.

The practical test of a response capability is time-to-safe: the elapsed time between a signal (say, a carrier-reported SIM swap) and the moment the compromised identity can no longer act. Programs that measure only detection latency routinely miss that their time-to-safe is minutes long.

Time-to-safe is measurable in a way detection latency is not, because its end state is observable: either the compromised identity can still act or it cannot. Instrumenting it means recording the signal timestamp, the decision timestamp, and the moment each dependent grant stopped working, then reporting the last of those rather than the second. Programs that stop the clock at the decision are measuring how fast they formed an opinion.

The response itself is a design surface with more than one setting. Ending a session is the blunt option; narrowing scope, lowering a limit and requiring step-up authentication before the next sensitive action are graduated ones, and they need somewhere in the application to record a reduced trust level. Where that place does not exist, every signal resolves to log or log out, which is the state most programs are actually in. The inputs are trust signals rather than scores, so each decision stays re-derivable at review time.

Detection and response also fail differently, which matters when choosing what to tune. A missed detection costs one incident; a response that fires wrongly costs every user it touches, and that cost is paid immediately and visibly. Programs usually discover this the first week a rule goes live, and the fix is almost always a narrower trigger rather than a gentler action.