MITRE ATT&CK coverage is not the same as attack risk

At a glance

What this is: This analysis argues that MITRE ATT&CK coverage is a poor proxy for identity attack risk because matrix shading does not show which real campaigns would succeed in a given environment.

Why it matters: IAM, PAM, and NHI teams need risk views that map to actual attack paths and likely targets, not just detection coverage, if they want to prioritise controls and account hardening.

Context

MITRE ATT&CK coverage is a language for detection and research, but it is not the same thing as identity attack risk. A shaded technique grid can show that a control claims to cover a technique, yet still leave unanswered which identity paths are exposed, which accounts are most attractive to attackers, and whether the likely campaign would actually work in the environment.

For identity security teams, the gap matters because risk is determined by the intersection of attacker behaviour, account exposure, and privilege path, not by how many matrix cells are checked. A useful coverage model has to explain the real-world attack, the likely target profile, and the operational conditions that make success more or less likely.

Key questions

Q: Why is MITRE ATT&CK coverage not enough to assess identity risk?

A: Because ATT&CK shows technique coverage, not whether a real attack campaign would succeed in your environment. Identity risk depends on reachable accounts, workflow weaknesses, privilege paths, and attacker fit. A product can look broad on a matrix and still leave the most exposed identities vulnerable to the campaigns that matter most.

Q: How should security teams evaluate identity attack exposure instead of coverage cells?

A: Start with the real attack you expect, then assess whether the target profile, account type, and access path exist in your environment. That approach shows which users an attacker would hit first, which workflows are vulnerable, and what controls actually change the likelihood of success.

Q: What are the signs that ATT&CK reporting is hiding identity risk?

A: A warning sign is when coverage reports are full of technique counts but cannot name the accounts, workflows, or campaign types most likely to be targeted. If the report does not change hardening priorities, verification steps, or privileged access design, it is not telling you where risk sits.

Q: What is the difference between technique coverage and attack exposure?

A: Technique coverage asks whether a control maps to a known adversary method. Attack exposure asks whether that method can actually succeed against your identities, workflows, and privilege structure. Exposure is the operational question defenders need because it connects adversary behaviour to the accounts that would be hit first.

Technical breakdown

Why ATT&CK coverage is not a risk metric

MITRE ATT&CK describes adversary tactics and techniques, which makes it valuable for threat research, detection engineering, and common vocabulary. It does not measure whether a specific environment is exposed to a given campaign, whether the identity paths are reachable, or whether the likely target accounts are protected. In identity security, that distinction matters because a technique can be “covered” in a product sense while still remaining operationally viable against a real account, workflow, or help-desk process. Coverage is an artefact of feature mapping; risk is a property of the environment and attacker fit.

Practical implication: treat ATT&CK as a reference model, then test actual identity exposure separately against your highest-risk accounts and workflows.

Identity attack likelihood depends on target profile, not matrix cells

A campaign becomes relevant when the attacker’s playbook matches the organisation’s identity conditions. For example, a social-engineering path aimed at help-desk reset procedures depends on who can reset accounts, what verification steps exist, and which users are socially and operationally attractive to target. The matrix alone cannot tell you which users are likely to be hit first or whether a technique will succeed against finance, IT, or executive accounts. That is why risk evaluation must start from the attack shape and the target population, then work back to the defensive controls that actually change the odds.

Practical implication: rank identity risks by attacker fit to specific user groups, privileged workflows, and account-reset paths rather than by generic technique coverage.

Plain-language attack mapping is better than shaded cells for defenders

The operational problem is not whether a technique exists on a grid, but whether defenders can explain the attack in terms the whole security team can use. A matrix cell does not tell a CISO what a Scattered Spider-style help-desk reset would do in their environment or which finance accounts sit in its path. Plain-language attack mapping makes the relevant control question visible: which accounts, which workflows, and which approval paths are most exposed. That turns identity security from abstract coverage accounting into decision support for prioritisation.

Practical implication: describe coverage in attack terms that map to accounts, workflows, and access paths, then use that narrative for control prioritisation.

NHI Mgmt Group analysis

