Least-privilege Entra admin roles: replacing Global Administrator

The fastest way to reduce risk from Global Administrator is to stop using it for routine work: inventory who holds which roles, map each recurring task to the least privileged role Microsoft documents for it, and move the rest behind just-in-time activation. Most day-to-day jobs, such as resetting passwords, assigning licences, managing devices or editing Conditional Access, have a narrower built-in role that does the job without tenant-wide control.

This article walks through that process for a Microsoft Entra ID tenant. You will export your current role assignments, replace broad assignments with task-sized roles, scope roles to administrative units, create a custom role where no built-in role fits, and finish with a short checklist you can repeat every quarter.

Who this is for and what you will have at the end

This guide is for tenant administrators and security engineers who inherited a tenant where several people are Global Administrators "because it was easier". It assumes you can already sign in to the Microsoft Entra admin center and run PowerShell.

At the end you will have:

• A list of every active and eligible directory role assignment in the tenant.
• A task-to-role mapping for the jobs your helpdesk and platform teams actually do.
• A plan that keeps Global Administrator to fewer than five people plus emergency access accounts.
• Optionally, a custom role and an administrative unit assignment for delegated administration.

Why least privilege matters for Entra roles

Microsoft describes least privilege as three things you control when you assign a role: a specific set of permissions, over a specific scope, for a specific period of time. Avoid assigning broader roles at broader scopes even when it looks more convenient, because limiting roles and scopes limits what is at risk if an account is compromised.

Global Administrators can read and modify almost every administrative setting in a Microsoft Entra organization and, with a few exceptions, all configuration settings in the Microsoft 365 organization. They can also elevate their access to read data. That is why Microsoft recommends keeping the number of Global Administrators low and protecting each of those accounts with multifactor authentication.

Microsoft Entra RBAC supports over 65 built-in roles, covering directory objects such as users, groups and applications as well as Microsoft 365 services such as Exchange, SharePoint and Intune. Built-in roles are free to use. The size of that catalogue is the reason task-based role selection is practical.

The numbers Microsoft publishes

Privileged roles and permissions carry a PRIVILEGED label in the portal, which helps you see which assignments count toward the second threshold.

Prerequisites

• Permission to read role assignments. Listing users, groups and assigned roles is a default user permission, so a standard account can read the data, but changing assignments requires the Privileged Role Administrator role.
• The Microsoft Graph PowerShell module (Install-Module -Name Microsoft.Graph).
• Licences matched to what you plan to use: custom roles need Microsoft Entra ID P1 for every user with a custom role assignment; Privileged Identity Management needs Microsoft Entra ID P2 or Microsoft Entra ID Governance; administrative-unit-scoped administrators need Microsoft Entra ID P1.
• Two working emergency access accounts. If you have not set these up, read Break-glass accounts and Conditional Access first so you do not lock yourself out while tightening roles.

Step 1: Inventory current role assignments

You cannot reduce what you have not counted. Start with the portal view, then export with PowerShell for something you can sort and share.

Portal export

1. Sign in to the Microsoft Entra admin center.
2. Browse to Entra ID > Roles & admins, then select All roles.
3. Select Download assignments, enter a file name and select Start bulk operation.

The CSV lists assignments at all scopes for all roles. To see only one role, open the role and select Download assignments; with a P2 licence you see the PIM experience instead and use Export. Note that bulk operations can run for up to one hour and have limitations in large tenants.

To see the roles of a single person, go to Entra ID > Users, select the user, then Assigned roles. The list shows whether each role was assigned directly or through a group, and with P2 it separates eligible, active and expired assignments.

PowerShell export

The following script lists every active assignment with the role name resolved. It uses -ExpandProperty "roleDefinition", which is the same relationship expansion shown in the cmdlet reference for a single assignment.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
 
$active = Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty "roleDefinition"
 
$report = $active | Select-Object PrincipalId, DirectoryScopeId,
    @{ Name = 'Role'; Expression = { $_.RoleDefinition.DisplayName } }
 
$report | Sort-Object Role | Format-Table -AutoSize
$report | Group-Object Role | Sort-Object Count -Descending |
    Select-Object Name, Count

The second table gives you the count per role. Check Global Administrator first. DirectoryScopeId of / means tenant scope; a value such as /<object id> means the assignment is limited to a single resource.

If you use PIM, list eligible assignments as well so you see the whole picture:

Connect-MgGraph -Scopes "RoleEligibilitySchedule.Read.Directory"
 
Get-MgRoleManagementDirectoryRoleEligibilitySchedule -All -ExpandProperty "roleDefinition" |
    Select-Object PrincipalId,
        @{ Name = 'Role'; Expression = { $_.RoleDefinition.DisplayName } }

Both outputs show PrincipalId rather than a name. Resolve the IDs against your user, group and service principal lists. Assignments can point at groups: a role-assignable group counts as one principal in this output, but every member of that group holds the role.

