Key Takeaways
The MTTD formula divides total detection time by incident count, so detection times of 3, 9, 6, and 2 hours give an MTTD of 5 hours.
Mandiant’s M-Trends 2026 report found global median dwell time rose from 11 days to 14 days.
Mean time to respond (MTTR) measures the delay after detection, so the two metrics must be tracked together.
SentryWire captures every packet and retains it for weeks, months, or years, which lets teams date an intrusion accurately.
Mean time to detect (MTTD) is a security performance metric that measures the average time between the start of a security incident and the moment a security team detects it. Security operations teams use it to gauge how quickly tools, analysts, and processes identify intrusions, malware activity, and other malicious behavior.
The figure is only as reliable as the evidence behind it. Teams that cannot establish when an incident actually started will report a better number than they have earned.
SentryWire builds enterprise-grade full packet capture for regulated, high-risk environments where fast, defensible detection and investigation are required. This page covers how to calculate the metric, how it compares with MTTR, what drives it up, and how retained packet evidence brings it down.
What Is MTTD in Cybersecurity?
In cybersecurity, MTTD is the average detection delay across all incidents in a measurement period, counted from the earliest attacker activity to confirmed detection. It is also called mean time to detection or mean time to discover.
Definitions differ between teams. Some stop the clock at the first automated alert, and others stop it when an analyst confirms a real incident. Choose one and keep it, because a change in method moves the number more than any new tool will.
Security operations center (SOC) leaders track it as a core security metric, often aligned to the Detect function of the National Institute of Standards and Technology (NIST) Cybersecurity Framework.
Why MTTD Matters for Security Teams
Detection speed matters because every hour an attacker stays undetected is an hour for lateral movement, data theft, and ransomware deployment. A short detection time limits that damage, while a long one lets a small intrusion grow into a data breach.
Global median dwell time rose from 11 days to 14 days in Mandiant’s M-Trends 2026 report, according to Wiz’s summary. The Microsoft Midnight Blizzard intrusion began in November 2023 and went undetected until January 12, 2024, a gap of roughly two months, per Wiz’s analysis.
Faster detection and containment also cut cost. IBM’s 2025 Cost of a Data Breach Report found that organizations using AI and automation across security workflows shortened breach lifecycles by 80 days and saved an average of $1.9 million per breach, as cited by Wiz.
Disclosure rules add time pressure. The Securities and Exchange Commission (SEC) requires public companies to disclose a material cybersecurity incident within four business days of determining it is material, so a late discovery compresses the time left to investigate. Tracking the metric also gives auditors and executives a measurable view of whether detection is improving.
How to Calculate MTTD
The MTTD formula is total time to detect all incidents divided by the number of incidents in the period. Most teams run the calculation monthly or quarterly.
MTTD = total time to detect all incidents ÷ number of incidents
Follow these steps to calculate it for a period:
Define the incident start and the detection point, and write both definitions down.
Record the start time and detection time for every incident in the period.
Subtract each start time from its detection time to get the time to detect.
Add the results and divide by the number of incidents.
For example, four incidents detected in 3, 9, 6, and 2 hours total 20 hours, which gives a mean of 5 hours.
The hardest input is the incident start time. Investigators usually learn it after the fact, from logs, endpoint telemetry, and network data, and missing records push teams to understate the result. A single long-running incident can also skew a small data set, so many teams report median time to detect alongside the average and break results out by severity.
MTTD vs. MTTR and Related Metrics
MTTD measures how long it takes to detect an incident, while MTTR measures how long it takes to respond once the incident is detected. Together with mean time to acknowledge (MTTA) and mean time to identify (MTTI), they make up the core incident response metrics most SOCs report.
| Metric | What it measures | Clock starts | Clock stops |
|---|---|---|---|
| MTTD (mean time to detect) | Detection speed | The incident begins | The security team detects the incident |
| MTTA (mean time to acknowledge) | Alert handling speed | The alert is generated | An analyst acknowledges the alert |
| MTTI (mean time to identify) | Triage speed | The alert is generated | Analysts determine the incident type and severity |
| MTTR (mean time to respond) | Response speed | The incident is detected | Response actions are completed |
A team can post a low MTTD and a high MTTR, which means threats are found quickly but contained slowly, so the metrics need to be read together. Some organizations expand the R in MTTR to resolve, recover, or remediate, so define it before comparing numbers across teams or vendors.
What Causes a High MTTD?
A high MTTD usually traces to visibility gaps, alert noise, disconnected tools, and short data retention. Each one delays either the first alert or the confirmation that the alert is real.
These are the most common causes:
Visibility gaps: flow-only, endpoint-only, and “snapshot in time” monitoring miss activity on the network.
Alert noise: false positives bury real incidents and cause alert fatigue.
Disconnected tools: signals sit in separate consoles, so analysts cannot correlate them early.
Short retention: without historical data, teams cannot trace an intrusion back to its start.
Single-method detection: signature-only rules miss unknown threats, and anomaly-only models can flood analysts with false positives.
How to Reduce MTTD
Reducing MTTD takes broader visibility, layered detection, and faster confirmation of alerts. No single tool does all three.
These steps lower detection time in most environments:
Capture all network traffic instead of samples, so no activity sits outside network visibility.
Combine signature-based detection rules for known threats with anomaly-based detection for unknown ones.
Run proactive threat hunting, which searches for intrusions instead of waiting for alerts.
Send alerts to a security information and event management (SIEM) or security orchestration, automation, and response (SOAR) platform for automated enrichment.
Map detection rules to MITRE ATT&CK techniques to find coverage gaps, and tune the rules on a schedule.
Feed threat intelligence into detection so new indicators of compromise (IOCs) are checked quickly.
Tuning takes sustained analyst time, and tighter detection rules can raise false positives before they settle. Plan for that cost when setting a target.
How Full Packet Capture Lowers and Verifies MTTD
Full packet capture lowers MTTD by letting analysts confirm alerts against the actual traffic, and it makes the number more accurate by preserving the evidence needed to date an intrusion. It supplies the record that detection tools alone do not keep.
SentryWire’s full packet capture platform records every packet at sustained 10Gbps+ speeds and retains the data for weeks, months, or years on commodity hardware. When an alert fires, analysts move from the alert to the matching packets and confirm or dismiss it, which shortens the gap between the first alert and a confirmed detection.
Retention also fixes the measurement problem. SentryWire’s integrated Suricata engine supports retrospective search-back, so a new IOC from a threat intelligence feed can be run against historical traffic. If the indicator appears in traffic from three months ago, the team has a documented start date and a result that reflects reality.
SentryWire integrates with Splunk, Elastic, and SOAR platforms, so packet evidence reaches analysts inside the tools they already use and supports incident response from first alert to final report. Retained packets also support audit documentation under Office of Management and Budget memorandum M-21-31, the North American Electric Reliability Corporation Critical Infrastructure Protection (NERC-CIP) standards, System and Organization Controls 2 (SOC 2), the Health Insurance Portability and Accountability Act (HIPAA), and SEC Rule 17a-4.
Full packet capture complements network detection and response (NDR), extended detection and response (XDR), and SIEM tools rather than replacing them, and it needs storage planning at enterprise scale. Organizations that need only flow monitoring are not the right fit.
Improving MTTD Starts With Better Evidence
Detection time improves when teams can see all network traffic, confirm alerts quickly, and look back far enough to date an intrusion. Detection tools raise the alert, and retained packet data supplies the proof.
To see how retained packet evidence supports faster detection, review SentryWire’s network security monitoring capabilities, read the platform overview, or contact the SentryWire team to discuss your environment.
FAQ copy provided, do not rewrite.
Frequently Asked Questions About MTTD
What is a good MTTD?
There is no single good MTTD, because the right target depends on your environment, the types of incidents you face, and how you define the start of an incident. A better goal is a steady downward trend measured the same way every quarter, with high-severity incidents detected in hours rather than days. Benchmark against your own history before comparing yourself to industry figures.
Is MTTD the same as dwell time?
MTTD is not the same as dwell time. The metric is an average across many incidents, while dwell time measures how long an attacker was present before discovery in one incident. The two are closely related, because each incident’s dwell time is one of the data points that feeds into the average. A falling trend generally signals shorter dwell times across your program.
How often should you calculate MTTD?
Calculate MTTD on a consistent schedule, typically monthly or quarterly, using the same definitions each time. Consistency matters more than frequency, because a single incident can swing the average sharply when incident volumes are low. Most teams also break results out by incident type or severity so that one slow outlier does not hide real progress.
How do you determine when an incident started?
The incident start is the earliest point of attacker activity that investigators can establish, such as initial access or the first malicious action. Analysts reconstruct it after the fact from logs, endpoint telemetry, and network data. Stored packet data is especially useful here because it can show the first malicious connection, even when the incident was only detected weeks later.
Does a lower MTTD always mean better security?
A lower MTTD does not always mean stronger security. The metric only counts incidents your team actually detected, so undetected intrusions never enter the average and can make results look better than reality. Read it alongside detection coverage, false positive rates, and MTTR for an accurate picture of how well your program performs.
