Microsoft has addressed a serious Azure Automation security issue that could have allowed attackers to cross tenant boundaries and assume another organization’s automation identity. The issue, tracked as CVE-2025-29827, was assigned a CVSS score of 9.9 and involved improper authorization in Azure Automation.
The vulnerability is especially important because Azure Automation is widely used for operational tasks such as DevOps workflows, resource deployment, patching, scripted runbooks, and secrets rotation. These jobs often run with managed identities that can access other Azure resources.
What Happened
The issue was discovered by Shay Shavit, a senior security researcher on Microsoft’s Azure Networking Security Research team, and reported to the Microsoft Security Response Center. Microsoft later issued an advisory for the vulnerability.
According to the report, the flaw could allow an attacker who already had access to their own Azure Automation account to breach a cloud trust boundary and assume the automation identity of another tenant. That could potentially allow the attacker to create or modify automation scripts, access sensitive configuration data or credentials stored in Azure Automation accounts, and create, change, or delete cloud resources.
Why Azure Automation Identity Matters
Azure Automation accounts can use managed identities to authenticate to other Azure services without storing traditional credentials in scripts. Microsoft documentation explains that an Automation account’s system-assigned managed identity can obtain tokens to access resources protected by Microsoft Entra ID, such as Azure Key Vault.
That makes managed identities powerful. They are useful because they remove hardcoded secrets, but they also become high-value security principals. If an automation identity is abused, the attacker may inherit whatever permissions that identity has across subscriptions, resource groups, Key Vaults, storage accounts, VMs, or other cloud services.
The Core Risk: Broken Tenant Isolation
The most serious part of the issue is not only privilege escalation. It is cross-tenant privilege escalation.
Cloud platforms depend on strong tenant isolation. One customer’s identity should never be able to affect another customer’s resources. In this case, the reported issue could have allowed an attacker operating from one Azure Automation account to assume another tenant’s automation identity.
That kind of flaw is dangerous because it challenges one of the basic security assumptions of public cloud: that tenant boundaries are enforced by the provider and cannot be crossed by customer-controlled workloads.
Default Settings Made the Risk Worse
The issue was tied to a default Azure Automation configuration that could make automation account identities public. According to Dark Reading, the default setting for Azure Automation identities is no longer public.
This is an important lesson for cloud security teams. Secure-by-default settings matter. Customers often assume that platform defaults are safe, especially in managed cloud services. But when a default exposes identity or trust relationships too broadly, the customer may inherit risk without realizing it.
Why Automation Accounts Are High-Value Targets
Automation accounts are attractive because they sit close to operations.
They may run scripts that start and stop VMs, rotate secrets, deploy infrastructure, patch systems, manage backups, interact with Key Vault, or perform administrative tasks across cloud workloads. Microsoft’s Azure Automation guidance describes the service as a platform for orchestrating frequent, time-consuming, error-prone infrastructure and operational tasks across cloud and hybrid environments.
If an attacker can take over or impersonate an automation identity, they may not need to compromise a human administrator. They can abuse the machine identity that already performs trusted work.
Least Privilege Is Critical
Microsoft’s own Azure Automation security guidance recommends applying least privilege when granting access to Automation resources, using granular RBAC roles, avoiding broad subscription-level assignments where possible, and limiting highly privileged roles such as Automation Contributor.
That guidance matters directly here. The blast radius of any automation identity takeover depends heavily on what permissions the automation account has. An identity limited to one narrow task creates less risk than one with broad contributor permissions across a subscription.
What Organizations Should Review
Even though Microsoft has addressed the default setting, organizations should still review their Azure Automation footprint.
Security teams should check:
- which Automation accounts exist across all subscriptions
- which managed identities are enabled
- what RBAC permissions those identities hold
- whether any Automation accounts have broad Contributor or Owner-like access
- whether runbooks contain secrets, tokens, or sensitive configuration data
- whether Automation accounts can access Key Vaults or production workloads
- whether unused runbooks, credentials, or identities can be removed
Microsoft documentation specifically recommends assigning only the permissions required for a runbook to complete its task. For example, if an Automation account only needs to start or stop a VM, its permissions should be limited to that action rather than broad access.
Recommended Defensive Actions
Organizations using Azure Automation should treat automation identities like privileged accounts.
Practical steps include:
- enforce least privilege on all Automation managed identities
- avoid wildcard-style or overly broad permissions
- remove unused Automation accounts and runbooks
- review access to Key Vault, storage, networking, and production resources
- monitor Automation account activity and runbook changes
- alert on unexpected script creation or modification
- use Microsoft Entra Privileged Identity Management for privileged access where appropriate
- separate production automation from lower-risk development automation
- periodically review identity permissions across subscriptions
Microsoft’s Azure Automation security guidance also recommends avoiding wildcard permissions and using Microsoft Entra Privileged Identity Management to improve visibility and protection around privileged accounts.
Final Thoughts
CVE-2025-29827 shows why cloud identity boundaries must be treated as critical security controls.
The issue was not just about Azure Automation. It was about what happens when trusted automation identities become reachable or assumable across the wrong boundary.
Automation accounts often hold the keys to operational workflows. They can deploy, patch, configure, rotate, and manage cloud resources at scale. That makes them extremely useful for defenders and extremely valuable to attackers.
Cloud automation identities must be tightly scoped, continuously reviewed, and monitored like privileged accounts. A default setting should never decide the security boundary for an enterprise cloud identity.
