Research across 14,652 detections shows why nearly half need attention, and what to measure instead of detection count.
We assessed 14,652 detections across the organizations included in our research. On average, 47% of detections in these organizations need attention. Yet every one of those detections still shows up as “deployed” in a coverage dashboard.
The control every other investment depends on
Detection is the control every other defensive investment depends on. When prevention fails, and at some point it always does, detection determines whether an intrusion becomes a contained event or a material incident.
Yet detection is also the control organizations are least able to prove works.
For years, the industry has measured detection strength by counting rules and tools. Deployed is not the same as protected.
The sample includes both customer-authored rules and vendor-managed detections across SIEM, endpoint, cloud, identity, email, and network tooling. Unlike studies limited to SIEM rule analysis, this data reflects detections across all detection-generating tools in the environment, including the vendor-managed detections that organizations consume but do not author.
Primarily a drift problem rather than an authorship problem
Across the average environment in the installed base, nearly half of all detections require intervention to function as intended.
This is primarily a drift problem rather than an authorship problem. Detections that were correct when written decay as the telemetry and environment beneath them change.
They fall into five failure modes.
Logic bugs. The detection runs, but its logic does not do what its author intended: wrong operators, broken parsing, conditions that can never be true. It will not fire when the technique it targets is used.
Missing telemetry. The detection is syntactically healthy but references data sources that stopped flowing, were never onboarded, or changed format. It runs against silence.
Wrong tables and data sources. The detection queries a table or index that does not contain the events it needs, a subtle failure that looks healthy in every dashboard.
Duplication. Multiple detections cover the same behavior with slight variations, multiplying alert volume and maintenance burden without adding coverage.
Noise. The detection fires so often, with so little precision, that analysts have learned to ignore it. A detection nobody trusts is operationally equivalent to no detection at all.
The critical characteristic all five share: they are invisible to inventory-based reporting. Every one of these detections shows up as “deployed” in a coverage dashboard.
Counting detections tells leadership nothing about whether the organization can actually detect.
Most of the detection surface
Industry analysis of detection health has focused overwhelmingly on the SIEM, because SIEM rules are the detections security teams write and can inspect. But the SIEM is a minority share of the modern detection surface. Endpoint platforms, cloud security tools, identity providers, email gateways, and network sensors all ship their own detections, and collectively they generate most of what lands in the queue.
This creates a problem the industry rarely names: most of the detection surface can’t be tuned by the people who depend on it.
How do you fix a noisy endpoint detection when the vendor controls the logic? You can’t edit it. You can’t see inside it. Your options are to suppress it entirely (trading noise for a blind spot) or let it keep flooding the queue and train your analysts to ignore it. Both outcomes degrade the defense, and every SOC lives with hundreds of these untouchable detections.
Detection health must be measured and managed across the entire stack, because that is how adversaries experience the defense. An attacker does not care whether the gap is in the SIEM or the endpoint product. Neither should the measurement.
The threat you saw coming
Threat intelligence tells organizations who is targeting them and how.
Across the organizations included in our research, average threat coverage was 63%, measured against each organization’s own threat landscape: the adversaries, campaigns, and TTPs its threat intelligence identified as relevant.
The figure measures how much of that intel-derived threat landscape had corresponding operational coverage through detections, hunts, or compensating visibility.
That means more than a third of the threats these organizations had already identified as relevant had no corresponding operational coverage.
The gap is not a knowledge failure. These are threats the organization’s own intelligence has already identified as relevant. It is an operationalization failure: intelligence arrives as reports, feeds, and briefings, and the work of translating it into detection logic, hunting hypotheses, and coverage decisions is manual, slow, and perpetually behind.
Intel is consumed; it is far more rarely operationalized.
The result is the most avoidable category of blind spot in security: the threat you saw coming and never built a defense against.
One in three relevant techniques
Across the organizations included in our research, an average of 64% of relevant MITRE ATT&CK® techniques were covered.
This is not coverage of the full ATT&CK framework. For each organization, we scoped the measurement to the techniques relevant to its specific threat landscape, technology stack, tools, and controls. Techniques targeting infrastructure the organization does not operate, or not associated with adversaries relevant to that organization, were excluded from the denominator.
That scoping matters in both directions. It makes the number more honest than raw framework coverage, which penalizes organizations for techniques that do not apply to them. But it also makes the remaining gap harder to excuse: roughly one in three techniques that apply to the organization’s environment and that relevant adversaries are known to use has no reliable detection.
These are not exotic corner cases. They are the documented tradecraft of the actors each organization’s own intelligence says to expect.
Read that number next to the 47%. The true detection posture is the intersection of what is covered and what actually works. A technique “covered” by a detection with a logic bug or missing telemetry is not covered.
Why the gaps persist
The 63% and the 64% describe blind spots. The reason they persist is not a knowledge gap or a tooling gap. It is the operating model.
Closing them means coordinating threat intelligence, attack paths, exposure data, hunts, detection gaps, and missing telemetry, simultaneously, across every tool, continuously rather than periodically. No team, at any size or skill level, can run that loop through tickets, meetings, and handoffs at the speed the threat landscape now moves. This is why intel goes unoperationalized, hunts stay periodic, and blind spots persist for months after the intelligence that revealed them has arrived.
The operating model is broken, and it needs to be fixed. We have written separately about why context dies as work moves between threat intelligence, threat hunting, detection engineering, investigation, and remediation, and about what an operating model that holds those functions together looks like.
As agentic adversaries compress the time defenders have to adapt, security teams need to know which detections work, which threats remain uncovered, and how quickly intelligence becomes protection. That requires threat intelligence, exposure data, hunting, and detection engineering to operate as one continuous system, not as siloed functions connected by tickets and quarterly reviews.
What to measure, and what to change
Report coverage as verified working detections mapped to relevant techniques. Treat any detection that can’t be shown to fire correctly as a gap.
Inventory and assess the full detection surface, including vendor-managed detections you can’t edit. That is where most of the queue comes from.
Establish a control point before the queue. Whether through platform capability or process, create the ability to refine, deduplicate, contextualize, and suppress detections across all tools before they consume analyst capacity. The architectural answer is a detection layer that sits before the queue; the approach Conifers built into CognitiveSOC™. When a detection needs tuning that can’t be done at the source, because the vendor owns the logic, the tuning is applied at the detection layer instead. This is a strategic layer driven by the detection engineering team, not another triage pass on the analyst queue. Triage manages the consequences of bad detections, one alert at a time; the detection layer fixes the detections themselves, so the queue improves at the source for every alert that follows.
Track the percentage of intel-identified threats with corresponding operational coverage, and the time from intelligence to operationalized defense.
Prioritize hunts by what is reachable (especially edge devices outside EDR coverage) and what is valuable. Run hunts iteratively until they produce either evidence or a detection. A hunt that finds nothing but produces a high-fidelity detection for a previously uncovered technique has directly moved the coverage numbers.
Every hunt, investigation, and incident should feed detection improvements. If lessons aren’t becoming detections, coverage is standing still while the threat landscape moves.
This is the flywheel that closes the gap: intelligence defines what matters, exposure defines where to look, hunting validates what is true in this environment, and detection engineering makes the answer permanent. And it only works if run continuously. A flywheel spun once a quarter is just another periodic review.
The bottom line
The industry has spent a decade measuring detection by volume: rules deployed, alerts generated, log sources onboarded. This data shows why that measurement failed. Nearly half of deployed detections need attention, a third of the known threat landscape is uncovered, and a third of relevant adversary techniques have no reliable detection, and all are invisible to inventory-based reporting.
Detection posture is not what is deployed. It is what is proven to work, against the threats that are coming, across every tool in the stack, and it’s only as current as the organization’s ability to continuously find its gaps and close them.
The full report, The Detection Blind Spot, is at conifers.ai/white-papers/the-detection-blind-spot.
Tom Findling is CEO and co-founder of Conifers, where he works on CognitiveSOC™, the agentic AI SOC platform behind Resilient Cyber Defense. He wrote the research report this piece draws on. More from Tom.