Azure managed identities on VMs create lateral movement risk

At a glance

What this is: This analysis shows how Azure VM managed identities can be abused for lateral movement when code execution on one VM yields tokens that open access to other resources.

Why it matters: It matters because IAM teams need to treat managed identities as high-impact non-human identities, not just convenient auth plumbing, when they can reach privileged downstream systems.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Abstract Security's analysis of managed identity lateral movement on Azure VMs

Context

Managed identities are Azure non-human identities attached to compute resources so workloads can authenticate without embedded passwords or keys. In this case, the governance gap is that a VM identity can inherit far more downstream reach than the VM owner understands, which turns one local compromise into cloud-wide access.

That matters for NHI governance because the identity is not just authenticating the VM, it is acting as a reusable access path into other resources. When the control plane is reachable from a token minted inside the VM, network boundaries and host-based assumptions no longer contain the blast radius.

The primary issue is not the existence of managed identities. It is the combination of token minting, over-granted permissions, and weak visibility into where those identities are used. That pattern is common enough to warrant treating VM-attached identities as governed access assets, not infrastructure convenience features.

Key questions

Q: What breaks when an Azure VM managed identity can run commands on other resources?

A: The boundary between local workload identity and tenant-wide authorization breaks down. A compromise of one VM can become a pivot into other VMs, storage, or secrets services if the attached identity is allowed to act beyond the original host. The fix is not just endpoint hardening. It is reducing identity reach and watching for cross-resource use of the same token source.

Q: Why do managed identities increase lateral movement risk in Azure?

A: Managed identities increase lateral movement risk when they are granted permissions beyond the workload’s narrow purpose. An attacker who controls one VM can use the identity to reach Key Vault, run commands on other systems, or alter cloud resources without re-authenticating. That is why scope, not token issuance, drives the risk.

Q: How can security teams know if cloud identity governance is actually working?

A: The clearest signals are fewer unresolved access findings, shorter evidence-collection cycles, lower counts of stale keys, and reduced reliance on manual review. If teams still spend days reconstructing access state, governance is not operating continuously. Effective programmes can show current MFA coverage, role scope, and credential age on demand.

Q: Who is accountable when a managed identity is abused?

A: Accountability usually sits with the cloud and identity teams together. Platform owners control how the VM and metadata service are exposed, while IAM teams control RBAC scope and lifecycle review. If the identity can act beyond its workload’s purpose, the failure is governance, not just detection.

Technical breakdown

How Azure managed identities mint control-plane tokens from a VM

A managed identity in Azure is a service principal tied to a resource, and the resource can request tokens from the Instance Metadata Service. If code executes on the VM, it can query the local metadata endpoint and obtain a token for whatever scope the identity is allowed to use. That token is then accepted by Azure control-plane services such as Resource Manager or Key Vault. The important architectural point is that token issuance happens inside the workload boundary, not through an interactive user session, so the VM becomes the trust boundary for downstream access.

Practical implication: inventory every VM-attached managed identity and map each token scope to the resources it can actually reach.

Why control-plane lateral movement bypasses network restrictions

This technique does not depend on SSH, RDP, or a public endpoint on the target VM. Once the attacker has code execution on one machine, they can use the token from that machine’s managed identity to call Azure APIs and execute commands or enumerate other resources. The second hop may look like legitimate service-to-service activity unless logs are correlated across AzureActivity and managed identity sign-in events. That is why traditional perimeter thinking fails here: the abuse path is authorization abuse, not network traversal.

Practical implication: correlate control-plane operations with identity provenance so a VM cannot silently act as a user on another VM.

Managed identity privilege scope and token audience determine blast radius

The blast radius depends on what the managed identity can do, not on whether it is system-assigned or user-assigned. A system-assigned identity is tied to one resource, but it can still carry powerful roles. A user-assigned identity can be shared across resources, which increases reuse risk if it is granted broad permissions. Once the token audience is switched from Azure Resource Manager to Key Vault, the attacker moves from VM administration into secrets and key access. That is a classic NHI chaining pattern: one identity enables the next authorization step.

Practical implication: restrict role assignments on managed identities to the smallest possible resource set and review shared identities with extra scrutiny.

Threat narrative

Attacker objective: The attacker aims to turn one constrained VM foothold into broader Azure resource access, including secrets stored in Key Vault.