ATT&CK coverage is a detection taxonomy, not a measure of identity risk. The framework is useful when teams need a shared language for adversary technique mapping, but it breaks down as soon as the question becomes which identities are actually exposed. A shaded matrix does not tell practitioners whether a help-desk reset, credential theft, or privilege path is reachable in their environment. The implication is that identity programmes need a separate exposure model, not a bigger ATT&CK grid.

Coverage-based reporting can overstate security by confusing theoretical detectability with practical resistance. A product can map to many techniques and still leave a narrow set of accounts, workflows, or reset paths highly exposed. That is a governance problem because leaders make prioritisation decisions on incomplete evidence. The practitioner conclusion is simple: ask which attacks fit your identity profile, not how many cells a vendor can colour in.

Identity attack fit: the more useful concept here is whether a real-world campaign matches your account structure, verification process, and privilege distribution. An attacker does not care that a technique is represented on a matrix if the actual path is blocked by workflow design or, conversely, left open by weak account governance. Teams should evaluate fit at the level of target profile and access path, because that is where risk becomes real.

Visibility alone does not answer the first-order identity question: which accounts would an attacker hit first? That is the part ATT&CK coverage obscures. The right lens is not whether a technique is known, but whether the organisation can name the real attacks it can withstand and the ones it cannot. Practitioners should push reporting toward attack-specific exposure statements rather than coverage percentages.

For identity security, the unit of account should be the attack path, not the technique grid. ATT&CK remains useful as a common taxonomy, but decision-making improves only when teams translate that taxonomy into plain-language exposure statements about users, help-desk workflows, and privileged access paths. That shift improves prioritisation, supports better board-level discussion, and makes identity risk legible across the security team.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Research and Survey Results

What this signals

Attack-path thinking is more useful than matrix thinking for identity programmes. Teams should stop treating ATT&CK coverage as a proxy for security posture and instead measure whether the organisation can name the specific identity attacks it would withstand or lose. That shift improves prioritisation across IAM, PAM, and NHI governance because it ties controls to reachable accounts and real campaign patterns.

Coverage language becomes meaningful only when it is translated into account-level exposure. In practice, that means asking which user groups, reset workflows, and privileged paths sit on the attacker’s shortlist. The value is not in more coloured cells, but in clearer decisions about where identity hardening will reduce actual attack success.

For practitioners

• Reframe coverage reports around real attack scenarios Replace technique-cell summaries with plain-language scenarios such as credential theft, help-desk takeover, and privilege-path abuse so leaders can see which attacks matter in their environment.
• Map attacker fit to specific identity populations Identify which user groups, reset workflows, and privileged accounts are most likely to be targeted first and score them by exposure and business reach.
• Test whether reported coverage changes defender decisions Ask whether a coverage claim would change account hardening, verification steps, or privileged workflow design. If it would not, it is reporting noise rather than risk insight.
• Separate detection mapping from exposure assessment Use ATT&CK for threat-language consistency, but maintain a separate assessment of reachable identity paths, privileged accounts, and likely campaign success.

Key takeaways

• ATT&CK coverage is useful for common adversary language, but it does not tell defenders which identity attacks are actually likely to work.
• The practical question is not how many techniques a product maps to, but which accounts, workflows, and privilege paths are reachable first.
• Identity teams should turn coverage reporting into attack-specific exposure analysis so prioritisation reflects real-world campaign fit.

Key terms

• Attack Coverage: Attack coverage is the extent to which a security program can simulate, detect, and respond to known attacker techniques across relevant environments. In practice, it measures whether controls and test cases align with real intrusion paths, not just whether threat intelligence has been read and cataloged.
• Identity Threat Exposure: Identity Threat Exposure is a weakness in identity infrastructure that attackers can exploit to gain credential access, escalate privileges, or move laterally. The term covers misconfigurations, legacy features, and insecure practices that do not look like classic software vulnerabilities but still create direct paths to compromise.
• Target Profile: The Target Profile defines the cybersecurity outcomes an organisation wants to achieve based on its risk strategy, mission needs, and expected changes. It reflects the desired future state rather than the current one. Teams compare it with the Current Profile to identify gaps, prioritise remediation, and build a realistic action plan.
• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.