The MITRE ATT&CK coverage gap, and why your real number is lower than the dashboard says
Measured MITRE ATT&CK coverage sits far below what most teams report. What a coverage number counts, how a broken detection rule stays green, and how to audit yours.
Most security teams have a MITRE ATT&CK coverage number, and it usually stands in for their whole detection posture. Most of those numbers are optimistic. CardinalOps read configuration metadata out of live production SIEMs for its 2025 State of SIEM Detection Risk report and found detections for 21% of MITRE ATT&CK techniques, in estates where the data already being collected could have covered 90%. It also found that 13% of the rules that did exist were silently broken.
The shortfall is not a data shortfall. It is the distance between what a coverage dashboard counts and what would actually fire next Tuesday.
If you read nothing else: a coverage number almost always counts rules that are mapped to a technique, not rules that are proven to fire on it. Mapping is a spreadsheet exercise. Firing depends on telemetry arriving, fields matching, filters not having quietly widened, and somebody noticing when they do. The first is easy to report. The second is the one an attacker meets.
What a MITRE ATT&CK coverage number actually measures
There are three different questions hiding inside one percentage, and they get further apart the longer an estate runs.
| The question | What it takes to answer honestly | What a coverage view usually reports |
|---|---|---|
| Do I have a detection rule mapped to this technique? | a mapping file and an enabled rule | yes — this is the number on the wall |
| Would that rule fire if the technique were used? | the right telemetry, matching fields, sane exclusions, a recent test | rarely |
| Would anyone triage it if it did fire? | a tier 1 queue with capacity, an owner, a clock | almost never |
The first question produces the figure people quote in board packs. The second is detection engineering. The third is triage and escalation, and it is the one that decides whether a detection was worth building. A technique whose rule fires into a queue nobody works is covered in the same sense that a smoke alarm with a flat battery is fitted.
Counting rules rather than techniques makes it worse. Six rules aimed at credential dumping is one technique covered, not six, and a dashboard that totals rules will flatter a portfolio that is deep in two tactics and empty in five.
How a broken detection rule stays green
This is the finding worth sitting with. Broken rules do not announce themselves, because in a detection stack the failure state and the healthy state produce identical output: nothing.
A rule stops working for ordinary reasons, none of which look like an incident at the time.
- A source stops sending. A collector is decommissioned, a forwarder fails after a reboot, a subscription lapses.
- A field is renamed. A platform upgrade or a schema change moves the attribute a rule keys on, and the query now matches nothing rather than erroring.
- An exclusion widens. Somebody suppresses a false-positive path during a busy week, the filter is broader than intended, and the rule survives in name only.
- An index or retention change moves the data out from under the search.
- A parser changes shape, so the values are present but no longer in the form the rule expects.
Each of these leaves a rule that is enabled, mapped, green on the coverage view, and dead. A rule that has not fired in ninety days is either watching a technique nobody has used against you or it has stopped working, and nothing in the average toolchain tells those two states apart. The difference is paid in dwell time. That is why CardinalOps's 13% is more alarming than the 21%: 21% coverage is a gap you know about, while 13% of rules silently broken is a gap you have already told yourself you closed.
Why more data does not move the number
The instinct on seeing a low coverage figure is to onboard another log source. The CardinalOps finding argues against it directly: the ingested data could already support detections for 90% of techniques. The constraint is detection engineering capacity, not collection.
This matters because ingestion is the thing your platform bills you for, and rule writing is the thing it does not. A coverage-driven onboarding programme reliably produces a bigger invoice and roughly the same percentage, because the new source arrives with no use cases written against it, no field mapping validated, and nobody freed up to do either. Adding sources is the visible move. Proving that what you already collect is being used is the one that shifts the number.
How to audit your own MITRE ATT&CK coverage
You can do a defensible version of this in an afternoon, without buying anything.
- Export the mapping and count techniques, not rules. One technique with six rules counts once. The result is your ceiling, and you should expect it to be well below what your last report claimed.
- Put a last-fired date against every enabled rule. Sort ascending. Everything silent for a quarter goes on a suspect list — not condemned, just no longer assumed to work.
- Check the telemetry each rule depends on is still arriving, in the field shape the rule expects. This catches the rename and parser failures, which are the quietest of the five.
- Test a sample. A handful of safe atomic tests per tactic, run deliberately, will tell you more than any mapping exercise. Fire them and confirm an alert actually lands in the tier 1 queue.
- Read your exclusion lists as if you were an attacker. Every suppression is a documented way not to be seen; some were meant to be temporary.
- Write down the techniques you cannot cover, and why. A recorded blind spot with a reason beats a green tile that is not true; auditors and regulators respond far better to the former, and so does whoever inherits the estate. It also gives threat hunting somewhere to start.
Do that once, and you have a real MITRE ATT&CK coverage figure. It will be lower than the old one and it will be worth something, which is the trade.
Coverage is a floor, not the finish line
Then the second problem arrives, and it is the reason coverage projects stall halfway. Every technique you genuinely cover adds volume to a backlog that a person still has to piece together by hand. Microsoft and Omdia's vendor-commissioned State of the SOC 2026 puts it at about a fifth of weekly capacity lost to manual correlation in two thirds of SOC teams. Improving detection without improving decision buys you more evidence that nobody has time to read.
That is the layer Seculogik works on. It sits above the detection stack you already run — Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, Cortex XDR, Elastic, OpenSearch, ClickHouse, Wazuh, or a connector we build if yours is missing — and turns what fires into a short list of qualified cases, each with a verdict, a readable decision trace, a clock and an owner.
Nine independent checks examine every alert and must agree on one verdict, and the case keeps the reasoning. The mechanics are on the correlation engine page, and the argument for why that layer is the hard part is in why the correlation engine is our crown jewel.
What we ship against the coverage problem
Two things, and both are deliberately unglamorous.
72 MITRE-mapped detection packs, importable from a screen. They ship with every edition, including the free one, so a new estate has real technique coverage on day one rather than an empty rule set and a quarter of detection engineering. You can see which technique each pack addresses before you import it, which means your coverage claim starts out attributable.
A verdict layer that makes the alerts worth generating. Alerts become cases, cases carry verdicts and owners, and the queue ranks on what a case has become rather than how it started. Our AI analyst module, SIROC, argues its hypotheses in the open and has its cited evidence checked against the case's own alerts. Gartner's formal position is that there will never be an autonomous SOC; we agree with it. What we ship is bounded autonomy: anything destructive stops at an approval gate with a person behind it.
Some honesty to go with that, because it is the same discipline as the audit above. We are pre-GA. We have no customers to name, no ANSSI or CSPN qualification, no third-party pentest report and no SLA. We publish no detection-accuracy figure of our own — the numbers in this piece are CardinalOps's and Omdia's, and we have told you who measured them and how.
Where to go next
If your coverage number has never been audited, audit it before you buy anything. If it has, and the answer was that your detections fire fine and your analysts still cannot keep up, that is the problem we built for. Start with the platform overview, check which edition matches your estate, or book a demo and bring a week of your own alerts.