What is dwell time?

Key takeaways

• Dwell time measures detection. Long dwell time means the attacker had time to expand foothold, harvest credentials, exfiltrate data, or stage ransomware.
• Industry benchmark dwell times have fallen from months (2015) to days or hours (2024-2025) as EDR and detection tooling matured. Mid-market manufacturers track behind the benchmark.
• The dominant cause of long dwell time at mid-market manufacturers is uneven detection coverage: EDR on some systems, none on others; SIEM logging some events, none from others; OT environment largely invisible.
• Dwell time is reducible without buying a full SOC. Tuned EDR, identity-anomaly detection, OT-aware monitoring, and a documented alert-triage path produce most of the available reduction.
• ARG measures dwell time during adversarial simulation and tracks it as a trend over time.

How is dwell time measured, and what does it indicate?

Dwell time is the elapsed time between two specific points:

• Initial compromise. The moment the attacker first gained unauthorized access. For email-based attacks, the moment credentials were submitted to a phishing page or an OAuth grant was approved. For ransomware, the moment of initial execution. For OT-side incidents, the moment the attacker first interacted with an OT asset.
• Detection. The moment the defending team became aware of the compromise. Not the alert timestamp; the moment a human recognized that an incident was happening.

The gap between the two points is the silent window during which the attacker had free access. The longer the window, the more damage the attacker accomplished before the defender had a chance to respond.

Dwell time indicates several things at once:

1. Detection coverage. Whether the right signals are being collected from the right systems.
2. Detection quality. Whether collected signals are being correlated, prioritized, and surfaced to a human.
3. Analyst capacity. Whether the human reviewing alerts has time and attention to act.
4. Attacker tradecraft. How sophisticated the attacker is at evading detection.

A long dwell time can reflect a sophisticated attacker, an under-coverage defender, an overloaded analyst, or all three. The diagnostic value is in breaking down the components.

Industry benchmark dwell times in 2025 and 2026

Major industry sources (Mandiant M-Trends, IBM Cost of a Data Breach Report, CrowdStrike Global Threat Report) track dwell time annually. The numbers vary by report and methodology, but the trend is consistent: dwell times have fallen materially over the last decade.

Approximate ranges by year (median, global, all-industry):

• 2015: 200+ days
• 2018: ~80 days
• 2020: ~25 days
• 2022: ~16 days
• 2024: ~10 days for externally-discovered, hours for internally-detected with mature EDR
• 2025-2026: Hours to a few days for organizations with modern detection; weeks to months for organizations without

The downward trend reflects EDR maturity, threat intelligence sharing, attacker behavior shifting toward fast-monetization (ransomware deploys quickly to avoid detection), and improved coordination between detection and response.

Mid-market manufacturers typically track above the median because of uneven detection coverage. Dwell times measured in days for office IT environments with EDR are common; dwell times measured in weeks or months for OT environments without OT-aware monitoring are equally common.

The relevant benchmark for a specific organization is not the global median; it is the trend of the organization's own dwell time over consecutive engagements. Improvement is the metric, not absolute number.

Why mid-market manufacturers have higher dwell times than enterprises

Three structural reasons.

1. Uneven detection coverage. Enterprises typically deploy EDR everywhere with disciplined exception management. Mid-market manufacturers often have EDR on Windows endpoints, partial coverage on servers, no coverage on OT, and ad-hoc coverage on shared systems. Attackers operate from the under-covered surface.
2. No dedicated security operations function. Enterprises run a SOC with named analysts watching alerts in real time. Mid-market manufacturers have IT teams that handle security as one responsibility among many. Alert triage happens on a different cadence; some alerts are missed for hours or days.
3. OT environment opacity. Most OT environments at mid-market manufacturers have minimal security monitoring. An attacker active in the OT zone can operate for weeks without producing a visible alert. See What is operational technology (OT) security?.