Categorise what you find

Microsoft's guidance for securing privileged access suggests removing accounts that are no longer needed in the highest roles first (Global Administrator, Privileged Role Administrator, Exchange Administrator and SharePoint Administrator), then sorting the remainder into categories:

• Administrative users who also use the account for non-administrative purposes, such as personal email.
• Administrative users who use the account for administrative work only.
• Shared accounts.
• Emergency access accounts.
• Accounts used by automated scripts.
• External users.

Each category has a different fix. Mixed-use accounts need a separate admin account. Shared accounts need to become individual accounts. Script accounts should move to workload identities with a narrower role. Administrator accounts should be cloud-only, not synchronised from on-premises Active Directory, because a compromised on-premises account can compromise Entra resources too.

Step 2: Map tasks to least-privileged roles

Microsoft publishes a task-by-task table in "Least privileged roles by task". For each feature area it lists the least privileged role and any additional roles that can also perform the task. Use that table as the source of truth rather than picking roles by name. Role names alone do not tell you what a role can do, and the table separates tasks on ordinary users from the same tasks on privileged admins.

The table below collects tasks that commonly end up with a Global Administrator assignment, taken from that article.

Several rows deserve a note.

Privileged accounts are protected separately. Resetting the password of a non-admin needs only Password Administrator, but resetting the password of a privileged admin needs Privileged Authentication Administrator. Helpdesk staff who handle only ordinary users should therefore not need either of the higher roles.

Read access rarely needs write roles. Auditors, managers and project staff who "need to see everything" usually fit Global Reader or Security Reader. Granting Global Administrator for visibility is the most common avoidable assignment.

Some tasks genuinely need Global Administrator. The same article lists a few user settings, such as the administration centre setting, LinkedIn account connections and the "keep user signed in" prompt, as Global Administrator tasks. These are infrequent, so they are good candidates for eligible assignments rather than standing ones.

Find a role in the portal

If the task is not in the table, go to Entra ID > Roles & admins > All roles and use the Service filter to narrow the list. Open a role to read the permissions it grants and compare them with the action you need. Check the PRIVILEGED label before assigning.

Step 3: Replace broad assignments

Work in this order so you never remove access someone still needs.

1. Assign the narrow role first. Give the person the least privileged role for their real tasks. Assign it through PIM as eligible if you have P2 licences.
2. Ask for a business justification for any Global Administrator assignment that remains. Microsoft's guidance is to ask users why they need administrative access and remove it for those who do not.
3. Remove the Global Administrator assignment and watch the audit log for access failures over the next days.
4. Keep the emergency access accounts as permanent Global Administrators and monitor their sign-ins.

For an assignment made through the portal, open the role under Entra ID > Roles & admins, select Assignments, and add or remove members. Only a Privileged Role Administrator can manage directory role assignments of users.

Use PIM so privileges are not standing

Microsoft recommends Privileged Identity Management for just-in-time access. A user is eligible for a role, activates it for a limited time, and the privilege is removed automatically when the time expires. PIM role settings can also require approval or send notification emails when someone activates a role, which gives early warning when new people are added to highly privileged roles. The full set-up is covered in Set up Entra Privileged Identity Management for just-in-time admin roles.

If one person has five or six eligible roles, activating each separately is tedious. Microsoft suggests PIM for Groups: grant a group access to several roles and make the person an eligible member of the group, so one activation covers all of them. See PIM for Groups and access reviews.

Require MFA for admins

Microsoft recommends turning on multifactor authentication for all administrator accounts, either through PIM role settings or through Conditional Access. For stronger enforcement on admin accounts, see Authentication strengths for phishing-resistant admins.

Step 4: Limit scope with administrative units

A role has three parts: a security principal, a role definition and a scope. The scope can be the tenant, an administrative unit, or a Microsoft Entra resource such as a group, enterprise application or app registration. When a role is assigned over a container such as the tenant or an administrative unit, it grants permissions over the objects inside the container but not over the container itself.

Administrative units suit regional or departmental delegation. Microsoft's own example combines the layers: a custom role scoped to an administrative unit lets a regional helpdesk admin reset passwords only for users in their region; PIM makes the role time-bound; Conditional Access requires a compliant device and MFA at activation; access reviews confirm the person still needs the assignment.

To check what exists, browse to Entra ID > Roles & admins > Admin units, select a unit, then Roles and administrators, select a role and open Assignments. In PowerShell, list scoped role members for a unit:

$adminUnit = Get-MgDirectoryAdministrativeUnit -Filter "displayname eq 'Example_admin_unit_name'"
Get-MgDirectoryAdministrativeUnitScopedRoleMember -AdministrativeUnitId $adminUnit.Id | Format-List *

Replace the display name with one of your own units. Administrators scoped to an administrative unit need Microsoft Entra ID P1; creating a unit and basic membership are available in Microsoft Entra ID Free.

