Azure's "Elevate Access" feature is a critical security control point that deserves more comprehensive technical coverage than it typically receives. At Permiso, our P0 Labs team brings diverse cloud security expertise, including deep knowledge of Azure. Along with a great product, we differentiate ourselves through meticulous research and technical insights. Your first thought may have been, “Another article on Elevate Access?” While this topic appears simple and has been addressed before, we aim to clarify, at times correct, and expand the general knowledge of Elevate Access usage and potential risks, including more recent changes to the feature.

This article aims to provide a deeper technical understanding of the Elevate Access mechanism, including its underlying implementation, the specific logs where activities are recorded, when you DON’T need Elevate Access to get the same permissions, and the practical techniques attackers use to leverage it. Our goal is to offer security professionals the detailed information they need to properly understand, secure, and monitor this capability in their Azure environments.

"Elevate Access"

What It Is

The 'Elevate Access' toggle (officially labeled 'Access management for Azure resources' in the Entra ID portal) has a simple purpose: to ensure your top administrators can maintain complete control. Its purpose is straightforward but profound: when activated, it grants an identity with the Global Administrator (Entra ID Role) role the User Access Administrator (Azure RBAC) role at the root scope (/). In essence, complete control of an Azure environment.

This is a crucial technical point that many articles misrepresent. To clarify the Azure hierarchy:

1. Root Scope (/): The absolute apex of the Azure hierarchy, existing in a gray space between Entra ID and Azure, largely unseen, represented in API calls as /. This is where Elevate Access assigns permissions.
2. Root Management Group (aka: Tenant Root Group): A separate entity that technically sits below the root scope. This is the highest management group in your hierarchy, but it's not the same as the root scope itself. Represented in API calls as /providers/Microsoft.Management/managementGroups/{tenantId}

Many security articles incorrectly state that Elevate Access grants permissions at the "Root Management Group" or “Tenant Root Group” scopes, but that's inaccurate. It grants permissions at the higher root scope.

When a Global Administrator uses “Elevate Access”:

1. A role assignment is created for the User Access Administrator role (GUID: 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9)
2. The assignment scope is the root scope ( / )
3. The principal ID is the objectId of the Global Administrator making the request

The result: The Global Administrator now has complete control over all RBAC assignments throughout the entire Azure tenant. This means they can grant any Azure role (including Owner) on any management group, subscription, resource group, or resource - regardless of existing separation of duties or delegation models.

Don't worry, we understand that Microsoft's documentation and illustrations are not clear; in fact, they get it wrong in some docs as well, for example:

As we have explained, Elevate Access is scoped at "root”, this is not the same as ANY of the management groups, and it’s easy to prove:

In a real example, we can clearly see we are reviewing the role assignment of the Tenant Root Group, which is the display name of the Root Management Group. As we review the assigned roles, we are able to evaluate the scopes. “This resource” means the assignment is at the scope of whatever we are reviewing, in this case that is the Tenant Root Group. Also shown is the scope of “Root (Inherited)”, which proves our previous point, root exists above the standard hierarchy and everything, including Tenant Root Group, inherits from root.

Microsoft's illustration of these pieces have also caused confusion, so we decided to create a more accurate illustration:

❓Note while Microsoft’s Elevate Access documentation and the Microsoft portal each references Root Scope, Root, and “/” each meaning the same thing,
Microsoft does use an alternate name of Tenant Scope. This naming is less common, used as a reference to the directory activity logging we will review next,
also referred to as “Tenant Activity Logs”, and when deploying templates inAzure Resource Manager (ARM):
https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-to-tenant?tabs=azure-cli#required-access

How It Is Performed

The simplest and most forward facing mechanisms for Elevate Access are within the Microsoft portals. The steps include:

1. Be a Global Administrator
2. Enable Elevate Access

   • Azure Portal: Entra ID → Manage → Properties

   • Entra ID Portal: Overview → Properties

      

     
     
     

While the toggle in the portal is the simplest way to activate Elevate Access, this capability also exists within the Azure CLI and Rest API. The capability does not exist at the time of writing, for PowerShell.

# Azure CLI

az rest --method post --url "/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"

# REST API

POST <https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01>

🚫 Note that removing a Global Administrator role from an identity does NOT disable Elevate Access.

Logging & Visibility

The Logging Dilemma: Why Most Teams Miss This Activity

The Elevate Access operation has historically not been logged in standard subscription Activity Logs, or in Management Group level activity logs. Instead, it has appeared in Azure Monitor Directory Activity Logs.

