The MTTR Clock Starts Too Late

A NHI account is added to a group in March (t_grant). The group has standing access to production (increased blast radius). Nothing uses that access until October (t_exercise). A detection fires in November (t_detect). The log entry recording the March change aged out of the IdP in June. The November investigation can't establish who granted the access, when, or why.

Four timestamps

For incidents that begin with identity, the mean-time-to-remediate (MTTR) clock leaves out the stretch of time in which the incident was still an unnoticed capability change and could have been prevented rather than contained and remediated after an incident has occurred. In the timeline above, there are four timestamps for any identity-originated incident:

• t_grant = time of grant - the authorization change that created the capability (grant, group add, role assumption, trust misconfiguration, key issuance)
• t_exercise = first exercise of that capability by an adversary
• t_detect = detection of that capability in action
• t_remediate = the grant is revoked whether it was ever exercised or detected

MTTR, as used by the SOC, is t_remediate - t_detect. Dwell Time, the other metric SOCs look to, is t_detect - t_exercise. Neither metric accounts for t_exercise - t_grant, which is the only interval in which the incident could have been prevented rather than contained.

Why the data can't be queried

Hydden asserts the causal event in identity-originated incidents is an authorization change that occurs potentially months before any detection sensor is triggered by an exercise event. The logs recording that change are already written by identity provider products: group changes, new accounts, permission grants. The data exists. What doesn't exist is a system your SOC can query during an investigation that holds a complete, entity-resolved, time-indexed authorization record, which is why the preventable interval is often unmeasurable rather than merely unmeasured:

• Retention. For example, Okta retains System Log events for 90 days, then removes them automatically. Entra ID audit logs are 30 days on P1 and P2, 7 days on Free. If the grant happened 11 months ago the record is gone unless an export was set up in advance.
• Fragmentation and entity resolution. The logs exist in different products under different account identifiers with no common key, so even with perfect retention you can't assemble one principal's authorization history without resolving identities and activities across systems.
• Snapshot overwrite. Posture tools that store current state cannot answer point-in-time questions at all. They will miss a grant that was added, used, and removed between two scans.

Recovering t_grant

Hydden's ledger is event-sourced, bitemporal, and cross-system, which is what it takes to recover t_grant and revoke before t_exercise. The event stream still holds the March change after the identity provider's own log has aged out, and it holds the grant that a snapshot would have missed entirely. That makes the preventable interval measurable, and it gives security teams a number they can instrument and drive down: time-to-revoke from grant, t_remediate − t_grant.

Hydden's "Why does this principal have access?" view traces the path from an account through a role and a permission to a resource.

Event time and discovery time

The event stream is the system of record for identity change, held for a configurable retention period, with erasures and corrections recorded as events rather than destructive updates so the audit chain survives them. What does bitemporality buy? Consider two questions that look identical but aren't: "What could this contractor reach last March?" and "What did we believe they could reach last March, when we looked in April?" An event stream answers the first question but only a bitemporal record can answer the second, because grants surface late, logs arrive out of order, and entity resolution changes retroactively the moment you learn two accounts belong to the same person. The gap between when a grant took effect and when you learned of it is visibility latency, and it is a second metric you can drive down.

Both axes together are what let you answer blast radius questions at a point in time: ”Eleven months ago, what could this principal do? What resources could they reach? And which of those did they actually touch?”

The blast radius map for one account: the identity, the roles, groups and direct grants that give it access, and the resources it can reach.

Ranking by blast radius delta

The grant-to-exercise interval contains millions of entirely legitimate grants, so analysts need prioritization. Rank grants by blast radius delta at the moment of grant: is this principal's set of reachable resources growing, by how much, and what just came into range?

An account's blast radius score, with resources reachable, share of the tenant, and critical resources, followed by its reach on the Blast Radius tab.

Time-to-revoke from grant

In identity security, the event that starts the clock is time-of-grant. Start by measuring one thing: for the grants that most expanded a principal's reach last quarter, how long did each one stand before it was revoked or reviewed? That interval is time-to-revoke from grant, and unlike MTTR it covers the window where the incident was still preventable.