Glossary

Dwell Time

In 2011, the median attacker sat inside a compromised environment for 416 days before anyone noticed, more than thirteen months of undetected access, by Mandiant’s count. Recent M-Trends reporting puts the global median at roughly ten to eleven days. That fortyfold compression is one of the few genuinely…

In 2011, the median attacker sat inside a compromised environment for 416 days before anyone noticed, more than thirteen months of undetected access, by Mandiant’s count. Recent M-Trends reporting puts the global median at roughly ten to eleven days. That fortyfold compression is one of the few genuinely encouraging long-term trends in security operations. It’s also more complicated than it looks, because part of the improvement is attackers choosing to announce themselves.

Dwell time is the metric that captures the gap those numbers describe, and for a CISO it may be the single most consequential measurement in the program: nearly everything an intruder does that causes real damage, lateral movement, privilege escalation, data staging, exfiltration, happens inside that window.

What Is Dwell Time in Cybersecurity?

Dwell time is the duration an attacker remains undetected inside an environment, measured from the first evidence of compromise to the moment the intrusion is identified. It’s typically expressed in days and reported as a median, because the distribution is badly skewed: a handful of intrusions discovered after years drag any average far away from the typical case. Detection is the endpoint, not remediation, the clock stops when you know the attacker is there, even though the response work is just beginning.

The metric matters because attacker impact compounds with time. An intruder caught within hours of initial access is usually still on one machine with one set of credentials. The same intruder three weeks later has mapped the network, harvested admin credentials, established redundant persistence, and located the data worth taking. Compressing dwell time doesn’t just shrink a number on a dashboard; it determines whether an incident is a contained event or a company-defining breach.

Who does the detecting matters too. Industry reporting consistently splits dwell time by notification source, and intrusions surfaced by external parties (law enforcement, a ransom note, a third party finding your data) carry longer dwell times than those caught internally. A SOC’s ability to find intrusions itself, rather than hear about them, is what the metric is really testing.

The environment being measured has also widened. Dwell time used to mean time on the corporate network; a modern intrusion may live entirely in a SaaS tenant, a cloud control plane, or a federated identity provider without ever touching a managed endpoint. Any internal definition of the metric needs to cover those surfaces explicitly, because they’re where detection coverage is usually weakest and where the long-tail dwell times now hide.

Reading the Benchmarks Without Fooling Yourself

Two Decades of Shrinking Medians

The long arc is real progress. Mandiant’s M-Trends series, the closest thing the industry has to a longitudinal record, shows the global median falling from 416 days in 2011 to under a month by 2020, ten days for intrusions investigated in 2023, and about eleven days in the 2024 data. Better endpoint detection, wider logging coverage, and more capable SOCs all contributed. And detection genuinely did get faster.

But medians conceal the tail. The same reports keep finding a meaningful share of intrusions that go undetected for months or years, often in environments with gaps in logging or unmanaged infrastructure. Your organization’s dwell time isn’t the industry median; it’s a function of your own coverage, and the intrusions you haven’t found yet don’t appear in your numbers.

The Ransomware Distortion

A significant slice of the improvement is attacker behavior, not defender skill. Ransomware operators end their own dwell time on purpose: the encryption event and ransom note are self-disclosure, and ransomware intrusions consistently show medians of only a few days, pulling the aggregate down. Modern extortion crews also simply move faster, some go from initial access to exfiltration in under 48 hours, which means shorter dwell time can coincide with worse outcomes. A three-day dwell time on a smash-and-grab exfiltration is not a defensive win. This is the honest limitation of the metric: it measures how long attackers stayed hidden, not how much damage they did while hidden.

What the Number Means Inside Your Own Walls

Measuring dwell time internally requires forensic honesty. The start of the clock is the earliest evidence of compromise found during investigation, not the timestamp of the alert that finally fired, which means every incident review should include the question “when did this actually begin?” Teams that backdate properly often discover their true dwell times are multiples of what the alerting data suggested. It’s an uncomfortable exercise (nobody enjoys documenting that the intruder arrived in March and the alert fired in May), and it’s the only version of the metric worth tracking.

You can also measure the metric before a real intruder does it for you. Purple team exercises and breach simulations produce a controlled dwell time: the red side establishes access and starts working through persistence and lateral movement, and the clock runs until the SOC notices. Organizations running these regularly get two things the annual pen test report doesn’t give them, a trend line on their own detection latency, and a specific list of which attacker behaviors passed through the environment without generating a single triaged alert.

Compressing Dwell Time in Practice

MTTD and MTTR, the Metrics That Move It

