Global Administrator and Privileged Role Administrator accounts can dismantle tenant security if compromised. Standing privileges and missing emergency access both create risk.

Preface

Privileged Entra roles are the highest-value targets. Securing them means removing permanent admin rights and building a resilient recovery path for lockouts and outages. These two goals pull in opposite directions, and the design work is in making both hold at the same time.

Problem

Permanent admin roles on personal accounts create standing privileges and a large blast radius after phishing or credential stuffing. Over-hardening without break-glass accounts can lock administrators out during Conditional Access mistakes or IdP outages.

How the failure happens in practice

Standing privilege

A typical tenant has more Global Administrators than anyone can explain: the original installer, a former contractor, a service desk lead, and an account used by a migration tool. Those accounts read email, browse the web, and sign in from personal devices. When one is phished, the attacker can add credentials to applications, create new admins, change federation settings, and disable logging, all before anyone notices.

Self-inflicted lockout

The opposite failure is a Conditional Access policy that blocks all administrators. Common causes are a location policy with a wrong IP range, a compliant-device requirement before admin workstations are enrolled, an MFA provider outage, or an expired federation certificate. Without an account that sits outside those dependencies, recovery means a support case with Microsoft while the tenant is unmanaged.

Solution

Align with CIS Microsoft 365 Foundations Benchmark Section 1 and NIST SP 800-53 AC-2/AC-3:

  1. Deploy PIM: Eligible roles only, short activation windows, MFA on elevation, justification, and optional approvals.
  2. Create break-glass accounts: At least two cloud-only Global Administrators excluded from standard Conditional Access.
  3. Secure break-glass credentials: Split long passwords or dedicated FIDO2 keys in separate physical safes.
  4. Alert in Sentinel: High severity on any break-glass sign-in or elevation.

Design guidance: PIM

  • Separate admin identities. Administrators use dedicated cloud-only admin accounts, not their daily mailbox account, and those accounts are not synchronized from on-premises AD.
  • Eligible by default. No human holds an active privileged role outside PIM except the break-glass accounts.
  • Least privilege role choice. Most tasks need Exchange, SharePoint, Intune, User, or Security Administrator, not Global Administrator. Keep the number of Global Administrators small; fewer than five is the usual guidance.
  • Role settings by tier. For Global Administrator and Privileged Role Administrator, require approval, a phishing-resistant authentication context on activation, a ticket or justification, and a maximum activation of one to four hours.
  • PIM for Groups. Use role-assignable groups with eligible membership for Azure and application roles, so the same governance applies outside directory roles.
  • Access reviews. Run quarterly reviews of eligible assignments and remove anyone who has not activated in the review period.

Design guidance: break-glass

  • Two or more accounts on the *.onmicrosoft.com domain, cloud-only, permanently active Global Administrators, not tied to any individual's phone or mailbox.
  • No shared dependencies. Do not rely on federation, on-premises MFA servers, a single network location, or a device compliance requirement.
  • Strong but independent authentication. With Microsoft enforcing MFA on admin portals, a FIDO2 key or certificate-based authentication is the practical option. Store keys in separate locations with documented custody.
  • Conditional Access exclusions with a twist. Exclude the accounts from standard policies, but consider one dedicated policy that requires phishing-resistant MFA for one account while the other stays fully excluded, so a broken policy cannot lock out both.
  • Monitored, not hidden. Any sign-in is an incident until proven otherwise.

Implementation steps

  1. Export all active and eligible role assignments (see the script below) and record a justification for each.
  2. Create and test the break-glass accounts first, before tightening any policy.
  3. Create dedicated admin accounts and convert active assignments to eligible in PIM.
  4. Configure role settings per role tier, starting with Global Administrator and Privileged Role Administrator.
  5. Add the break-glass accounts to an exclusion group used consistently by every Conditional Access policy.
  6. Deploy the detections below and route them to an on-call channel, not a shared mailbox.
  7. Test break-glass sign-in at least quarterly and after any change to Conditional Access or authentication methods.

PowerShell: Audit Active Privileged Assignments

Role assignment schedules expose start and expiry inside ScheduleInfo. An assignmentType of Assigned is a direct active assignment, while Activated is a current PIM elevation. Assignments with no expiration are standing privilege. 

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -All -Filter "assignmentType eq 'Assigned'" |
    Select-Object PrincipalId, RoleDefinitionId,
        @{n='StartDateTime'; e={$_.ScheduleInfo.StartDateTime}},
        @{n='EndDateTime';   e={$_.ScheduleInfo.Expiration.EndDateTime}},
        @{n='ExpirationType'; e={$_.ScheduleInfo.Expiration.Type}} | Format-Table

Monitoring and detection

Alert on any break-glass sign-in, successful or failed. Use object IDs rather than UPNs so a rename does not silently break the rule:

let BreakGlass = dynamic(["<object-id-1>", "<object-id-2>"]);
union SigninLogs, AADNonInteractiveUserSignInLogs
| where UserId in (BreakGlass)
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress, AppDisplayName, Location

Track PIM activations and role assignments made outside PIM, which often indicate bypass or persistence:

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has "PIM activation" or OperationName has "outside of PIM"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = tostring(TargetResources[0].userPrincipalName)
| project TimeGenerated, OperationName, Actor, Target, Result

Also alert on changes to the break-glass accounts themselves: authentication method changes, group membership, and Conditional Access exclusion edits.

Common mistakes

  • Making break-glass accounts PIM-eligible, which adds the very dependency they are meant to avoid.
  • Storing break-glass passwords in the same password vault that depends on Entra sign-in.
  • Never testing the accounts, then discovering an expired key or a forgotten exclusion during an outage.
  • Converting admins to eligible but leaving activation at eight hours with no approval, which recreates standing privilege during the working day.
  • Leaving service accounts with permanent Global Administrator because "automation needs it"; use scoped app permissions or workload identities instead.

Where to start

Build and test two break-glass accounts first, because every later hardening step is safer once recovery exists. Then count your Global Administrators, move them to eligible PIM assignments on separate admin accounts, and turn on the sign-in alert before you consider the work done.