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

What ATT&CK coverage can and cannot tell you

MITRE ATT&CK is a technique and adversary-behaviour catalog, not a verdict on whether your identity controls are actually resilient. It helps you ask, “Can we detect or block this method?” but not, “Would this campaign succeed against our reachable accounts, privilege paths, and operational weaknesses?” That gap matters most when identity exposure is shaped by real-world workflows rather than a checklist of techniques.

ATT&CK is strongest when you need to map observed or anticipated attacker behaviour to defensive detection and response. It is weaker as a standalone measure of identity risk because identity risk is conditional: the same technique can be low impact in one environment and high impact in another depending on account ownership, approval paths, credential hygiene, delegation, and where privilege is actually concentrated.

A matrix score can therefore create false comfort if it is treated as coverage of the thing that matters most, namely attack feasibility in your environment. A product may advertise broad ATT&CK alignment and still leave weakly governed accounts, stale access paths, or overprivileged non-human access untouched.

Why identity risk needs a different lens

Identity risk asks whether an attacker can move from a technique to a successful outcome through accounts, roles, tokens, secrets, or delegated access that are truly reachable. That means the question is not only whether a tactic exists in the catalog, but whether the identity surface exposes a usable path from initial access to privilege, persistence, or lateral movement.

This is why controls around Identity Security Posture Management matter alongside ATT&CK mapping. Posture tells you where the risky identities are, which entitlements are excessive, and which accounts are stale or misconfigured. Technique coverage alone does not reveal whether the attacker can actually exploit those conditions.

Identity risk also depends on governance and lifecycle, not just detection. If a service account was never retired, a contractor account was never removed, or an integration token has broader reach than intended, the campaign path can remain open even when security tooling claims wide technique coverage.

How to judge ATT&CK against real attack paths

The useful test is whether your defensive view connects techniques to reachable assets and privilege. A campaign only matters if the attacker can use the identities that exist, the workflow approvals that are weak, the secrets that are exposed, and the trust relationships that the environment actually allows.

That is why practitioners should pair ATT&CK with identity-specific analysis, including who owns the account, how the credential is issued and rotated, whether the privilege can be escalated, and whether the access path crosses environments. NHI lifecycle management is especially relevant where non-human accounts, secrets, and service identities can be reused or left active after the original business need has changed.

ATT&CK is also a better input to prioritisation than to assurance. It can help you say which techniques deserve coverage, but it cannot tell you which identities are most exposed, which campaigns are most likely to succeed, or which privilege path would produce the worst business impact if abused.

Risk and Threat Considerations

ATT&CK-only assessment can miss the highest-risk identity failures because it measures technique breadth, not environment-specific exploitability. The main exposure is false confidence: teams may believe they are covered while the actual attack path remains open through stale accounts, overprivileged access, shared credentials, or weak delegation.

Failure mechanism: An attacker uses a known technique that is nominally “covered” in the matrix, then pivots through reachable identities or unused privileges that were never tested against the real workflow and trust boundaries in the environment.

Impact: The result can be credential abuse, privilege escalation, lateral movement, or long-lived persistence even though the security program appears mature on paper.

Practitioner Guidance

What to verify: Test ATT&CK coverage against concrete identity paths, not just control statements. Confirm which accounts are reachable, which secrets are valid, and which privilege escalations are actually possible in production.

What to measure: Track the proportion of high-value identities with standing privilege, unrotated secrets, orphaned access, or cross-environment reach. Those measures are more decision-useful than a simple technique-coverage tally.

Common mistake: Treating “mapped to ATT&CK” as equivalent to “resistant to compromise.” That shortcut hides the difference between knowing a technique exists and proving that it cannot succeed against your identity estate.

Practitioner takeaway: Use ATT&CK to frame attacker behaviour, then use identity analysis to determine whether that behaviour can actually land, move, and persist in your environment.

Related resources from NHI Mgmt Group

• How should security teams use breach and attack simulation to assess MITRE ATT&CK coverage before expanding detections?
• What is the difference between prompt injection risk and identity abuse in agents?
• How should security teams use MITRE ATT&CK in identity programmes?
• How can ATT&CK help teams evaluate identity detection coverage?