MITRE ATT&CK Coverage Mapping Guide: Measuring Detection Coverage Honestly

A green ATT&CK heatmap often says more about how generously a team scored itself than about what it can actually detect. Coverage mapping is the practice of recording, per ATT&CK technique, what data you collect, which detections you run and how well they have been shown to work. Done honestly, it tells a SOC where to invest next and tells leadership what risk remains; done badly, it creates false confidence. This guide explains how the ATT&CK v20 structure affects coverage maps, which free tools and Center for Threat-Informed Defense (CTID) resources help, how to score coverage with evidence, and the heatmap mistakes to avoid. It is for detection engineers, SOC managers and purple team leads who build or report coverage.

Key takeaways

• Separate visibility, detection and validation. Collecting the right logs, having a rule and having proved the rule fires are three different states and need three different scores.
• Coverage is per technique, per platform and per procedure. One PowerShell rule on Windows endpoints does not cover T1059.001 on servers you do not log, or the many ways the technique can be run.
• Map against the version you run. ATT&CK v20 (October 2026) uses detection strategies and analytics instead of the old data sources, and v19 split Defense Evasion into Stealth and Defense Impairment, so older layers need upgrading.
• Prioritise before you map. Score the techniques your relevant adversaries use and the choke points they depend on, not all 700 or so techniques and sub-techniques.
• Report with evidence and confidence, not a single percentage. A coverage number without a test date and data source behind it is an opinion.

What a coverage map is, and what it is not

A coverage map is an annotated view of the ATT&CK matrix. The ATT&CK Navigator, MITRE's open source tool for this, is deliberately generic: its documentation says it lets you colour cells, add comments and assign numerical scores to show "defensive coverage, red/blue team planning, the frequency of detected techniques or anything else". That flexibility is the problem. The tool will happily show any number you give it, so the meaning of each colour must be defined before anyone scores anything.

Comparing layers is where value appears: techniques in the threat layer with visibility but no detection are quick wins; techniques with detection but no validation are untested claims. See the MITRE ATT&CK Guide for Defenders for the framework basics.

How the ATT&CK v20 structure affects coverage maps

Recent releases changed the objects that coverage maps rely on. ATT&CK v20.0 was released on 13 October 2026, following v19 (28 April 2026) and v18 (28 October 2025).

• Detection strategies and analytics (v18): MITRE's v18 release notes say the detections in techniques "have been replaced with Detection Strategies", introducing Detection Strategy and Analytic objects and deprecating Data Sources. Each detection strategy (IDs such as DET0560) groups platform-specific analytics (IDs such as AN1543), and each analytic names log sources through data components and lists "mutable elements", the values you are expected to tune locally.
• Data components remain: in the v20 enterprise dataset all 38 data source objects are deprecated, while 106 data components are active and referenced by analytics as log sources. Coverage tools that score by data source therefore need a mapping step.
• Defense Evasion split (v19): the tactic was split into Stealth (TA0005) and Defense Impairment (TA0112). Impair Defenses was revoked by Disable or Modify Tools (T1685), and new techniques include Disable or Modify System Firewall (T1686), Exploitation for Defense Impairment (T1687), Safe Mode Boot (T1688), Downgrade Attack (T1689) and Prevent Command History Logging (T1690). A layer scored on v17 that shows Impair Defenses as green now points at a revoked object.
• Size: the v20 enterprise dataset has 15 tactics, 227 techniques and 479 sub-techniques, with 705 detection strategies and 1,770 analytics.
• Versioning: the Navigator can load past ATT&CK versions and has a layer upgrade interface that steps through each changed technique and lets you copy annotations forward. Use it at every major release instead of rebuilding by hand.

The detection strategy for Valid Accounts (DET0560) illustrates the new model: it has separate analytics for Windows, Linux, macOS, identity providers and containers, with mutable elements such as logon type, time window, geo-IP mismatch and service account scope. Covering T1078 on Windows says nothing about your identity provider or Kubernetes clusters. Score per analytic, or at least per platform.

Tools and community resources

Commercial SIEM, EDR and BAS platforms also tag content with technique IDs. Treat those tags as a starting point: a vendor rule tagged T1003.001 shows that a rule exists, not that it is enabled, tuned and fed with the right logs in your environment. See the Breach and Attack Simulation (BAS) Guide.

