Your admin count is wrong, and here is why
Ask an auditor how many Global Administrators your Microsoft 365 tenant has, then ask your IT lead, and you can get two different, correct answers. Microsoft splits every role assignment into active and eligible, and the ordinary places people look — a Graph API call, a monitoring dashboard, the admin center's default view — mostly return active assignments only. Eligible admins, who gain the identical access in minutes through Privileged Identity Management, sit one deliberate query away and need their own licence to see at all. This piece covers what active versus eligible means, where common views and APIs draw the line, Microsoft's recommended ceiling on the role, and what to say when somebody asks for the number.
01 / 10
Three answers to one question
Consider a fictional 120-person logistics firm going through its annual insurance renewal. The auditor opens the Microsoft Entra admin center, goes to Roles and administrators, and counts three people holding Global Administrator. The IT lead, working from a different screen, says there are five. Neither one is lying, and neither screen is broken.
The gap is not a mistake. It is two different populations, both genuinely called Global Administrator, produced by two different mechanisms Microsoft built for two different jobs. Knowing which one you are looking at, and which one nobody thought to check, is the actual skill here, not the arithmetic.
02 / 10
What the role actually grants
Start with what is at stake in getting this number right. Microsoft's own description of the role is blunt: it can manage all aspects of Microsoft Entra ID and Microsoft services that use Microsoft Entra identities. That is not one console's worth of access. It is close to all of them, across the tenant.
That reach is why the count is worth arguing about. It is the number an auditor, an insurer or a board is really asking for when they ask how many admins you have, and getting it wrong in either direction, reporting too few or padding it out of caution, is its own small problem.
03 / 10
Active and eligible are not the same list
Microsoft Entra Privileged Identity Management, PIM, splits every role assignment into two kinds, and the definitions are exact enough to quote directly. An active assignment doesn't require a user to perform any action to use the role. Users assigned as active have the privileges assigned to the role. An eligible assignment requires a user to perform one or more actions to use the role — in practice, activating it for a few hours when the work calls for it.
Microsoft is explicit about what eligible does not mean: there's no difference in the access given to someone with a permanent versus an eligible role assignment. The only difference is that some people don't need that access all the time. Eligible is not a smaller grant. It is the same grant, gated behind a step the person has not taken yet today.
None of this exists without a licence. PIM requires either a Microsoft Entra ID P2 or a Microsoft Entra ID Governance licence to run at all, which is worth checking before you assume your tenant even has an eligible population to miss.
04 / 10
Three places to look, three different numbers
The disagreement rarely starts inside PIM itself. It starts upstream, in which page or which API produced the number in the first place. The paths people actually use return three different populations, by design, and none of them is wrong for the job it was built for.
| Where you look | What it returns | Who is missing | Licence needed |
|---|---|---|---|
| Graph: directoryRoles members | Principals assigned to the role | Eligible, not yet activated | None |
| Graph: roleManagement roleAssignments | Active unified role assignments | Eligible, not yet activated | None |
| Graph: roleEligibilityScheduleInstances | Instances of role eligibility | Active or permanent admins | Entra ID P2 or Governance |
| Portal: PIM, Microsoft Entra roles | Eligible roles, Active roles tabs | Nothing, if both tabs are read | Entra ID P2 or Governance |
05 / 10
Why a monitoring tool reports a floor, not a total
Here is our reading, not a line Microsoft publishes about any specific product. A system that counts admins by reading the Graph endpoint that lists a role's members is reading a description that says only that it returns principals assigned to the directory role, with no mention of active or eligible. Getting the eligible population back takes a second, deliberate query against a different endpoint, gated behind the P2 or Governance licence from the previous section.
That is not a defect unique to one vendor. It is a property of where Microsoft put the two populations in its own API surface. A number that looks exact, three Global Administrators, can still be a floor rather than a total. The honest caveat is not that a tool might be wrong. It is that the tool and Microsoft's own simplest view are reading the same narrower population, and the eligible admins are one query further away.
06 / 10
The ceiling Microsoft actually recommends
Whichever number you land on, Microsoft has published an opinion on how large it should be. Its own guidance is direct: Microsoft recommends that you assign the Global Administrator role to fewer than five people in your organization. Global Administrators essentially have unrestricted access, and it is in your best interest to keep the attack surface low.
Cross that line and the portal notices on its own: If you have 5 or more privileged Global Administrator role assignments, a Global Administrators alert card is displayed on the Microsoft Entra Overview page to help you monitor Global Administrator role assignments. That card costs nothing and is worth checking, whether or not it has ever fired for you.
One thing the guidance does not settle: whether fewer than five is meant to include eligible assignments alongside active ones, or count active assignments only. Microsoft states the ceiling without saying which of the two populations from earlier it is counting. Reading it as the full set of people who could become Global Administrator with one activation, not only the ones sitting in the role today, is the stricter interpretation, and it is ours, not a sentence Microsoft wrote.
07 / 10
Break-glass accounts count too, on purpose
Two of your Global Administrators are probably meant to be there permanently. Microsoft is specific about it: organizations should have two cloud-only emergency access accounts permanently assigned the Global Administrator role, held in reserve, unassigned to any individual, for the day everyone else is locked out. A companion page states the instruction even more plainly: Create two or more emergency access accounts.
These accounts sit outside your everyday controls on purpose, not because they are exempt from policy but because a control that can lock out the account meant to unlock everything defeats itself. Microsoft's own guidance is to exclude emergency access accounts from Conditional Access policies that block or restrict sign-in, MFA and compliant-device requirements included, because otherwise such an account might be unusable during the exact emergency scenarios it's designed for.
Do that arithmetic honestly and fewer than five gets tight fast. Two break-glass accounts, a working IT lead, and one more person for a specific project already puts you near the ceiling, before anyone has done anything wrong.
08 / 10
A role that watches without joining the count
If the job is visibility rather than administration, Microsoft ships a role built for exactly that. Global Reader, per Microsoft's own description, can read everything that a Global Administrator can, but not update anything. Assigning that role to whoever needs to monitor the tenant, or to the application a monitoring tool uses, keeps the Global Administrator count exactly where it was, because Global Reader is a separate role, not a smaller edition of the same one.
That is our recommendation, not a line from Microsoft's role reference. The page defines the role; it does not tell you when to reach for it instead of Global Administrator. It follows from the earlier point about what the role grants: if nobody using it needs to change a setting, nobody needs the role built to change settings.
09 / 10
What to actually tell the auditor
Answering how many Global Administrators you have honestly takes a short list, not a single screenshot.
- State the active count first, and name the screen or query it came from.
- Ask whether Privileged Identity Management is licensed and turned on, and if so, add the eligible count as a second, separately labelled number.
- Name the break-glass accounts explicitly and confirm they are excluded from Conditional Access, so the exclusion reads as policy, not an oversight.
- If active plus eligible reaches five, say so, and say what plan exists to bring it down. That is the same number Microsoft's own portal already watches.
10 / 10
Where to start
Before your next audit or renewal, open Roles and administrators, then separately open Privileged Identity Management's Microsoft Entra roles view, and write down both counts for Global Administrator, active and eligible, plus which two accounts are your break-glass pair. That one page answers the question every future auditor is going to ask, and it costs nothing to build.
Disclosure: this is a category we sell into. Avalon CloudSec reads Microsoft 365 and Azure through permissions that are read-only by architecture, every Microsoft Graph permission it holds is a read permission, and Azure access uses Microsoft's own Reader roles, which is how it reports on Conditional Access policy and privileged access without ever holding the access it reports on. Its own admin count carries the same limitation described above: because it reads role assignments through the Microsoft Graph API, a Global Administrator who is eligible but has not activated the role is not included, so the count is a floor, not a total, and the product says so rather than rounding up. To see what that looks like against your own tenant, email support@awservices.org.
Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.
Primary sources
- Microsoft — What is Privileged Identity Management?
- Microsoft — Microsoft Entra ID Governance licensing fundamentals
- Microsoft — Best practices for Microsoft Entra roles
- Microsoft — Manage emergency access admin accounts
- Microsoft — Microsoft Entra built-in roles reference
- Microsoft Graph — List directoryRoles
- Microsoft Graph — List members of a directory role
- Microsoft Graph — List unifiedRoleAssignments
- Microsoft Graph — unifiedRoleAssignment resource type
- Microsoft Graph — List roleEligibilityScheduleInstances
- Microsoft Graph — unifiedRoleEligibilityScheduleInstance resource type
- Microsoft — List Microsoft Entra role assignments
- Microsoft — Assign Microsoft Entra roles in PIM
- Microsoft — Assign Microsoft Entra roles