Azure Monitor Directory Activity Logs were the only place these events appeared - and while you didn’t technically need to enable Elevate Access, you did need to be a Global Administrator to initially view the log, this is likely because Microsoft has tied part of the root scope Azure permission for/providers/Microsoft.Insights to the Entra ID Global Administrator Role. This log is accessed via the Azure Portal under Monitor → Activity Log → Directory Activity or through REST API calls (tenant-activity-logs).

The latter would be necessary to obtain logs in external systems such as a SIEM; Directory Activity logs do not have a diagnostic logging option to send the logs to another destination such as storage accounts or Log Analytics.

Microsoft Logging Preview

Recently, members of the Permiso P0 Team have seen random social media posts popping up discussing Elevate Access as if new, make no mistake, the feature has existed a long while. We decided to take another look at the documentation for any changes, we found that the most logical reason there is new interest is two fold. First, there is still widespread lack of awareness about Elevate Access and how it works. Second, as of this writing in March 2025, you can now find the following note in the Elevate Access documentation, for release of a public preview update to logging:

In short the public preview is to replicate the Elevate Access event log from the Azure Monitor Directory Activity Log, into the Entra ID Audit log. A rare acknowledgement from Microsoft that these important logs required better visibility. This update makes sense considering from the perspective of the portal, that is where you would have enabled Elevate Access. Microsoft uses this new preview as their method for alerting on Elevate Access activity within Sentinel, via Log Analytics (because as we said before, you cannot send Directory Activity logs to Log Analytics). Use appropriate log retention methods to ensure important events remain available for security analysis and aren't lost due to native aging policies.

Portal Visibility

Recently, Microsoft has begun to ensure it is easy to view Global Administrators with Elevate Access enabled. Within parts of the Entra ID portal / service, as well as any Access control (IAM) tab within Azure, the following warning can be observed:

🚫This warning comes with a catch, to view this warning and the list of elevated users, you must yourself be a Global Administrator or have a role at the root
scope.

If you select to view the role assignments, a simple list of identities will be presented (See the “Users with elevated access” figure in the next section). While the extra logging location and portal visibility enhancement aid in the ability to see part of the access at the root scope. These improvements are limited to access provided directly via the Elevate Access feature. Next we will review additional reasons why these improvements alone are not enough.

Root Scope Access - But Not “Elevate Access”

Let us be clear, Microsoft bettering the ability to see this higher level of access is a great update. It is unfortunate that these visibility enhancements are locked behind needing to be a Global Administrator or having a role at the root scope, they can also then lead to a greater false sense of security.

In the following image, the user Nathan, provided another user “Elevate Test” the Global Administrator role in Entra ID. The “Elevate Test” user authenticated and also elevated their access. As we can see, both instances of Elevate Access are visible to the newly elevated “Elevate Test” user. In addition, Microsoft has started to role out the ability for any one user with Elevate Access enabled, to disable Elevate Access for other users, which can be seen in the screenshot.

Microsoft has opted for a way to show whom has used the Elevate Access feature, which is the required initial way to get access to the root scope. What about users whom have elevated access and then utilize Azure PowerShell or the Azure CLI to provide other users, service principals, or groups this same access without the need to use the Elevate Access feature?

This Azure role assignment appears as a simple role assignment. However, it only appears in the Azure Monitor Directory Activity log. So while Microsoft is trying to show use of Elevate Access, it seems they forgot about what happens after that and the additional logs still lost in the Azure Monitor Directory Activity log.

💡The command used in the Azure CLI to assign a role at the root scope: az role assignment create --assignee "<userId>" --scope "/" --role "Owner"

That is what we see in the image below, an Owner scoped above the Tenant Root Group, within the root scope and whom is not tracked by Elevate Access. Microsoft has given more insight, but still falls short of providing a complete picture.

There are three ways to view this extra root scope access. The first we see pictured above, where we review IAM in Azure to find all root level roles. The second requires that we are first an Entra ID Global Administrator in order to view the Azure Monitor Directory Activity logs, at which point we can see all new assignments via both Elevate Access and root scope role assignments. The third requires that we provide an identity, such as a service principal, the Reader role at the root scope in order to call the Tenant Activity Log API and ensure our monitoring and alert systems receive ALL management plane logs, including those at the root scope.

💡Only Microsoft built in roles can be used at the root scope, custom roles are blocked.

Real World Danger

A realistic attack or misuse leveraging Elevate Access:

