How do managed identities on an Azure VM acquire access tokens?

How the Azure VM metadata flow works

Managed identities are built to let a VM prove itself to Azure without embedding a password, client secret, or certificate in the workload. On an Azure VM, the token request is sent to the Azure Instance Metadata Service, which sits behind the VM boundary and returns a token only when the request comes from that instance. That design keeps the credential material out of the guest OS and application code.

The practical value is not just convenience. It changes the trust model from “store and protect a secret” to “let Azure mint a short-lived token for a known instance.” That is why managed identity is often used for key vault access, storage access, and other Azure-native services where the workload needs repeatable access without static credentials.

What determines what the VM can access

The identity itself does not confer broad access. The token is only useful where the identity has been granted role assignments or other supported permissions, so authorization is still the real control point. A VM with a managed identity can request a token all day long and still be blocked if the assigned scope is narrow or absent.

For practitioners, the key distinction is between token issuance and resource authorization. The Azure control plane authenticates the VM’s managed identity through IMDS, but the target service decides what that token can do based on the identity’s permissions, audience, and scope. The Azure RBAC and service principals guide covers how role assignments and scopes shape what a workload identity can actually reach, and the Azure security guide reinforces the same principle for managed identities in Azure.

Why token hygiene still matters even without stored credentials

Managed identities remove static secret storage, but they do not remove identity risk. If the VM is compromised, an attacker who can run code on it may be able to query IMDS and obtain tokens from the instance context, then use those tokens against whatever the identity can access. The attack surface shifts from secret theft to runtime abuse, overprivilege, and unauthorized token acquisition.

That is why it is not enough to say “there are no credentials on disk.” You still need to care about permission scope, token audience, logging, and whether the identity is reused across too many applications or environments. The broader NHI guidance on common non-human identity failure modes and the definition of non-human identities is useful here because a managed identity is still an identity with lifecycle and privilege consequences, even though it is machine-attached rather than user-attached.

Risk and Threat Considerations

Managed identity reduces secret exposure, but it also concentrates trust in the VM runtime and its assigned permissions. If the identity is over-scoped, token theft or unauthorized token requests can turn a local compromise into access to downstream Azure resources, especially when the same identity has broad access across subscriptions or resource groups.

Failure mechanism: An attacker with code execution on the VM abuses IMDS from the instance context, obtains a valid access token, and reuses that token before it expires or before the permission scope is corrected.

Impact: The attacker may read data, modify resources, or pivot into adjacent Azure services without ever needing a stored password or client secret.

Practitioner Guidance

What to verify: Confirm the VM is using the intended system-assigned or user-assigned managed identity, and verify that the identity’s role assignments are scoped to the smallest resource set that still allows the workload to function. If the workload only needs read access to one storage account or one Key Vault, anything broader is a design problem, not a convenience.

What to measure: Watch for unexpected token request patterns, repeated IMDS access from unusual processes, and identities that request tokens for services they should never call. Those signals are often more actionable than waiting for a visible failure, because token issuance itself is not inherently suspicious.

Common mistake: Treating managed identity as a replacement for authorization design. It replaces secret handling, but it does not replace least privilege, environment separation, or monitoring for misuse.

Practitioner takeaway: The security question is not “can the VM get a token,” but “what can that token reach if the VM or its workload is compromised?” Build the identity with tight scope and assume the token path itself is part of the attack surface.

Related resources from NHI Mgmt Group

• Guide: Cloud Workload Identity Guide
• What is the difference between Azure managed identities and federated workload identity federation for application access?
• What are the signs that managed identities are being misused for lateral access in Azure?
• How should security teams decide between service principals and managed identities in Azure?
• How should teams govern Azure service principals and managed identities over time?