MFA Not Enforced All Users Conditional Access Entra: The Critical Gap Admin-Only Policies Miss

MFA Not Enforced All Users Conditional Access Entra: What It Actually Means

MFA not enforced all users conditional access Entra is a distinct, common, and Critical-severity gap in Microsoft Entra ID — and it is not the same failure as having no Conditional Access at all. A tenant can pass every "do you have Conditional Access" checklist, show a policy that literally targets All users, and still leave every non-admin account reachable with a password alone. That happens when the policy's grant control requires something other than MFA (device compliance, for example), or when MFA enforcement is scattered across several role-scoped or app-scoped policies that each look solid on their own but never add up to blanket coverage.

This is the narrower, more common, and more dangerous sibling of two better-known problems:

• Zero Conditional Access policy of any kind targeting all users. That is the baseline-coverage failure — see Conditional Access Baseline Policy Coverage Gaps in Entra ID for tenants with no policy at all covering admin roles, all users, all cloud apps, or device compliance. This article assumes a policy targeting all users already exists; the gap here is narrower and easier to miss — the policy exists, but it does not require MFA.
• MFA required for admins only. Most Conditional Access hardening starts here, and for good reason — see Azure Identity Security: Why MFA Alone Is Not Enough. But an admin-scoped MFA policy, however well built, structurally cannot protect the accounts it was never assigned to. Standard users sign into the same mailboxes, the same SharePoint sites, and the same line-of-business apps admins do; they are not a lower-value target, they are simply an unprotected one.

This is also why the gap is easy to miss even for teams that have already done real hardening work. An organization that deployed admin-scoped MFA per MFA_NOT_ENFORCED_ADMINS or locked down Global Admin authentication per PA_GLOBAL_ADMIN_NOT_MFA has done the harder-looking work first, and reasonably assumes the easier, broader case — every remaining user — is already covered by extension. It structurally is not: admin-scoped and all-user policies are built on different assignment conditions in Entra ID, so completing one leaves the other's coverage exactly where it started, at zero.

Two Separate Templates, Two Separate Secure Score Actions

Microsoft does not model "require MFA" as a single control. In the Conditional Access template gallery, Require multifactor authentication for admins and Require multifactor authentication for all users are listed as two separate templates. Both appear together under Microsoft's own "Secure foundation" category — the set Microsoft explicitly recommends deploying as a group — and both appear again, still as two separate entries, under the "Zero Trust" category. Neither template description claims to cover the other's ground, in either list.

The same split exists in scoring. Microsoft Entra ID's Identity Secure Score tracks "Require multifactor authentication (MFA) for administrative roles" and "Ensure all users can complete MFA" as two distinct improvement actions in its own catalogue. A tenant can max out the first and score zero on the second; Secure Score does not treat them as redundant, and a reviewer reading a Conditional Access export shouldn't either.

The all-users action is also scored as a percentage of total users protected, not as a binary pass/fail. In Microsoft's own worked example, having 5 users protected out of 100 total users nets roughly 0.53% of a possible 10.71% for that control — meaning most tenants that have "started" on all-user MFA are still carrying most of the exposure the control is meant to close.

How Fragmented Coverage Hides the Gap

The admin-MFA template and the all-users-MFA template are not scoped the same way, and that difference is exactly how a gap survives a casual policy review:

• Require multifactor authentication for admins assigns under Directory roles, and only to a defined list of built-in roles — Global Administrator, Application Administrator, Authentication Administrator, Privileged Role Administrator, Security Administrator, and others named explicitly in Microsoft's documentation. Microsoft's own warning is direct: "Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles." A custom "IT Support" role with elevated permissions, or a role assigned only at the administrative-unit level, is invisible to this policy even while it is enabled and enforced.
• Require multifactor authentication for all users assigns under Include: All users, with exclusions limited to break-glass accounts and directory-synchronization service accounts. There is no role condition for a user to fall through.

Because the two policies use different assignment models, a tenant can accumulate several genuinely-enforced MFA policies — one scoped to Global Admins, one scoped to a specific finance app, one triggered only by risky sign-in — and still never have deployed the one policy whose Include is literally All users, whose Target resources is All resources, and whose grant control requires MFA. Each individual policy is real; none of them, summed together, equal the baseline Microsoft recommends. Entra ID Conditional Access Gaps covers the broader pattern of exclusions and scope mismatches that let a Conditional Access set look complete while leaving real exposure in production. Azure Privileged Access: Too Many Global Admins covers the parallel failure on the privileged side, where standing admin roles and PIM gaps compound the same underlying weakness from the other direction.

