Azure managed identities on VMs create lateral movement risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Abstract Security's research: Managed identities attached to Azure VMs can be abused as a lateral movement path after initial code execution on a VM.

Why it matters: It matters because VM-bound identities can bypass network controls and widen the effective blast radius of a compromised workload identity estate.

Context

Managed identity is an Azure identity model for workloads, not people, and it is meant to replace embedded secrets with token-based access for compute resources. The security gap appears when code running on a VM can reach the Instance Metadata Service and request a token for whatever downstream permissions that identity already has.

In this case, the problem is not authentication at the login screen. It is the governance gap between a VM session, the managed identity attached to that VM, and the Azure resources that identity can control. Once those layers are chained together, traditional network restrictions and direct user permissions no longer describe the real access path.

Key questions

Q: What breaks when a VM managed identity can be queried from attacker-controlled code?

A: The assumption that a workload identity remains local to the VM breaks. If attacker-controlled code can reach the metadata endpoint, it can mint a valid token for whatever downstream permissions the identity already has, turning a host compromise into a broader Azure authorisation problem.

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 do teams know a managed identity is too broadly scoped?

A: A managed identity is too broadly scoped when it can reach resources that are not required for the workload's runtime function, especially across resource groups or into vault and administration roles. If one host compromise can affect more than one critical service, the scope is already too wide.

Q: What should security teams do when a managed identity is attached to multiple Azure resources?

A: They should treat the shared identity as a delegated trust path and reassess whether each attachment is necessary. If the same identity can operate more than one system, compromise of any one attachment can become a tenant-wide pivot opportunity.

Technical breakdown

How Azure VM managed identities expose downstream permissions

A managed identity in Azure is a service principal bound to a compute resource, such as a virtual machine, so the workload can obtain tokens without a stored secret. The key technical detail is that any code executing on that VM can query the Instance Metadata Service and receive an access token for the attached identity. That token is then accepted by Azure Resource Manager or by a target service such as Key Vault, storage, or SQL, according to whatever role assignments the identity already has. This is why managed identity is convenient for application-to-cloud authentication but dangerous when an attacker achieves code execution on the host.

Practical implication: Treat VM execution as a token issuance point, not just a host compromise, and constrain what the attached identity can reach.

Why control-plane access bypasses network restrictions

This abuse path works because Azure control-plane operations are authorised by identity and token scope, not by the source IP path to the workload. If an attacker can obtain a valid token and invoke a run command or other management action, then perimeter controls around SSH, RDP, or private endpoints do not stop the request. In other words, the attacker is not logging in to the second VM in the conventional sense. They are reusing an identity-backed control-plane authorization path that is orthogonal to the network path defenders often monitor.

Practical implication: Review management-plane permissions separately from network exposure and assume private networking does not neutralise identity misuse.

Why token scope determines the final blast radius

The blast radius is governed by the permissions attached to the managed identity and by the resource scope requested from IMDS. In the article's chain, one VM identity can be used to reach another VM, and a second identity can then request a token for vault.azure.net to enumerate or access Key Vault objects. That means the compromise does not end at the first VM. It extends to every downstream Azure resource reachable by the identity, including secrets, certificates, and encryption keys that can unlock still more infrastructure.

Practical implication: Map managed identity permissions to actual downstream resources and remove unnecessary reach before compromise turns into environment-wide access.

Threat narrative

Attacker objective: The attacker wants to turn one limited VM compromise into control over additional Azure resources and access to sensitive secrets or keys.

1. Entry begins with compromise of a user account that can execute commands on a VM hosting a managed identity.
2. Credential access occurs when code on the VM queries Azure Instance Metadata Service and obtains a token for the attached managed identity.
3. Lateral movement follows when that token is reused to execute commands on a different VM and then to request a Key Vault-scoped token.
4. Impact is the ability to enumerate Key Vault resources and potentially extract secrets, certificates, or encryption keys across the environment.

Breaches seen in the wild

• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).
• Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Managed identities attached to VMs create a control-plane blast radius that network security never measures. Once code can run on the host, the identity bound to that host can be converted into permissions on other Azure resources. That makes the real trust boundary the token issuer and the role assignment, not the VM's subnet or inbound rule set. Practitioners should therefore assess VM identity scope as a lateral movement surface, not as a local authentication convenience.

VM-bound managed identity breaks the assumption that a workload identity stays local to the system it was created for. That assumption was designed for a world where identity use and resource scope aligned neatly. It fails when the same token issuer can be queried from arbitrary code execution on the host and then reused against different resource groups, storage services, or vaults. The implication is that identity containment has to be evaluated by reachable authorisation scope, not by attachment point.

Identity blast radius is now the more useful unit of analysis than host compromise. The article shows a chain that begins with one user, passes through one VM, and ends in another VM and a vault. That is a governance problem because access review, least privilege, and offboarding controls are all blind if they only look at the machine or the human account in isolation. Practitioners should model how far a managed identity can push the tenant once it is converted into a token.

Managed identity abuse exposes the gap between workload IAM and privileged resource governance. Azure treats the identity as an ordinary service principal, but the operational effect is much closer to delegated control of downstream infrastructure. The governance failure is not merely over-permissioning. It is the assumption that a workload identity's trust domain ends where the VM ends. Security teams should govern managed identity as a privileged delegation path with environment-wide impact, not as a narrow application credential.

Token scope is the hidden control point in this attack pattern. The same VM-hosted identity can request different audience tokens, and each audience expands what the attacker can query or operate. That makes scope design, role assignment, and identity isolation the decisive factors in whether a managed identity remains contained. Practitioners should treat every scope accepted by IMDS as a potential escalation target.

What this signals

Managed identity should be governed as a delegated privilege path, not just as a secretless convenience. The practical difference is that the token source sits on the workload, while the authorization effect lands elsewhere in the tenant. That changes how teams should think about blast radius, because the risk is created by where the identity can act, not just where it is attached.

Workload identity isolation is the control that matters most here. When one VM identity can be used to command another VM and then to reach Key Vault, the design has already crossed a governance boundary. The right programme response is to treat shared identity attachments, cross-group permissions, and vault access as one connected trust chain.

For practitioners

• Map managed identity reach before granting VM permissions Inventory every Azure resource a VM-attached managed identity can touch, including other VMs, Key Vault, storage accounts, and cross-group scopes. Remove broad contributor roles where the workload only needs a narrow service action.
• Separate control-plane permissions from network controls Review Azure Resource Manager and run-command access independently from SSH, RDP, and private endpoint design. A private network does not prevent a valid token from authorising control-plane actions on another resource.
• Reduce managed identity reuse across resources Avoid attaching one user-assigned identity to multiple systems unless the shared access is explicitly required and bounded. Shared identities turn a single compromise into a multi-resource pivot path.
• Monitor for metadata-based token issuance Alert on IMDS-style token retrieval patterns followed by run-command activity or cross-resource service principal calls. That sequence is the clearest signal that code execution on one VM is being used to obtain another identity's token.
• Tighten Key Vault roles for workload identities Give managed identities only the minimum Key Vault permissions needed for runtime access. Avoid administrator-level vault roles where read or unwrap access is sufficient.

Key takeaways

• Managed identities on Azure VMs can turn a single host compromise into broader Azure control-plane reach if the attached identity is over-scoped.
• The article's attack path moves from one VM to another and then into Key Vault, showing how lateral movement can cross resource groups and security boundaries.
• Teams need to review workload identity scope, attachment reuse, and privileged vault access together, because each control affects the same blast radius.

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.
• Azure Instance Metadata Service: Azure Instance Metadata Service is a local endpoint that provides information about a running Azure resource, including configuration and identity-related details. Because it is reachable from within the cloud instance, SSRF attacks may abuse it to retrieve sensitive metadata or tokens.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• 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.

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.