How to Audit Azure Owner and User Access Administrator Assignments: Find, Reduce, Monitor

Any identity holding Owner, User Access Administrator or Role Based Access Control Administrator in Azure can grant itself or anyone else full control of everything below its scope, so these few assignments decide who really runs your Azure estate. This guide is a focused task runbook: how to find every such assignment across management groups, subscriptions, resource groups and resources, including the root scope created by elevated access, how to decide which ones to keep, how to reduce or constrain the rest, and how to watch for new ones. It is written for cloud platform, identity and security operations teams. The concepts behind Azure RBAC and service principals are covered in the Azure RBAC and Service Principals Guide; this page is the audit itself.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Audit the role-granting roles, not just Owner. Microsoft lists Owner, Contributor, Reservations Administrator, Role Based Access Control Administrator and User Access Administrator as privileged administrator roles; three of them can assign the Owner role.
• Start at the top of the hierarchy. Assignments at a management group or the root scope (/) inherit down to every subscription, so one stale assignment there outweighs dozens at resource group level.
• Elevated access is a separate switch. A Global Administrator who sets Access management for Azure resources to Yes gets User Access Administrator at root scope, and deactivating the Global Administrator role in PIM does not turn it off.
• Constrain instead of remove where delegation is needed. Role Based Access Control Administrator with a condition such as "Allow all except specific roles" lets teams manage access without being able to hand out Owner.
• Keep watching after the clean-up. Alert on Microsoft.Authorization/roleAssignments/write for these role IDs and on elevated access events, and re-run the inventory on a schedule.

What you are looking for

Azure RBAC scopes form a parent and child hierarchy of management group, subscription, resource group and resource, and lower levels inherit role permissions from higher levels. The roles below are the ones Microsoft documents as privileged administrator roles. Use the role definition IDs, not display names, in queries and automation.

For each assignment, record the principal (user, group, service principal or managed identity), principal type, scope, whether it is direct or through a group, whether it is an active or PIM eligible assignment, any condition, and who created it. That record becomes the evidence for your review. The Privileged Account Inventory Template gives a format you can reuse.

Step 1: Find elevated access at root scope

Check this first, because it sits above every management group. Elevation is a per-user toggle available only to Global Administrators, and it grants User Access Administrator at / to the signed-in user.

1. In the Azure portal open Microsoft Entra ID > Manage > Properties and look under Access management for Azure resources. A banner shows how many users have elevated access; Manage elevated access users lists them. Microsoft notes this list and bulk removal are rolling out in stages.
2. The same warning appears on any subscription's Access control (IAM) page as an "Action required" banner with a View role assignments link.
3. Pull history from the Microsoft Entra audit logs with the service filter Azure RBAC (Elevated Access) (documented as preview), or from the Azure activity log. The elevation entry reads that the user "has elevated their access to User Access Administrator for their Azure Resources".
4. Remove anything not tied to an open, approved task. The user who elevated sets the toggle back to No; the root assignment cannot be removed from the IAM page.

Step 2: Inventory assignments across the hierarchy

Run the inventory with a read-only identity, at the widest scope you can see. Three documented methods, each suited to a different job:

Portal

On Access control (IAM) > Role assignments at any scope, the Privileged tab lists privileged administrator role assignments and the Privileged card shows their count. View assignments opens Manage privileged role assignments, where you can add a condition or remove an assignment. Good for spot checks, slow for an estate.

Azure CLI

• Management group: az role assignment list --scope /providers/Microsoft.Management/managementGroups/{groupId}
• Subscription and everything below: az role assignment list --all in the subscription context, adding --include-inherited to see assignments made at parent scopes.
• One role: filter with --role using the role definition ID (the flag is in the az role assignment CLI reference).
• One person, including their groups: az role assignment list --all --assignee {upn} --include-groups.

Use az account management-group list to enumerate management groups first. Microsoft notes that assignments authorised through Azure Lighthouse are not shown by these commands; review those delegations separately (see the Azure Lighthouse Security Guide).

Azure Resource Graph

For a tenant-wide view in one query, use the authorizationresources table. Microsoft's sample returns role assignments with roleDefinitionId, principalType, principalId and scope. Adapting it to these roles (our adaptation of the sample, so test it in your tenant):

authorizationresources
| where type =~ 'microsoft.authorization/roleassignments'
| extend roleDefinitionId = tostring(properties.roleDefinitionId)
| extend principalType = tostring(properties.principalType)
| extend principalId = tostring(properties.principalId)
| extend scope = tostring(properties.scope)
| where roleDefinitionId endswith '8e3af657-a8ff-443c-a75c-2fe8c4bcb635'
     or roleDefinitionId endswith '18d7d88d-d35e-4fb5-a5c3-7773c20a72d9'
     or roleDefinitionId endswith 'f58310d9-a9f6-439a-9e8d-f62e7b41a168'
| summarize assignments = count() by roleDefinitionId, principalType, scope

Resolve principalId to names in Microsoft Entra ID afterwards, and expand group membership: a group with Owner at a management group makes every member an Owner there.

REST

For automation, GET https://management.azure.com/{scope}/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01 with $filter=atScope() (this scope only) or $filter=principalId+eq+'{objectId}'. Use API version 2022-04-01 or later so conditions are returned.

Step 3: Classify each assignment

Sort every finding into one of these buckets before changing anything. The decisions in the right-hand column are our recommendations.

Owner assignments created by the classic administrator conversion carry the description "The Classic Admin role was converted to an Azure Owner role on behalf of the user due to Classic Admin retirement", which makes them easy to filter. Microsoft states that classic administrator roles were fully retired in May 2026.

