MTTD, MTTC and coverage: the SOC metric blind spot

At a glance

What this is: This is a SOC metrics analysis showing that MTTD, MTTC and MTTR can mislead when teams measure only worked incidents rather than the full alert queue.

Why it matters: It matters to IAM and security practitioners because detection coverage affects whether identity abuse, NHI compromise or human-account misuse is found before blast radius expands.

By the numbers:

• Crogl's 2026 State of SecOps research found the average enterprise SOC takes in 4,330 alerts a day and investigates 37% of them.
• The average enterprise SOC investigates 37% of its alerts, leaving 63% unworked and outside MTTD reporting.

👉 Read Crogl's analysis of MTTD, MTTC and MTTR and the SOC coverage gap

Context

Mean time to detect, contain and respond are only useful when the measurements reflect the whole detection pipeline, not just the incidents a team had time to investigate. In SOC operations, coverage is the governance gap that turns flattering averages into weak control signals, especially when alerts accumulate faster than analysts can clear them.

For identity-heavy environments, that gap matters because stolen credentials, over-privileged accounts and compromised service identities often begin as low-signal alerts. When those alerts sit unworked, an attacker can move from initial access to privilege abuse before the SOC has a true detection window. Crogl's analysis makes the starting position look common rather than exceptional.

As an operational metric story, this is less about a single tool and more about how teams define the unit of detection work. The article's core argument is typical of mature SOC debate: averages alone do not tell you whether your programme can actually see the queue.

Key questions

Q: What breaks when MTTD is measured without alert coverage?

A: MTTD can look strong while the SOC ignores a large share of the queue. That creates a false sense of detection performance because the metric only reflects worked incidents. Coverage is the missing denominator, and without it leaders cannot tell whether threats were found quickly or simply not examined at all. Security teams should report both numbers together.

Q: Why does low alert coverage increase security risk?

A: Low coverage leaves weak signals uninvestigated, which gives attackers more time to operate before the SOC sees a pattern. In identity-heavy environments, that can mean stolen credentials, token abuse or privilege escalation remain invisible until damage forces a review. The risk is not just slower response, but a longer dwell window for every missed alert.

Q: How can security teams reduce MTTD without hiring more analysts?

A: Shrink the wait between an alert firing and a human investigating it. The most effective way is to enrich and triage alerts automatically on arrival so analysts receive a documented finding instead of an untouched queue. That approach improves coverage, shortens delay, and keeps detection performance tied to actual operational capacity.

Q: What should SOC leaders report to show detection performance honestly?

A: Report MTTD, MTTC and MTTR next to the percentage of alerts investigated in the same period. That combination shows whether speed gains came from better detection operations or from simply working a smaller slice of the queue. It is the cleanest way to keep the metric meaningful for leadership decisions.

Technical breakdown

Why MTTD can understate real detection delay

MTTD is an average over incidents that were already identified as incidents, which means it excludes alerts that fired but never received investigation. That creates a survivorship problem for SOC reporting. If a team clears only the easiest or most visible cases, the metric improves even while hidden dwell time grows. Mean time to detect also sets the ceiling for MTTC and MTTR because containment and response cannot begin before detection. In practice, this means the metric is only as honest as the alert population it covers.

Practical implication: Track MTTD alongside queue coverage so detection performance cannot look better simply because fewer alerts were worked.

Coverage as the missing denominator in SOC metrics

Coverage is the share of alerts that are actually investigated. It is not the same as alert volume, and it is not the same as incident count. When coverage is low, MTTD tells you how fast the team works the portion it chooses to examine, not how fast the programme detects threats across the full operational queue. That makes coverage a control variable, not a vanity metric. A SOC that investigates every alert on arrival will usually expose more weak signals, but it also shortens the time an attacker can hide inside the unworked backlog.

Practical implication: Measure investigation coverage as a first-class SOC control, not as a side note to detection time.

Autonomous investigation and the queue bottleneck

Automation only reduces MTTD when it removes the wait between alert creation and analyst review. Scripted playbooks help, but they still assume someone has already chosen what to automate. Autonomous investigation changes the operating model by collecting context from connected tools as soon as the alert lands, then returning a documented finding for the analyst. That reduces human queue pressure rather than just speeding up individual cases. The mechanism matters because the bottleneck is usually not detection logic, but analyst availability relative to alert arrival.

Practical implication: Use automation to shrink the time-to-investigate gap, not just to accelerate selected response steps.

NHI Mgmt Group analysis