Detection

Confirming this gap does not require guessing — Microsoft Entra ID logs the exact authentication stage reached on every sign-in, per user, per app.

Per Microsoft's own guidance for finding administrator MFA gaps: "Any sign-in where Authentication requirement is Single-factor authentication means there was no multifactor authentication policy that was required for the sign-in." That guidance is written for administrators specifically, but the field itself is not role-scoped — it is a property of the sign-in event, so the same check applies to any user population, admin or not.

authenticationRequirement is exposed on the signIn resource in the Microsoft Graph beta endpoint — it is not present on the stable v1.0 signIn resource — and it supports $filter with the eq and startsWith operators:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=authenticationRequirement%20eq%20%27singleFactorAuthentication%27

The filter is percent-encoded — %20 for the spaces, %27 for the quotes — so the request works pasted into a command-line client as well as into Graph Explorer. Left unencoded, the raw spaces make tools like curl reject the URL locally, before it is ever sent.

Or with the Microsoft Graph PowerShell SDK's beta module:

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgBetaAuditLogSignIn `
  -Filter "authenticationRequirement eq 'singleFactorAuthentication'" `
  -Top 50 `
  -Property UserPrincipalName, AppDisplayName, CreatedDateTime, AuthenticationRequirement

Remediation

1. Deploy Microsoft's all-users MFA template

Check first whether Microsoft already put one in the tenant. Microsoft-managed policies are created and deployed by Microsoft directly into eligible tenants, and one of them is named Multifactor authentication for all users — it "covers all users in your organization and requires them to use multifactor authentication whenever they sign in." It arrives inert: "The policy is automatically created in your tenant in a Report-only state." Microsoft then enables it "no less than 30 days after they're introduced in your tenant if they're left in the Report-only state," notifying tenants two weeks beforehand. Filter on Microsoft in the Created by column before you build a duplicate.

Otherwise use the Conditional Access template gallery, or build the equivalent policy directly:

• Under Assignments → Users, set Include: All users.
• Under Exclude, add only your organization's documented break-glass/emergency-access accounts and, if you use hybrid identity sync, the Directory Synchronization Accounts role — not a broad "IT team" exclusion that quietly recreates the gap.
• Under Target resources, set Include: All resources, with no app exclusions.
• Under Grant, choose Require authentication strength and select the built-in Multifactor authentication strength.

2. Roll out in report-only mode, and confirm it actually leaves that mode

Review projected impact through Policy impact or the Conditional Access Insights and Reporting workbook before switching Enable policy to On — this is how you catch a break-glass, service, or legacy-auth account that would otherwise be unexpectedly blocked. A policy left in report-only mode indefinitely, or an exclusion list that quietly grew past its original scope, enforces nothing while still showing "On" — check this after rollout, not only at creation.

3. Validate coverage with the What If tool

Run the What If tool for a sample of ordinary, non-admin users — not just the admin accounts already covered by the other policy — to confirm the new policy actually applies to them. Policies that are enabled and policies in report-only mode are both included in an evaluation run, so a policy still staged in report-only will show up here. Read the output as a simulation rather than a guarantee: Microsoft notes the tool "doesn't test for Conditional Access service dependencies," and that conditions you leave unspecified are conditions it cannot evaluate.

4. Don't let this substitute for admin-scoped MFA, or the reverse

If the admin-scoped MFA policy is not deployed yet either, treat it as a second, separate action. See Azure Identity Security: Why MFA Alone Is Not Enough and Azure Privileged Access: Too Many Global Admins. Deploying one policy does not substitute for the other; both are on Microsoft's own "Secure foundation" list for a reason.

5. Move beyond baseline MFA once coverage is stable

Once broad MFA coverage is enforced and stable, move from the baseline Multifactor authentication strength toward phishing-resistant or passwordless methods for the users who can support them — see Entra ID Passwordless MFA Registration Change.

How EtcSec Detects This

EtcSec's Azure/Entra audit checks for MFA_NOT_ENFORCED_ALL specifically: a Conditional Access configuration where no policy targeting all users and all (or effectively all) cloud apps carries a grant control that requires MFA or an MFA-equivalent authentication strength. It is evaluated independently from MFA_NOT_ENFORCED_ADMINS, PA_GLOBAL_ADMIN_NOT_MFA, and CA_NO_POLICY_ALL_USERS — clearing one of those checks does not clear this one.