Dwell time is an outcome; MTTD (mean time to detect) and MTTR (mean time to respond) are the operational levers underneath it. MTTD covers the same territory as dwell time from the SOC’s side of the glass, how quickly threats are surfaced, while MTTR governs how quickly a detected threat is actually shut down. The three form a cluster: dwell time is what the board asks about, MTTD and MTTR are what the SOC can instrument week over week. Improving them means shrinking every stage between signal and verdict, coverage gaps that delay the first signal, alert backlogs that delay triage, and investigation queues that delay confirmation.

The reason to obsess over the detection half is that it’s a race with a defined finish line. Attackers need time to reach their objective, to escalate privileges, find the data, stage it, and move it, and every hour of dwell time you remove is an hour subtracted from that project plan. Catch the intrusion during initial reconnaissance and containment is a single host reimage. Catch it after domain admin has been achieved and you’re rebuilding identity infrastructure over a long weekend. Same intrusion, wildly different incident, and the only variable that changed is when you noticed.

Coverage Against the Middle of the Kill Chain

Long dwell times live in the middle techniques: persistence, credential access, lateral movement, the quiet phases between initial access and impact. MITRE ATT&CK is most useful here as a mapping exercise rather than a compliance artifact, take your active detection rules, map them to the techniques attackers use during those middle phases, and the blank cells show you where an intruder can operate silently. Teams that run this exercise usually find their coverage clusters at initial access and impact (where vendors compete) and thins badly in between (where dwell time accumulates). The follow-through, writing detections for your specific blind spots, is where the exercise either pays off or becomes shelfware.

The Triage Bottleneck Nobody Budgets For

Here’s the uncomfortable pattern in many breach post-mortems: the SIEM did fire. The signal existed, sometimes weeks before discovery, and it died in a queue of ten thousand look-alike alerts, or was closed by an exhausted analyst as another false positive. Detection technology wasn’t the gap; investigation capacity was. Dwell time in these cases isn’t the time to signal, it’s the time to someone taking the signal seriously.

That’s the specific bottleneck an AI SOC attacks. When investigation capacity stops being the scarce resource, every alert can be worked to a verdict instead of sampled. Conifers CognitiveSOCâ„¢ runs autonomous investigations at an average of about 2.5 minutes per case with better than 99% accuracy, which changes the math on those buried signals: the weak lateral-movement alert that a queue would swallow gets fully investigated the moment it fires. For AI SOC platform evaluations focused on dwell time, that queue-to-verdict latency is the number to interrogate, and you can see it directly at a live demo.

Frequently Asked Questions About Dwell Time

What’s the difference between dwell time and MTTD?

They measure the same gap from different vantage points. Dwell time is incident-centric and forensic: for this intrusion, how many days elapsed between compromise and discovery, established after the fact by investigation. MTTD is program-centric and operational: across our detections over a period, what’s the mean time from threat activity to detection. Dwell time is usually reported as a median across breaches (often by outside researchers); MTTD is a KPI a SOC computes about itself. In practice they diverge because MTTD calculations often start the clock at the first alert, while proper dwell time starts at the first evidence of compromise, which may precede any alert by weeks.

What is a good dwell time benchmark?

The global median in recent M-Trends reporting sits around ten to eleven days, so beating that is table stakes for a funded enterprise SOC. But the more useful internal targets are shaped by attacker speed: with ransomware crews routinely reaching encryption inside 72 hours and some exfiltrating within 48, a defensible goal is detecting active intrusions in hours, not days, at least for crown-jewel segments. It depends heavily on sector and architecture, a hospital network with legacy OT equipment and a cloud-native SaaS company aren’t playing the same game. Benchmark against your own trend line quarter over quarter; the external medians are context, not a finish line.

Does shorter dwell time always mean better security?

No, and this is where the metric breaks down as a standalone score. Dwell time falls when attackers self-disclose (ransomware) and when they simply work faster, neither of which reflects defensive improvement. It can also look artificially good when you’re only finding the noisy intrusions, a SOC that catches commodity malware in hours while a quiet espionage operator sits in the identity infrastructure for a year has a great median and a terrible problem. Read dwell time alongside detection source (internal versus external), the severity mix of what’s being caught, and coverage metrics. A shrinking median with rising external notifications is a warning, not a win.

How do attackers stay undetected for so long?

Mostly by looking like the environment. Long-dwell intrusions favor valid accounts over malware, living-off-the-land binaries over custom tools, and activity paced to blend into business hours, techniques that generate low-severity signals or none at all. And they concentrate in the places coverage is thinnest: unmanaged devices, appliances that can’t run EDR, forgotten cloud tenants, and identity systems where “suspicious” and “normal admin work” look identical in the logs. The defense isn’t one product; it’s closing logging gaps, watching identity behavior as carefully as endpoints, and hunting proactively for the intrusions your alerting was never going to surface.

← Back to Resources
See it live

Watch an agent investigate a real alert.

CognitiveSOC™ runs the investigation end-to-end on top of your existing SIEM, SOAR and XDR, and shows its work.