What breaks when cloud identities can move laterally across services?

Why This Matters for Security Teams

When cloud identities can move laterally, the real risk is not just access misuse but trust expansion. One workload, token, or service principal can become a bridge into storage, secrets, CI/CD, or production APIs if permissions are shared too broadly. That is why lateral movement by non-human identities is a governance failure, not just an incident response problem. NIST SP 800-53 Rev. 5 emphasises access control, least privilege, and separation of duties because once trust is overextended, defenders lose containment leverage.

This issue shows up in breaches where a single exposed token or over-permissioned role lets an attacker pivot across systems, such as the Snowflake breach and the 230M AWS environment compromise. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say NHI practices lag human IAM, which helps explain why lateral trust chains remain so common. In practice, many security teams encounter cross-service compromise only after an attacker has already reused one identity to reach several systems.

How It Works in Practice

Lateral movement happens when an identity is not scoped to a single task, service boundary, or trust context. A cloud role may authenticate cleanly, then inherit access to other resources through wildcard permissions, inherited policies, trust relationships, or shared secrets. Once inside, an attacker can chain service calls, query metadata, pull secrets, and assume additional roles without needing a new compromise each time.

Current guidance suggests treating the identity itself as the containment boundary. That means replacing broad standing access with explicit workload identity, short-lived credentials, and runtime authorisation decisions. For cloud and agentic environments, cryptographic workload identity matters because it proves what the workload is, not merely what credential it currently holds. Standards and implementation guidance from SPIFFE and policy evaluation approaches such as NIST AI Risk Management Framework support this shift toward context-aware control.

• Use per-service identities instead of shared accounts or shared API keys.
• Issue short-lived credentials with narrow TTLs and automatic revocation.
• Enforce policy at request time, not only at provisioning time.
• Separate trust domains so one compromise cannot imply access to adjacent systems.
• Monitor identity-to-identity hops, not just user-to-resource access.

This aligns with NHIMG research showing that organisations still struggle with consistent access across hybrid and multi-cloud environments, especially when secrets are shared manually or reused across workloads. The Code Formatting Tools Credential Leaks case is a reminder that exposure often begins with convenience, then becomes a pivot path. These controls tend to break down in multi-account cloud estates with inherited trust and long-lived static credentials because the identity graph becomes too connected to contain quickly.

Common Variations and Edge Cases

Tighter identity segmentation often increases operational overhead, requiring organisations to balance containment against automation speed and engineering friction. That tradeoff becomes visible in environments that depend on shared build agents, cross-account deployment pipelines, or managed service integrations, where teams are tempted to broaden trust just to keep delivery moving.

There is no universal standard for this yet, but best practice is evolving toward per-workload identity, ephemeral secrets, and policy-as-code. The hard part is not issuing credentials but deciding when a service is allowed to inherit another service’s authority. That is especially true for autonomous or semi-autonomous systems, where an identity may trigger actions across storage, compute, and third-party APIs in ways no human operator would pre-authorise in advance. The Azure Key Vault privilege escalation exposure illustrates how adjacent permissions can turn a local weakness into broader enterprise compromise.

In practice, the highest-risk edge cases are legacy applications, service meshes with overly broad mTLS trust, and cloud platforms that rely on static roles for machine-to-machine access. Those environments need gradual refactoring, not just policy tightening, because lateral movement is often embedded in the architecture itself.

Related resources from NHI Mgmt Group

• How should public-sector teams govern access across legacy systems and cloud services?
• How should security teams govern non-human identities in cloud environments?
• What breaks when service account credentials are reused across cloud services?
• What breaks when machine identities are not inventoried across cloud and on-prem systems?