Require MFA for Administrators: Privileged Account Takeover Protection

Why this risk matters

Admin accounts are the highest-value target in any Microsoft 365 environment. A single compromised Global Admin or Exchange Admin can reconfigure the entire tenant — disabling security controls, creating backdoor accounts, exfiltrating data, or handing over persistent access to an attacker — without ever triggering an alert. Yet many organisations still rely on passwords alone for privileged accounts, or apply MFA inconsistently across their admin population.

Microsoft's own data shows that MFA blocks over 99% of account compromise attacks. For admin accounts specifically, the consequence of skipping this control isn't a single compromised inbox — it's the entire tenant. A policy that requires strong MFA specifically for administrator roles is one of the most important security baselines you can put in place.

Note that "strong MFA" for admins means more than SMS or voice call. Phishing-resistant methods — FIDO2 security keys or certificate-based authentication — are the recommended standard. At minimum, Microsoft Authenticator with number matching should be enforced for all privileged identities.

What happens if this is abused

  • Attacker obtains admin credentials through phishing or credential stuffing and signs in without any MFA challenge
  • Full tenant access gained: Conditional Access modified, audit logging disabled, Defender settings changed
  • Backdoor admin accounts or service principals created for persistent access that survives the initial remediation
  • All user mailboxes, Teams conversations, SharePoint sites, and connected applications accessible without further authentication
  • Customer or employee data exfiltrated at scale with no further interaction required
  • Existing MFA and Conditional Access policies weakened or removed before the compromise is detected

When this is expected or acceptable

There are very few legitimate exceptions to MFA for admin accounts:

  • Break-glass emergency access accounts are sometimes intentionally excluded from MFA Conditional Access policies to ensure access during an outage or identity provider failure — but these must be documented, closely monitored, and paired with strong compensating controls
  • Service accounts with admin roles that perform automated tasks cannot complete MFA challenges — these should use certificate-based or client credential authentication, not be excluded from MFA as interactive users

An exclusion that exists without documentation or a named owner is not a break-glass account. It is a gap.

Checks to perform before taking action

  • Identify all accounts with admin role assignments in Entra ID — including permanent assignments and PIM eligible assignments
  • Check which of these accounts are already covered by a Conditional Access policy requiring MFA
  • Identify any admin accounts excluded from MFA policies and confirm whether each exclusion is documented and intentional
  • Confirm which MFA methods are registered for each admin account — SMS or voice call should be flagged for upgrade
  • Review whether any admin accounts are shared between multiple people (they shouldn't be)
  • Check whether break-glass accounts are separately documented and whether their exclusions have compensating controls

Safe remediation steps

  1. Create a dedicated Conditional Access policy scoped to directory role holders (Global Admin, Exchange Admin, Security Admin, and similar) requiring MFA on every sign-in
  2. Deploy in Report-only mode and review which admin sign-ins would be challenged
  3. Confirm each admin has a compliant MFA method registered — assist any who haven't with registration before enforcing
  4. Enable number matching in the Microsoft Authenticator authentication policy if not already active
  5. Enforce the policy for all admins, with only documented break-glass accounts excluded
  6. Where possible, move toward phishing-resistant MFA (FIDO2 or certificate-based) for the most privileged roles
  7. Use Privileged Identity Management (PIM) to convert standing admin roles to just-in-time eligible assignments for additional protection

Related risks and follow-on checks

After enforcing this control, review these related areas:

  • Admins with Risky MFA Settings — the GSO finding that surfaces admin accounts using weak or missing MFA; this policy addresses the finding at the policy layer
  • Require MFA for Azure Management — deploy alongside this policy to ensure the Azure portal and control plane are also protected
  • Unprotected Admin Portals — ensure admin portal Conditional Access policies enforce at least equivalent protection
  • Break-Glass Accounts — review emergency access account configuration as part of this rollout
  • CA MFA Bypass Paths — confirm there are no Conditional Access gaps that allow admin sign-ins to bypass MFA
TBD CTA