To elevate access is to flip the Global Administrator switch that grants the User Access Administrator role at the Azure root scope, inherited by every management group and subscription in the tenant. Entra ID roles and Azure roles are separate systems, and a Global Administrator does not automatically have any access to Azure subscriptions or management groups. Elevating access bridges the two: the caller receives User Access Administrator at root scope (/), which allows viewing all resources and assigning access in any subscription or management group in the tenant.
Why it matters to a lean team
User Access Administrator can manage every role assignment and role definition in scope and can assign itself or others the Owner role, so at root scope one directory role becomes full access to every Azure resource the company runs. Three properties make it a problem for a small team. The setting is per user, not tenant-wide, so each Global Administrator who flips it creates a separate root-scope assignment. Deactivating a PIM Global Administrator assignment does not turn the toggle off, so an administrator can drop the directory role and keep the Azure root access. And the assignment cannot be removed from the IAM blade like an ordinary one, so the usual cleanup habit fails. A compromised admin account inherits that standing privilege for free, so it belongs in any identity blast radius calculation.
How it shows up in Entra ID and Azure
In the portal the control is Microsoft Entra ID, Manage, Properties, "Access management for Azure resources", set to Yes. Only users holding the Global Administrator role see the toggle, and if the role is managed in PIM the assignment must be activated first. Over REST it is POST https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01. Azure describes the action, Microsoft.Authorization/elevateAccess/Action, as "Grants the caller User Access Administrator access at the tenant scope", and the Contributor role explicitly excludes it. The result is a User Access Administrator role assignment at scope /. Elevate and remove events land in both the Entra directory audit logs and the Azure activity logs; Microsoft notes the directory audit logs are easier to filter and export and can be streamed to Microsoft Sentinel for alerting.
What to do about it
- Treat elevation as a task, not a state. Microsoft says to remove the elevated access once the root-scope changes are done: the same user sets the toggle back to No, or use
Remove-AzRoleAssignment,az role assignment delete, or the REST API. The IAM blade refuses and points to those methods. - If Global Administrator is managed in PIM, set the toggle to No before deactivating the role, because deactivation does not reset it.
- Another Global Administrator with elevated access at root scope can remove a different user's root-scope assignment, which matters when the holder has left or is the account you are containing.
- Alert on the elevate event in the directory audit log, and keep the Global Administrator count small, since only that role can flip the switch (see how many Global Administrators a Microsoft 365 tenant should have).
Related terms
- Global Administrator: the only role that can elevate.
- Privileged Role Administrator: can hand out Global Administrator.
- PIM eligible assignment: the toggle needs an active assignment; deactivation does not clear it.
- Identity blast radius and attack path: what an elevated account can reach and how it got there.
- Emergency access account: a permanent Global Administrator that can elevate at any time.
- Containment verification: re-reading Azure after removal to confirm the assignment is gone.
See the glossary index for every term, or start with what to do when an Entra admin account is compromised.
Where Orbitra fits
Orbitra reads Entra directory roles and Azure RBAC role assignments into one identity graph, so an account's directory roles and its Azure role assignments appear together in its blast radius: what an identity can reach before you act, and what remains reachable after. Response actions come from an allowlisted catalog and run only after a person approves them, and Orbitra independently re-reads Microsoft after supported response actions to verify the final state. Orbitra tells you which steps are permanent before you approve them, and removing an Azure role assignment is one of them. Works alongside Microsoft native controls.
Sources
- Elevate access to manage all Azure subscriptions and management groups (Microsoft Learn, checked September 2026)
- Azure built-in roles: Privileged (Microsoft Learn, checked September 2026)
- Microsoft Entra built-in roles (Microsoft Learn, checked September 2026)