Admins with Risky MFA Settings: Privileged Account Takeover Risk

Admin accounts are the highest-value targets in any Microsoft 365 environment. When a privileged user — a Global Admin, Exchange Admin, Security Admin, or similar — is using a weak or bypassable MFA method, the protection MFA is supposed to provide can be defeated through attacks that work reliably in the real world.

Overe flags admin accounts where MFA is missing entirely, relies on SMS or voice calls, uses push notifications without number matching, or where the account is excluded from Conditional Access policies that enforce strong authentication. Any of these conditions creates a credible path to full tenant compromise.

Not all MFA is equal. SMS-based MFA can be defeated through SIM swapping, SS7 interception, and social engineering attacks on mobile carriers. Push-only notifications without additional verification are vulnerable to MFA fatigue — attackers send repeated approval requests until a tired or distracted admin accidentally accepts. Phishing-resistant methods such as FIDO2 security keys and certificate-based authentication are not vulnerable to either technique.

For privileged accounts specifically, the consequence of a bypass is not a single compromised user. It is the entire tenant.

• Attacker phishes or credential-stuffs an admin account, then defeats SMS MFA through a SIM swap or SS7 attack
• Repeated push notification requests sent to an admin until one is accepted (MFA fatigue / push bombing)
• Full tenant access obtained, including the ability to create new admin accounts and disable existing security controls
• Conditional Access policies, audit logging, and Defender settings modified or disabled silently
• Backdoor admin accounts created for persistent access, surviving password resets and MFA re-registration
• 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

There are very few legitimate reasons for an admin account to rely on weak MFA. Some scenarios require judgment rather than automatic remediation.

Break-glass or emergency access accounts are sometimes intentionally excluded from certain Conditional Access policies to ensure access during an outage or lockout. These should be documented, monitored closely, and paired with compensating controls. An exclusion that exists without documentation or a named owner is not a break-glass account — it is a gap.

Some environments are mid-transition away from legacy authentication and may have temporary weaknesses. These should be time-bound with a clear remediation plan, not treated as an acceptable ongoing state.

An admin account without phishing-resistant or strongly verified MFA should never be the permanent default for any privileged identity.

Before modifying any admin account's authentication settings:

• Confirm which admin roles the account holds and whether they are permanently assigned or eligible via Privileged Identity Management (PIM)
• Identify whether this is a named individual account, a service account, or a shared or break-glass account
• Check when the MFA method was registered and whether it has been modified recently
• Review the account's sign-in history for unusual locations, unfamiliar devices, or off-hours activity
• Confirm whether the account is explicitly excluded from any Conditional Access policy enforcing strong MFA — and whether that exclusion is documented
• Check whether Microsoft Authenticator is registered and whether number matching is enabled
• Review related Overe alerts or Defender incidents tied to this identity before making changes
• Confirm with the account owner or their line manager that they are aware of and actively using their MFA registration

1. Use Overe to confirm the full list of admin accounts with weak or missing MFA across the tenant before acting on any individual account
2. Prioritise Global Admins, Privileged Role Admins, Exchange Admins, and Security Admins first
3. For accounts with no MFA registered, enforce registration via Entra ID and require it through Conditional Access before the next interactive sign-in
4. For accounts using SMS or voice MFA, guide the user to register a stronger method — Microsoft Authenticator with number matching, or a FIDO2 security key — before removing the weaker method
5. Enable number matching in the Microsoft Authenticator policy if it is not already active tenant-wide
6. For accounts excluded from MFA Conditional Access policies, review the exclusion — if it is not documented and intentional, remove it
7. Where PIM is available, convert permanent admin role assignments to eligible assignments to reduce standing privileged access
8. Document any accepted exceptions with a named owner, a review date, and compensating controls

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Microsoft: Configure Microsoft Entra multifactor authentication - https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-getstarted

Microsoft: Number matching in Microsoft Authenticator - https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match

Microsoft: Secure access practices for administrators in Microsoft Entra ID - https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning

• Users with risky MFA settings
• Conditional Access MFA bypass paths
• Conditional Access exclusions creating risk
• Privileged role assignments without clear ownership
• Privileged Identity Management not used for admin roles
• Break-glass accounts