The Global Admin Hardening Playbook: 8 Levels from Exposed to Locked Down

Here is a pattern that shows up in otherwise well-run tenants: MFA and Conditional Access deployed for every user, carefully tuned, fully enforced. And then the Global Administrator accounts, the ones that can take over mail, SharePoint, Teams, and Defender in a single session, carry the exceptions. "Just for testing." "It might break the automation."

Attackers live for those cracks. Privileged accounts are the number one target precisely because one compromised Global Admin means full tenant control, and the fallout is real: downtime, legal exposure, regulatory headaches, and direct financial loss.

This playbook is a progressive, 8-level framework for securing admin accounts. Think of it as a progress bar for the tenant: each level adds resilience, and the goal is to move from red to yellow to green.

Why do strong tenants have weak admins?#

Even in well-managed environments, the same findings repeat:

• Too many Global Admins, often created during migrations or vendor setups and never removed
• Service accounts with GA for third-party integrations, left out of Conditional Access
• MFA exceptions for "testing" or "it might break automation"
• Global Admin tied to a daily-driver user who also lives in email, Teams, and SharePoint
• Shared credentials saved in notes, chats, or unsecured vaults

One bad exception can unravel the strongest user controls. The eight levels below close them in order, from visibility to continuous review.

Phase one: see what you are defending#

Level 1. Inventory every admin#

You cannot protect what you cannot see.

Where to look:

• Entra admin center → Roles & administrators → Global administrator
• Export active assignments and review Last sign-in, User type, and Usage

Questions to answer per account:

• Is it active?
• Does it have MFA, and which MFA method?
• Who has access?
• Where are the credentials stored?
• Is it tied to a regular user logging in every day?
• Which accounts are the break-glass users?

Quick win: remove or disable any GA created for a retired integration. It shrinks the attack surface immediately.

Level 2. Establish and name break-glass accounts#

Emergency access accounts exist so a Conditional Access failure or outage cannot lock you out of your own tenant.

Best practice:

• Create two cloud-only break-glass accounts with long, random passwords
• Exclude exactly one from Conditional Access; include the other
• Store credentials in a secure vault (consider splitting password and keys among custodians)
• Use a clear naming convention (for example EMERGENCY-GA-01, EMERGENCY-GA-02)
• Monitor them like crown jewels: no interactive use outside an emergency
• Full guidance: Best Practices for Break Glass Accounts

Phase two: harden how admins authenticate#

Level 3. Validate MFA and move toward phishing-resistant methods#

Not all MFA is equal, and admin accounts deserve the strongest available.

Actions:

• Review Authentication methods → User registration details for every admin
• Disable weak methods tenant-wide (email OTP, and SMS where feasible)
• Enable phishing-resistant options: FIDO2 passkeys, Windows Hello for Business, certificate-based authentication
• Create a Conditional Access policy for admin roles that requires an authentication strength of phishing-resistant

Level 4. Enforce least privilege and ditch permanent GA#

Fewer standing privileges means a smaller blast radius.

Do this:

• Convert "always-GA" users to role-appropriate rights (Intune Admin, Exchange Admin, Global Reader)
• Replace user-based service accounts with service principals, app registrations, or managed identities using delegated or application permissions scoped to the minimum required
• Target: 2 to 4 Global Admins maximum per tenant, per Microsoft and CIS guidance

Vendor pushback? Challenge any "needs Global Admin" claim. Most integrations can run on least-privilege Graph permissions.

Level 5. Isolate admin work to dedicated devices#

Admins should not manage tenants from the same machine they browse the web on.

Options, from good to best:

• Good: Conditional Access requiring a compliant device for admin roles
• Better: an isolated admin VM (physical device or Azure) with a hardened baseline
• Best: a full Privileged Access Workstation (PAW) model plus named locations

Phase three: remove standing privilege and watch for change#

Level 6. Just-in-time elevation with PIM (requires P2)#

Privileged Identity Management removes standing privilege entirely: admins elevate only when needed.

PIM setup checklist:

• Make admins Eligible for roles, not Active
• Require justification and optionally a ticket ID for activation
• Configure approval for sensitive roles
• Limit activation duration (1 to 4 hours)
• Notify security contacts on activation

The result: even if credentials are stolen, no admin rights exist until a PIM activation occurs, and your controls stand in front of it.

Level 7. Alert on role assignments and unusual sign-ins (requires P2)#

Early detection means fast containment. Three places to wire it up:

• In PIM, enable notifications when members become Eligible or Active
• In Microsoft 365 Defender, create custom alert policies for "Add member to role" events and route them to a shared SOC mailbox
• Advanced: stream AADAuditLogs to Log Analytics or Sentinel and alert on Global Admin changes with KQL. Microsoft's walkthrough: Configure a Log Analytics workspace and a custom workbook (opens in new tab)

Level 8. Access reviews on a schedule (requires P2)#

Permissions creep is drift in its purest form. Access Reviews keep it from accumulating:

• Identity Governance → Access Reviews → New review
• Scope to Global Administrator (Active and Eligible)
• Frequency: quarterly, with a 14 to 15 day review window
• Reviewers: selected owners or security staff (never "self" for service accounts)
• Auto-apply: optional; we recommend caution for service accounts
• Require a reason, enable reminders, and notify through your ticketing system

The admin inventory checklist (copy and paste)#

Drop this into your internal wiki or a shared doc for every tenant:

• List all Global Admin assignments (active and eligible)
• For each GA: active? Still needed?
• MFA present? Which methods? (Aim for phishing-resistant)
• Credential storage: where, who has access, rotation cadence
• Tied to a daily user? (Move to a separate admin identity)
• Service accounts: replace with a service principal or app registration
• Break-glass: 2 cloud-only accounts, naming, storage, monitoring
• Least privilege: reduce GA count; use scoped roles
• PAW or compliant device enforced for admin sign-in
• PIM enabled with approvals and justification
• Alerts configured for role changes and unusual admin sign-ins
• Access Reviews scheduled quarterly

Automating the whole playbook#

Every check in this playbook can be done by hand, once. The hard part is doing it consistently across every tenant, every quarter, and proving it. CloudCapsule runs these exact Global Admin checks automatically, flagging excessive admins, weak or absent MFA, daily-use identities, and Conditional Access exclusions across all your tenants.