Coverage, not just speed, is the decisive SOC control variable. A low MTTD can coexist with a weak detection programme if the team only investigates a minority of alerts. That means governance has to measure the queue, not only the cases that reached closure. For identity-led attacks this is especially relevant, because the first sign of abuse may be a low-priority auth event or privilege anomaly. The practitioner conclusion is simple: report detection coverage beside time-to-detect, or the metric will flatter the programme.

MTTD without queue context can mask identity abuse windows. Credential theft, service-account misuse and over-privileged access often generate early warnings that are easy to defer. If those warnings are never investigated, dwell time becomes the attacker-controlled variable. This is where IAM and SOC disciplines intersect: identity signals only help if they are not buried under operational backlog. The practical conclusion is to treat unworked identity alerts as a governance failure, not just an SOC nuisance.

Autonomous investigation is a workflow design response to alert inflation. The article's strongest implication is not that analysts should work harder, but that the investigation model must scale differently. When every alert can be enriched on arrival, teams reduce backlog pressure without assuming perfect staffing growth. That matters for NHI and human identity monitoring alike, because both depend on timely interpretation of weak signals. The practitioner conclusion is to redesign the queue before the queue redesigns your detection window.

Detection metrics must evolve from incident averages to operational truth. MTTD, MTTC and MTTR still matter, but only when they are paired with the share of alerts that were actually examined. This aligns with NIST Cybersecurity Framework 2.0 thinking about detect and respond outcomes, and it fits the broader move toward measurable security operations. The practitioner conclusion is to build reporting that answers whether the SOC saw the environment, not just whether it closed the tickets it touched.

What this signals

SOC teams should expect MTTD reporting to come under more scrutiny as buyers and boards ask whether the metric covers the full queue or only the alerts that were eventually worked. The control question is shifting from how fast a team closes incidents to how much of the operational signal it actually sees.

Detection coverage debt: when a SOC repeatedly reports healthy time-to-detect numbers without measuring the backlog, it is accumulating a governance debt that later appears as dwell time. That debt is most visible when identity events, token misuse or credential anomalies sit unworked for long periods.

For identity-heavy programmes, the next planning step is to connect SOC queue management to NHI Lifecycle Management Guide and NIST Cybersecurity Framework 2.0 outcomes. That pairing helps teams link detection quality to identity governance rather than treating them as separate disciplines.

For practitioners

• Measure alert coverage alongside MTTD Publish the percentage of alerts investigated in the same dashboard as MTTD, MTTC and MTTR so leadership can see whether the SOC is measuring the whole queue or only the worked subset.
• Rebaseline metric definitions Fix the start and stop points for detection, containment and response, then keep those definitions stable across reporting periods so trend lines stay comparable.
• Automate first-pass investigation Use enrichment and autonomous investigation to reduce the wait between alert arrival and analyst review, especially for repeated identity and authentication signals.
• Prioritise identity-linked alerts for queue discipline Treat authentication failures, token anomalies and privilege-abuse signals as backlog-sensitive cases because delayed review extends the dwell time of compromised identities.

Key takeaways

• MTTD can look healthy even when the SOC misses most of the queue, so coverage must be reported beside it.
• The operational risk is dwell time, because unworked alerts give attackers more time to abuse credentials and privileges.
• Teams should improve queue coverage first, then use automation to shorten the gap between alert arrival and investigation.

Key terms

• Mean Time To Detect: Mean Time To Detect, or MTTD, measures how long it takes to identify a security issue after it begins. It is a useful SOC performance indicator because AI should shorten this interval only if it improves signal correlation and analyst comprehension.
• Mean time to contain: Mean time to contain is the average time it takes to limit an incident after it is detected or suspected. It is a practical resilience metric because it reflects how quickly teams can reduce attacker reach, protect critical identities, and prevent one compromise from spreading further.
• Mean Time To Respond: Mean Time To Respond, or MTTR, measures how long it takes to contain or remediate an incident after detection. In AI-assisted SOCs, MTTR improves only when automation is accurate, bounded, and able to support safe escalation paths.
• Detection Coverage Analysis: The process of mapping which attacker techniques are well covered, thinly covered, or completely uncovered by current detections. In practice, it turns detection engineering into a measurable input for hunting, letting teams rank what to investigate next instead of guessing.

What's in the full article

Crogl's full blog covers the operational detail this post intentionally leaves for the source:

• How the MTTD, MTTC and MTTR formulas are applied across an actual SOC reporting period
• Crogl's explanation of why coverage belongs next to time-to-detect in executive reporting
• The autonomous investigation model used to reduce alert wait time and backlog pressure
• The supporting research context behind the 4,330 daily alerts and 37% investigation rate

👉 Crogl's full post explains the detection metric blind spot and the autonomous investigation model in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and identity lifecycle control. It gives security practitioners a practical foundation for connecting identity operations to broader security outcomes.