Defender for Cloud has paired recommendations, "A maximum of 3 owners should be designated for subscriptions" and "There should be more than one owner assigned to subscriptions", so aim for two or three, not one. A single Owner who leaves can orphan a subscription.

Step 4: Reduce and constrain

Change in this order so you never lock yourself out.

1. Protect recovery first: confirm your break-glass accounts and their path back to Owner before removing anything. See the Break-Glass Account Guide.
2. Convert standing access to eligible: in ID Governance > Privileged Identity Management > Azure resources, select the scope, open Roles > Add assignments and set Assignment type to Eligible with an end date. Activation can require MFA, justification or approval through the role settings. See the Privileged Identity Management (PIM) Guide.
3. Narrow scope: move management group or subscription assignments down to the resource groups people actually manage. Microsoft advises a narrow scope when a privileged role is unavoidable.
4. Swap to job function roles: replace Owner or Contributor with the service-specific role that covers the task, such as Virtual Machine Contributor.
5. Constrain delegation: where a team must manage access, assign Role Based Access Control Administrator and on the Conditions tab pick a template: Constrain roles, Constrain roles and principal types, Constrain roles and principals, or Allow all except specific roles. Excluding Owner, User Access Administrator and Role Based Access Control Administrator is a common pattern; Microsoft's delegation examples article covers the condition syntax. Assignments outside the condition fail with an error.
6. Remove what is left over: remove stale assignments in small batches, announced to the owning team, after exporting the current state as JSON so you can recreate an assignment if a removal breaks a workload.

Testing and rollback: pilot on one non-production subscription, watch deployment pipelines for authorisation failures for a week, and keep the exported assignment list as your rollback record. PIM assignments cannot be created for less than five minutes or removed within five minutes of creation, so allow for that in automated tests.

Step 5: Monitor for new assignments

Role assignment changes are written to the activity log as Microsoft.Authorization/roleAssignments/write (create) and Microsoft.Authorization/roleAssignments/delete. Microsoft notes the activity log view covers the past 90 days, so send it to a Log Analytics workspace or your SIEM for longer retention (see the Azure Monitor, Activity Log and Diagnostic Settings Guide).

Microsoft's change history article gives sample Kusto queries over AzureActivity for role assignment changes; adapt one to summarise successful writes by caller and filter for the role definition IDs above. Microsoft Sentinel ships an Azure RBAC (Elevate Access) analytics rule template that works once the Microsoft Entra ID audit logs connector is enabled.

These detections map to ATT&CK T1098.003 Additional Cloud Roles, the technique an intruder uses to give a compromised identity more control, and T1078.004 Cloud Accounts. If an alert shows an unexpected Owner grant, follow the Azure Subscription Compromise Playbook.

Measuring progress

• Privileged assignments at management group and root scope: trend towards a short, named list.
• Share of Owner and User Access Administrator assignments that are PIM eligible: target close to 100% for humans (our target).
• Subscriptions with two or three Owners: percentage of subscriptions meeting both Defender for Cloud owner recommendations.
• Workload identities with role-granting roles: count of service principals and managed identities holding Owner, User Access Administrator or unconditioned RBAC Administrator.
• Elevated access time open: median time between elevation and removal.
• Unapproved privileged grants: alerts per month that had no matching change record.

Framework mapping

For a wider review programme beyond Azure, see the Access Review Checklist.

Common failure patterns

• Auditing subscriptions only: management group and root assignments are missed, and they are the broadest.
• Trusting display names: custom roles can carry a familiar name; query by role definition ID and check custom roles for roleAssignments/write.
• Ignoring group membership: the assignment list shows one group, while dozens of people inherit Owner through it, including nested members.
• Leaving elevated access on: a Global Administrator elevates for a one-off fix and the root User Access Administrator assignment stays because the PIM role expired but the toggle did not.
• Pipeline identities as Owner: a deployment service principal given Owner "to make role assignments work" becomes the easiest path to control the subscription. Use a conditioned RBAC Administrator assignment instead.
• Cutting to one Owner: over-zealous clean-up leaves a single Owner and a future orphaned subscription.

Practitioner checklist

• Check Access management for Azure resources and the Entra audit logs for elevated access, and remove any not tied to a change.
• Inventory Owner, User Access Administrator and RBAC Administrator assignments at root, management group, subscription and resource group scope by role definition ID.
• Expand group assignments to their members and resolve every principal ID.
• Remove guest, external, blocked and deprecated accounts holding Owner.
• Review Owner assignments converted from classic administrators.
• Convert human assignments to PIM eligible with an end date and activation requirements.
• Replace workload identities' role-granting roles with job function roles or conditioned RBAC Administrator.
• Keep two or three Owners per subscription and a tested break-glass path.
• Alert on privileged roleAssignments/write, custom role changes and elevated access, retained beyond 90 days.
• Re-run the inventory quarterly and record the metrics (our recommended cadence).

Standards and references

• Microsoft Learn: Best practices for Azure RBAC
• Microsoft Learn: Elevate access to manage all Azure subscriptions and management groups
• Microsoft Learn: Steps to assign an Azure role (privileged administrator roles)
• Microsoft Learn: List Azure role assignments using Azure CLI
• Microsoft Learn: Azure Resource Graph sample queries by category
• Microsoft Learn: Delegate Azure role assignment management to others with conditions
• Microsoft Learn: View activity logs for Azure RBAC changes
• Microsoft Learn: Identity and access recommendations in Defender for Cloud

Related NHI Mgmt Group resources: Azure RBAC and Service Principals Guide · Privileged Identity Management (PIM) Guide · JIT Access Guide · Azure Managed Identities Security Guide