How should security teams use MITRE ATT&CK in identity programmes?

Why This Matters for Security Teams

MITRE ATT&CK is most useful in identity programmes when it shifts the conversation from “what failed” to “how an adversary progressed.” Identity events such as token theft, session hijacking, privilege escalation, and account misuse are often scattered across IAM, endpoint, SaaS, and cloud logs. ATT&CK gives those teams a shared attacker-behaviour model, which makes it easier to validate controls, tune detections, and prioritise response around likely next moves.

This matters even more where non-human identities are involved, because NHIs often outnumber human identities by 25x to 50x in modern enterprises and are frequently over-privileged or poorly rotated, as documented in the Ultimate Guide to NHIs. Security teams should also distinguish ATT&CK mapping from generic alert tagging: the value is in connecting identity telemetry to escalation, persistence, and lateral movement paths that attackers actually use. NHI Management Group’s analysis of 52 NHI Breaches Analysis shows how often identity control gaps become breach enablers rather than isolated misconfigurations. In practice, many security teams encounter ATT&CK gaps only after a token or service account has already been used to move laterally, rather than through intentional control validation.

How It Works in Practice

Security teams should map identity-centric detections to ATT&CK techniques that describe adversary behaviour, then use those mappings to test whether controls actually interrupt the chain. For example, authentication anomalies can be aligned to initial access or valid account use, excessive token issuance to credential access, and unusual privilege grants to privilege escalation. The point is not to force every IAM event into ATT&CK, but to create a consistent language for SOC, cloud, and identity teams.

A practical workflow usually looks like this:

• Classify identity events by attacker objective, not by product source.
• Map authentication, token, session, and role changes to ATT&CK techniques that reflect escalation, persistence, and lateral movement.
• Correlate IAM signals with cloud audit logs, endpoint telemetry, and SaaS activity so that one identity path can be seen end to end.
• Use the mapped techniques to validate detections, response playbooks, and containment steps.

MITRE’s MITRE ATLAS adversarial AI threat matrix is useful when identity programmes also cover AI agents or LLM-driven workloads, because those systems can blend identity misuse with tool abuse and data access in ways that resemble multi-step intrusion paths. For identity-specific operating guidance, the Ultimate Guide to NHIs highlights why visibility, rotation, and offboarding need to be tied to actual adversary behaviour rather than static inventory alone. These controls tend to break down in highly distributed SaaS and cloud environments because identity events are fragmented across too many logs to reliably reconstruct attacker progression without strong correlation rules.

Common Variations and Edge Cases

Tighter ATT&CK mapping often increases engineering and analyst overhead, requiring organisations to balance better behavioural context against the cost of maintaining detections, taxonomies, and telemetry quality. Best practice is evolving, and there is no universal standard for how granular identity-to-ATT&CK mapping should be.

One common edge case is service accounts and API keys that generate little or no user-facing telemetry. In those environments, ATT&CK mapping may be strongest at the session, token, or cloud control-plane layer, not at the human login layer. Another is third-party SaaS access, where identity activity may be visible only partially. NHI Management Group’s State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes ATT&CK coverage incomplete unless SaaS signals are brought into scope.

For agentic systems, ATT&CK should be paired with agent-focused guidance rather than used alone, because autonomous behaviour changes the threat model. The right question is not only “what technique happened?” but “what did the agent have authority to do next?” Current guidance suggests using ATT&CK as the behavioural backbone while keeping entitlement review, JIT access, and workload identity controls in a separate governance layer. That approach is strongest when identities are ephemeral and actions are time-bound; it is weakest where long-lived secrets, unmanaged integrations, or opaque vendor workflows prevent reliable attribution.

Related resources from NHI Mgmt Group

• How should security teams use identity context in SOC alert triage?
• How should security teams use cyber deception in identity security programmes?
• How should security teams use kernel telemetry in workload identity programmes?
• How should security teams use browser telemetry in identity risk programmes?