Azure access elevation: when a Global Administrator takes over every subscription
Entra ID and Azure have separate permission models: being a Global Administrator does not, in principle, grant any rights on subscriptions. In principle only, because a single toggle lets you cross that line. You had better know who flips it.
How it works
In the Entra ID properties, the "Access management for Azure resources" option is available to any Global Administrator. When they set it to "Yes" for their own account, Entra ID grants them the Azure User Access Administrator role at root scope (/), above every management group and every subscription in the tenant.
The mechanism exists for good reasons: regaining control of a subscription that no longer has an owner, or getting a complete view when setting up management groups. But its consequences are considerable.
Why it is a major risk
User Access Administrator can assign any Azure role to anyone. Within minutes, a Global Administrator can therefore make themselves Owner of every resource: virtual machines, key vaults, storage accounts, databases. If domain controllers or synchronisation servers are hosted in Azure, a compromise of the Entra ID tenant spreads to the on-premises directory.
The direct consequence for the security model: the Global Administrator role must be treated as equivalent to full control of Azure and protected accordingly, even in organisations where Azure and Entra ID teams are separate.
Persistence. The root assignment does not go away on its own. An administrator who forgets to turn the option off keeps full access to Azure, even after losing their Entra ID role. For an attacker, it is a quiet way to keep a foothold.
Detecting elevation
Elevation is logged, but not where teams usually look. Subscription activity logs do not show it. According to current Microsoft documentation, it appears:
- in the Azure directory activity log, under the
Microsoft.Authorization/elevateAccess/actionoperation; - in Microsoft Entra audit logs, which can be exported to Log Analytics to drive an alert.
Exact locations and names have changed over recent years; check them against the current documentation and test your detection with a controlled elevation.
Reviewing and cleaning up root assignments
Existing root scope assignments can be listed with Azure CLI, for example: az role assignment list --scope "/" --role "User Access Administrator". Any assignment that does not match ongoing work should be removed; the simplest way is for the holder to set the option back to "No". Depending on the version, the Entra portal also offers a view of users with elevated access.
Good practice:
- Keep elevation for documented cases, with a ticket and a planned duration.
- Turn the option off as soon as the work is done and confirm no assignment remains.
- Alert in real time on every elevation.
- Reduce the number of Global Administrators and activate them through PIM.
- Manage Azure access through explicit assignments on management groups rather than through elevation.
What an audit checks
- Assignments at the Azure root scope and their justification.
- Logging and alerting on the elevation operation.
- The number of Global Administrators and how they are assigned.
- Tier 0 resources hosted in Azure: domain controllers, synchronisation servers, critical key vaults.
- The procedure governing the use of elevation.