Twenty-one days. That is the average time a threat actor spends inside an enterprise network before detection, according to the 2024 M-Trends report. In that three-week window, they enumerate credentials, establish persistence, locate critical data stores, and prepare for exfiltration — all while your SIEM continues generating alerts about failed SSH logins and misconfigured S3 buckets. The problem is not that your detection tools are broken. The problem is you are measuring the wrong thing.
What Dwell Time Actually Measures
Dwell time is the elapsed period from first intrusion to detection. It is not the same as time-to-alert, time-to-escalation, or time-to-resolution — metrics that appear on most SOC dashboards but that, individually, tell you very little about adversary progression.
A threat actor operating a supply-chain implant may never trigger a high-severity SIEM alert. Their access looks legitimate. They log in with valid credentials obtained through a phishing campaign. They move laterally using administrative tools already present on the host. They read files at volumes within normal thresholds. No rule fires. No threshold is crossed. Meanwhile, dwell time accumulates.
In our experience reviewing post-incident timelines, teams focused on mean time to respond (MTTR) can achieve sub-four-hour resolution on the alerts they see — and still suffer weeks-long breaches from activity that never generated an alert. MTTR optimization addresses alert handling speed. It does not address detection coverage. Those are fundamentally different problems.
The gap between visibility and detection
Most enterprise SOC environments have better visibility than they realize — EDR telemetry, SIEM logs, identity provider events, cloud audit logs — but that visibility exists in siloed systems that do not talk to each other in real time. An analyst triaging a CrowdStrike alert does not have automatic context from Okta showing that the same user's credentials were used from two different geolocations four hours earlier. The data is there. The correlation is not.
Why Alert Volume Is a Misleading Proxy
The most common mistake we see SOC teams make is treating alert volume as a proxy for coverage. A SIEM generating 50,000 alerts per day looks busy. It may also be generating zero detections of the adversary who has been living in your network for two weeks using a compromised service account.
Alert volume metrics measure how loud your detection tools are, not how effective they are. They incentivize tuning toward sensitivity — more alerts, more coverage, right? — which is exactly backward. High-sensitivity configurations produce alert noise that buries genuine signals. In a SOC fielding 3,000 alerts per analyst per month, investigation depth degrades. Time per ticket drops. Context windows shrink. Real threats get triaged the same way false positives do: quickly, with insufficient evidence, and often incorrectly.
The 45-to-65 percent false positive rate observed across enterprise SIEMs is not primarily a detection-rule quality problem. It is an architecture problem. Rules written for individual event types, without cross-signal correlation, produce probabilistic noise rather than adversarial evidence.
What high-performing teams measure instead
The SOC teams we have seen achieve sub-48-hour dwell time consistently share one pattern: they measure threat coverage by adversarial technique, not alert count. They track which MITRE ATT&CK techniques they have behavioral detection for, not how many alerts those detections generate. Coverage per technique, not volume per day.
Measuring Dwell Time in Practice
Measuring your own dwell time requires retrospective analysis of incidents you have already resolved. For each confirmed incident, document: when the first indicator was available in any log source, and when it was acted on. The gap between those two timestamps is your dwell time for that incident.
Most teams discover, when they do this analysis for the first time, that the data was available much earlier than the detection. A threat actor who establishes persistence on a Thursday may have a corresponding service account creation logged in Active Directory on Monday. The signal was there. No one saw it because no hunt mission was looking for service account creation from non-standard hostnames during business hours.
| Metric | What It Measures | Dwell Time Relevance |
|---|---|---|
| MTTD (Mean Time to Detect) | Time from intrusion to confirmed detection | Direct proxy for dwell time |
| MTTR (Mean Time to Respond) | Time from detection to resolution | Irrelevant if detection is late |
| False Positive Rate | Percentage of alerts that are not real threats | Indirect: high FPR buries real signals |
| ATT&CK Coverage % | Techniques with behavioral detection | Determines which TTPs you can detect at all |
Persistent Signal Nodes: The Architecture Shift
Reducing dwell time requires moving from event-triggered detection to continuous behavioral analysis. Event-triggered detection responds to what happens. Continuous behavioral analysis tracks the pattern of what has been happening over time — and queries against that historical context to surface low-and-slow adversarial progressions that no single event would trigger.
The architectural concept behind this is what we internally call persistent signal nodes: telemetry events that are retained as graph nodes in a live threat model, not discarded after failing to trigger a correlation rule. An endpoint with an unusual outbound connection that did not cross a threshold still becomes a node. A user account with a new service principal registration that looked like normal IT activity still becomes a node. Those nodes sit in the threat graph, available for retrospective correlation when a subsequent event connects them into an adversarial pattern.
Without persistent signal nodes, your detection model resets on every event. With them, you are building a continuous picture of adversary behavior that can surface dwell-time threats that would otherwise go dark between alert windows.
Operationalizing persistence
In practice, this means retaining telemetry in a queryable form for at minimum 30 days — and ideally 90 days for high-value targets. It means running hunt missions against historical data, not just live streams. And it means designing correlation logic that asks "what does this event look like in context of the last seven days of activity from this host and user?" rather than "does this event match a known-bad pattern?"
Setting a Dwell Time Target
Industry average is 21 days. Mature SOC operations achieve sub-72-hour dwell time for intrusions that affect endpoints covered by behavioral detection. The meaningful question for any security team is not "how do we get to zero?" — that is not achievable against sophisticated adversaries — but rather "what dwell time is acceptable given our risk profile, and what coverage changes are required to reach it?"
For a financial institution holding customer payment data, even 24 hours of undetected access to production systems is a significant business risk. For a software development company with no PII in production, the calculus is different. Dwell time targets should be derived from a breach cost model, not a regulatory checkbox.
"We spent two years optimizing MTTR and got very good at responding to alerts fast. Then a red-team exercise showed us we had 17-day dwell time on activity that never alerted. That's when we understood we were solving the wrong problem."
— Composite observation from post-incident reviews across mid-market enterprise security teams
Practical Takeaways
- Add MTTD (mean time to detect) to your monthly SOC metrics alongside MTTR — they measure different failure modes
- Run quarterly retrospectives on past incidents to measure actual dwell time and identify where signals were present but uncorrelated
- Audit your ATT&CK technique coverage at least twice a year — coverage gaps are where dwell time accumulates
- Retain telemetry for at least 30 days in a queryable form to enable retrospective correlation
- Define a dwell time target based on your breach cost model, not industry averages
Dwell time is not a tool problem. It is a detection architecture problem. Alert volume optimization, MTTR tuning, and headcount additions all operate at the wrong level of the stack. The teams that consistently achieve low dwell time have invested in cross-signal correlation, persistent telemetry, and behavioral analysis that covers the TTPs adversaries actually use — not just the ones that generate alerts. That is the architectural shift worth measuring toward.
