What is MTTD (Mean Time to Detect)?

MTTD runs from the moment malicious activity begins to the moment the SOC knows about it, either because a rule fired or because an analyst found it during a hunt. The start is usually reconstructed after the fact from forensic artifacts: a file creation time, a process start, the first log line that touched the attacker's infrastructure. The end is the alert time. Everything in between counts, so MTTD measures the whole detection pipeline: the delay before a log reaches the SIEM, how often the rule runs, enrichment, and the minutes before someone confirms the alert is real.

Rule scheduling sets a floor that faster analysts can't remove. In Microsoft Sentinel, scheduled analytics rules run at the interval you configure, on a built-in five-minute delay that absorbs ingestion lag. Near-real-time (NRT) rules run once every minute on a two-minute delay. An attack caught by an hourly scheduled rule can wait more than an hour before an incident exists, even with every analyst on shift idle.

The arithmetic is simple, and the average misleads. Take three confirmed incidents in a month:

• a phishing payload detected after 40 minutes,
• a brute-force login after 3 hours,
• and a web shell a hunt found after 9 days.

Mean MTTD is about 73 hours, roughly three days, which describes none of the three. The median is 3 hours. Report the median and the 90th percentile next to the mean, split by severity or by detection source, or one long-dwell intrusion will hide every improvement you make on the rest.

MTTD stops where MTTR starts

• MTTD covers attacker activity up to detection.
• Mean time to acknowledge (MTTA), when a team tracks it, covers the gap between an alert's creation and the moment an analyst picks it up.
• MTTR covers detection to the first response action that changes the incident, such as isolating a host or disabling an account; some teams read the R as recover or resolve, so check the definition before comparing numbers between teams.

The two fail for different reasons. A long MTTD points to missing logs or missing rules, a long MTTR to slow triage, missing playbooks, or approval chains.

No standard sets a good MTTD, because the number depends on what you count

Mandiant's M-Trends 2026 report, built on its 2025 incident investigations, puts global median dwell time (the days an attacker was present before detection) at 14 days, up from 11 the year before, and at 122 days for cyber espionage and North Korean IT worker cases. In 52% of those investigations the organization detected the activity itself, up from 43% in 2024. These are breaches serious enough to call in Mandiant, so they describe intrusions that got past detection; the alerts a tuned SOC closes every day sit at the other end of the curve. For known patterns covered by a tuned rule, a target in minutes is realistic. The benchmark that tells you something is your own median and 90th percentile per severity, tracked month over month.

In Microsoft Sentinel you can measure a proxy from the SecurityIncident table

The table writes a new row every time an incident is created or updated, so first keep the latest row per IncidentNumber with arg_max. CreatedTime minus FirstActivityTime then gives the minutes between the first activity in the incident's alerts and the incident's creation. Call it a proxy in the report. FirstActivityTime is the earliest event your rules saw, not the start of the intrusion, so anything the attacker did before the first alerted event is invisible and the real MTTD is longer. Keeping only incidents classified as TruePositive stops false positives from pulling the number down; open incidents have no classification yet and drop out. This version covers the last 90 days:

SecurityIncident
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where CreatedTime > ago(90d)
| where Classification == 'TruePositive' and isnotempty(FirstActivityTime) and CreatedTime >= FirstActivityTime
| extend DetectMin = (CreatedTime - FirstActivityTime) / 1m
| summarize Incidents = count(), MeanMin = round(avg(DetectMin), 1), MedianMin = round(percentile(DetectMin, 50), 1), P90Min = round(percentile(DetectMin, 90), 1) by Severity
| order by MedianMin desc

Read the output by severity. A High median close to your rule interval plus the five-minute delay means the pipeline works as designed. A median far above it points to ingestion lag, or to a rule that only fires once an aggregation threshold is crossed, such as ten failed logins in an hour. A P90 many times the median usually means a handful of incidents were found late by a hunt or a user report, and those are the ones to review one by one. A sudden jump after a change (a new cloud tenant, a network re-architecture, a log forwarder outage) is often the first sign of a coverage gap.

What brings MTTD down:

• log coverage across endpoints, network, identity, and cloud;
• rules tuned well enough that analysts trust them;
• 24/7 monitoring;
• threat hunting that finds what rules miss;
• and new threat intel indicators matched against historical logs as soon as they arrive.

What pushes it up:

• an unmonitored server,
• a SaaS app with no log forwarding,
• alert fatigue from noisy rules,
• and monitoring that stops at 6 p.m.