What is mean time to detect (MTTD)?
Mean time to detect (MTTD) is a security operations metric that measures the average time between the moment malicious or anomalous activity begins in an environment and the moment the security team detects it. It's one of the most widely tracked KPIs for a Security Operations Center (SOC), because it quantifies how long a threat can operate undetected: the attacker's dwell window. A lower MTTD means threats are spotted faster, shrinking the time an adversary has to escalate privileges, move laterally, or exfiltrate data. A higher MTTD signals blind spots in visibility, noisy detections, or overwhelmed analysts. MTTD is almost always read alongside its response-side counterpart, mean time to respond (MTTR). Although the concept originated in IT reliability engineering, where it tracked how quickly teams noticed faults and outages, MTTD has become a core security metric. This page explains what it measures, how to calculate it, why the definition is trickier than it looks, how it relates to MTTR and the other SOC timing metrics, and the practical levers that bring it down.
Key takeaways
- MTTD measures detection speed. It's the average time from when malicious or anomalous activity starts to when the team becomes aware of it, a direct proxy for attacker dwell time.
- The formula is simple; the inputs are not. MTTD is total detection time divided by the number of incidents, but pinning down the true activity start time and what counts as "detected" is where teams disagree.
- MTTD is not MTTR. MTTD covers the detection phase; MTTR covers response and remediation. A low MTTD paired with a high MTTR points to a response bottleneck, not a detection one.
- Lower MTTD reduces breach cost. Detection lag correlates directly with damage; industry research consistently ties faster detection to lower incident cost and smaller blast radius.
- Visibility, detection quality, and intelligence drive it down. Broad telemetry, well-tuned detections mapped to MITRE ATT&CK, native threat intelligence, and automation are the levers that consistently lower MTTD.
What MTTD actually measures
At its core, MTTD is a measure of visibility and detection capability. It reflects how efficiently an organization's tooling, processes, and people can notice that something is wrong. For that reason, MTTD is best read in aggregate, across a function or the whole organization and over time, rather than as a single headline number. Trends matter more than any one month's figure.
The metric appears in two closely related contexts. In cybersecurity, MTTD is the time from the start of malicious activity (unauthorized access, malware deployment, a policy violation) to the moment security tools or analysts identify it. In IT operations and site reliability engineering, the same metric tracks how quickly teams notice a service degradation or outage. In both cases the message is the same: the longer detection takes, the more damage accumulates.
MTTD also has clear limits. It doesn't measure how severe a threat is, how resilient the environment is, or how quickly the team can fix the problem once found. Those questions belong to other metrics. MTTD answers one thing well: how long did the threat stay invisible?
How to calculate MTTD
The standard formula is straightforward. For each incident, subtract the time the activity began from the time it was detected, sum those durations across all incidents in a period, and divide by the number of incidents:
MTTD = (Σ detection time across incidents) ÷ number of incidents
A quick worked example: if a SOC investigates three credential-misuse attempts that went undetected for 5, 11, and 9 minutes respectively, the MTTD is (5 + 11 + 9) / 3 = 8.33 minutes. Over a larger set of incidents the calculation is the same, just with more data points.
To compute this accurately, teams rely on event logs across endpoint, network, identity, and cloud telemetry; detection rules or automated alerts tied to suspicious activity; timeline reconstruction during investigations; and normalized timestamps that reconcile different log sources.
Two refinements are common. First, many teams strip out extreme outliers so a single very slow detection doesn't distort the average. Second, MTTD is often segmented by incident severity or attack class, because the acceptable detection window for a critical ransomware precursor is very different from that of a minor policy violation, and a blended average can hide a dangerous gap.
Why the MTTD definition is harder than it looks
The arithmetic is trivial, but the inputs are not, and this is where many MTTD reports quietly lose credibility.
The first ambiguity is the activity start time. Determining when malicious activity truly began requires retrospective analysis, and most organizations only have that level of forensic detail for incidents they investigated deeply. For everything else, the start time is an estimate. The second ambiguity is what counts as "detected." Detection can mean the first alert fired, the alert that actually led to an investigation, or the point at which an incident was formally declared. Each definition produces a different number, and organizations often don't document which one they use.
The right response isn't to abandon MTTD but to define it explicitly and apply it consistently. Because the metric drives investment decisions, staffing arguments, and vendor evaluations, a shifting definition undermines every decision built on it. Pick a definition of "detected," document it, and hold it stable so the trend line means something.
MTTD vs MTTR, MTTC, and MTTA
MTTD belongs to a family of SOC timing metrics, each measuring a different moment in the incident lifecycle. Reporting them separately, rather than as a single blended number, is what reveals where time is actually being lost.
The relationship between MTTD and MTTR is the one that matters most in practice. MTTD covers the time an attacker spends undetected; MTTR covers the time the team spends fighting back once the threat is visible. They typically trace to different root causes: shortening MTTD requires better detection logic, broader telemetry, and faster triage, whereas shortening MTTR requires better response workflows, automated containment, and clean incident handoffs. A SOC can post an excellent MTTD and a poor MTTR, or the reverse, which is exactly why blending them obscures the real bottleneck.
Why MTTD matters for security and the business
The case for driving MTTD down is ultimately about limiting damage. Every hour a threat stays undetected is an hour an adversary can use to steal credentials, move between systems, disable backups, exfiltrate data, or stage ransomware. Detection lag correlates directly with breach cost: industry research, including IBM's long-running Cost of a Data Breach analysis, has consistently found that incidents identified and contained quickly cost substantially less than those that linger for weeks or months. The often-cited figure that organizations can take around 200 days to detect a breach underscores how wide that window can be when detection is weak.
MTTD also serves as a benchmark for SOC maturity and a bridge to the boardroom. A consistently low MTTD suggests streamlined telemetry ingestion, precise detections, and efficient triage; a rising MTTD exposes architectural blind spots, skill gaps, or tool misconfigurations. As a single quantifiable number, MTTD gives CISOs a way to communicate detection performance to executives and to evidence compliance with frameworks such as GDPR, HIPAA, PCI DSS, and NIS2, several of which require timely detection and disclosure of incidents.
How to reduce MTTD
Bringing MTTD down is rarely a matter of buying more monitoring; it's about getting more signal, and more usable signal, out of the environment. The most effective levers are:
- Broaden visibility and telemetry: Missing endpoint coverage, limited cloud logging, or unmonitored identity signals create blind spots that attackers exploit. Comprehensive, well-managed logging across endpoint, network, cloud, and identity is the foundation of low MTTD.
- Improve detection quality: Generic, default rules miss advanced behavior. Custom, behavior-based detections aligned to MITRE ATT&CK and known adversary techniques catch real attack patterns earlier and cut the noise that buries genuine signals.
- Leverage threat intelligence: Feeding high-fidelity indicators of compromise (IoCs) into detection pipelines gives tooling a head start on known threats, so an artifact seen elsewhere triggers an alert the moment it reappears in your environment.
- Reduce false positives: Alert fatigue is one of the biggest hidden drivers of slow detection. Tuning correlation rules, applying risk-based alert scoring, and suppressing known-benign patterns surface true threats faster.
- Automate triage and correlation: Automation and analytics that correlate signals across sources compress the time between an alert firing and an analyst recognizing it as real, which is often the largest chunk of MTTD.
One caution: MTTD can be gamed. Because speed is easy to manipulate, teams measured crudely may log a token acknowledgment early to produce a low number. The goal is genuine detection quality, so pair MTTD with coverage and false-positive metrics rather than treating raw speed as the only target.
Expert insight: Detection speed is a function of intelligence and coverage, not just tooling
MTTD is capped by two things working in tandem: how much of the environment you can actually see, and how good your detections are at recognizing malicious behavior in that telemetry. Improve one without the other and MTTD stays high. Broad telemetry with weak detections floods analysts with noise; sharp detections over partial telemetry miss everything they never ingested. Most guidance treats these as separate levers to pull in sequence. They're not: they have to move together.
This is where Sekoia's approach is relevant. The Sekoia agentic SOC platform unifies SIEM, XDR, SOAR, and native cyber threat intelligence in one environment, and that combination maps directly onto both MTTD levers. On the coverage side, the platform ingests and correlates telemetry from across endpoint, network, cloud, and identity so signals aren't stranded in disconnected tools. On the detection-quality side, content is written and maintained by Sekoia's in-house Threat Detection & Research (TDR) team, mapped to MITRE ATT&CK, and continuously informed by native threat intelligence, so known-bad artifacts and adversary techniques are recognized quickly rather than after the fact. Behavioral analytics surface the subtle activity that signature-based rules miss, and automation compresses the triage lag between an alert firing and an analyst confirming it. As a European vendor with a data-sovereignty posture, Sekoia adds this detection depth without forcing teams to hand data to a black box.
When a vendor promises a lower MTTD, ask how. A credible answer addresses telemetry breadth, detection engineering, native intelligence, and triage automation together, not a single dashboard number. Detection speed is earned across the whole pipeline.