Yes. Service accounts, workload identities, API keys, and automated actions often create the very behaviours attackers exploit, yet they are frequently under-tested. If those identities are not included, teams can overstate coverage and miss the paths most likely to support lateral movement or hidden persistence.
Why This Matters for Security Teams
ATT&CK coverage is only meaningful when it reflects the identities and activity that actually exist in the environment. Human user testing alone can miss service accounts, workload identities, API keys, scheduled jobs, and orchestration layers that attackers routinely abuse for persistence, privilege escalation, and lateral movement. A coverage map that excludes these elements can create false confidence and delay detection engineering work that matters most.
This is especially important for teams operating cloud workloads, CI/CD pipelines, or agentic automation, where machine-driven actions may look legitimate unless they are explicitly modelled as part of the threat surface. The MITRE ATT&CK Enterprise Matrix is useful here because it helps teams map behaviours to adversary techniques rather than relying on account type alone. That distinction matters when the same identity can be used interactively, programmatically, or through delegated automation.
Security leaders also need this validation to support defensible control reporting. If ATT&CK coverage is used to justify monitoring maturity, incident readiness, or control investment, the underlying test scope should include the identities most likely to be targeted or hijacked. In practice, many security teams discover their blind spots only after a service account or automation path has already been used for persistence, rather than through intentional coverage validation.
How It Works in Practice
Practical validation starts by inventorying identity types and automated actors, then mapping each to the ATT&CK techniques it can realistically exercise or be used to emulate. That includes interactive users, privileged administrators, service accounts, cloud roles, machine identities, scripts, and AI agents with tool access. The objective is not to test everything equally, but to confirm whether detections, logs, and response playbooks can see the behaviours most likely to matter.
Teams usually get better results when they combine technique-based validation with identity-based test cases. For example, a detection for credential dumping may be adequate on an endpoint, but that does not confirm coverage for a workload identity abusing cloud APIs. Similarly, a rule that flags interactive logons may not detect service account impersonation, token reuse, or abnormal automation timing. Current guidance suggests aligning detection tests to both the attack technique and the identity context in which it occurs.
- Map each important identity class to likely ATT&CK techniques and sub-techniques.
- Test whether logs preserve identity attributes, source system, and execution context.
- Validate alert quality for machine actions that are expected but unusual in timing, volume, or target.
- Confirm response playbooks can isolate identities, revoke tokens, or disable automation safely.
For control depth, many organisations also anchor validation to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around access enforcement, audit logging, and monitoring. That helps separate “we have telemetry” from “we can actually detect and respond to abuse of non-human actors.” These controls tend to break down when identity sprawl, short-lived credentials, and fragmented logging prevent reliable correlation across cloud, endpoint, and identity providers.
Common Variations and Edge Cases
Tighter validation often increases testing overhead, requiring organisations to balance deeper coverage against operational friction and alert fatigue. Not every environment needs the same level of machine-identity testing, and best practice is evolving for agentic AI systems that execute actions through tools or delegated permissions.
One common edge case is ephemeral infrastructure. Short-lived containers, serverless functions, and dynamically created credentials may not persist long enough for conventional detection workflows, so validation has to focus on control-plane events, token issuance, and orchestration logs rather than only host telemetry. Another is high-volume automation, where expected activity can mask abuse unless baselines are built around identity behaviour, not just process names or IP addresses.
There is no universal standard for how much ATT&CK coverage should be validated against machine identities, but current guidance suggests prioritising identities that can reach sensitive systems, perform privileged actions, or chain into persistence paths. The most useful programmes treat coverage validation as a living control, not a one-time assurance exercise, and revisit it after major cloud, IAM, or automation changes. That matters most where organisations have many service principals, complex delegation, or AI-driven workflows that alter behaviour without obvious human initiation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE-AT&CK and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE-AT&CK | T1078 | Valid accounts technique covers stolen or abused identities used for persistence and movement. |
| NIST CSF 2.0 | DE.CM-8 | Coverage validation depends on monitoring activity and detecting anomalous identity behaviour. |
Test detection for valid account abuse across users, service accounts, and machine identities.
Related resources from NHI Mgmt Group
- How can ATT&CK help teams evaluate identity detection coverage?
- When should organisations treat machine access as a high-risk identity problem?
- When should organisations treat a machine identity like privileged access?
- How should organisations prove identity governance is reducing risk, not just activity?