Scoring coverage honestly

Use a scale with definitions tied to evidence. DeTT&CT's detection scale is a good reference because each level states the expected false negatives, timing and evasion resistance: -1 none; 0 forensics or context only (logged, no detection); 1 basic signature covering a small part of the procedures; 2 fair (correlation rules, more aspects covered); 3 good (more complex analytics, real time, many known procedures); 4 very good (almost all known procedures, harder to evade); 5 excellent (all known procedures). Its visibility scale runs from 0 (none) to 4 (excellent). A simpler internal scale works if it keeps the same discipline:

• Score per scope: record the platform or system group each score applies to (DeTT&CT's applicable_to field does this). "Windows workstations: 3; Linux servers: 0" is honest; "T1059: 3" is not.
• Expire scores: validated scores decay to "untested" after a set period or after a major change to the log pipeline or detection.
• Record confidence and source: note whether a score came from testing, an incident, a vendor tag or analyst judgement.
• Sub-techniques count: do not mark a parent technique covered because one sub-technique is.

Prioritising what to map

Trying to score the entire matrix stalls most programmes. Start threat-informed:

• Adversary-driven: build a threat layer from the ATT&CK groups and campaigns that target your sector, plus your own incident history. See the Threat Actor Groups Guide.
• Choke points and prevalence: CTID's Top ATT&CK Techniques methodology weighs prevalence (from its Sightings data), choke points (techniques many attack paths pass through) and actionability (how many public analytics from MITRE CAR, Elastic, Sigma and Splunk, and how many CIS and NIST SP 800-53 mitigations, exist). It cites Rootkit (T1014) as a technique with no detections or mitigations in those repositories, where effort brings diminishing returns.
• Identity techniques: Valid Accounts (T1078 and its sub-techniques), Steal Application Access Token (T1528), Application Access Token (T1550.001) and Additional Cloud Credentials (T1098.001) are high-value for most cloud estates and are often scored only for user accounts, not service accounts. See the ITDR Guide.
• Crown jewels: weight techniques that reach your most important systems, such as OS Credential Dumping (T1003) on domain controllers or Data from Cloud Storage (T1530) on regulated data stores.

How to build and maintain the map

1. Agree definitions: publish the scoring scale, evidence rules, expiry period and which ATT&CK version and domains (Enterprise, ICS, Mobile) you map against.
2. Inventory data sources: list each log source with platform scope, retention and quality, and map it to ATT&CK data components. SMAP helps with sensor names; DeTT&CT's data source file can generate a rough visibility layer.
3. Tag detections in code: keep technique IDs in rule metadata in your detection repository (Sigma, KQL, SPL or vendor format) so layers are generated automatically, not maintained by hand in a spreadsheet. See the Detection Engineering Guide.
4. Build a threat layer and compare: use Navigator score expressions to produce a gap layer, for example techniques in the threat layer where detection is below 2.
5. Validate a sample first: pick ten high-priority techniques and test them with atomic tests, BAS or a purple team exercise before publishing any coverage figure. See the Purple Teaming Guide.
6. Publish with caveats: report the map with its version, date, scope and the share of scores that are validated.
7. Maintain on a cadence: regenerate layers on every detection deployment, revalidate quarterly for priority techniques, and run the Navigator layer upgrade at each ATT&CK release. If a pipeline change breaks a log source, automatically downgrade dependent scores; restore them only after a fresh test.

Where identity fits

Identity techniques are where coverage maps are most often overstated, because the same technique ID spans very different systems. Valid Accounts (T1078) covers domain accounts (T1078.002), local accounts (T1078.003) and cloud accounts (T1078.004), and its detection strategy has separate analytics for Windows, Linux, macOS, identity providers and Kubernetes. A rule on Windows logon events covers one of those five.

• Score human and non-human identities separately: service accounts, workload identities, API keys and OAuth applications behave differently from people and usually need different log sources (cloud control plane, IdP service principal sign-ins, Kubernetes audit logs).
• Check token techniques: Steal Application Access Token (T1528), Application Access Token (T1550.001), Web Session Cookie (T1550.004) and SAML Tokens (T1606.002) are frequently blank on maps because they need SaaS and IdP audit data rather than endpoint telemetry.
• Behavioural analytics count: many identity detections are anomaly models rather than signatures. Record them in the map with the same evidence rules. See the UEBA Guide and the Service Account Security Guide.

Decision guidance

• Small teams: skip whole-matrix scoring. Map the top 20 to 30 techniques from a threat layer, use the hosted Navigator for non-sensitive layers and record evidence in the rule repository.
• Mature SOCs: use DeTT&CT or an equivalent YAML or database model, generate layers in CI from detection metadata, and feed BAS or purple team results back automatically.
• Navigator versus spreadsheet: spreadsheets are fine for evidence, but generate visual layers from them; hand-coloured matrices drift from reality.
• Vendor coverage claims: when evaluating products, ask for coverage per platform, the analytic logic, the data required and test results, and test a sample in your own environment. See the SIEM Buyer's Guide.
• Executive reporting: show progress on the priority set (for example "18 of 25 priority techniques validated on Windows and identity provider") rather than a matrix-wide percentage.

Detection and measurement

• Validated coverage of priority techniques: share of threat-layer techniques scored 3 or higher, per platform.
• Visibility gap: number of priority techniques with no required data collected.
• Evidence freshness: share of validated scores tested in the last 12 months (or your chosen period).
• Test pass rate: percentage of purple team or BAS procedures detected, and median time to alert.
• Score drift: scores downgraded after log pipeline failures or rule changes, and time to restore.
• Incident alignment: techniques seen in real incidents or hunts that the map showed as covered but where no alert fired. Track these closely; they measure how honest the map is. See the Threat Hunting Guide.

Common failure patterns

• Counting rules, not capability. A heatmap colours a technique green because a rule tagged with its ID exists, even if the rule is disabled, untuned or missing its log source. Zscaler analyst Kyle Rainey's widely cited write-up on ATT&CK pitfalls makes the underlying point: coverage is neither binary nor static, so measure the efficacy of what you can detect rather than claiming completeness.
• Technique-level green for a procedure-level rule. One command line pattern for a broad technique is scored as full coverage. Variants run differently and are missed.
• Ignoring identity and SaaS platforms. Maps focus on endpoints, while attackers use valid cloud accounts. In the Snowflake customer breaches, attackers logged in with infostealer credentials to accounts without MFA and ran ordinary-looking queries; a map that showed Valid Accounts as covered by endpoint logon rules would have said nothing about that data platform.
• Stale versions. Layers built on old ATT&CK versions still show revoked techniques such as Impair Defenses and miss new ones such as T1685.
• Alerting on everything. Teams write noisy alerts for discovery techniques to turn cells green. Some techniques are better served by logging for context and hunting than by alerts, as both DeTT&CT's "forensics / context" level and Rainey's pitfalls note.
• Percentage as the headline. "We cover 78% of ATT&CK" invites the question "of which procedures, on which systems, proved when?" and usually has no answer.

Where it maps in frameworks

Practitioner checklist

• Publish a scoring scale that separates visibility, detection and validation, with evidence rules and an expiry period.
• Pin the ATT&CK version and domain, and run the Navigator layer upgrade at each release.
• Build a threat layer from relevant groups, campaigns, incidents and CTID Top ATT&CK Techniques before scoring.
• Score per platform or system group, and never credit a parent technique for one sub-technique.
• Store technique IDs in detection rule metadata and generate layers automatically.
• Map log sources to ATT&CK data components and the analytics in each detection strategy.
• Validate priority techniques with purple team or BAS tests and record dates and results.
• Downgrade scores automatically when a log source or rule breaks.
• Report validated coverage of priority techniques, not a matrix-wide percentage.

Standards and references

• MITRE ATT&CK: Updates October 2025 (v18)
• MITRE ATT&CK: Updates April 2026 (v19)
• MITRE ATT&CK: Detection of Valid Account Abuse Across Platforms
• MITRE ATT&CK: ATT&CK Navigator
• MITRE Center for Threat-Informed Defense: Top ATT&CK Techniques
• MITRE Center for Threat-Informed Defense: Mappings Explorer
• MITRE Center for Threat-Informed Defense: Sensor Mappings to ATT&CK
• Rabobank CDC: DeTT&CT

Related NHI Mgmt Group resources: Detection Engineering Guide · Threat Hunting Guide · SOC Maturity Model · Detection Engineering Maturity Model · UEBA Guide