I carried a mostly-green heatmap into a quarterly detection review at a fintech. Three weeks later, an attacker used rundll32.exe to call comsvcs.dll by ordinal number and wrote the LSASS dump with a non-.dmp extension. Our T1003.001 cell was green because we had a rule keyed on the MiniDump export string and .dmp files. The rule never fired. The technique we had marked as covered was the exact technique that got us.
I built that map myself, in good faith, following the standard advice for MITRE ATT&CK mapping. The orthodoxy I walked in with was that a high coverage percentage meant we were covered. After that incident I rebuilt how my team maps, and the first thing we threw out was the percentage.
In Brief:
- A green technique cell built on one rule shows that an analytic exists, not that it catches the technique, and MITRE's own guidance says a single analytic is unlikely to cover a technique.
- Enterprise security information and event management (SIEM) systems ship detections for roughly a fifth of ATT&CK techniques while ingesting data that could cover nine in ten, by CardinalOps' count. Inflated scores come from counting mapped moves before validating detections.
- Honest mapping happens at procedure and variant granularity, weighted by the adversaries that actually target your sector.
- Use the map to feed the detection backlog from incident response (IR) postmortems and purple-team results. A map that lives in a board slide gets the same treatment as most red-team findings: filed and forgotten.
What a coverage score is actually counting
Most dashboards define ATT&CK coverage as the share of framework techniques for which at least one detection exists, but MITRE's Design and Philosophy paper explains why technique coverage is hard to reason about when each technique may have many procedures. That's true and useless, because it counts rule existence. Existence says nothing about whether the rule fires and which procedure variants it catches. It also says nothing about which layer of the environment it watches. MITRE's own heatmap guidance treats green as provisional, and says a single analytic is unlikely to provide sufficient coverage for any given technique. Coverage and detection health are separate measurements, and the detection engineering pillar already covers that split, so I won't rebuild it here.
The production data shows how far the two drift apart. Enterprise SIEMs have detections for an average of 21% of ATT&CK techniques while ingesting data that could cover 90%, per CardinalOps' fifth annual report. Picus ran 160 million attack simulations for its Blue Report 2025 and found only 14% generated alerts; 54% of attacker activity in the same dataset was logged with no alert at all. A score that can't distinguish those states isn't measuring detection.
The moves that turn ATT&CK mapping into a vanity number
Every inflated coverage number I've audited followed the same path of least resistance when leadership asks for a single number. Teams inflate maps when they treat them as proof and stop treating them as a work queue.
Counting a technique green off a single thin rule
Jared Atkinson shows the mechanics in a SpecterOps capability abstraction example: a rule keyed on Invoke-Kerberoast colors T1558.003 green while missing Rubeus entirely, even though both tools rely on the same KerberosRequestorSecurityToken class. One tool signature colors one green cell while most implementations of the technique stay invisible. MITRE's own guidance cautions teams not to stop at the first way an adversary performs a technique.
Thin rules also frequently die in production. The same CardinalOps report found 13% of production SIEM rules are broken and will never fire. Misconfigured data sources accounted for part of the problem, and missing fields and parsing errors did the rest. Those rules still count in a naive map, so the score includes detections that cannot alert on anything.
Mapping to tactics when someone asks for coverage
When someone asks whether we cover credential access, answering at the tactic level is the fastest way to say yes. Tactic columns are easy to color and each one hides dozens of techniques and hundreds of procedures underneath. Anton Chuvakin calls these maps a palliative measure because they skip the technique-level detail that determines whether coverage is real.
Teams also inflate scores by changing the denominator quietly. Many techniques aren't network-addressable at all, so a vendor claiming 92% coverage should be asked which denominator the percentage uses. Internal teams do the same thing when they quietly scope the map to endpoint-detectable techniques. And the framework itself shifted underneath these maps in April 2026: ATT&CK v19 split Defense Evasion into the Stealth and Defense Impairment tactics, so any tactic-level map built earlier is already misaligned.
Chasing the easy techniques to pad the breadth number
Writing rules for whatever is cheapest to detect grows the green area fastest, and it aims at the wrong outcome. MITRE's Get Started guidance says not to pursue 100% because every organization faces a different threat profile. Red Canary explicitly deprioritizes some techniques, noting that File Deletion (T1107) is low-specificity and poorly suited for detection. Breadth-chasing also buys alert fatigue: Forrester's Allie Mellen wrote that vendors detecting on every technique have the potential to be noisy, with high false positive rates and excessive alerting.
Meanwhile the techniques adversaries actually use go unwatched. CardinalOps found organizations had detections for only 4 of the 10 most commonly observed ATT&CK techniques. That's the breadth trade in one line: the map gets wider while the paths attackers walk stay dark. That is why the next backlog item should follow adversary behavior.
How we keep the map honest
We changed map entries and priority logic, then moved the output to the teams that consume it. That forced the map to describe inspectable evidence and stripped wished-for confidence out of coverage claims.
Map to procedures and variants
After the LSASS miss, I replaced the one cell with procedure rows for our T1003.001 entry: Mimikatz sekurlsa::logonpasswords, Task Manager dumps, ProcDump, and comsvcs.dll via rundll32, which CISA treats as distinct procedures requiring distinct rules. The DFIR Report later documented the same trick in Akira intrusions, with MiniDump invoked by ordinal (#+000024) and dumps written to \Windows\Temp\ as .sys, .docx, and .avhdx files. The variant that beat us was not exotic. Sigma supports ATT&CK sub-technique labels, so we use it for variant rows and reserve each sub-technique tag for its claim scope.
We also score each row for how easily an adversary evades it with the Summiting the Pyramid levels: Level 1 for ephemeral values like hashes and filenames, up to Level 5 for invariant behaviors an attacker can't change without abandoning the technique. In Navigator we use numeric scores with a gradient that replaces green fill, and the comment field carries rule names so the tooltip tells a reviewer what actually sits behind a cell. That keeps a score from hiding whether the backing analytic is a filename match, a tool signature, or a behavior.
Weight the map by the adversaries that actually hit our sector
I work in fintech, and M-Trends 2026 still ranks the financial sector among the most-targeted, so those intrusions define our priority list before any framework math does. We combine the sub-techniques Mandiant reports most often with Red Canary's top ten across 1,700 customer environments, which surfaces techniques like Cloud Accounts (T1078.004) and Email Forwarding Rule (T1114.003). Several of those live in identity and SaaS telemetry, which is exactly where programs built on rebadged cloud hygiene stop looking.
Mechanically, we keep one Navigator layer per threat report, combine them with score expressions, and overlay the result against a detection layer generated from DeTT&CT, which scores visibility and detection quality separately. Techniques scoring high on the adversary layer and low on ours are the backlog, in order. The Center for Threat-Informed Defense (CTID)'s Top ATT&CK calculator adds a useful third input: it scores prevalence and choke points, then factors in actionability. That keeps us from spending a sprint on a technique nobody can realistically detect.
Let the map drive the backlog, not the board deck
Two inputs update our map: IR postmortems and purple-team results. Every postmortem that exercises our incident response plan now ends with procedure rows added to the map, detected or missed, and the misses become backlog items with the incident attached as justification. Purple-team findings enter the same way, sorted with a simple gap taxonomy: white for untested, red for missing logs, orange for logs without a rule, green for validated. Orange items go straight to detection engineering; red items go to the logging owner first, because a rule without data is a decoration.
We stopped reporting the percentage upward as an outcome. In managed purple-team data, most red-team findings are never formally reviewed by blue-team defenders, and a coverage map that exists for a slide meets the same end. Ours lives next to the backlog, and Navigator lets each technique cell point at the tickets and rules behind it.
What the map is good for once you stop scoring it
Once the percentage is gone, the map earns its keep as a prioritization tool and a shared vocabulary with intel and IR. It also records what we've actually validated. It needs quarterly maintenance because the framework moves underneath it: recent releases replaced detection text notes with structured Detection Strategies and Analytics, and Enterprise now carries DETO697 Detection Strategies with platform-specific event IDs. That structure sits closer to procedure level than anything ATT&CK shipped before, and it's our reference baseline now.
The map I'd bring into that same review today has more yellow and red than green, and I trust it more than the one that looked finished. When someone asks for our coverage percentage, I give them a procedure count for the ten techniques most likely to hit us instead. If you want one thing to do this week: take your most-attacked technique, list every documented procedure under it, and count how many your rules would catch when run by an attacker who read the same DFIR reports you did. That count is the honest starting point.
Frequently asked questions about MITRE ATT&CK coverage
How do you measure MITRE ATT&CK coverage accurately?
Score data visibility and detection quality as separate values per technique, which is what DeTT&CT's YAML administration files do, and map at procedure granularity below technique IDs. Use validation testing to set the level for a technique, because a rule's tag only records the claim.
Is 100% MITRE ATT&CK coverage possible?
No, and MITRE's own guidance says not to attempt it because not every technique applies to every organization. A University of Illinois study also found many techniques aren't realizable as endpoint detection rules at all. Prioritize depth on the techniques in your threat profile.
How many detections per technique is enough?
There's no universal number, and MITRE's Design and Philosophy paper poses the question without resolving it. A couple of stable, validated rules give more confidence than a pile of untested ones, and a focused set of well-tuned detections across your priority techniques beats a large noisy set.
Should detections be mapped to techniques or sub-techniques?
Sub-techniques at minimum, since Red Canary found they remove ambiguity about the scope of detection for a given technique. Adversaries operate at the procedure level below that, so track variant rows under each sub-technique you claim.
What's the difference between an attack being logged and being detected?
Logging means the evidence landed somewhere; detection means a rule fired and a person got told. The Picus Blue Report 2025 found 54% of activity was logged while only 14% generated alerts. A useful convention scores these separately: green for high-confidence detection, yellow for logged only, red for blind spot.