MTTD, MTTC and coverage: the SOC metric blind spot

At a glance

What this is: Crogl says MTTD, MTTC and MTTR can overstate SOC effectiveness when the queue of uninvestigated alerts is ignored.

Why it matters: SOC and identity teams need coverage alongside detection metrics because unworked alerts can mask the real time attackers remain undetected.

Context

Mean time to detect is only meaningful if the organisation is actually looking at the events that matter. In SOC operations, the metric can improve on paper while uncovered alerts continue to age in the queue, which makes coverage a governance problem rather than just a workflow issue. For identity-adjacent alerting, that matters because missed signals around accounts, tokens, and access anomalies can persist until the attacker has already moved.

The article’s central point is that the denominator matters as much as the clock. If only a fraction of alerts are investigated, MTTD describes a managed subset, not the full operational reality. That makes the conversation less about speeding up a single workflow and more about whether the SOC is measuring the share of its alert volume it actually handles.

Key questions

Q: How should security teams measure MTTD without hiding uninvestigated alerts?

A: Measure MTTD on top of a separate coverage metric that shows what share of the alert queue was actually investigated. If the denominator only includes worked incidents, the metric can improve while threats remain untouched. The safer approach is to report detection timing, queue volume, and investigation coverage together so the operational picture stays honest.

Q: Why does low alert coverage distort SOC performance reporting?

A: Low coverage means the SOC is averaging only the alerts it had time to touch, not the alerts that actually existed. That can make detection, containment and response look faster than they are because the hardest or noisiest events are excluded from the sample. Coverage reveals whether the metric reflects the environment or just the manageable subset.

Q: What are the signs that a SOC is measuring only a partial alert workload?

A: Common signs include improving MTTD while backlog age rises, analysts clearing routine alerts but deferring complex ones, and incident volumes that do not align with alert intake. When the queue grows faster than investigators can process it, the metric is tracking throughput on a subset rather than end-to-end detection performance.

Q: Should organisations prioritise detection tuning or response automation first?

A: Start with the detection paths that already lead to the highest-risk outcomes, then automate only the response actions you can safely reverse or audit. If tuning is too weak, automation amplifies bad decisions. If response is absent, good detections still arrive too late to matter.

Technical breakdown

Why MTTD stops being representative when alerts go unworked

Mean time to detect is an average over incidents that were identified and processed, so it only reflects the subset that entered the investigative path. If alerts fire but are not reviewed, the clock keeps running outside the metric. That creates a structural blind spot: a SOC can report a low MTTD while a separate backlog of unworked alerts hides the threats that matter most. In governance terms, the metric is bounded by investigation coverage, not just by detection logic.

Practical implication: measure the full alert queue, not only completed investigations, when judging detection performance.

How MTTC and MTTR inherit the same coverage problem

Containment and response begin after detection, so they cannot correct for missed alerts upstream. A SOC that detects only the easiest or most visible incidents may still show respectable containment and response averages while more serious events sit outside the sample entirely. That means MTTC and MTTR can look operationally healthy even when alert handling is selective. The technical issue is denominator bias, not just slow response. Once the investigative funnel is incomplete, downstream clocks describe a partial workload.

Practical implication: pair containment and response metrics with alert handling rate so selective investigation does not distort performance reporting.

Why coverage is the control variable behind detection latency

Coverage is the share of the alert stream that receives investigation at all. It matters because detection latency is not only a speed problem, it is a workload allocation problem. If the queue routinely outpaces analyst capacity, the organisation is no longer measuring how quickly it finds threats, but how quickly it gets to the alerts it had time to touch. For SOCs that support IAM and NHI monitoring, this is especially important because access abuse often appears first as a noisy anomaly rather than a clean incident.

Practical implication: treat coverage as a core SOC control, not an optional efficiency metric.

NHI Mgmt Group analysis

Coverage is the missing SOC control because detection metrics are only as honest as the queue they sample. MTTD, MTTC and MTTR describe performance after an alert has entered the investigative path, which means they can improve even while unworked alerts accumulate outside the measurement boundary. That is a governance failure, not a dashboard quirk. Practitioners should judge whether the SOC is measuring the whole alert population or only the portion it can clear.

Detection latency is increasingly a workload problem, not just an alert-quality problem. The article shows that the bottleneck often sits between signal generation and human review. That shifts the conversation from tuning individual detections to managing investigative capacity, queue discipline, and coverage as operational controls. For identity programmes, the implication is direct: missed access anomalies and token misuse can remain invisible if no one ever reaches the alert.

Coverage blindness creates a false sense of security in identity-linked monitoring. When access events, authentication anomalies, and service-account misuse are buried in an overfull queue, the SOC may believe it is improving because the subset it handles is shrinking in age. In reality, the unexamined share may be where the real risk lives. Practitioners need reporting that distinguishes handled alerts from merely generated alerts.

Named concept: metric denominator drift. This article exposes a pattern where the metric looks better because the underlying population being measured quietly narrows. That matters across security governance because any detection KPI can be gamed by shrinking the sample rather than improving control performance. The practical conclusion is to align reporting with full queue visibility, not only incident-level averages.

For identity and NHI monitoring, coverage is the first-order issue and MTTD is the second-order proof. If the SOC cannot keep pace with alert volume, identity abuse may be detected only after the attacker has already expanded access or triggered business impact. That makes coverage a prerequisite control for meaningful detection metrics. Practitioners should treat queue coverage as evidence that the metric can be trusted at all.

What this signals

Metric denominator drift: SOC teams should assume that any detection KPI can become misleading once the sample narrows to only the alerts analysts had time to review. The programme response is to manage queue coverage as a first-class control, because metrics without full-population visibility reward selectivity rather than resilience.

In identity-heavy environments, access abuse often starts as a noisy anomaly that competes with a high-volume alert stream. If those signals sit in the unworked portion of the queue, the SOC can be late without realising it, so detection reporting needs to reflect investigative reach, not just incident averages.

For practitioners

• Track alert coverage alongside MTTD Report the share of alerts actually investigated in the same view as mean time to detect so the metric cannot hide unworked queue volume.
• Define consistent metric boundaries Fix start and stop points for detection, containment and response, and keep those definitions stable across reporting periods.
• Measure backlog age and arrival rate Monitor how quickly alerts accumulate versus how quickly analysts clear them so queue growth is visible before it distorts performance reporting.
• Prioritise identity-linked alerts for handling Ensure access anomalies, service account abuse and token misuse are not left in the unworked fraction of the queue.

Key takeaways

• MTTD, MTTC and MTTR can all improve on paper while a growing slice of alerts never gets investigated at all.
• Coverage is the control variable that shows whether detection metrics reflect the whole queue or only the easy subset.
• SOC leaders should pair timing metrics with alert-handling rate so reporting cannot reward selective 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.
• Alert Coverage Rate: The proportion of generated alerts that are actually investigated or dispositioned by the SOC. It is a useful operational measure because it shows whether security teams are realising the value of their detection stack or leaving a backlog of unworked findings that weakens response quality.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for teams that need practical governance language for machine identities, access control, and lifecycle risk.