Microsoft 365 admin centres and admin roles: who controls what in your tenant

Most Microsoft 365 tenants hand out far more administrative power than anyone needs, because the admin model is spread across eight or more admin centres that each have their own role system. The Microsoft 365 admin centre, Entra, Exchange, SharePoint, Teams, Defender, Purview and Intune all decide who can do what, and the same person can end up with standing rights in all of them through a single Global Administrator assignment. This guide maps each admin centre to the roles that control it, explains how Entra directory roles flow into workload role groups, and sets out a least privilege design using Privileged Identity Management (PIM), administrative units and emergency access accounts. It is for Microsoft 365 administrators, identity engineers and auditors. Details come from Microsoft Learn, checked November 2026; confirm them in your own tenant.

Key takeaways

• Entra roles sit above everything. Directory roles assigned in Microsoft Entra ID apply across Microsoft 365 and map into Exchange, Purview and other workload role groups, so an Entra assignment is usually the one that matters most.
• Global Administrator is for emergencies. Microsoft recommends fewer than five Global Administrator assignments and fewer than ten privileged role assignments, and shows warnings in the Entra admin centre when you exceed them.
• Workload role groups give narrower control. Exchange role groups, Intune RBAC roles with scope tags, Defender Unified RBAC and Purview role groups let you grant task level rights without any tenant wide directory role.
• Standing access should be the exception. PIM turns permanent assignments into eligible ones that are activated for a limited time with MFA, justification and optional approval.
• Scope before you grant. Administrative units, Intune scope groups and Defender device groups limit which users and devices an administrator can touch, which matters most for helpdesk and regional teams.

The admin centres and what each one controls

The Microsoft 365 admin centre is the common entry point. Microsoft Learn describes it as the place to manage users, licences, groups, billing, domains, service health, the Message centre and support requests, with links out to the specialist admin centres for deeper control. It manages only a subset of Entra and Intune roles; the rest are managed in their own portals.

An audit that only looks at the Microsoft 365 admin centre misses Exchange role group members, Intune role assignments, Defender custom roles and Purview role groups.

How Entra directory roles flow into workload permissions

Microsoft Learn states that Entra global roles apply across all of Microsoft 365, and that to limit permissions to Exchange Online features you assign Exchange permissions in the Exchange admin centre or Exchange Online PowerShell instead. The same pattern applies to Purview. The mappings below are the ones Microsoft documents.

• Exchange Administrator is broader than it sounds: it maps to Organization Management, which Microsoft describes as full administrative access to the entire Exchange organisation and the only role group holding the Role Management role by default. Whoever holds it can change who else administers Exchange.
• Entra roles beat scoped Purview assignments: Microsoft Learn notes that if a user has both an Entra role and a Purview role group assignment scoped to an administrative unit, the Entra role takes precedence and the user's effective permissions are unscoped. Scoping in Purview only works if you have not also handed out the Entra role.
• Intune Administrator is privileged: it grants read and write to all Intune data and audit data, and Microsoft advises against using it for day to day administration. In Microsoft Graph and PowerShell it appears as Intune Service Administrator.
• Global Administrator does not automatically hold Defender workspace permissions under Unified RBAC, but it can assign them, including to itself. Treat it as able to reach everything.

The roles that matter most and their least privileged alternatives

Microsoft's guidance on every admin roles page is the same: use the role with the fewest permissions and keep Global Administrator for emergencies. The practical work is knowing which narrower role does the job. The table below combines the Microsoft 365 admin roles page and the Entra "least privileged roles by task" page.

Roles that are more powerful than their names suggest

• Privileged Role Administrator: manages role assignments and PIM settings, so it can make anyone, including itself, a Global Administrator.
• Privileged Authentication Administrator: can reset authentication methods for any user including Global Administrators, which is why Microsoft recommends holding one for recovery and why it must be protected like Global Administrator.
• Application Administrator and Cloud Application Administrator: can add credentials to applications. An application that holds high Graph permissions becomes a route to those permissions for whoever can add a secret to it.
• Helpdesk Administrator: can only reset passwords for users who are not administrators (or who hold a short list of low roles such as Directory Readers and Reports Reader), which makes it a safe default for service desks.
• SharePoint Administrator: does not get automatic access to all sites or OneDrive, but Microsoft Learn notes the role can give itself access to any site or OneDrive.

Entra marks the risky ones for you. Roles and permissions that can delegate directory management, modify credentials, change authentication or authorisation policies, or access restricted data carry a PRIVILEGED label (in preview), with a Privileged column and filter on the Roles and administrators page. See the Least Privilege Techniques Guide for the general method.

Workload role systems in detail

Exchange Online

