The enterprise security industry spent the better part of a decade dismantling the local admin problem. Group Policy restrictions. LAPS. Privileged Access Workstations. Tiered administration models. Thousands of hours of remediation work to eliminate the standing, overprovisioned, poorly monitored local administrator accounts that made lateral movement trivial for attackers.
Then cloud architecture arrived and offered a clean alternative: managed identity. No passwords to rotate. No credentials to leak. Automatic issuance and scoping. The Microsoft, AWS, and Google sales pitch was compelling and, in principle, sound. Managed identity is a significant improvement over hardcoded service account passwords in scripts.
But CVE-2026-26117, the Azure Arc agent privilege escalation disclosed this week, reveals that we have replicated the local admin problem under a different name — and with less detection coverage than we had for the original.
What We Actually Built
A managed identity in Azure is not a limited, scoped credential. It is an authentication token that can be presented to any Azure API endpoint. Its permissions are determined by RBAC role assignments made at subscription, resource group, or resource level. In practice, those role assignments are made at deployment time by engineers who are optimising for functionality, not least privilege.
Arc-enrolled servers — now present in hundreds of thousands of enterprise environments as Microsoft drives hybrid management adoption through Defender for Cloud and Azure Automanage — routinely carry role assignments like Contributor on resource groups, Key Vault Secrets User, and Log Analytics Contributor. These assignments were made because they were the path of least resistance to making the management tooling work. Nobody flagged them in a quarterly access review, because managed identity role assignments sit outside most organisations’ PAM programmes.
CVE-2026-26117 shows that an attacker with a standard domain user account can, through a named pipe race condition in the Arc agent, obtain the managed identity token of any Arc-enrolled host. That token expires after an hour — but in that hour, it is a credential to every Azure resource the machine identity can reach.
This is not meaningfully different from stealing a domain service account password from a script file on a shared drive. The credential is overprovisioned, poorly monitored, and obtainable by any authenticated local user. The attack surface is the same. We changed the delivery mechanism, not the underlying design problem.
The Monitoring Gap
The local admin problem was eventually contained — not perfectly, but substantially — because we built detection around it. We logged privileged logons. We alerted on unexpected admin group membership changes. We built analytics that detected lateral movement via stolen admin tokens.
Managed identity token usage leaves almost no trail by default. An Azure managed identity access token request from a legitimate service and a stolen token request from an attacker look identical in Azure Activity Logs unless you have specifically enabled diagnostic logging on the target resource and built analytics over it. Most organisations have not. The question “which processes on this host have requested managed identity tokens in the past 30 days?” is not answerable from the default tooling without custom instrumentation.
This is where the analogy breaks down in the attacker’s favour. At least with local admin, an unexpected interactive logon generated an event. With managed identity, the theft is silent and the subsequent usage is noise-free against the background of legitimate service operations.
The Agentic Amplifier
The Azure Arc disclosure arrives alongside a second story this week: CVE in Microsoft Entra’s Agent ID model allowed tenant-level takeover via service principal hijack. These are two separate vulnerabilities affecting two separate products — but they converge on the same structural observation.
As AI agents, automation pipelines, and hybrid management tooling proliferate, the number of service principals and managed identities in enterprise tenants is growing at rates that far exceed organisations’ ability to maintain meaningful oversight. Every AI agent spawned from Copilot Studio creates a service principal. Every Arc-enrolled server creates a managed identity. Every Defender for Cloud integration creates additional application registrations.
The PAM discipline that most mature organisations apply to human privileged accounts — regular access reviews, just-in-time provisioning, session recording, anomaly detection — is almost never applied to this expanding estate of machine identities. The tooling is improving, but the practice has not kept pace.
What Needs to Change
The answer is not to stop using managed identity — it is a genuine security improvement over the alternatives for credential management. The answer is to apply the same operational discipline we finally developed for human privileged accounts.
That means inventorying every managed identity and service principal in the environment and its actual role assignments. It means setting resource-level diagnostic logging as a baseline expectation, not an optional enhancement. It means including managed identity access reviews in PAM governance cycles with the same frequency applied to service account reviews. And it means building detection rules around anomalous managed identity token issuance patterns — unexpected source hosts, unusual resource access patterns, token requests from processes that don’t match the expected service baseline.
CVE-2026-26117 will be patched. The underlying governance gap will persist until security programmes explicitly expand their definition of privileged access to include the machine identities that now hold the keys to cloud infrastructure. The attackers have already noticed.