1. Entry occurred when the attacker compromised a limited user account and used it to reach a VM they could administer through Azure control-plane actions.
2. Escalation happened when code execution on that VM allowed the attacker to query the metadata endpoint and inherit the VM’s managed identity token.
3. Impact followed when the attacker reused a second VM’s managed identity to reach Key Vault and enumerate or extract sensitive secrets and keys.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Managed identity lateral movement is a trust-boundary failure, not just an endpoint compromise. The attacker did not need to break the target VM’s network perimeter or log in interactively. They only needed code execution on a resource that was already trusted to mint tokens, which converted local execution into control-plane reach. For practitioners, the governance mistake is treating the VM as the primary boundary when the identity is the true boundary.

Blast radius now depends on token audience and downstream role design. A VM identity that can reach Resource Manager, and then Key Vault, has already crossed from workload authentication into privilege chaining. That is a named concept worth tracking: identity blast radius. It describes how far a single managed identity can propagate access when permissions are stacked across resources, and it should be measured as an architecture property, not a one-off exception.

System-assigned versus user-assigned is not the real security distinction. Both are NHIs, and both can be over-granted. The more important question is whether the identity can be reused, shared, and authorized across unrelated assets without lifecycle controls that follow the actual dependency graph. If the answer is yes, the environment has created reusable privilege rather than constrained workload identity.

Detection quality depends on identity provenance, not just activity logging. The article shows that AzureActivity and managed identity sign-in logs can reveal when one resource is acting as another resource. That means visibility into caller identity, xms_mirid context, and metadata-derived user agents is now part of identity governance, not just SOC telemetry. For practitioners, the operational takeaway is that NHI monitoring must be joined to cloud control-plane analytics.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why cloud identity abuse often hides inside ordinary operations.
• That visibility gap makes the 52 NHI Breaches Analysis useful for teams building detection around privilege chaining and token misuse.

What this signals

Identity blast radius: teams should start treating the downstream reach of a workload identity as a measurable governance property, not a technical footnote. If a VM identity can reach another VM or Key Vault, the access model already extends beyond the host boundary and should be reviewed with the same rigour as privileged human access.

The next programme shift is toward joined-up cloud and identity telemetry. AzureActivity, managed identity sign-in logs, and privilege review workflows need to be analysed together, because isolated logging will miss the moment a workload begins acting as a proxy for another resource. That is now a core NHI governance requirement, not an optional detection enhancement.

With 92% of organisations exposing NHIs to third parties in our reference research, the broader signal is clear: machine identities are increasingly shared, reused, and over-trusted. For Azure teams, that means managed identity lifecycle, role scope, and offboarding discipline should be reviewed alongside workload deployment, not after an incident.

For practitioners

• Map every VM-attached managed identity to its real downstream reach List the Azure Resource Manager, Key Vault, and storage resources each identity can access, then flag any identity that spans unrelated resource groups or subscriptions.
• Remove shared trust from shared identities Avoid reusing a user-assigned managed identity across VMs unless the access pattern is intentionally identical and tightly bounded by policy.
• Correlate control-plane actions with metadata-derived sign-ins Join AzureActivity with managed identity sign-in logs and alert when a resource identity initiates a run-command or API call on another resource.
• Tighten Key Vault permissions on workload identities Treat Key Vault Administrator as a high-risk assignment for managed identities and replace it with resource-specific permissions wherever possible.

Key takeaways

• Managed identities can turn a single VM compromise into cross-resource access when token scope and role grants are too broad.
• The strongest evidence here is the control-plane pivot path, where AzureActivity and metadata-derived sign-ins reveal one resource acting as another.
• Practitioners should narrow managed identity reach, review shared identities aggressively, and correlate identity provenance with workload actions.

Key terms

• Managed Identity: A cloud-provider-managed identity assigned to a compute resource, allowing it to authenticate to cloud services without storing credentials in application code.
• Control-plane Lateral Movement: A movement pattern where an attacker uses cloud API permissions rather than network access to reach additional resources. The abuse happens through authorized platform actions, so the compromise can look legitimate unless identity provenance and resource relationships are analysed together.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Instance Metadata Service: Instance Metadata Service, or IMDS, is a local endpoint that exposes instance information and, in Azure, can mint tokens for attached managed identities. It is designed for trusted workloads on the host, so compromise of the machine can become compromise of the identity if access is not tightly controlled.

What's in the full report

Abstract Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact Azure CLI and IMDS request sequence used to reproduce the lateral movement path.
• The log fields and joins used to detect a managed identity acting through another resource.
• The example Sentinel-style detection logic for correlating run-command activity with metadata endpoint use.
• The Abstract Platform rules referenced for spotting this pattern in production environments.

👉 Abstract Security's full post covers the attack chain, log artifacts, and detection logic in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.