1. An attacker compromises a Global Administrator account through credential theft, phishing, or token manipulation.
2. The compromised Global Administrator already previously utilized Elevate Access and has access to all of Azure.
3. The compromised Global Administrator is utilized to create a new user without any normal roles or permissions of consequence, staying under the radar.
4. The compromised Global Administrator utilizes their root “/” scope permissions and provides the newly created user the “Owner” role at the root scope.

This scenario follows what we have discussed up to this point. An attacker is now building persistence while they escalate their privileges at the highest possible point in the Azure environment. All tools and services, from storage, to compute or automation from Runbooks and Logic Apps, often used for legitimate and sensitive tasks could be used against an environment. Depending on the attacker, a low and slow approach or an all-out onslaught could follow and affect the environment before all access can be revoked or the organization can identify what has happened.

Detection & Mitigation Methods

Weak Mitigation Methods:

• Azure Policy: From Microsoft, “Azure Policy ensures that resource state is compliant to your business rules without concern for who made the change or who has permission to make a change.” Azure Policy cannot stop the use of Elevate Access, nor is it meant to assist in RBAC, it is tied to resource compliance. And because Elevate Access sits at the root scope, any policy could simply be altered.
• Just-in-Time Access via Privileged Identity Management (PIM): Unfortunately, PIM is largely a compliance control often given too much credit around security.
  • Yes, you could ensure your Global Administrator only has access to the role if they click the activate button and provide a justification. Unfortunately, those are not security controls and attackers can, like the real user, both click a button and poorly write a random justification. You may be one of few organizations that also requires approval for the role activation, this may provide some assistance assuming it’s not normal for the identity to activate the role. Even if approval is required, most organizations grant it too freely, and a compromised admin can socially engineer or exploit this process. We recommend you review our previous blog around PIM to get the most out of the service and understand its pitfalls : https://permiso.io/blog/privileged-identity-management-pim-for-many-a-false-sense-of-security
  • Elevate Access is not governed by PIM outside of needing to be a Global Administrator to first enable it. However, once it’s enabled, that access remains, you would not need to activate the Global Administrator role again to have full access over Azure. From Microsoft, “…deactivating your role assignment does not change the Access management for Azure resources toggle to No.”

Strong Mitigation Methods:

• Limit Global Administrators:
  • Microsoft has always recommended less than 5 Global Administrators, the best way to limit who can use Elevate Access is to limit, monitor and educate your Global Administrators.
  • PIM has created bad habits of more users being given the Global Administrator role in a JIT fashion, it is still the Global Administrator role. Requiring that your users click a button before they can activate a role does not justify a lack of least privilege. We would only need to be a Global Administrator for a few minutes to severely impact an environment, create persistence, weaken security OR Elevate Access.

Detection:

• Monitor and alert on risky sign-ins: Microsoft can at times create noise with risky sign-ins. However, you should always pay close attention to risky sign-ins from users with privileged roles.

• Ensure you monitor and alert on the Elevate Access event.

  • operationName: Microsoft.Authorization/elevateAccess/action.

  Microsoft (currently in-preview) has made this event available to the standard Entra ID audit log.

• Permiso recommends ensuring you have a mechanism to collect, store and alert directly from the Azure Monitor Directory Activity logs. As we have discussed, Microsoft also copies the Elevate Access event from this log, they ignored other potentially important logs, including:

  • Root Scope Role Assignments
  • Cloud Shell Session Start

   

✅ When permissions are properly configured, Permiso monitors and creates detections from Azure Monitor Directory Activity logs today.

Microsoft's Elevate Access feature is a powerful mechanism that grants Global Administrators complete control over an Azure tenant. While Microsoft has introduced replication of the Elevate Access log into Entra ID Audit Logs, this improvement fails to track privilege escalation beyond the Elevate Access feature itself—leaving organizations vulnerable to undetected persistence techniques at the root scope.

To mitigate this risk, security teams must:

• Limit Global Administrators to the smallest possible number.
• Monitor Azure Monitor Directory Activity Logs for Elevate Access activations (or the Entra ID Audit Log), root scope role assignments, and Cloud Shell usage.

Without these steps, attackers leveraging Elevate Access can silently persist at the highest level of control—long after the initial event has faded from view.

About Permiso

Permiso protects, detects and responds to all human and non-human identity threats, across all environments. Permiso bridges the gap between siloed identity security tools by securing identities across the IdP, IaaS, PaaS and SaaS layers. Through a combination of ML-based behavioral-baselining and 1,000+ detection rules, Permiso enables security organizations to harden their identity security posture and detect suspicious and malicious activity in their environments more quickly than ever.