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

When a VM’s managed identity stops being local

A managed identity is supposed to reduce secret handling, but the security boundary is only as strong as the code that can reach the VM’s token source. If untrusted code can query the metadata endpoint, the identity is no longer a host-local convenience, it becomes an externally reachable authorisation capability that can be exercised from inside the compromised VM.

That changes the threat model in a specific way: the attacker does not need to steal a password or key first. They can ask the platform for a valid token, then use whatever downstream permissions were already assigned to the managed identity, which is why workload identity governance matters as much as hardening the guest OS.

A Cloud Workload Identity Guide is useful here because it shows how Azure managed identities fit into the broader pattern of cloud workload identity, where token issuance, trust boundaries and least privilege have to be designed together.

Why attacker-controlled code can turn token minting into broader Azure access

The crucial break is the assumption that “the VM is the identity holder” rather than “the code running on the VM can exercise the identity.” Once attacker-controlled code is executing on the instance, the metadata service becomes a token broker for the attacker’s session. If the identity has access to storage, Key Vault, queues, databases or control-plane actions, the compromise expands from a single process to every resource the identity can reach.

This is not a token theft problem in the classic external sense. It is an in-process authority problem. The attacker may never need to export the token if they can call the same endpoint, repeatedly mint fresh tokens, and chain that access into enumeration, data access or privilege expansion inside Azure. A Service Account Security Guide and the NHI Authentication Guide both reinforce the same operational lesson: authentication material that can be reached from code is part of the attack surface, even when no secret is stored on disk.

The practical consequence is that managed identities must be treated like privileged runtime capabilities, not just an implementation detail of the VM. A section on NHI security challenges is relevant because this pattern sits squarely in overprivilege, credential reachability and hidden lateral movement potential.

What practitioners should verify before trusting a managed identity

First verify whether the VM actually needs the identity at all, and if so, whether the identity is scoped to one workload purpose. The right question is not “can the VM authenticate?” but “what can the token do if arbitrary code on the VM requests it?” That means reviewing assigned roles, checking for control-plane permissions that are broader than the workload’s function, and confirming whether the token can reach production data or administrative APIs.

Next verify exposure of the token path itself. Any path that lets low-trust code, container workloads, browser-invoked automation or unreviewed agents reach the metadata endpoint increases the blast radius of a VM compromise. A NHI Lifecycle Management Guide and the regulatory and audit perspectives on NHI governance are useful for checking ownership, reviewability and revocation discipline around identities that live longer than any one process.

Finally, verify whether the workload can be broken into smaller trust zones. If a single VM identity is shared across multiple apps, deployment agents or admin utilities, attacker-controlled code in one component can inherit access intended for another. That is a design failure, not just an incident response problem.

Risk and Threat Considerations

The main risk is privilege inflation after host compromise. Once code on the VM can mint tokens, the attacker can reuse the managed identity’s standing permissions without needing a separate credential theft step, which makes the VM a convenient launch point for Azure resource abuse and downstream lateral movement.

Failure mechanism: The metadata endpoint or local token broker is reachable by attacker-controlled code, so token issuance is no longer limited to trusted workload paths. The attacker can then request fresh tokens and act as the managed identity until the identity’s permissions are reduced or the host is remediated.

Impact: A compromise that should have remained local to one VM can become access to storage, secrets, management APIs or other subscribed resources, and the resulting activity may look like legitimate workload behaviour unless token use is tightly monitored.

Practitioner Guidance

What to prioritise: Treat the managed identity as part of the workload’s blast radius analysis. If the identity can reach high-value Azure resources, reduce its scope before you chase endpoint hygiene improvements.

What to verify: Confirm that each VM identity has only the minimum roles needed for one workload purpose, and that no adjacent process, container or automation path can call the metadata endpoint on its behalf.

Common mistake: Assuming “no secret on disk” means “low risk.” In practice, the identity is still usable from inside the host, so compromise detection must include token abuse, not just credential exfiltration.

Practitioner takeaway: If attacker-controlled code can query the VM’s managed identity, the real control question is whether that identity is sufficiently narrow that a local compromise cannot become an Azure-wide authorisation event.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• What breaks when a public-facing cloud app can execute attacker-controlled code?
• What breaks when an Azure VM managed identity can run commands on other resources?
• What breaks when a client library can execute code from attacker-controlled JSON responses?