A useful administrator-role audit answers six questions for every assignment: who or what has access, which role, at what scope, through which assignment path, for what approved purpose, and under which protections. The result should be a reviewed decision register—not an unqualified export of administrator names.
Begin with the decision owner, the tenants in scope, the review date, and the evidence window. Include Microsoft Entra roles and the administrative roles used by Microsoft 365 services. Do not assume that “no Global Administrator” means “no high-impact access.” Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator, application-management roles, and combinations of narrower roles may still create material exposure.
List the tenants, administrative units, Microsoft 365 workloads, evidence sources, licensed governance features, reviewers, and approved read permissions. Avoid using Global Administrator merely to conduct a read-focused review.
Identify built-in and custom roles, mark roles Microsoft labels privileged, and note service-specific administrative roles that affect Exchange, SharePoint, Teams, Intune, security, applications, and identity.
Capture users, groups, and service principals; direct and group-based access; tenant and resource scope; and active, eligible, expired, permanent, or time-bound state where available.
Record group owners, membership, assignment eligibility, nested dependencies, and the process controlling membership. A governed role-assignable group is different from an unexplained direct assignment.
Ask the accountable owner to name the task requiring each role. Compare it with Microsoft’s least-privileged role guidance and document the proposed keep, narrow, make eligible, expire, or remove decision.
Check authentication, Conditional Access treatment, PIM activation settings, sign-in evidence, role-management audit events, alerts, and exception handling. Treat human and workload identities according to how they authenticate and operate.
Verify that at least two cloud-only emergency accounts remain independent, monitored, recoverable, and reserved for emergencies before changing standing privilege.
Create replacement roles first, confirm operational coverage, schedule high-impact removals, preserve evidence of approval, and validate that intended administration still works after the change.
| Field | Question it answers |
|---|---|
| Principal and type | Is this a named user, guest, group, service principal, or emergency account? |
| Role and scope | What can the principal administer, and where? |
| Assignment path and state | Is access direct or group-based, active or eligible, permanent or time-bound? |
| Owner and approved purpose | Who can defend the need, and which task requires the permission? |
| Protection and activity | How is access activated and authenticated, and what evidence shows recent use or change? |
| Decision and due date | Will the assignment be retained, narrowed, made eligible, expired, removed, or investigated? |
Microsoft’s role-assignment documentation explains that assignments link a user, group, or service principal to a role definition and can exist at different scopes. It also warns that an assignment scoped to a single application does not appear in the tenant-scoped assignment list. Preserve scope in the export so those assignments are not silently missed.
Microsoft Entra audit logs show changes made in the directory, while sign-in logs describe authentication activity. Both can strengthen a decision, but neither establishes business purpose by itself.
Review role-management audit activity for additions, removals, eligible assignments, activations, and changes to PIM policy. Confirm actor, target, timing, result, and approval context.
Review the applicable interactive, non-interactive, service-principal, and managed-identity sign-in records. A human administrator and a workload identity leave different evidence and require different controls.
Record retention, licensing, export range, unavailable data, portal or API scope, and identities that cannot be conclusively matched. Do not convert missing evidence into a clean finding.
Microsoft Entra access reviews can recertify role assignments through Privileged Identity Management where licensing supports the feature. Microsoft notes that review results are not applied until the review closes and an administrator applies them. Design reviewers, fallback ownership, decision reasons, recurrence, and result application before relying on automation.
For a deeper evidence-backed review, see the Entra ID Security Assessment, the Global Administrator count guide, and the sample assessment output.
No. Review other privileged and workload-specific roles, custom roles, users, groups, service principals, assignment state, and scope. A single tenant-level Global Administrator list can miss narrower-scope assignments and other high-impact permissions.
Not without validating ownership, emergency access, replacement roles, dependencies, and rollback. Record the decision, stage the change, and verify that required administration still works.
No. Access reviews support recertification, but the reviewer still needs task, owner, scope, activity, and operating context. Results also need to be closed, applied, and checked for exceptions that could not be removed automatically.
There is no useful universal cadence for every role. Set recurrence according to privilege, standing versus eligible access, personnel and technology change, regulatory or customer obligations, and the organization’s ability to act on results.
These links open the current Microsoft Learn documentation in a new tab. Product capabilities and licensing should be confirmed for the tenant being reviewed.
Use the free checker for an initial signal, or request an Entra-focused assessment to validate privileged access, dependencies, and safe remediation priorities.