Why Your Identity Telemetry Has Already Forgotten the Attack (and how an ITDR can solve it)

Before building 8Layers, our team spent years inside SOCs and incident response engagements. Back then, investigating certain threats was reasonably straightforward because endpoints had EDR (Endpoint Detection and Response), Networks had NDR (Network Detection and Response), and emails had ESA (Email Security Appliance). On the other hand, firewalls, and some cloud logs - especially the identity ones - were fed into SIEMs with years of tuning behind them. 

Firewalls are as important today as they were 10 years ago, however, when the conversation comes to identity, the relevance of this data source grows exponentially. Identity is now: NHI (non-human identities) are growing 40x faster than humans, and recently the explosion of AI Agents make them even more relevant. Most organizations had no coherent strategy for capturing identity data to begin with. And when they finally did, nobody was paying close attention, because no dedicated tooling existed to make it actionable.

The pattern seeing repeatedly was that the identity layer was largely blind for the majority of organizations, and even when signals existed, there was no infrastructure to connect what happened months ago with what is happening right now. Those two things live in different storage tiers, with different query costs, and most platforms never bridge them.

Credentials are now the leading initial access vector in breaches, involved in 38% of all incidents analyzed by Verizon's 2024 DBIR. That gap is where the most damaging attacks live.

The Window Attackers Already Know About

SIEMs and analytics platforms work with very large volumes of data. If you want to query the last seven days, that data sits in fast, recent storage and the query is quick. But if you want to correlate old data with new data, or look for a pattern that spans months, you are running operations across multiple storage layers. Those operations are expensive. Technically possible, if you pay for it. But the cost is prohibitive for most organizations, and in practice it rarely happens.

According to the report Machine-Speed Attacks: Cloud Defense at the Inflection Point, published by CSA Lab Space, the average time to detect a cloud breach in 2025 was 219 days. Dwell time with modern tools and in mature environments is around 11 days as mandiant stated in the M-Trends 2026 report. An attacker who establishes initial access in January and escalates in March is effectively invisible to a platform that cannot efficiently correlate across that span.  

This is not a configuration problem. It follows directly from how these platforms are built to handle data at scale. And attackers do not need to understand the technical details to exploit it. They just need to be patient.

The same logic applies to automated detection. A rule that fires on a single event has no way to account for an event from four months ago that gives it meaning. The platform never makes that connection, not because the rule is wrong, but because the data it would need is outside the window.

More Rules Do Not Fix a Storage Problem

The industry's response to detection gaps has been to add more rules. Leading platforms compete on how many out-of-the-box detections they ship, with the implicit argument that broader coverage means better protection. In practice, however, this approach tends to overwhelm security teams with unnecessary noise and generate the need for additional tooling detection engineering would make redundant.

That argument misidentifies the problem.

More rules help when the challenge is producing signals. They do not help when the challenge is connecting events and signals that are separated by months. A rule that detects credential abuse on a given day cannot incorporate context from a dormant identity that was flagged as high risk six months earlier, if that earlier signal lives outside the platform's practical query horizon.

This distinction also changes how detection sophistication should be evaluated. There is a difference between a platform that detects individual events and a platform that can build what you might call meta-detections: cases where detection A, which already correlates several signals, coincides with detection B, which correlates several others, and the combination tells you something neither detection could tell you alone. That kind of intelligence requires the full history to be available, with no time limit.

The Non-Human Identity Problem Makes This Worse

This architectural constraint matters more now than it did a few years ago, because the identity surface has changed.

Non-human identities, including service accounts, API keys, OAuth applications, and AI agents, already outnumber human identities in enterprise environments. According to Entro Labs' 2025 research, for every human identity in an organization there are on average 92 non-human identities. They behave differently than human identities. They do not have predictable work hours. Their activity patterns are harder to baseline. And they are frequently created for a specific project and then abandoned, sitting dormant for months or years.

A dormant OAuth application created more than a year ago and suddenly activated is exactly the kind of signal that falls outside an usual detection window. It is also exactly the kind of signal that appears in real attack chains. The creation event and the activation event are causally connected. If your detection engine cannot correlate them, it cannot see the chain.

The Question to Ask Your Vendor

The next time you evaluate an ITDR platform, or review the one you already have, ask a direct question: how far back can your correlation logic reach, and what determines that limit?

If the answer involves storage costs, query performance, or data tiers, you have the information you need. The platform has a ceiling. That ceiling may be adjustable, at additional cost. But it was not designed to treat historical identity context as a permanent, first-class input to detection logic.

That distinction matters for the attacks that cause the most damage. Isolated events that match a known signature will be caught regardless. It is the slow campaigns, the ones that span quarters and combine techniques that individually look benign, that fall through. An attacker who is patient enough, and sophisticated enough, already knows where your window ends.

The industry has spent years competing on rule count. It is time to start asking what happens when the relevant context for that rule occurred outside the window the platform can see.

How 8Layers Approaches It

8Layers was built around that question. Thor, the platform's identity threat detection and response module, runs a temporal engine that keeps the full activity history of every identity, human and non-human, with no detection window. A dormant OAuth application's creation event and its activation a year later are evaluated as part of the same story. Thor builds signals over time and only raises an alert when a real kill chain emerges: one alert per attack, not one per signal. Each alert opens an investigation workspace with the timeline, related entities, and causality graph already reconstructed, and every detection is mapped to MITRE ATT&CK and written in a readable, auditable language. When the context that matters happened months ago, it is still part of the investigation.

See how Thor correlates across the full identity history. Book a demo.