Step 5: Create a custom role when no built-in role fits

Create a custom role only when the built-in catalogue is too broad or too narrow for a responsibility. Custom roles can include only permissions that are enabled for custom use, in these categories: app registrations, enterprise applications, consent, devices, users and groups. A custom role can be assigned at directory scope or at an app registration resource scope only, and the number of custom roles per tenant is limited by the Microsoft Entra service limits.

Portal steps

1. Sign in as at least a Privileged Role Administrator.
2. Browse to Entra ID > Roles & admins and select New custom role.
3. On the Basics tab, enter a name and description. You can clone the baseline permissions from an existing custom role, but you cannot clone a built-in role.
4. On the Permissions tab, search for and select the permissions you need.
5. On Review + create, check the list and select Create. The role then appears in the list of roles you can assign.

PowerShell

This example, from the Microsoft documentation, creates a role that can manage basic properties and credentials of app registrations:

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
 
$displayName = "Application Support Administrator"
$description = "Can manage basic aspects of application registrations."
$templateId = (New-Guid).Guid
 
$rolePermissions = @{
    "allowedResourceActions" = @(
        "microsoft.directory/applications/basic/update",
        "microsoft.directory/applications/credentials/update"
    )
}
 
$customAdmin = New-MgRoleManagementDirectoryRoleDefinition -RolePermissions $rolePermissions `
    -DisplayName $displayName -Description $description -TemplateId $templateId -IsEnabled:$true

Assign the new role to a user at the scope of one app registration, or at directory scope, from the portal or by calling the role assignment API with principalId, roleDefinitionId and directoryScopeId. Azure CLI is not supported for Microsoft Entra role assignments.

Keep custom roles few and documented. Each one is another definition to review.

Verification

After the changes, confirm the result rather than assuming it.

1. Re-run the inventory script from Step 1 and compare the Global Administrator count with the previous run. The target is fewer than five people plus the emergency access accounts.
2. Open Entra ID > Overview and confirm the Global Administrators alert card is gone. Open Roles & admins and confirm no privileged-assignment warning is shown.
3. Sign in as a test account holding only the new narrow role and perform the task it was meant for.
4. Review the audit log for role assignment changes to confirm each change was recorded and made by the expected account. If you keep logs long term, send Entra logs to Log Analytics so role changes remain searchable.

Troubleshooting

A user cannot perform a task after losing Global Administrator

Compare the task with the "Least privileged roles by task" table and check whether it needs one of the "additional roles" listed there. Microsoft Entra evaluates access from the roles in the user's token and from assignments that apply directly or through group membership at the relevant scope.

A role assigned at an administrative unit does not apply to the whole tenant

This is expected. Scoped assignments grant permissions over the objects in the unit only, and assignments at a single resource scope are not visible in the tenant-scope list. Look at the unit's Roles and administrators page, not the global role page.

The role-assignment cmdlet returns only IDs

Get-MgRoleManagementDirectoryRoleAssignment returns PrincipalId and RoleDefinitionId. Use -ExpandProperty "roleDefinition" for the role name and look up the principal separately, as shown in Step 1.

"Insufficient privileges" from Graph PowerShell

Request the Graph permission scope that matches the operation when you call Connect-MgGraph. Reading role assignments uses RoleManagement.Read.Directory; creating custom roles uses RoleManagement.ReadWrite.Directory, and creating one also requires the Privileged Role Administrator role.

The Assigned roles page for a user shows a role the user does not hold directly

The list includes roles inherited through a group. Open the group, check that it is role-assignable, and review its members and owners. A group owner decides who is added, which indirectly decides who gets the role.

Closing checklist

• Export all active and eligible directory role assignments.
• Keep Global Administrator to fewer than five people, plus two cloud-only emergency access accounts.
• Keep privileged role assignments under ten.
• Use cloud-only accounts, separate from daily-use accounts, for administration.
• Map every recurring task to the least privileged role in Microsoft's task table.
• Use Global Reader or Security Reader for read-only needs.
• Make elevated roles eligible in PIM, with MFA at activation.
• Scope delegated admins with administrative units.
• Create custom roles only for gaps, and document each one.
• Review role assignments on a schedule with access reviews.

References

• Best practices for Microsoft Entra roles: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices
• Least privileged roles by task: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/delegate-by-task
• Overview of Microsoft Entra role-based access control: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-overview
• Create a custom role in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-create
• List Microsoft Entra role assignments: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/view-assignments
• Secure access practices for administrators in Microsoft Entra ID: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning
• Get-MgRoleManagementDirectoryRoleAssignment: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.governance/get-mgrolemanagementdirectoryroleassignment
• Get-MgRoleManagementDirectoryRoleEligibilitySchedule: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.governance/get-mgrolemanagementdirectoryroleeligibilityschedule