- 194 days - global average to identify a breach (IBM Cost of a Data Breach 2024).
- 64 days - additional time to contain it, for a total lifecycle of 258 days.
- 10 days - global median dwell time reported by Mandiant M-Trends 2024, driven down by faster ransomware detonation.
- ~62 minutes - average attacker breakout time from initial access to lateral movement (CrowdStrike 2024 Global Threat Report).
- Stolen credentials - remain the single most common initial access vector in the Verizon DBIR.
On April 13, 2026, two very different companies disclosed breaches on the same day. McGraw-Hill confirmed that 13.5 million records had been pulled from a misconfigured Salesforce instance, surfacing only after extortionists posted the data and set a ransom deadline. Booking.com confirmed that attackers had been harvesting reservation data by compromising hotel partners - not Booking's own infrastructure - for weeks before the scope was understood.
Neither company found the breach first. Neither breach happened inside the traditional network perimeter. And that is the uncomfortable update to the dwell time conversation: the clock is still running, but it is running in places most CISOs are not watching.
The companies that end up in the headlines almost always had the tooling. EDR, SIEM, SOC, a mature compliance program, quarterly pen tests. The gap is not in what they bought. It is in the detection model those tools are wired into, which has not kept up with how modern attackers actually operate - through SaaS configuration drift, through a supplier's compromised workstation, through identity rather than endpoint.
The Numbers Nobody Wants to Quote
The IBM Cost of a Data Breach 2024 report put the global average at 194 days to identify a breach and 64 days to contain it. That is 258 days between the first foothold and the last eviction - more than eight months. For sectors like healthcare and finance, the number runs longer.
A separate number from Mandiant M-Trends 2024 looks friendlier at first glance: global median dwell time of 10 days. But that figure is bent downward by ransomware. When an attacker encrypts your environment on day nine, dwell time ends on day nine - not because you detected them, but because they announced themselves. Strip out ransomware and the median for stealth intrusions stretches back into months.
The gap between those two numbers tells you more than either does alone. Fast, noisy attackers get caught quickly. Patient, credential-based attackers stay undetected for most of a year. Both are happening in the same environments, often on the same week.
Why Detection Fails
Three structural reasons explain almost every long-dwell breach I have investigated.
1. Attackers look like administrators. "Living off the land" - using native tools like PowerShell, WMI, remote desktop, and built-in cloud APIs - is now the default playbook for serious intrusions. There is no malware signature to catch, because there is often no malware. A stolen set of admin credentials plus native tooling produces telemetry that looks, to an untrained eye and to most out-of-the-box detection rules, like normal IT operations. The Change Healthcare intrusion in early 2024 and the wave of Snowflake-customer breaches later that year both relied heavily on stolen credentials and legitimate-looking access patterns.
2. Detection coverage is thinner than the dashboard suggests. Most security programs are over-invested in endpoint and under-invested in identity, SaaS, and third-party access. The attacker landscape moved first. Sensitive data now lives in Salesforce, Google Workspace, Microsoft 365, Snowflake, GitHub, and a long tail of SaaS apps with weak logging and weaker alerting. If your detection story stops at the laptop and the firewall, you have left the most valuable data unwatched.
3. The loud signals crowd out the quiet ones. A mature SOC processes tens of thousands of alerts per month. The ones that get triaged first are the ones that look urgent: malware callbacks, brute-force attempts, obvious policy violations. The ones that get closed as noise are exactly the ones a patient attacker generates - a single successful login from a new country at an unusual hour, a small API call pattern from a service account, a privilege escalation that looks like a legitimate change. Alert fatigue is not a people problem. It is a detection-design problem.
How Attackers Stay Invisible
The modern intrusion playbook has converged across ransomware crews, state-aligned groups, and financially motivated actors. It looks like this:
Phishing, infostealer logs from underground markets, or an MFA-fatigue push. No exploit, no 0-day. Just a valid username and password, sometimes already sold online for a few dollars.
Log in through the same VPN, SSO, or SaaS portal a real employee would use. From the identity provider's perspective, it is a normal session.
Use native tools to map the environment - directory queries, cloud console browsing, reading shared drives and wikis. Slow, human-paced, well under most rate-limit thresholds.
Data is staged in cloud storage the company already uses - OneDrive, Google Drive, an S3 bucket - then moved out in chunks over days or weeks. DLP tools tuned for email rarely catch it.
At no point in this sequence does the attacker do something a legacy signature would flag. Everything is policy-compliant, correctly authenticated, and indistinguishable from the hundreds of legitimate sessions happening at the same time. The detection has to happen at the behavior layer - sequences and anomalies across identity, endpoint, and SaaS - not at the artifact layer.
The Intrusion-to-Discovery Gap
When a breach is finally discovered, the forensic timeline almost always looks the same. First access: weeks or months before the disclosure date. Lateral movement: within hours of that first access. Data staging: within days. Exfiltration: usually complete well before anyone notices.
CrowdStrike's 2024 report put average breakout time - the interval from initial foothold to the first lateral move - at roughly 62 minutes. The fastest observed was just over two minutes. Against that clock, a detection program measured in days is effectively absent for the critical window where the intrusion is still contained to a single host.
This is why the conversation about breach prevention is incomplete without a conversation about detection speed. You will not prevent every intrusion. The question that determines whether an intrusion becomes a breach is how quickly you see it and how quickly you respond.
What to Measure Instead
Most security programs measure activity. Patches applied, alerts closed, phishing click rates. None of those numbers predict whether you will be in the headlines next year. Four others do, and they are the ones worth arguing over at the quarterly review.
MTTD (Mean Time to Detect), measured by injecting synthetic adversary behavior quarterly and tracking how long until your SOC flags it. Not theoretical; measured.
MTTC (Mean Time to Contain), the interval from detection to the attacker being evicted. A fast detection followed by a slow containment is still a long breach.
Detection coverage by surface - endpoint, identity, email, SaaS, cloud control plane, OT. Map your detections against the MITRE ATT&CK techniques active in your industry. The gaps are where attackers live.
Purple-team pass rate. Quarterly exercises where offensive and defensive teams collaborate. The metric is not "did we stop it" but "did we see it, how fast, and what would have needed to change to see it sooner."
Five Actions That Shrink Dwell Time
Across dozens of engagements, five actions consistently move the number more than anything else.
1. Instrument identity like it is the primary attack surface, because it is. Feed every authentication event, MFA change, privilege escalation, and service-account action into your detection stack. Alert on the sequences, not just the individual events. A password reset followed by a new-country login followed by a group-membership change is a story - treat it as one.
2. Assume credentials are already stolen. Design detections around what happens after a successful login, not just how the login happened. A valid session from a compromised account is indistinguishable from a legitimate one at the authentication layer. The anomaly appears in what the account does next.
3. Close the SaaS and third-party blind spots. Pull audit logs from every high-risk SaaS tool into your SIEM or detection platform. Build alerts on mass downloads, admin role changes, and OAuth app grants. The MOVEit fallout and the 2024 Snowflake-customer incidents both exploited visibility gaps that endpoint-centric programs could not close.
4. Run purple-team exercises on a fixed cadence. Quarterly, not annually. Use threat-intel-driven scenarios that mirror actual TTPs seen against your industry. The point is not to pass; the point is to find the gap between what the red team does and what the blue team sees, then engineer it closed.
5. Report MTTD and MTTC to the board every quarter. Detection speed is the single cleanest indicator of security maturity. Once it is on the executive scorecard, it gets funded. Until then, detection investment loses every budget fight to the next prevention tool.
Frequently Asked Questions
What is attacker dwell time?
Attacker dwell time is the number of days between when an attacker first compromises a system and when the defender detects and contains them. It combines mean time to detect (MTTD) and mean time to contain (MTTC). The IBM 2024 average was 258 days end-to-end.
Why do most breaches go undetected for so long?
Three structural reasons: attackers use stolen credentials and native admin tools so their activity looks legitimate; detection coverage is thin in identity, SaaS, and OT environments; and alert fatigue pushes analysts to triage loud signals and miss the quiet ones.
Who usually discovers a breach?
Historically, more than half of breaches were discovered by an external party - law enforcement, a customer, a supplier, or the attacker posting stolen data on a leak site. Internal detection has improved but still misses a large share of targeted intrusions. Plan for the case where it does not find the breach first.
What is a realistic MTTD target?
For a well-instrumented mid-market organization: under 24 hours for identity and endpoint, under 7 days for SaaS and third-party access. Global median dwell time has dropped to roughly 10 days in recent Mandiant data, so single-digit days is achievable with investment in identity telemetry and detection engineering.
Closing
The companies that avoid the headline are not the ones with the thickest wall. They are the ones that saw the intruder quickly, moved faster than the attacker, and made containment a muscle instead of a project. Prevention is a budget line. Detection is a capability, and the two do not substitute for each other.
If you do not know your MTTD today, that is the first number to go find. Measure it. Publish it to the executive team. Make reducing it the scorecard the program runs against. Eight months of dwell time is not a technology problem, it is a decision the organization keeps making by default. Once somebody in the room names it and puts it on the quarterly scorecard, it starts moving inside one cycle.
Written by
Asaf Levy
Cybersecurity expert with 30+ years of experience across enterprise CISO, CTO, and co-founder roles. Advises boards and executive teams on detection engineering, incident response, and reducing attacker dwell time.