Mean Time to Detect (MTTD) in 2026: Formula, Benchmarks and How to Reduce It
Mean Time to Detect (MTTD) is a cybersecurity operations metric used to measure how long, on average, it takes an organization to detect security incidents after the chosen starting point for measurement.
It sounds simple, but MTTD is frequently misunderstood.
Organizations may calculate detection time from:
- the estimated beginning of malicious activity;
- the first observable malicious event;
- the moment an alert became technically detectable;
- another consistently defined incident starting point.
For that reason, two companies can both report an MTTD of “30 minutes” while measuring different things.
A useful MTTD program therefore requires two things:
a consistent definition + reliable timestamps
MTTD should also not be confused with:
- attacker dwell time;
- Mean Time to Acknowledge;
- Mean Time to Contain;
- Mean Time to Respond;
- Mean Time to Recover.
NIST’s current incident-response guidance emphasizes improving the effectiveness and efficiency of incident detection, response and recovery as part of an integrated cybersecurity risk-management program. NIST finalized SP 800-61 Rev. 3 in April 2025, replacing Rev. 2 and aligning incident response with Cybersecurity Framework 2.0.
The practical goal of MTTD is not simply to produce a lower number for a dashboard.
It is to answer:
How quickly are we recognizing real malicious activity, and where are detection delays occurring?
MTTD at a Glance
| Metric | What it measures | Example |
|---|---|---|
| MTTD | Average time until detection | 42 minutes |
| Median detection time | Middle detection interval | 18 minutes |
| P90 detection time | 90% detected within this interval | 3.4 hours |
| Dwell time | Attacker presence before discovery/detection | 14 days in a specific dataset |
| Time to acknowledge | Alert → analyst action | 7 minutes |
| MTTC | Incident validation → containment | 48 minutes |
| Recovery time | Incident → restored operations | 14 hours |
The exact starting and ending points should be documented internally.
Table of Contents
What Is Mean Time to Detect?
Mean Time to Detect is generally calculated as the average elapsed detection time across a defined group of incidents.
A simple representation is:
MTTD = Total Detection Time ÷ Number of Incidents
But the formula is only useful if every incident uses the same definition of detection time.
For example, suppose your organization defines detection time as:
Estimated start of malicious activity → first reliable security detection.
Then every incident in the dataset should follow that definition.
Do not mix:
- attack start → detection;
- alert generation → analyst review;
- detection → confirmation
inside the same metric.
Those measure different parts of the response process.
MTTD Formula
The basic formula is:
MTTD = Σ Detection Intervals ÷ Number of Incidents
Suppose three confirmed incidents had these detection intervals:
| Incident | Malicious activity began | Detection | Detection interval |
|---|---|---|---|
| Incident A | 08:00 | 08:20 | 20 min |
| Incident B | 10:00 | 11:30 | 90 min |
| Incident C | 14:00 | 14:10 | 10 min |
Total detection time:
20 + 90 + 10 = 120 minutes
Number of incidents:
3
Therefore:
MTTD = 120 ÷ 3 = 40 minutes
Your MTTD for those incidents is 40 minutes.
Why the Median Matters Too
The arithmetic mean can be distorted by one unusually slow incident.
Using the same example:
10 min, 20 min, 90 min
MTTD:
40 minutes
Median:
20 minutes
The median tells you that the typical middle incident was detected considerably faster than the mean suggests.
Now imagine:
8 min, 10 min, 12 min, 15 min, 3 days
The one three-day detection failure can dramatically increase the mean.
That failure absolutely matters—but leadership should understand both:
- normal detection performance; and
- extreme detection failures.
For that reason, mature security programs should consider reporting:
median + mean + percentiles
rather than relying on one average.
Add P90 and P95 Detection Time
Percentiles can expose the incidents that your average hides.
For example:
Median: 18 minutes
MTTD: 31 minutes
P90: 2.5 hours
P95: 6.8 hours
This tells leadership something much more useful:
Most incidents are detected relatively quickly, but a small number remain undetected for much longer.
Those long-tail events deserve investigation.
Cybersecurity Time MTTD Dashboard
A useful operational dashboard could include:
| Metric | Current | Target | Trend |
|---|---|---|---|
| MTTD | 42 min | <30 min | Improving |
| Median detection | 21 min | <20 min | Stable |
| P90 detection | 3.1 hrs | <2 hrs | Needs work |
| Time to acknowledge | 8 min | <5 min | Improving |
| MTTC | 58 min | <45 min | Needs work |
| Incidents externally discovered | 18% | <10% | Improving |
The specific targets should be based on your own:
- risk;
- environment;
- staffing;
- business criticality;
- incident types.
There is no universal “30-minute MTTD” requirement.
MTTD vs Dwell Time
These terms are often used as if they mean the same thing.
They should not be.
MTTD
An operational metric calculated by an organization across a set of incidents.
Example:
Average detection interval across this quarter’s 22 confirmed incidents = 37 minutes.
Dwell Time
Usually describes how long a threat actor remains in an environment before discovery or detection.
The exact definition can vary by research organization.
Mandiant’s M-Trends 2026 reports a global median dwell time of 14 days, compared with 11 days in the previous reporting period. Mandiant attributes part of the increase to stealthier long-term espionage and DPRK IT-worker activity.
That does not mean:
“The average organization’s MTTD is 14 days.”
It means that among the Mandiant Consulting investigations represented in that dataset, the median attacker dwell time was 14 days.
For a dedicated explanation, see Dwell Time Cybersecurity.
MTTD vs Mean Time to Acknowledge
An alert can be detected automatically but sit untouched in a queue.
Example:
10:00 — EDR generates high-severity alert.
10:04 — SIEM receives it.
10:37 — Analyst begins investigation.
Security technology detected the activity quickly.
But the SOC did not acknowledge it for 33 minutes.
That is a different problem.
Tracking both metrics helps determine whether delay comes from:
technology
or:
operations.
MTTD vs Mean Time to Contain
Mean Time to Contain measures another stage.
Example:
09:00 — Attack detected.
09:10 — Incident confirmed.
10:00 — Compromised account disabled and endpoint isolated.
Detection may have been fast, but containment required additional time.
See Mean Time to Contain (MTTC).
MTTD vs MTTR
MTTR is ambiguous.
Organizations use it to mean:
- Mean Time to Respond;
- Mean Time to Repair;
- Mean Time to Remediate;
- Mean Time to Recover.
Do not report “MTTR” to executives without defining it.
For your site’s dedicated response metric guide, see Mean Time to Respond.
Why MTTD Matters
A lower detection interval gives defenders more opportunity to act before attackers achieve their objectives.
The consequences of delayed detection can include:
- credential theft;
- privilege escalation;
- lateral movement;
- persistence;
- data exfiltration;
- ransomware deployment;
- destructive activity.
Attack speed makes this increasingly important.
Mandiant reports that some initial-access partners can hand access to another attacker group in less than 30 seconds, illustrating how quickly apparently minor activity can become a larger compromise.
Verizon’s 2026 DBIR also reports that vulnerability exploitation became the leading breach entry point in its dataset, accounting for 31%, while third-party involvement continued to rise.
This reinforces a simple operational lesson:
security teams cannot assume every intrusion develops slowly.
There Is No Universal “Good MTTD”
Your current FAQ says:
“High-performing organizations aim to detect threats within hours rather than days.”
That sounds reasonable, but it is too broad to be used as a benchmark.
A good MTTD for one environment could be unacceptable for another.
Consider:
Payment fraud
A few minutes may matter enormously.
Ransomware execution
Detection may need to happen in minutes.
Cloud administrator compromise
Minutes or hours can be critical.
Low-severity policy violation
A longer interval may be acceptable.
The better question is:
Does our detection speed match the risk and attack speed of each use case?
Risk-Based MTTD Targets
Instead of one universal number, establish targets by incident class.
Example:
| Incident type | Example internal target |
|---|---|
| Privileged account compromise | <15 min |
| Ransomware execution | <10 min |
| Critical server malware | <15 min |
| Cloud account takeover | <30 min |
| Suspicious outbound transfer | <30 min |
| Low-severity malware | <4 hrs |
These are illustrative targets, not industry standards.
Each organization should define its own thresholds.
Measure MTTD by Detection Source
A single enterprise-wide average may hide poor controls.
Segment detection by technology.
| Detection source | MTTD |
|---|---|
| EDR | 12 min |
| Identity | 19 min |
| SIEM | 31 min |
| Cloud logs | 58 min |
| Network detection | 24 min |
| User reports | 4.2 hrs |
| Vendor notification | 11 hrs |
Now the organization can see where investment is needed.
For example:
Cloud detection = 58 minutes
may indicate:
- missing logs;
- weak correlation;
- poor cloud-native detections.
Measure MTTD by Incident Severity
Another useful view:
| Severity | MTTD |
|---|---|
| Critical | 9 min |
| High | 18 min |
| Medium | 44 min |
| Low | 3.2 hrs |
Critical incidents should generally receive faster detection and escalation than low-risk events.
If the opposite occurs, detection engineering may be misaligned with business risk.
Internal vs External Discovery
One of the most valuable detection metrics is:
Who discovered the incident?
Possible sources include:
- your SOC;
- employee;
- customer;
- supplier;
- security researcher;
- law enforcement;
- attacker notification.
An organization whose serious breaches are frequently discovered by outsiders has a different problem than one whose SOC reliably detects them internally.
Track:
% internally detected
and:
% externally discovered
alongside MTTD.
The 2026 Threat Environment Makes Detection Harder
Detection is becoming more complicated because attackers increasingly target systems with weaker telemetry.
Mandiant notes that some adversaries are maintaining persistence in edge devices that often lack standard monitoring telemetry, contributing to longer dwell times in some investigations.
Common visibility gaps include:
- VPN appliances;
- firewalls;
- hypervisors;
- identity infrastructure;
- SaaS applications;
- unmanaged cloud workloads;
- network appliances.
An endpoint-only detection strategy is therefore insufficient.
7 Practical Ways to Reduce MTTD
1. Improve Continuous Monitoring
Security teams need visibility across:
- endpoints;
- identity;
- cloud;
- network;
- applications;
- critical infrastructure.
Tools may include:
- EDR;
- SIEM;
- identity threat detection;
- network detection;
- cloud-native security telemetry.
The objective is not to collect every possible log.
It is to collect the logs needed to detect meaningful threats.
2. Strengthen Detection Engineering
Default vendor detections are not enough.
Organizations should build detections around:
- privileged account abuse;
- suspicious authentication;
- impossible travel;
- token abuse;
- credential dumping;
- lateral movement;
- unusual administrative tools;
- large outbound data transfers;
- unexpected persistence.
Detection rules should reflect your environment.
3. Use Behavioral Detection Carefully
Behavioral analysis can identify deviations such as:
- administrator signing in from unusual infrastructure;
- user accessing systems never previously used;
- abnormal download volumes;
- unexpected service-account activity.
Behavior helps find attacks that do not match known malware signatures.
But behavior-based systems should be tuned carefully to avoid overwhelming analysts with false positives.
4. Correlate Alerts Into Incidents
A modern attack may generate several individually weak signals:
new device
suspicious login
privileged role change
large cloud download
Individually, each alert may appear moderate.
Together, they may indicate account takeover.
Correlation can shorten detection time by connecting related evidence automatically.
5. Centralize Critical Logs
Central visibility accelerates investigation.
Prioritize logs from:
- identity provider;
- Active Directory;
- EDR;
- firewall;
- VPN;
- cloud control plane;
- email security;
- critical SaaS;
- DNS.
NIST’s current incident-response guidance stresses integrating incident detection and response across organizational cybersecurity risk management.
6. Improve Alert Triage
More alerts do not necessarily mean better detection.
Alert overload can increase MTTD because analysts spend time reviewing low-value events.
Track:
- alerts per analyst;
- false positive rate;
- alert-to-incident conversion;
- queue age;
- time to acknowledge.
Retire low-value detections when appropriate.
Improve useful detections instead.
7. Define Clear Escalation Procedures
Detection is wasted if nobody acts.
For high-severity detections, define:
- who receives the alert;
- maximum acknowledgement time;
- incident owner;
- escalation path;
- legal/compliance escalation threshold;
- executive escalation threshold.
Your security plan should answer:
What happens during the first 15 minutes after a critical alert?
For the broader operational process, see Cybersecurity Incident Response Timeline.
Cybersecurity Time Detection Improvement Workflow
A useful improvement cycle is:
Collect
↓
Detect
↓
Validate
↓
Measure
↓
Find delays
↓
Tune
↓
Retest
This cycle should be repeated rather than treating MTTD improvement as a one-time project.
Do Not Optimize MTTD in Isolation
Imagine a SOC that lowers MTTD by creating thousands of very sensitive alerts.
Detection time improves.
But:
- false positives triple;
- analysts become overloaded;
- real incidents wait longer;
- containment gets slower.
The security program has not necessarily improved.
MTTD should be evaluated alongside:
- false positive rate;
- time to acknowledge;
- incident conversion rate;
- containment time;
- analyst workload.
Cybersecurity Time Detection Funnel
| Stage | Example metric |
|---|---|
| Telemetry generated | Logging coverage |
| Detection generated | Detection latency |
| Alert queued | Queue age |
| Analyst acknowledges | MTTA |
| Incident validated | Validation time |
| Containment begins | Escalation time |
| Threat contained | MTTC |
This makes it easier to identify where delay actually occurs.
MTTD and Incident Response
Detection is only the beginning.
A healthy sequence is:
attack → detection → validation → containment → eradication → recovery
A low MTTD combined with slow containment can still produce a serious breach.
NIST SP 800-61 Rev. 3 explicitly focuses on improving detection, response and recovery together rather than optimizing detection in isolation.
For the full lifecycle, see Cybersecurity Incident Response Timeline 2026.
MTTD and Regulatory Readiness
Detection speed can also affect regulatory readiness—but another distinction matters:
MTTD is not automatically the legal reporting clock.
For example:
SEC
The four-business-day Form 8-K Item 1.05 clock generally begins after a company determines a cybersecurity incident is material, not simply when an alert fires.
UK GDPR
The relevant 72-hour notification period is tied to awareness of a reportable personal data breach.
Other regulations use their own triggers.
That is why your incident timeline should preserve:
- detection;
- validation;
- awareness;
- classification;
- materiality.
See Cyber Incident Reporting Deadlines: US vs UK.
Example: Detection vs Regulatory Trigger
09:00 — EDR alert.
09:15 — SOC validates malware.
10:30 — Investigation identifies unauthorized access.
14:00 — Personal data compromise becomes reasonably certain.
Next day 09:30 — Public company determines incident is material.
These are separate timestamps.
Do not calculate all compliance deadlines from 09:00 simply because that was the first alert.
MTTD and the Data Breach Timeline
Reliable MTTD depends on reliable timestamps.
For each incident, record:
- estimated malicious activity start;
- first observable malicious event;
- first detection;
- analyst acknowledgement;
- incident validation.
Without those timestamps, your MTTD becomes guesswork.
Use Data Breach Timeline Template to standardize incident chronology.
Common MTTD Measurement Mistakes
1. Using Different Starting Points
One incident starts at compromise.
Another starts at first alert.
Another starts at confirmation.
The resulting average is meaningless.
2. Confusing MTTD With Dwell Time
They are related but not interchangeable.
3. Measuring Only Detected Incidents
This creates survivorship bias.
Incidents discovered months later or externally may radically change your understanding of detection performance.
4. Ignoring False Positives
Extremely aggressive detection can reduce apparent MTTD while overwhelming analysts.
5. Using Only the Mean
Use:
- mean;
- median;
- P90/P95;
- worst cases.
6. Comparing Your MTTD Directly With Vendor Statistics
Different studies use different:
- populations;
- definitions;
- incident types;
- measurement methods.
Benchmark carefully.
7. Assuming Tool Deployment Automatically Improves MTTD
Buying a SIEM or EDR is not enough.
Detection quality also depends on:
- telemetry;
- rules;
- staffing;
- triage;
- escalation.
What Does M-Trends 2026 Actually Tell Us?
Mandiant reports that global median dwell time increased to 14 days in its 2026 report, based on investigations conducted during 2025.
That statistic is useful because it demonstrates that stealthy attackers can still remain undetected for significant periods.
But it should be quoted accurately:
Mandiant global median dwell time: 14 days
not:
Average MTTD worldwide: 14 days.
Those are different statements.
What Does Verizon DBIR 2026 Tell Us?
Verizon’s 2026 DBIR reports that exploitation of vulnerabilities accounted for 31% of breach entry points in its dataset and had overtaken stolen credentials as the leading initial access vector.
It also reports substantial growth in third-party involvement.
That means detection programs should extend beyond endpoint malware monitoring to include:
- exposed services;
- vulnerability exploitation;
- supplier compromise;
- identity activity.
This is useful context for MTTD even though DBIR does not provide one universal MTTD benchmark for every organization.
A Practical MTTD Improvement Plan
Step 1 — Define the metric
Write down:
MTTD begins at ______ and ends at ______.
Do not proceed until that definition is clear.
Step 2 — Establish baseline
Measure at least:
- mean;
- median;
- P90.
Step 3 — Segment
Break results down by:
- severity;
- detection source;
- business unit;
- attack type.
Step 4 — Identify delay
Determine whether delay occurs in:
- telemetry;
- alert generation;
- correlation;
- triage;
- escalation.
Step 5 — Improve
Tune the specific bottleneck.
Step 6 — Retest
Compare results over time.
Example Quarterly MTTD Report
| Metric | Q1 | Q2 | Q3 |
|---|---|---|---|
| Mean | 62 min | 48 min | 36 min |
| Median | 33 min | 27 min | 19 min |
| P90 | 6.2 hrs | 4.1 hrs | 2.8 hrs |
| Critical incident MTTD | 22 min | 14 min | 9 min |
| External discovery | 21% | 16% | 11% |
That is far more informative than reporting:
MTTD improved 26%.
MTTD Questions for the CISO and Board
Senior leadership does not need every SOC alert.
But it should understand:
- Are critical incidents detected faster?
- Are some systems essentially invisible?
- Are detection delays improving?
- How many incidents are discovered externally?
- Which technologies produce the slowest detections?
- Does supplier compromise create visibility gaps?
- Are analysts overwhelmed?
For board-oriented metrics, combine MTTD with broader operational risk rather than presenting it alone.
Frequently Asked Questions
What is Mean Time to Detect?
Mean Time to Detect is the average elapsed time it takes an organization to detect security incidents according to a consistently defined starting and ending point.
What is the MTTD formula?
MTTD = Total Detection Time ÷ Number of Incidents
For example:
120 minutes total across 3 incidents:
MTTD = 40 minutes
What is a good MTTD?
There is no universal number.
A good target depends on:
- incident type;
- business criticality;
- available telemetry;
- threat model.
Critical account takeover may require a much shorter detection target than a low-severity policy violation.
Is MTTD the same as dwell time?
No.
MTTD is an organizational average metric.
Dwell time usually describes how long attackers remain in the environment before discovery/detection, often in external incident-response research.
Mandiant reported a global median dwell time of 14 days in M-Trends 2026, but that should not be treated as a universal MTTD benchmark.
Is MTTD the same as response time?
No.
Detection measures when the organization recognizes the threat.
Response covers actions after detection such as:
- validation;
- containment;
- remediation;
- recovery.
Should we use mean or median detection time?
Use both when practical.
The mean captures overall average performance.
The median reduces distortion from unusually long incidents.
Percentiles provide even better visibility into long-tail detection failures.
Does lower MTTD always mean better security?
Not automatically.
A low MTTD achieved by generating excessive false positives may degrade overall SOC performance.
Pair MTTD with:
- false-positive rate;
- time to acknowledge;
- containment time;
- workload.
How can MTTD be reduced?
Focus on:
- better telemetry;
- detection engineering;
- identity monitoring;
- alert correlation;
- central logging;
- triage;
- clear escalation.
Is NIST SP 800-61 Rev. 2 still current?
No.
NIST finalized SP 800-61 Rev. 3 in April 2025, and Rev. 3 supersedes Rev. 2.
Final Takeaway
Mean Time to Detect is useful—but only when it is defined and measured correctly.
The formula is straightforward:
total detection interval ÷ incidents = MTTD
The difficult part is establishing:
- a consistent starting point;
- reliable timestamps;
- comparable incidents;
- meaningful segmentation.
A mature detection program should therefore move beyond one average and track:
MTTD + median + P90/P95 + detection source + severity + external discovery
The strongest security teams do not ask only:
“What is our MTTD?”
They ask:
“Which attacks do we detect quickly, which remain hidden, and why?”
NIST’s current incident-response guidance reinforces that detection should be viewed as one part of the broader cybersecurity risk-management and incident-response lifecycle—not as an isolated scoreboard metric.
And current threat research shows why that matters: Mandiant continues to observe long-lived stealthy intrusions while also seeing attack hand-offs happen in seconds, and Verizon reports vulnerability exploitation becoming the leading initial access vector in its 2026 DBIR dataset.
MTTD is not about making a dashboard number smaller. It is about shortening the period in which attackers can operate without effective defensive action.
Primary External Sources
Use a concise source section at the end.
NIST SP 800-61 Rev. 3 — Incident Response Recommendations
NIST finalized Rev. 3 in April 2025 and it supersedes SP 800-61 Rev. 2.
Mandiant M-Trends 2026 Executive Edition
Mandiant reports 14 days of global median dwell time in its 2026 dataset and discusses both stealthy long-term persistence and very rapid attacker hand-offs.
Verizon 2026 Data Breach Investigations Report resources
Verizon’s 2026 DBIR reports vulnerability exploitation as the leading breach entry vector in its dataset.
