Follow MITRE ATT&CK detection coverage is the ratio of adversary techniques your SOC can detect, validated against the technique set your threat model prioritizes, on the current framework version.
A coverage percentage means nothing without its denominator and proof method. Validated coverage counts techniques where a deployed detection rule fires against its required data source, divided by the techniques your SOC has prioritized, on ATT&CK v19 (released 2026-04-28). Every gap between that definition and the number on your slide is where the measurement breaks down. This page gives the method, the failure modes, and the questions that separate a vendor’s library figure from the coverage you actually run.
How do I measure my organization’s MITRE ATT&CK detection coverage?
Five steps, each measured per tactic, on ATT&CK v19:
- Inventory your deployed detection rules.
- Map each rule to ATT&CK technique IDs it covers.
- Confirm the required log source for each mapped technique is collected and passing its contract gates: freshness, null-rate, and field-semantics. A source that flows but fails its contract does not count.
- Prove each rule fires against a real or simulated test event. Tools: Atomic Red Team, MITRE Caldera, AttackIQ.
- Compute the ratio per tactic.
Step 3 is where most programs quietly lose ground: a log source can be technically ingested while its null-rate or schema drift makes the detections above it unreliable.
Step 4 matters because a rule that has never fired might never fire, whether from a logic error, a parser change, or a renamed field. Tools like ATT&CK Navigator, or a coverage-audit product like Prime Hunt, support the mapping and validation.
Count a technique that spans two tactics once per tactic, which is ATT&CK Navigator‘s default. This keeps percentages comparable across sources.
What does an ATT&CK coverage percentage actually count?
It counts techniques, not sub-techniques or procedures, and each carries different data dependencies.
T1078 (Valid Accounts) needs identity and authentication telemetry. Its cloud sub-technique T1078.004 (Cloud Accounts) adds cloud control-plane logs joined to the identity provider. A rule written against generic authentication logs alone leaves T1078.004 uncovered, so it covers only part of Valid Accounts.
A defensible program measures against its prioritized technique set, states the denominator, and calls the difference.
What’s the difference between a detection content vendor’s claimed ATT&CK coverage and the coverage actually deployed and validated in my environment?
Four independent measurements exist. They are not interchangeable, and only the last one describes what your SOC detects.
| Coverage type | What it counts | Who reports it |
|---|---|---|
| Library | Techniques with at least one rule available in a vendor’s content catalog, unattached to any environment | The vendor |
| Deployed | Techniques with a mapped rule installed and enabled in your SIEM or XDR | Your detection engineering team |
| Collected | Techniques whose ATT&CK-required data sources are actively ingesting and passing contract and quality gates | Your SOC platform or data team |
| Validated | Deployed rules proven to fire against real or simulated technique execution, through atomic testing or adversary emulation | Your SOC, via purple team or atomic testing |
Coverage-analytics tools like CardinalOps and Prime Hunt reconcile claimed mappings against your live Splunk, Elastic, or Microsoft Sentinel environment, where the library-to-validated gap becomes visible.
Which ATT&CK techniques can I not detect because of the logs I am not collecting?
Detection depends on data. Without the required data source collected, no detection fires, regardless of how many rules you own.
Map each prioritized technique to the data components its ATT&CK detection strategy uses (ATT&CK v19.2; version 18 replaced per-technique data sources with detection strategies, analytics, and data components), then reconcile against what your environment actually collects. A technique with no collected source scores zero.
| Technique | ATT&CK v19.2 detection strategy and data components | Log source in practice | Priority |
|---|---|---|---|
| T1110 Brute Force | DET0463: User Account Authentication (DC0002) | Identity provider auth logs (Okta, Microsoft Entra ID) | Tier-0 |
| T1059 Command and Scripting Interpreter | DET0516: Process Creation (DC0032), Command Execution (DC0064) | EDR and endpoint process telemetry | Tier-0 |
| T1071 Application Layer Protocol | DET0444: Network Traffic Content (DC0085), Network Traffic Flow (DC0078) | Network sensor, proxy, and DNS logs | Tier-1 |
Rank missing sources by the coverage each adds, weighed against ingest volume, licensing, parser effort, retention cost, and SLO reliability.
Prime Hunt runs a data audit that maps the log sources you actually collect to ATT&CK and lists the techniques with no telemetry behind them.
How do I find and close gaps in my MITRE ATT&CK detection coverage?
Close a gap by deploying a rule and proving it fires against a collected source. Adding a rule to a catalog does not close a gap.
- Build a heatmap on ATT&CK v19 using ATT&CK Navigator.
- Prioritize by threat model and which data sources already pass their gates.
- Source or author the rule.
- Validate it fires end to end using Atomic Red Team, MITRE Caldera, or AttackIQ.
- Re-measure.
What changes when ATT&CK releases a new version?
The denominator changes. Recompute.
ATT&CK v19 (initially released April 28, 2026) split the former Defense Evasion tactic into two new tactics, Stealth and Defense Impairment. A percentage computed before that split cannot compare to one after, because the taxonomy changed, not only technique counts.
Re-map to the new structure, recompute per tactic, and publish the delta. Do not relabel the old number.
How should I report ATT&CK detection coverage to our board?
Report validated coverage, not library size. Three metrics belong in the board package:
| Report line | What it shows | Owner |
|---|---|---|
| Validated coverage per collected source | Techniques proven to fire, grouped by the log source they depend on | Detection engineering |
| Gap list | Prioritized techniques with no firing rule or no collected source, each with a named owner | SOC manager |
| Time-to-coverage | Median and P90 days from technique publication to a deployed, proven detection, by technique class | SOC manager |
Give the board three questions for any vendor: what is the coverage denominator, which log sources does it assume are collected, and which ATT&CK version is it computed on.
How long should it take my SOC to have a detection in production after a new attack technique goes public?
Measure time-to-coverage: from technique or procedure publication (t0) to a detection deployed and proven to fire in production (t1).
Track median and P90 by technique class, since a commodity technique and a novel procedure carry different windows. Set the target based on your own program maturity. A published vendor turnaround time describes that vendor’s pipeline, not yours; SOC Prime’s published figure is a 24-hour SLA for detection content against emerging threats.
Where this does not hold
A coverage percentage cannot demonstrate detection effectiveness when any of its inputs are unknown: whether each source passes its gates, whether each rule has fired, whether the denominator is a real threat-model set. A number that cannot confirm all three describes a catalog, not a defended environment.
Coverage measurement checklist
- Rules inventoried and mapped to ATT&CK technique IDs (v19).
- Required data source for each mapped technique collected and passing freshness, null-rate, and field-semantics gates.
- Each rule proven to fire against a real or simulated execution.
- Denominator: techniques prioritized for your threat model.
- Coverage computed per tactic, each cross-tactic technique counted once per tactic.
- Missing sources ranked by coverage added against ingest volume, licensing tier, parser effort, retention cost, and SLO reliability.
- Board report shows validated coverage per source, gaps with owners, and time-to-coverage.
- Coverage recomputed and the delta published on every ATT&CK version change.
FAQ
How do I measure my organization’s MITRE ATT&CK detection coverage?
Inventory deployed rules, map each to ATT&CK technique IDs, confirm each required data source is collected and passing quality gates, prove each rule fires against a test event, and compute the ratio per tactic on ATT&CK v19. ATT&CK Navigator, Atomic Red Team, and MITRE Caldera support the mapping and validation steps. Prime Hunt supports coverage audit across SIEM environments.
How do I find and close gaps in my MITRE ATT&CK detection coverage?
Build a heatmap of current coverage against your prioritized technique set, not the full ATT&CK matrix. Closing a gap means deploying a rule against a collected data source and proving the rule fires.
Which ATT&CK techniques can I not detect because of the logs I am not collecting?
Map each prioritized technique to its ATT&CK-required data source, then reconcile against the sources your environment actually collects. Any technique whose required data source is not collected scores zero regardless of rules owned. Rank missing sources by the coverage they unlock and the cost to ingest.
How long should it take my SOC to have a detection in production after a new attack technique goes public?
Track time-to-coverage: the interval from technique publication to a detection deployed and proven to fire in production. Measure median and P90 by technique class. Set the target based on your program maturity, not a vendor benchmark.
What is the difference between a vendor’s claimed ATT&CK coverage and validated coverage in my environment?
A vendor’s library figure counts techniques with at least one rule in the catalog. Validated coverage counts only techniques where a deployed rule fires against a collected data source in your environment. The buyer’s number is always the validated one.
How should I report ATT&CK detection coverage to our board?
Report three metrics: validated coverage per collected source, a prioritized gap list with named owners, and time-to-coverage for new techniques. Give the board three qualifying questions for any vendor number: what denominator, which collected log sources, and which ATT&CK version.
What changes when ATT&CK releases a new version?
The denominator changes. A percentage computed on a prior version is a different number. Re-map rules to the new taxonomy, recompute per tactic, and publish the delta. ATT&CK v19 (released 2026-04-28) split Defense Evasion into Stealth and Defense Impairment, making pre-v19 numbers incomparable without recomputation.
Is 100 percent ATT&CK coverage achievable or meaningful?
Some techniques require data sources your environment does not collect. Others describe procedures no single rule can detect. Expanding collection carries ingest volume, licensing, and retention cost. A defensible program targets its prioritized technique set and states the denominator rather than pursuing a total that has no operational definition.
Related reading
- Attack Chains: See the Full Story Behind Every Threat (August 2026)
- MITRE Attack Flow v3.0.0 (October 2025)
- Uncoder AI Automates MITRE ATT&CK Tagging in Sigma Rules (April 2025)
