Who is accountable when a zero trust cloud model still allows lateral movement?

Accountability usually sits across IAM, cloud security, and application teams because the failure is often shared between policy design, identity lifecycle management, and segmentation enforcement. Frameworks such as NIST CSF and NIST SP 800-53 expect clear ownership for access control, monitoring, and revocation decisions.

Why This Matters for Security Teams

A zero trust cloud model is only as strong as the controls that prevent one compromised workload, identity, or token from reaching other assets. When lateral movement still exists, the issue is rarely a single broken setting. It usually reflects gaps in identity governance, segmentation design, workload trust boundaries, or monitoring coverage. That is why NIST guidance on zero trust emphasizes continuous verification, explicit access decisions, and strong telemetry, as described in NIST SP 800-207 Zero Trust Architecture.

For accountability, the key mistake is assuming “zero trust” is a product state rather than an operating model. Cloud teams may deploy network policies, IAM teams may enforce conditional access, and application teams may publish service-to-service permissions, yet none of those functions alone can stop movement if trust is too broad or logs are incomplete. Security leaders need ownership that spans design, implementation, and validation, because lateral movement is often enabled by the seams between teams. In practice, many security teams encounter lateral movement only after an intrusion has already crossed from one workload or account into another, rather than through intentional detection design.

How It Works in Practice

Accountability in this scenario should be assigned by control domain, not by vague program labels. NIST SP 800-53 Rev. 5 is useful here because it breaks security into specific control families for access control, audit logging, system and communications protection, and incident response. That helps teams separate who owns policy, who implements it, and who verifies that it works. The same logic applies to attack-path analysis using the MITRE ATT&CK Enterprise Matrix, which can show whether lateral movement is occurring through valid accounts, remote services, shared credentials, or mis-scoped permissions.

In practice, a mature operating model usually assigns responsibility across four layers:

• IAM owns authentication strength, conditional access, and lifecycle revocation for users, service accounts, and privileged identities.
• Cloud security owns segmentation, policy-as-code, posture review, and cross-account guardrails.
• Application and platform teams own service-to-service authorization, secrets handling, and local trust boundaries.
• SOC and detection engineering own telemetry, alerting, and correlation rules that identify abnormal east-west movement.

This distribution matters because lateral movement often exploits the interface between layers. For example, a workload can have the right network policy but still pivot through an over-permissioned role, a long-lived secret, or an API path that was never reviewed after deployment. Clear RACI mapping is essential, but current guidance suggests it must be paired with evidence: access reviews, segmentation tests, and detection validation. These controls tend to break down in fast-scaling multi-account cloud environments because ownership becomes fragmented and inherited permissions outpace review.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance reduced blast radius against deployment speed and troubleshooting complexity. That tradeoff is real, especially in platform engineering environments where teams rely on shared services, ephemeral workloads, and service meshes. Best practice is evolving, but there is no universal standard for making every trust decision fully granular without affecting reliability.

Some edge cases shift accountability in important ways. In shared responsibility cloud models, the provider may secure the underlying service, but the customer still owns identity design, tenant segmentation, and workload authorization. In containerised or serverless estates, lateral movement may not look like classic host-to-host pivoting; it may occur through overly broad roles, token reuse, or access to metadata and secrets endpoints. Where identity is involved, the question often becomes whether the organisation treated workloads as security and privacy controls targets rather than just application components.

Where governance is weak, accountability should not stop at operations. Security leadership must own whether the architecture was ever validated against realistic attack paths. If a “zero trust” rollout still permits lateral movement, the likely root cause is not absence of a control category but failure to prove that the control operates across identity, network, and workload boundaries.

Related resources from NHI Mgmt Group

• Who is accountable when a resilience architecture still allows lateral movement during an incident?
• Why do service accounts and workloads still create lateral movement risk in cloud environments?
• Why do valid credentials still create risk in a Zero Trust model?
• Who should be accountable for identity governance in a Zero Trust model?