Who is accountable when lateral movement leads to a breach?

Why This Matters for Security Teams

lateral movement is not just a detection problem. It is the point where access design, privileged identity governance, and containment either hold or fail together. If an attacker can reuse service accounts, pivot through admin pathways, or traverse workload identities, the organisation has already lost control of internal trust boundaries. NHI Management Group’s 52 NHI Breaches Analysis shows how often compromised identities become an enterprise-wide issue rather than a single-system event.

Current guidance in frameworks such as MITRE ATT&CK Enterprise Matrix treats lateral movement as a chain of techniques, but accountability in real organisations is shared across control owners. IAM owns who can authenticate, PAM owns how privilege is granted and bounded, and infrastructure teams own whether east-west movement is actually constrained. When those responsibilities are split without a single control owner, every response becomes a handoff problem. In practice, many security teams discover the accountability gap only after an internal pivot path has already been used to reach crown-jewel systems, rather than through intentional control testing.

How It Works in Practice

Accountability should be mapped to the control that failed, not only to the team that spotted the breach. If a service account moved laterally because it had broad trust, the issue sits with identity governance and segmentation. If a privileged session was reused across systems, PAM and session containment failed. If an attacker chained tools across environments, the organisation likely lacked sufficient workload identity boundaries and policy enforcement at the point of use.

A practical model is to assign ownership across three layers:

• Identity layer: service accounts, API keys, certificates, and workload identities must have named owners, clear purpose, and expiry.

• Privilege layer: PAM and JIT controls should limit standing privilege and require step-up approval for sensitive paths.

• Containment layer: network segmentation, conditional access, and host isolation should reduce the blast radius when an identity is misused.

For NHI-heavy estates, TruffleNet BEC Attack — Stolen AWS Credentials is a useful reminder that compromised credentials often become a foothold for deeper movement, not a single-point event. Control verification should be aligned to NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement, auditability, and segmentation. Storm-2949 Azure Breach also illustrates how one identity failure can cascade across cloud control planes when privilege boundaries are weak. These controls tend to break down in hybrid environments with shared admin domains and unmanaged service accounts because ownership is diffuse and policy enforcement is inconsistent.

Common Variations and Edge Cases

Tighter containment often increases operational overhead, requiring organisations to balance breach resistance against service reliability and developer friction. There is no universal standard for this yet, especially where legacy systems, automation platforms, and cloud control planes intersect. Best practice is evolving toward shared accountability matrices that assign one owner for identity issuance, one for privilege boundaries, and one for lateral containment.

Edge cases matter. In multi-cloud or hybrid estates, the same workload identity may be trusted by several platforms, so a single compromise can cross domains faster than a human analyst expects. In high-automation environments, an agent or orchestration workflow may legitimately traverse many systems, which makes static allowlists too blunt unless they are paired with context-aware authorisation and short-lived secrets. The Ultimate Guide to NHIs — Why NHI Security Matters Now is useful here because it frames why identity sprawl, not just perimeter weakness, drives this class of breach. For broader incident patterns, the The 52 NHI breaches Report shows that compromise is rarely isolated to one team’s domain. Where there is no single authority for internal trust boundaries, accountability should be treated as a governance defect, not a postmortem label.

Related resources from NHI Mgmt Group

• Who is accountable when lateral movement reaches sensitive systems?
• Who is accountable when credential compromise leads to lateral movement?
• Who is accountable when a public SAP exploit leads to lateral movement into identity systems?
• Why do standing privileges increase lateral movement risk so much?