Topic starter
02/08/2026 12:01 pm
TL;DR: An attacker can pivot from a compromised user to a VM’s managed identity, then reuse that identity to run commands on other resources and reach Key Vault, bypassing network controls and standard login paths, according to Abstract Security. The blast radius assumption breaks when VM-bound identities can mint tokens for downstream access.
Editorial analysis by NHI Mgmt Group, based on content published by Abstract Security: “Moving Laterally through Abuse of Managed Identities attached to VMs”.
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.
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.
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.
Practitioner guidance
- 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.
- Separate control-plane permissions from network controls Review Azure Resource Manager and run-command access independently from SSH, RDP, and private endpoint design.
- Reduce managed identity reuse across resources Avoid attaching one user-assigned identity to multiple systems unless the shared access is explicitly required and bounded.
Bottom line: Managed identities on Azure VMs can turn a single host compromise into broader Azure control-plane reach if the attached identity is over-scoped.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:07 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Azure managed identities on VMs create lateral movement risk