In July, a detection fires on a service account: production resources are being read by a session the SOC can't explain. The account is a non-human identity (NHI) that a deployment pipeline authenticates as. The service account sits in a group with standing access to production. That group membership is the only reason a pipeline credential can reach production. The analyst needs to know who added the service account to that group, when, and why.
Hydden's "Why does this principal have access?" view traces the path from an account through a role and a permission to a resource.
The first adversary use of that access was in June, a month before anything fired, when someone holding the service account's credential used it from outside the pipeline. The authorization change that made it possible was in March, when the service account was added to the group. The IdP wrote a log entry for that change in March, and that entry aged out of the IdP in June, before the alert existed. So in July the investigation can reconstruct the exercise and the detection, but it can't establish who granted the access, when, or why.
The incident has four points in time: the grant in March, the first adversary use in June, the detection in July, and the remediation after that. The metric SOCs report, MTTR, measures only from detection to remediation. Before getting into what it takes to recover the grant, it helps to name the four points precisely, because once they have names it becomes clear which span MTTR measures and which span it leaves out.
Four timestamps
Every identity-originated incident has four timestamps:
- t_grant: time of grant, the authorization change that created the capability (grant, group add, role assumption, trust misconfiguration, key issuance). In the service account's case, March.
- t_exercise: first exercise of that capability by an adversary. June.
- t_detect: detection of that capability in action. July.
- t_remediate: the grant is revoked, whether or not it was ever exercised or detected.
Prevent time runs from t_grant to t_exercise, dwell time from t_exercise to t_detect, and MTTR from t_detect to t_remediate.
MTTR, the mean time to remediate as used by the SOC, is t_remediate − t_detect. For the service account, that clock starts in July. Dwell time, the other metric SOCs look to, is t_detect − t_exercise, June to July. Neither metric accounts for t_exercise − t_grant, the prevent time, which ran from March to June. It is the only interval in which the incident could have been prevented rather than contained, and MTTR leaves it out. During that interval the incident was still an unnoticed capability change, before an event becomes an incident.
Why the data can't be queried
Hydden asserts that 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. In the service account's case the sensor fired four months after the grant.
The logs capturing 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 system of record for authorization. This is why the preventable interval is often unmeasurable rather than merely unmeasured. Three mechanisms cause it.
Retention. Okta retains System Log events for 90 days, then removes them automatically. Entra ID audit logs are kept for 30 days on P1 and P2, and 7 days on Free. The service account's March grant was about four months old when the July alert fired, so on either IdP the log entry 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. 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. They will miss a grant that was added, used, and removed between two scans.
Recovering t_grant
Hydden's Identity System of Record 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 service account's March change after the identity provider's own log aged out in June, and it holds the grant that a snapshot would have missed.
Change events in Hydden's event feed, including group_member_added, each with its timestamp and the source that recorded it.
The event stream feeds the system of record for identity change, held for a configurable retention period. Erasures and corrections are written as events rather than overwriting updates, so the audit chain survives them.
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.
Event time and discovery time
What does bitemporality buy? Consider two questions that look identical but aren't:
- "What could this service account reach in March?"
- "What did we believe it could reach in March, when we looked in April?"
An event stream answers the first question. Only a bitemporal system of record can answer the second, for three reasons:
- Grants surface late. A grant made in March may not be discovered until a scan in April, so the answer you would have given in March differs from the answer you give now.
- Logs arrive out of order. An event timestamped earlier can arrive after events timestamped later, so the history has to be re-sorted as late events land.
- Entity resolution changes retroactively. When you learn in May that two accounts belong to the same owner, their earlier histories are joined, so the answer about what that owner could reach in March changes.
The gap between when a grant took effect and when you learned of it is visibility latency. You can measure it and drive it down, like time-to-revoke.
Keeping both times, when a change happened and when you learned about it, is what lets you answer blast radius questions at a point in time. In July, the analyst's questions about the service account are these: "In March, what could this principal do? What resources could it reach? And which of those did it actually touch?"
The blast radius view for an account: nodes reached, direct connections, and depth in hops.
Ranking by blast radius delta
The grant-to-exercise interval contains millions of legitimate grants, so analysts need prioritization. The service account's March group add was one of them, and nothing about it looked different from the rest on the day it happened.
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? A pipeline service account whose reachable set jumps to include production is the kind of grant that should rise to the top in March, not in July.
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. For the service account, that was March, three months before the first adversary use and four months before the SOC's clock started.
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.
Schedule a one on one to measure time-to-revoke from grant against your own identity history.