TL;DR: Unosecur reports that Azure managed identity token abuse lets attackers turn a single Azure VM foothold into trusted cloud access by querying IMDS for an OAuth token. The core failure is a trust-model and least-privilege gap: access review and MFA assumptions do not protect local workloads once identity inheritance is overbroad.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: Azure managed identity token abuse via IMDS shows how a VM compromise can expose trusted workload tokens when permissions are too broad.
Why it matters: It matters because IAM, cloud security, and NHI teams need to treat managed identities as governed execution identities, not just another configuration detail.
👉 Read Unosecur's analysis of Azure managed identity token abuse via IMDS
Context
Azure managed identity abuse is a trust problem, not a software bug. In this pattern, a process running on a VM can ask the Instance Metadata Service for a token and inherit whatever cloud permissions the managed identity already holds.
That changes the governance question for cloud programmes: the security boundary is no longer just the VM, but the combination of local execution, identity scope, and control-plane rights. When managed identities are broadly scoped, the blast radius is defined by the permissions granted at design time, not by the attacker’s original access level.
Key questions
Q: What breaks when Azure managed identities are over-privileged?
A: Over-privileged managed identities turn a single VM compromise into trusted cloud access. Once an attacker can query IMDS, the returned token can be replayed against Azure APIs with the identity’s full RBAC scope. The break is in the entitlement model, because the token is legitimate even when the process using it is not.
Q: Why does IMDS token abuse create such a large cloud security risk?
A: Because the platform trusts the identity that the VM already owns. If that identity has broad permissions, the attacker can replay a valid token across Azure APIs and act like a legitimate workload, which makes blast radius a privilege-design problem rather than a token-format problem.
Q: What are the signs that identity abuse is already in progress?
A: Watch for unusual MFA re-registration, repeated helpdesk changes, new devices appearing just before privilege changes, and administrative access from unexpected locations or tools. Those signals often appear before ransomware, exfiltration, or lateral movement. Identity events that cluster around one account or tenant are a strong warning that the attacker is operating through legitimate access.
Q: Should teams focus more on VM hardening or identity governance for IMDS risk?
A: They need both, but identity governance is the control that limits the blast radius once VM execution is lost. Hardening reduces entry, while least-privilege RBAC determines how much the attacker can do if IMDS is reached. Broad identity scope is what makes one foothold dangerous.
Technical breakdown
How IMDS turns local code execution into trusted token access
Azure Instance Metadata Service exposes identity information to processes running on the host. When a process can reach 169.254.169.254 with the correct metadata header, IMDS returns an OAuth token for the managed identity attached to that VM. That token is not a password prompt or human login. It is a workload credential that the cloud control plane will trust if the token is valid and the identity has scope to act. The danger comes from the identity being reachable from any local process, not from the token format itself.
Practical implication: Restrict who can execute code on the VM, because IMDS access becomes decisive once local execution is possible.
Why overprivileged managed identities expand blast radius
A managed identity inherits whatever roles were assigned to it in Azure RBAC or downstream data-plane permissions. If that identity carries Contributor, Owner, or broad data access, a stolen token can be replayed exactly like a legitimate workload session. That is why this pattern is a governance failure: the attacker does not need to break encryption or bypass MFA, only to act inside an already-trusted identity context. The blast radius is set by the role assignment, not by the exploit method.
Practical implication: Review managed identity scope as a privilege design problem, not as an authentication problem.
How to detect IMDS token abuse in runtime logs
IMDS abuse is usually visible as an unusual sequence: VM execution, then metadata queries, then new Azure API activity by the same identity. Strong detection depends on correlating Azure Activity Logs, AADManagedIdentitySignInLogs, AzureDiagnostics, and workload telemetry so that identity use can be tied back to a host event. Standalone sign-ins are often too weak to flag, because the token looks legitimate once issued. The control value comes from matching identity behaviour to workload context.
Practical implication: Build alerting around host-to-identity correlation, not just around token issuance or API calls in isolation.
Threat narrative
Attacker objective: The attacker wants to turn one VM foothold into trusted cloud control by abusing the permissions already attached to the managed identity.
- Entry begins with code execution on an Azure VM through RCE, SSRF, RunCommand abuse, SSH compromise, or stolen administrator access.
- Credential access follows when the attacker queries IMDS and retrieves a managed identity OAuth token through the local metadata endpoint.
- Escalation and lateral movement occur when the token is replayed against Azure APIs and the managed identity’s permissions are used for broader control-plane or Key Vault access.
- Impact is cloud compromise, data theft, workload modification, or subscription-wide abuse that reflects the scope of the inherited identity.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Managed identity trust inheritance is the real control boundary: The article shows that Azure does not authenticate intent, only local reachability and token validity. That means a VM compromise can become a trusted identity event without breaking the normal cloud auth flow. Practitioners should treat identity inheritance as the security boundary, not the presence of a token endpoint.
Overprivileged managed identities create identity blast radius, not just excess access: Once the token is issued, Azure RBAC becomes the attack surface. Contributor or Owner-level assignments turn a single runtime compromise into control-plane reach, data access, and workload modification. The issue is not merely too much access; it is that inherited access is durable and reusable across actions that look legitimate to the platform.
Least privilege for NHIs must be designed for runtime abuse, not audit comfort: The trust model was designed for a local process that should only ask for the identity it needs. That assumption fails when any code on the VM can reach IMDS and obtain a token with broader permissions than the task requires. The implication is that privilege design has to be scoped to execution context, not to the machine as a whole.
IMDS token abuse is a governance gap that crosses cloud, IAM, and NHI discipline: This is not just an Azure issue and not just a cloud issue. It sits where workload identity governance, detection engineering, and IAM role design meet, which is why point controls fail if the identity programme is fragmented. The practical conclusion is that managed identity review must be continuous, not periodic.
Identity blast radius is the right concept for this class of abuse: The article makes clear that one compromised host can expose a much larger permission set than the host itself suggests. That is the governance concept teams should measure, because it describes how far trust extends once a managed identity token is minted. Security teams should evaluate blast radius as a first-class programme metric.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: Cloud Workload Identity Guide
What this signals
Identity blast radius is the metric that matters here. If a single VM can mint a token that reaches control-plane actions, the managed identity has become a standing trust amplifier rather than a bounded workload credential.
Azure IMDS abuse also shows why periodic access review is insufficient for NHIs. The dangerous state appears only at runtime, so programmes need continuous correlation between execution events and workload identity behaviour before token replay turns into subscription-level impact.
For practitioners
- Reduce managed identity scope to task-level minimums Replace broad roles such as Contributor or Owner with narrowly scoped Reader or data-plane permissions that match the workload’s real function. Review every managed identity assignment for unintended control-plane reach, especially where one VM can influence many resources.
- Correlate VM execution with identity sign-ins Join Azure Activity Logs, AADManagedIdentitySignInLogs, and AzureDiagnostics so that an IMDS token request is evaluated alongside the process or host event that preceded it. Alert when identity use follows unusual execution on the same VM.
- Restrict local paths to IMDS Harden hosts so only intended system services can reach the metadata endpoint, and reduce opportunities for SSRF, RunCommand abuse, and compromised admin sessions to query IMDS from arbitrary code paths.
- Audit workload identity behaviour continuously Treat sudden access to new resources, especially Key Vault or subscription-level operations, as a runtime anomaly rather than a routine sign-in. Continuous review is needed because the token appears legitimate once issued.
Key takeaways
- Azure managed identity abuse shows that workload credentials can become a cloud-wide trust problem when the identity is scoped too broadly.
- The attack chain starts with a VM foothold and becomes dangerous only when IMDS returns a token that inherits excess permissions.
- Least-privilege RBAC and host-to-identity telemetry are the controls most likely to reduce the blast radius of this pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on managed identities carrying broader permissions than the workload needs. |
| NHI-04 — Insecure Authentication | IMDS token minting depends on local trust assumptions that can be abused after VM compromise. | |
| Recommendation — Audit managed identity assignments and remove any permissions that exceed the workload’s actual task scope. Restrict metadata endpoint exposure and validate that only intended workload paths can request tokens. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes token retrieval followed by broader cloud movement through Azure APIs. |
| Recommendation — Map IMDS abuse to credential access and lateral movement, then prioritise detections around token replay and cloud API expansion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Managed identity tokens are authenticators whose lifecycle and scope must be controlled. |
| Recommendation — Apply authenticator management to limit token exposure, scope, and reuse across cloud workloads. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core failure is excessive access permissions granted to the managed identity. |
| Recommendation — Review entitlements for managed identities and reduce each one to the minimum access needed. | ||
Key terms
- 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.
- 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.
- 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.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Azure-specific attack chain examples showing how IMDS token retrieval is chained from RCE, SSRF, or RunCommand abuse
- Detection guidance for correlating Azure Activity Logs, AADManagedIdentitySignInLogs, and AzureDiagnostics
- Immediate containment steps for revoking excessive RBAC assignments and rotating accessed secrets
- Practical examples of runtime behavioural analytics for managed identities
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 26, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org