Skip to content
Browse all topics
Microsoft 365 essentials

Microsoft 365 admin role design

By Emil Björk · Microsoft ecosystem consultant, Gothenburg

How to design admin role assignments for least-privilege Microsoft 365 administration at scale.

3 min read

Share as imagePNG

Microsoft 365 has over 100 built-in admin roles in Entra ID, plus support for custom roles, administrative units, and PIM-driven elevation. Designing role assignments thoughtfully — rather than handing out Global Administrator — is one of the highest-leverage security improvements available.

The principle: least privilege

Every admin should have the narrowest role that lets them do their job:

  • Helpdesk staff resetting passwords need Helpdesk Administrator, not Global Administrator.
  • Exchange admins managing mailboxes need Exchange Administrator, not Global.
  • Compliance officers running eDiscovery need Compliance Administrator, not Global.
  • Security analysts investigating need Security Operator + Security Reader, not Global.
  • License managers assigning licences need License Administrator, not Global.

Global Administrator should be reserved for tenant-wide actions that genuinely require it, not as a convenience role.

The headline roles

For most organisations, focus on:

Identity

  • Global Administrator — never more than a handful.
  • Privileged Role Administrator — assigns other admin roles.
  • User Administrator — user lifecycle.
  • Helpdesk Administrator — password resets, MFA.
  • Authentication Administrator — manage authentication methods.

Workload-specific

Security and compliance

  • Security Administrator — security configuration.
  • Security Operator — security incident response, no config changes.
  • Security Reader — read-only.
  • Compliance Administrator — Purview.
  • Compliance Data Administrator — Purview operations on data.

Global Reader

  • Global Reader — read-only across everything. The most underused valuable role.

Privileged Identity Management

For privileged roles, use PIM:

  • Eligible assignments rather than active.
  • MFA at activation.
  • Justification required.
  • Approval for highest-power roles.
  • Time-bound activation (1–8 hours).
  • Audit trail of activations.

PIM converts "I have Global Admin always" to "I can elevate to Global Admin for 4 hours when needed." Massive security improvement; minor operational overhead.

Administrative units

For delegated administration, administrative units (AUs) scope roles to subsets of the directory:

  • "User Administrator scoped to EMEA AU" — manages users in EMEA only.
  • "Helpdesk Administrator scoped to Manufacturing AU" — resets passwords for manufacturing staff only.

For multi-regional / multi-divisional organisations, AUs are essential. Without them, regional admins need tenant-wide permissions.

Custom roles

When built-in roles don't fit:

  • A regional IT lead needing combination of permissions.
  • An application owner needing specific app-management rights.
  • A specific compliance role needing read-only access to specific Purview features.

Custom roles fill gaps but add complexity. Use sparingly.

Break-glass accounts

For emergency recovery from CA disasters:

  • At least two break-glass Global Administrators.
  • Excluded from all Conditional Access policies.
  • FIDO2 keys with credentials stored offline.
  • Monitored — every sign-in alerts the security team.

Discussed in detail in the break-glass guide; foundational to admin role design.

Role assignment patterns

By function

Most organisations assign roles by job function:

  • IT operations team — workload admins per their specialisation.
  • Help desk — Helpdesk Administrator.
  • Security team — Security Administrator and related.
  • Compliance team — Compliance Administrator.
  • Executive admins — Global Reader for visibility, no change rights.

By project / temporary

For short-term needs:

  • Project work requiring elevated access — assign via PIM with project-duration eligibility.
  • External consultants — guest accounts with specific eligible roles.
  • Audit and assessment — Global Reader for the audit period.

After the project, remove the assignment.

Service-account considerations

For service principals and managed identities, similar principles:

  • Least privilege — only the Graph scopes the app needs.
  • No standing high-privilege assignments.
  • Workload identity PIM (preview) extends PIM to service principals.
  • Periodic review of service-principal permissions.

Audit and review

Quarterly review of admin role assignments:

  • Who has each privileged role?
  • Why?
  • Still needed?
  • PIM active vs eligible breakdown.
  • Break-glass account access verified?

Use PIM access reviews to automate the recertification.

Common pitfalls

  • Too many Global Administrators — convenience over security.
  • No PIM — every admin permanently active.
  • No administrative units — regional admins given tenant-wide.
  • No break-glass exclusion in CA policies — risk of tenant lockout.
  • Custom roles proliferating — easier to add than maintain.
  • No documentation — why specific assignments were made.

For Microsoft 365 customers, admin role design is one of the security investments where small effort produces large risk reduction. Start with built-in roles; layer PIM; scope with AUs where appropriate; document everything; review quarterly.

Frequently asked questions

What is the least-privilege model for Microsoft 365 admins?
Separate admin accounts, no standing Global Administrator (PIM eligible), workload-specific roles for daily work, administrative units to scope helpdesk roles, Global Reader for anyone who only needs to look, and quarterly access reviews of every role assignment.
Should admin accounts have mailboxes?
No. An admin account with no mailbox cannot be phished by email and cannot be targeted by mail-based malware. Admins use their everyday account for email and the admin account only for administration, ideally from a privileged access workstation.
How do I audit who has admin roles?
Entra admin center → Roles and administrators lists assignments per role, with PIM eligible and active views if P2 is in place. Export it monthly with Graph PowerShell (Get-MgDirectoryRoleMember) and diff against the previous month.

Was this useful?

Spot something wrong or want a topic covered? Send it through the contact form.