Exchange uses three kinds of role. Administrator roles are assigned through role groups; end user roles (names beginning with My, such as MyContactInformation) are assigned through role assignment policies; and application roles belong to RBAC for Applications. Roles expose Exchange cmdlets, so a role grants the same task in the admin centre and in PowerShell. Microsoft recommends adding users to role groups rather than assigning roles directly. Application access to mailboxes is a separate problem covered in the Microsoft 365 Application Access Policies and RBAC for Applications Guide.

Intune

Intune has built-in roles that cannot be edited: Application Manager, Endpoint Privilege Manager, Endpoint Privilege Reader, Endpoint Security Manager, Help Desk Operator, Intune Role Administrator, Policy and Profile Manager, Read Only Operator and School Administrator, plus Cloud PC Administrator and Cloud PC Reader where Windows 365 is licensed. Each role assignment has scope groups, which define the users and devices the administrator can manage, and scope tags, which limit which policies, apps and devices are visible. Microsoft recommends choosing specific security groups rather than "Add all users" or "Add all devices". Roles are managed under Tenant administration, Roles, All roles.

Defender

Defender Unified RBAC gives one permissions model on the Permissions and roles page of the Defender portal for Defender for Endpoint, Vulnerability Management, Defender for Office 365 Plan 2, Defender for Identity, Defender for Cloud data, Exposure Management, Defender for Cloud Apps (preview) and Microsoft Sentinel workspaces. Each workload must be activated before Unified RBAC controls it; until then the old models apply. Microsoft Learn states it became the default for new Defender for Endpoint and Defender for Identity tenants in 2025 and for new Defender for Office 365 Plan 2 organisations from July 2026. Initial access to the page needs at least Security Administrator in Entra, but a custom role with the Authorization permission can replace that. Compliance features such as DLP and insider risk stay in Purview RBAC, and Exchange Online PowerShell and Security and Compliance PowerShell keep their own models.

Purview

Purview permissions are managed at Settings, Roles and scopes. A role is a set of tasks (for example Case Management for eDiscovery) and a role group is a set of roles for one solution. Only Organization Management holds the Role Management role. Role group assignments can be given an expiry date for temporary access, except eDiscovery Manager and eDiscovery Administrator, and can be scoped to administrative units. Some service settings, such as auditing and MRM retention, are still managed in the relevant admin centre.

Teams and SharePoint

Teams has seven documented admin roles: Teams Administrator, Teams Communications Administrator, Teams Communications Support Engineer, Teams Communications Support Specialist, Teams Device Administrator, Teams Reader and Teams Telephony Administrator. Pick the Support Specialist role for first line support, as it sees less call data than the Support Engineer. SharePoint site admins need no Microsoft 365 admin role at all.

Designing least privilege with PIM, groups and administrative units

Microsoft's Entra role best practices give a clear target state: least privilege at a specific scope for a specific time, PIM for just in time access, MFA on every admin account, recurring access reviews, fewer than five Global Administrators, fewer than ten privileged role assignments, role-assignable groups, and cloud-only accounts for Entra roles.

• PIM eligible assignments: an eligible user activates a role for a duration up to the configured maximum, giving a justification, passing MFA and, if configured, waiting for approval. Microsoft is explicit that an eligible assignment grants the same access as a permanent one once active; the gain is that it is not there the rest of the time. PIM also sends activation notifications, keeps downloadable audit history and prevents removal of the last active Global Administrator and Privileged Role Administrator. See the Privileged Identity Management (PIM) Guide.
• PIM for Groups: assign roles to a role-assignable group and make people eligible members, so one activation gives every linked role, and the group has no standing owners or members.
• Administrative units: containers of users, groups or devices that limit a role's scope, for example a regional helpdesk that can reset passwords only for its own users. They cannot be nested, adding a group does not bring its members into scope, and a role assigned outside an administrative unit is tenant wide. Each administrative unit administrator needs Entra ID P1.
• Cloud-only admin accounts: Microsoft recommends cloud-native accounts for Entra roles because a compromised synchronised on-premises account can carry that compromise into Entra.
• Licensing: custom roles and Conditional Access need Entra ID P1; PIM needs Entra ID P2 or Entra ID Governance; entitlement management and access reviews need Entra ID Governance or Entra Suite.

Choosing a model by organisation size

Emergency access accounts

Microsoft Learn recommends two or more emergency access accounts that are cloud-only on the onmicrosoft.com domain, not federated or synchronised, permanently assigned Global Administrator and not tied to an individual. They should use phishing-resistant authentication that differs from normal admin accounts, with passkeys (FIDO2) recommended and certificate-based authentication as the alternative where you run a PKI. Exclude them from Conditional Access policies that block or restrict sign-in, using a dedicated group. Send sign-in logs to Azure Monitor and alert at critical severity on every sign-in, then review each use. Validate the accounts at least every 90 days, after IT staff changes and when subscriptions change, and store credentials in separate secure locations. See the Break-Glass Account Guide.

Implementation: moving a tenant to least privilege