The fixes are achievable without enterprise-scale investment. Tuned detection on the systems that actually matter (identity, endpoint, OT-adjacent IT), a documented triage path with response time targets, and OT-aware monitoring as a managed service produce most of the available reduction at a mid-market cost structure.

Examples of dwell-time impact in real incidents

What dwell time costs in practice:

• Credential theft to ransomware deployment. Spear phish on a Tuesday; credentials harvested; OAuth grant approved Wednesday; lateral movement across the IT environment Thursday and Friday; ransomware encrypts servers Saturday night. Dwell time: four days. With modern identity-anomaly detection, the dwell time can be hours; the four days is what missing or untuned detection costs.
• Vendor-mailbox BEC into wire fraud. Vendor's mailbox compromised week 1; attacker reads emails for two weeks learning AP cadence; modified invoice sent week 3; wire processed week 3; vendor follows up about non-payment week 5. Dwell time: more than a month, by which point recovery is unlikely. See What is business email compromise (BEC)?.
• OT engineering workstation compromise. Spear phish lands on an engineer's workstation; attacker establishes persistence; weeks of reconnaissance and credential harvesting on the OT-adjacent network; eventual PLC programming modification discovered through quality variance. Dwell time: months. The OT environment had no security telemetry; detection came through production data, not security tools.
• Insider data exfiltration during notice period. Departing engineer downloads CAD repositories over the final two weeks of employment. Detected during a routine audit-log review three weeks after departure. Dwell time: five weeks from start of exfiltration. With identity-anomaly detection tuned for unusual download volume, the dwell time can be hours.
• Persistent OAuth grant survived password reset. Spear phish landed nine months ago; OAuth grant approved; password reset followed standard rotation but did not revoke the grant; attacker retained mailbox access continuously. Dwell time: nine months. Discovered through quarterly OAuth audit. See What is consent phishing (OAuth phishing)?.

The pattern: every hour of dwell time is hours the attacker had to expand foothold or accomplish their objective. Reducing dwell time is the single highest-leverage investment in detection capability.

How to reduce dwell time without buying a SOC

For a mid-market manufacturer without dedicated security operations:

1. EDR with tuned detection. Out-of-the-box EDR catches many commodity patterns; tuning catches more. Time spent tuning EDR per the environment pays back in dwell time reduction.
2. Identity-anomaly detection. Microsoft Entra Identity Protection, Okta ThreatInsight, or equivalent. Anomalous logons, OAuth grants, MFA fatigue patterns, impossible-travel events. The identity layer is where dwell time accumulates most for mid-market environments.
3. Centralized alert routing. All security alerts route to a single queue with documented triage time targets. A 30-minute triage target for high-severity alerts during business hours, with documented after-hours coverage, is achievable without a dedicated SOC.
4. Managed detection and response (MDR) for after-hours coverage. A managed service covers the time the internal team cannot. Pricing for mid-market MDR is typically mid-four to low-five figures monthly; the dwell-time reduction usually justifies it.
5. OT-aware monitoring. Passive OT monitoring with industrial-protocol understanding produces detection coverage on a surface that is otherwise silent. Managed-service variants exist for mid-market budgets.
6. Honey-account and honey-file deployment. Carefully-placed decoy accounts and files produce high-confidence alerts when accessed. Low cost, high signal.
7. Documented playbooks for top alert types. When an alert fires, the analyst knows what to check, who to call, how to escalate. Time is not lost figuring out the process during the event.
8. Regular detection drills. BAS and continuous adversarial simulation exercise the detection layer continuously. Drift surfaces quickly.

The combination produces dwell times in hours to a day or two for most attack patterns, which is appropriate for the mid-market manufacturer threat model.

Best practices for detection engineering on a small team

Detection engineering at a mid-market manufacturer is constrained by team capacity. Practical principles:

