Watch enough detection programs report their MTTD, and a pattern surfaces. Most teams are measuring the elapsed time from when an alert is generated to when someone in the queue acknowledges it. That number tracks how fast a shift clears a work queue. It says little about how fast the team finds an adversary.
The definition that matters is narrower and harder to hit. Mean time to detect is the elapsed time from the adversary's activity entering the environment to a defender's confirmed identification of malicious behavior; that is, the clock stops only when someone reviews the evidence and confirms that something is wrong. Teams that optimize the queue-acknowledgment version can post an improving dashboard while genuine threats dwell undetected, because the two numbers measure different things and only one of them is the metric attackers care about.
Mean time to detect is the elapsed time from the moment adversary activity enters the environment to the moment a defender has confirmed identification of malicious behavior. That is a different measurement from the alert-to-acknowledgment figure most dashboards report, and the difference is not academic. One measures detection capability, and the other measures how quickly a queue gets touched.
The empirical consequence of measuring the wrong thing shows up in the breach data. The IBM 2025 Cost of a Data Breach report recorded a 241-day mean time to identify and contain. A number that large is a trailing indicator of detection failure. It shows what happens when the gap between activity and confirmed identification goes unmanaged.
Even the standards vocabulary supports the narrower definition. The NIST glossary entry for mean time to detect and the NIST CSF Detect function both anchor detection to confirmed identification of an event, which gives practitioners an authoritative frame when they align internal definitions to something defensible.
Three 2025 reports set the reference points. Each measures a different failure mode that feeds MTTD.
IBM 2025 Cost of a Data Breach. The 241-day mean time to identify and contain covers the full arc from initial compromise to containment. It is a trailing indicator. The number only resolves after an incident is over, which tells you where detection failed rather than how fast detection is working today.
Verizon 2025 DBIR. Credential-driven intrusions continue to dominate the access patterns SOCs miss, per the 2025 Data Breach Investigations Report. Credential abuse matters to MTTD specifically because it generates log events that resemble legitimate user behavior. Detecting it depends on behavioral baseline coverage rather than signature matching, which raises the bar on what your telemetry has to see.
SANS 2025 Detection and Response Survey. In the 2025 Detection and Response Survey, 73% of teams ranked false positives as their dominant detection challenge, a finding that the Stamus Networks summary connects directly to worsening alert fatigue. Every analyst-hour spent clearing a false positive is an hour MTTD keeps climbing on the alerts that were real.
Four factors set where MTTD lands in any given SOC. Improving one while ignoring the others produces marginal movement; the material compression comes from addressing all four together.
IDC research shows the average enterprise monitors roughly two-thirds of its environment. That gap is the first driver. For incidents originating in unmonitored log sources, MTTD is undefined. No log source means no alert, and no alert means the detection clock never starts.
The gap is usually a budget decision presented as a detection-engineering one. Teams exclude log sources because ingestion-priced storage makes full retention expensive. Cost drives the exclusion, even when the excluded sources are ones adversaries target. Operationally, telemetry coverage means knowing which log sources are in scope, which are excluded, and whether the excluded set includes the credential stores, cloud workloads, or network infrastructure that adversaries target.
The SANS 73% figure lands here. False positives drive MTTD because they consume investigation cycles that would otherwise go to confirmed threats. A team clearing noise efficiently has bandwidth for real detections; a team buried in it cannot improve MTTD no matter how good its detection content is.
The mechanism is straightforward. Noisy rules fire on benign activity, so queue volume stops correlating with actual threat presence. Teams that measure MTTD from queue-clearing rather than confirmed identification will post a flattering number while real threats dwell in the noise.
Detection content is only as good as its coverage of the techniques adversaries use against your stack and sector. The MITRE ATT&CK data sources provide the evaluative frame. A detection that does not map to a relevant technique leaves a gap no amount of analyst discipline closes, because the alert for that technique never fires. Having a detection library is only useful when it covers the techniques that matter to you.
The Verizon credential-abuse finding connects here. If credential-misuse techniques are underrepresented in your detection content, MTTD for those intrusions is undefined regardless of how strong the rest of your program is.
Detection throughput is bounded by investigation capacity, and human triage is serial. One analyst works one alert at a time, so queue depth extends MTTD directly when alert volume outpaces staffing. This driver comes last because it depends on the other three. Fix coverage and signal-to-noise, and the queue pressure that makes analyst capacity the binding constraint eases considerably.
Each lever maps to a driver above. Treat them together, not as a menu.
Close log coverage gaps. Ingestion-priced SIEMs force teams to leave logs out because storage cost scales with ingestion volume, so every excluded source is a budget decision that doubles as a detection blind spot. Federated search inverts that model. Raw logs stay where they live and get searched in place, so teams retain everything without paying to ingest and parse it upfront. Strike48's search-in-place architecture provides complete log coverage for security teams that ingestion economics have forced to accept blind spots, and its search-in-place connectors for S3, Splunk, Elastic, and existing data lakes deliver that coverage without migrating data.
Retire noisy rules and validate against ATT&CK data sources. The fix for false-positive volume is auditing detection content against the MITRE ATT&CK data sources relevant to your environment and retiring rules that fire on benign patterns without contributing to technique coverage. Reducing alert volume is only worth doing when the retired rules were not covering a real gap.
Invest in detection content mapped to real techniques. The test for a useful rule is whether it covers a technique adversaries use against organizations in your sector and technology profile, not whether it is syntactically valid. Map existing content against ATT&CK data sources to find gaps before an incident finds them for you.
Automate triage to extend analyst capacity. Automating Tier 1 triage removes the serial bottleneck that keeps the queue growing, which is the natural companion to the detection work that precedes response.
State the ceiling plainly. MTTD cannot improve for incidents that generate no alerts, because the relevant log sources were never collected. A team reporting low MTTD across two-thirds of its environment has said nothing about the other third. Where no alerts fire, the number stays blank.
That is why the number needs two qualifiers before anyone can trust it. The first is which definition fed it. The second is what coverage percentage contributed to it. Without both, the figure is an approximation waiting to fail an incident review.
Fixing the visibility floor is necessary but not sufficient. The serial triage bottleneck still bounds how fast confirmed identification happens. Strike48 gives security teams complete log visibility plus agentic triage that runs investigations in parallel, which compressed MTTD below eight minutes in early enterprise deployments. That result required both conditions at once. Complete data so the alerts can fire, and parallel investigation so confirmation is not waiting in a queue. Strike48's agentic log intelligence platform connects every log source, including those excluded by cost from traditional SIEM pipelines, to agents that investigate without the queue-depth constraint that bounds human teams.
If your team already reports MTTD, you are ahead of the teams that do not measure it at all. The point here is to give you a way to stress-test the number, not to dismiss the work.
Two questions do the work. First, which definition fed it, alert-to-acknowledgment or adversary-activity-to-confirmed-identification? Second, what percentage of the environment generated the log data? If either answer is uncertain, the metric is uncertain. That is a structural observation about what MTTD can capture given its inputs, not a verdict on how well your team runs its program. A precise number over a partial environment tells you less than an honest one that names its own coverage.
Define the metric before you report it. MTTD reported upward should specify which definition was used and which log sources contributed. A number without those qualifications is an approximation that will surface its limitations during the next incident review.
Segment MTTD by attack category. Credential-based intrusions behave differently from malware-driven attacks, so a single organization-wide figure obscures technique-specific gaps. Segment by MITRE ATT&CK tactic or threat scenario to show where detection content is performing and where it is not.
Track coverage percentage alongside MTTD. Report the two together, MTTD of X minutes across Y% of the monitored environment. That framing forces the visibility conversation and keeps a coverage reduction from looking like a detection improvement. Strike48's verifiable audit trail on every agent action gives security leadership and compliance teams a documented investigation record that supports MTTD reporting without manual reconstruction.
The definitional gap is real and measurable, and the visibility floor is the structural constraint that caps how low MTTD can go regardless of analyst skill or detection content quality. You cannot compress a number below the coverage that feeds it.
Before your next leadership review, ask which definition and which coverage percentage your MTTD figure reflects. If either answer is uncertain, the conversation worth having is about what complete visibility plus agentic triage produces in practice. Strike48 provides agentic log intelligence that combines complete log coverage with parallel autonomous investigation for security teams measuring MTTD against partial environments.