Conditional access baseline policy coverage gaps entra ID tenants carry are the most basic form of Conditional Access failure there is: not a misconfigured policy, not an over-broad exclusion, but no policy at all covering admin roles, all users, all cloud apps, or device compliance. A tenant can have a dozen Conditional Access policies in the admin center — legacy authentication blocks, risk-based sign-in rules, app-specific exceptions — and still have zero coverage on any one of these four baselines. Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure covers scope drift, exclusions, and legacy authentication inside existing policies. This article is about the question that comes before all of that: does a baseline policy exist at all?
Conditional Access Baseline Policy Coverage Gaps, Entra ID: The Four Blind Spots
Microsoft's own Conditional Access deployment guidance is explicit that a tenant should be able to point to a small set of baseline policies that apply broadly, not a pile of narrow exceptions. As Microsoft puts it in its deployment planning guidance, organizations should create a policy that targets all users, all resources without app exclusions, and requires multifactor authentication — because it "ensures you don't need to update Conditional Access policies every time you onboard a new application." A tenant missing any of the four gaps below has not reached that baseline, regardless of how many other policies it has configured.
No policy targeting admin roles (CA_NO_POLICY_ADMINS)
Microsoft's common Conditional Access policy for administrators recommends requiring phishing-resistant MFA on at least fourteen highly privileged roles at minimum: Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, User Administrator, and others with tenant-wide impact. Without a policy that specifically targets these directory roles — rather than relying on a generic all-users MFA policy that might be excluded or under-scoped for admin sign-ins — a compromised administrator credential faces no additional access control at all.
No policy targeting all users (CA_NO_POLICY_ALL_USERS)
A policy that targets specific groups or apps is not the same as a policy that targets All users. Microsoft's Conditional Access user-assignment documentation notes that All users in a Conditional Access assignment includes B2B guests as well as members, which is exactly the point: partial user coverage, built one group at a time, tends to miss whichever account type nobody thought to add. A tenant with strong MFA on its marketing team and nothing on contractors or newly onboarded staff has this gap, even if the policy list looks full.
No all-cloud-apps coverage (CA_NO_ALL_APPS_COVERAGE)
Microsoft's Conditional Access deployment guidance states plainly that "from a security perspective, it's better to create a policy that includes All resources (formerly 'All cloud apps')" specifically because app-by-app scoping means every newly onboarded SaaS application starts out unprotected until someone remembers to add it to a policy. A tenant that only wrote a Conditional Access policy for Exchange Online and the Azure portal has left every other resource — including third-party OAuth apps and Microsoft Graph — outside any Conditional Access evaluation, since sign-ins to non-targeted resources are governed by nothing.
No device-compliance requirement (CA_NO_DEVICE_COMPLIANCE)
Microsoft documents a Conditional Access policy that requires devices accessing resources be marked compliant with the organization's Intune compliance policies, or Microsoft Entra hybrid joined. Without it, MFA-satisfied sign-ins from unmanaged, unpatched, or personally owned devices reach the same resources as sign-ins from a hardened, compliance-verified corporate laptop — MFA proves who is signing in, not that the device they're using is safe to trust with the session.
⚠️ Warning: These four gaps are independent of each other. A tenant can require MFA for all users and still have zero admin-specific policy, or cover every cloud app for MFA while requiring no device compliance anywhere. Each has to be verified on its own — passing one does not imply the others are covered.
Why "We Have Conditional Access" Doesn't Mean Baseline Coverage Exists
Two things routinely give tenants false confidence that these four baseline gaps are closed when they are not.
Security Defaults is not a substitute, and it disappears the moment any custom policy is created. Microsoft enables Security Defaults automatically for new tenants to provide a minimum MFA baseline, but Security Defaults and Conditional Access policies are mutually exclusive — they cannot be enabled at the same time. The trap: an admin who creates a single narrow Conditional Access policy (for example, blocking legacy auth for one department) silently disables Security Defaults tenant-wide in the process, even though that one policy does nothing to cover admin roles, all users, all apps, or device compliance. The tenant ends up with less baseline protection than it had before, while the admin center still shows "Conditional Access: configured." Azure Tenant Hardening: Fix Insecure Default Settings covers this and other default-setting traps in new tenants.
Microsoft-managed policies cover a narrower slice than "baseline" implies, and start in report-only. Since late 2023, Microsoft auto-deploys a set of Microsoft-managed Conditional Access policies to eligible tenants, including MFA requirements for admins and for all users. This is a genuine improvement, but two limits matter for this article: first, the admin-focused managed policy targets sign-ins to Microsoft admin portals specifically (Azure portal, Microsoft 365 admin center, Entra admin center, and similar), not admin role sign-ins to arbitrary line-of-business apps; second, Microsoft creates these policies in report-only mode by default, which evaluates but does not enforce. A tenant relying on the managed policy without ever checking whether it graduated out of report-only has the same practical exposure as having no policy — a distinct but adjacent failure mode to the report-only drift covered in conditional access report-only mode, stale exclusions.
Detection
Detection for baseline coverage gaps means enumerating what actually exists in the tenant's Conditional Access policy set — not what the tenant intended to configure.
| Signal | Where to check | What it tells you |
|---|---|---|
Policy conditions.users scope across all policies | Microsoft Graph GET /identity/conditionalAccess/policies, or Get-MgIdentityConditionalAccessPolicy (Policy.Read.All) | Whether any enabled policy includes All users/roles versus only specific groups — the direct check for CA_NO_POLICY_ALL_USERS and CA_NO_POLICY_ADMINS |
Policy conditions.users.includeRoles populated with admin directory role IDs | Same Graph query, filtered to enabled state | Confirms a policy exists that specifically targets privileged directory roles, not just a generic all-users MFA rule that could be excluded for admins |
Policy conditions.applications.includeApplications value | Same Graph query | All means All resources/All cloud apps coverage exists; anything else means the policy is scoped to specific apps and every unlisted app is unprotected |
Policy grantControls containing compliantDevice or domainJoinedDevice | Same Graph query | Confirms whether any enforced policy actually requires device compliance or hybrid join, as opposed to MFA alone |
Policy state value (enabled vs enabledForReportingButNotEnforced) | Same Graph query, or the Report-only tab in the admin center | Distinguishes an enforced policy from a Microsoft-managed or custom policy still sitting in report-only — a policy in report-only does not close the gap |
| Conditional Access gap analyzer workbook | Entra admin center → Monitoring & health → Workbooks → Conditional Access section (requires Reports Reader and a Log Analytics workspace) | Purpose-built to surface users, applications, and named locations with no Conditional Access policy applied at all, using real sign-in evidence rather than policy text |
conditionalAccessStatus field on sign-in log entries | Entra admin center sign-in logs, or GET /auditLogs/signIns | notApplied on a sign-in from an admin role, a standard user, or an unmanaged device is the runtime confirmation that the corresponding baseline gap is real, not theoretical |
💡 Tip: Policy review before sign-in review. A gap analyzer workbook or sign-in log query only shows evidence for identities and apps that actually signed in during the observation window. Enumerating the policy set with Graph first tells you definitively whether the four baseline policies exist, independent of whether anyone happened to trigger the gap that day.
Remediation
- Deploy a dedicated admin-role MFA policy first. Target the documented set of highly privileged roles (Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, and the rest of Microsoft's common-policy admin role list), require MFA or a stronger authentication strength, and exclude only break-glass accounts — see Entra ID Break Glass Emergency Access Accounts before creating that exclusion.
- Deploy a baseline all-users policy scoped to
All usersandAll resources. Avoid app-by-app or group-by-group scoping for the baseline layer; add narrower, stronger policies on top for specific high-value apps rather than trying to enumerate every app that needs the baseline. - Add a device-compliance or hybrid-join requirement for at minimum the same admin roles and sensitive resource set covered above, using Intune compliance policies as the enforcement source.
- Check whether Microsoft-managed policies exist and whether they're still in report-only. If they are, either graduate them to enforced after a validated review window, or replace them with tenant-owned policies that cover the broader scope this article describes rather than only Microsoft admin portals.
- If Security Defaults was silently disabled by an earlier narrow policy, don't just re-enable it — replace it with the explicit baseline policies above; Security Defaults and custom Conditional Access remain mutually exclusive, and re-enabling it would remove whatever narrower policy prompted the question in the first place.
- Validate with the What If tool and the gap analyzer workbook for a representative admin account, a representative standard user, and a representative unmanaged device before considering the gap closed — policy configuration and confirmed enforcement are not the same evidence.
How EtcSec Detects This
EtcSec's Azure/Entra checks map directly to the four gaps in this article: CA_NO_POLICY_ADMINS and CA_NO_POLICY_ALL_USERS flag the absence of any enabled policy targeting admin roles or all users respectively, CA_NO_ALL_APPS_COVERAGE flags the absence of a policy scoped to all cloud apps/resources, and CA_NO_DEVICE_COMPLIANCE flags the absence of any device-compliance grant control. AZ_SECURITY_DEFAULTS_NO_CA catches the specific trap described above: Security Defaults disabled with no compensating Conditional Access baseline in place.
ℹ️ Note: EtcSec automatically checks for this vulnerability during every AD/Azure audit. Run a free audit to verify your environment.
Related Reading
- Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure
- How to Audit Microsoft Entra ID Security (Azure AD): Practical Review Guide
- Entra ID Break Glass Emergency Access Accounts: Missing, Unmonitored, Unexcluded
- Azure Identity Security: Why MFA Alone Is Not Enough
- MFA Fatigue: Detection and Prevention for Microsoft Entra ID
- Azure Tenant Hardening: Fix Insecure Default Settings
Primary References
- Plan your Microsoft Entra Conditional Access deployment
- Require MFA for all users with Conditional Access
- Conditional Access Setup: Users, Groups, and Workload Identities
- Targeting resources in Conditional Access policies
- Require MFA for administrators with Conditional Access
- Common Conditional Access policy: Require MFA for admins accessing Microsoft admin portals
- How to require compliant devices with Conditional Access
- Require administrators use compliant or hybrid joined devices
- Microsoft-managed Conditional Access policies for enhanced security
- Automatic Conditional Access policies in Microsoft Entra streamline identity protection
- Configure Security Defaults for Microsoft Entra ID
- Conditional Access gap analyzer workbook
- Get-MgIdentityConditionalAccessPolicy (Microsoft.Graph.Identity.SignIns)
- List conditionalAccessPolicies — Microsoft Graph v1.0
Explore the identity security pages that support this topic