1. Detect tactics, not just indicators. Indicators (specific malware hashes, specific IPs) date quickly. Tactics (suspicious PowerShell, anomalous OAuth, LSASS access) age slowly. Detection rules built around tactics produce sustained value.
2. Tune for the actual threat model. Generic detection rules produce noise. Detection rules tuned for ransomware-affiliate TTPs, BEC operator tradecraft, and supply-chain attack patterns produce signal.
3. Map to MITRE ATT&CK. Coverage tracked against the MITRE ATT&CK matrix so the team knows what is and is not covered. Gaps drive detection-engineering priorities.
4. Reduce false positives ruthlessly. A detection rule that fires repeatedly without value erodes analyst attention. Time spent suppressing false positives produces better detection than time spent adding new rules.
5. Document each detection. What it detects, why, what to do when it fires, what tunings have been applied. Without documentation, detection rules become tribal knowledge and rot when team members change.
6. Run purple team exercises on a recurring cadence. Detection improvement happens fastest with attackers in the room explaining technique. Quarterly purple team work compounds.
7. Coordinate with the IT team's normal change cycle. Configuration changes, system updates, and new software all affect detection. The detection team sees changes before they break detection.
8. Plan for OT separately. OT detection engineering is its own discipline. Mid-market manufacturers typically rely on OT-aware MDR providers rather than internal OT detection.

Dwell time FAQs

What is the difference between dwell time and MTTR?

Dwell time measures detection latency: the gap between compromise and discovery. Mean time to respond (MTTR) measures response latency: the gap between detection and containment. Both matter. Dwell time tells you how long the attacker had free access; MTTR tells you how fast the defending team acted once the attack was known. See What is incident response (IR)?.

Does EDR reduce dwell time on its own?

Partially. EDR catches many commodity attack patterns automatically and reduces dwell time for those patterns to minutes or hours. EDR does not catch targeted attacks that avoid known indicators, attacks that defeat EDR through configuration or process abuse, or attacks against systems outside EDR coverage (often OT). EDR is necessary but not sufficient.

Why is dwell time longer in OT environments?

OT environments have less detection coverage than IT environments. Many OT systems do not support standard EDR; OT-aware monitoring is less widely deployed; OT incidents look like process anomalies rather than security events. The combination produces longer dwell times measured in months rather than days in some OT-targeted incidents. See What is operational technology (OT) security?.

What is an acceptable dwell time for a mid-market manufacturer?

Hours for credential-theft and ransomware-staging attacks, given modern EDR and identity-anomaly detection. Days at most for targeted attacks. A manufacturer with dwell time in weeks is materially below current expectations; in months, well below. The benchmark is moving down as detection tooling improves; programs need to move with it.

How ARG measures dwell time during simulated engagements

Dwell time is one of the operational metrics ARG tracks during continuous adversarial simulation. Each engagement produces a measurable dwell-time figure for each simulated attack, with trend tracking over time.

The measurement is operated by James Wall on the digital side. For each simulated attack chain (spear phish + credential capture, OAuth consent grant, vishing call resulting in MFA reset, assumed-breach post-exploitation), ARG records:

• Initial compromise time. When the simulated foothold was established.
• First defender signal. When detection telemetry first showed evidence (alert fired, log entry produced, anomaly flagged).
• First defender response. When a human (the IT lead, MDR provider, or other defender) actually acted on the signal.

The first-to-second gap is detection latency; the second-to-third gap is response latency. The total is the simulated dwell time.

Tracked over engagements, the metric shows whether the program is actually improving the time between attacker compromise and defender awareness. Specific findings (a rule that did not fire when it should have, an alert that fired but was not triaged in time, an attack technique with no detection coverage) flow into the risk register and the detection-engineering backlog.

The continuous testing surface is the real production environment, not a lab. Detections built in a lab do not transfer; detections tuned during simulation against the real stack do. The output of every quarter is a measurable dwell-time improvement on specific technique categories, with the evidence package suitable for insurance underwriting, CMMC, and customer security reviews.

Apply as a founding client or see how the engagement works for the full delivery cycle.