1. Inventory every admin path. Export Entra role assignments (active and eligible), Exchange role group members, Intune role assignments, Defender Unified RBAC roles, Purview role groups and partner relationships. Filter Entra roles by the PRIVILEGED label first.
2. Create emergency access accounts and test them before removing any Global Administrator, so a mistake cannot lock you out.
3. Separate admin identities. Give administrators cloud-only admin accounts without mailboxes or day to day licences, and require phishing-resistant MFA for admin roles with Conditional Access. See the Conditional Access Guide.
4. Map tasks to narrow roles. For each person, list what they actually do over a month (sign-in and audit logs help) and pick the least privileged role from Microsoft's task table.
5. Pilot PIM with one team. Convert their assignments to eligible, set activation duration, MFA and justification, and require approval for Global Administrator and Privileged Role Administrator. Watch for activation failures for two weeks.
6. Roll out by role tier. Global Administrator and Privileged Role Administrator first, then the other PRIVILEGED roles, then workload roles. Keep the old active assignment as an eligible one so rollback is a single change.
7. Scope delegated teams. Add administrative units, Intune scope groups and scope tags, and Defender device groups for regional or business unit admins.
8. Schedule access reviews for privileged roles and role-assignable groups, and remove anything not reconfirmed.

Rollback: if a team cannot work after a change, re-add the role as an active, time-bound assignment with an end date rather than a permanent one, and fix the underlying role choice before it expires.

Detection and measurement

Admin role changes are one of the most valuable signals in a Microsoft 365 tenant, because adding a cloud role is a documented persistence and privilege escalation technique (ATT&CK T1098.003 Additional Cloud Roles), usually after an attacker has taken over a valid cloud account (T1078.004 Cloud Accounts).

• Entra audit logs: alert on "Add member to role", "Add eligible member to role", PIM activations of Global Administrator or Privileged Role Administrator, new credentials added to applications and service principals, and consent to application permissions.
• Exchange and Purview: alert on Add-RoleGroupMember and changes to Organization Management, and on new role group assignments in Purview. These appear in the unified audit log; see the Microsoft 365 Unified Audit Log Guide for Detection.
• Emergency accounts: a critical alert on any sign-in, as Microsoft recommends.
• Intune and Defender: review Intune role assignment and scope tag changes and Defender Unified RBAC role edits, since these change who can push code to devices or isolate machines.

Common failure patterns

• Every IT person is a Global Administrator. Often inherited from the person who bought the subscription and never undone. Use the fewer than five target and move everyone else to narrow roles.
• Fixing Exchange rights in Exchange only. Removing someone from Organization Management does nothing while they still hold the Entra Exchange Administrator role that maps back into it.
• Scoped Purview or admin unit roles undone by a tenant wide role. An Entra Compliance Administrator assignment silently overrides a scoped Purview assignment, as Microsoft documents.
• Forgotten application privileges. In the Microsoft Midnight Blizzard breach, a legacy test OAuth application with elevated access was used to grant the Exchange full_access_as_app role and read executive mailboxes. Service principals holding roles or Graph application permissions are non-human admins: inventory them with an owner. See How to review Microsoft 365 app registrations with mail permissions.
• Synchronised admin accounts. An on-premises compromise flows straight into Entra when the admin account is synced, which is why Microsoft recommends cloud-only admin accounts.
• Untested emergency accounts. Accounts caught by a new Conditional Access policy or holding an expired credential fail exactly when they are needed.

Framework mapping

Practitioner checklist

• Export admin assignments from Entra, Exchange, Intune, Defender and Purview, plus partner relationships, into one list.
• Keep Global Administrator assignments below five and privileged role assignments below ten.
• Create at least two cloud-only emergency access accounts with passkeys, alert on every sign-in and test them every 90 days.
• Replace broad roles with the least privileged role for each task, using Microsoft's task tables.
• Make all privileged roles eligible in PIM with MFA, justification and approval for the highest roles.
• Use cloud-only, separate admin accounts and require phishing-resistant MFA for admin roles.
• Scope regional and helpdesk admins with administrative units, Intune scope groups and tags, and Defender device groups.
• Remember that Entra roles override workload scoping; remove the Entra role when you scope in Purview or Exchange.
• Alert on role assignment changes, PIM activations, app credential additions and Exchange role group changes.
• Run access reviews of privileged roles and role-assignable groups every quarter.

Standards and references

• Microsoft Learn: About admin roles in the Microsoft 365 admin center
• Microsoft Learn: Best practices for Microsoft Entra roles
• Microsoft Learn: Least privileged roles by task in Microsoft Entra ID
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management
• Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
• Microsoft Learn: Permissions in Exchange Online
• Microsoft Learn: Microsoft Defender XDR Unified role-based access control
• Microsoft Learn: Permissions in the Microsoft Purview portal

Related NHI Mgmt Group resources: Microsoft 365 Security Guide · Privileged Identity Management (PIM) Guide · Entra ID Security Guide · Break-Glass Account Guide