Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure

Entra ID conditional access gaps are the difference between policies that look broad in the admin center and controls that actually evaluate the users, guests, apps, protocols, and workload identities that matter in production. A tenant can show green-looking Conditional Access coverage and still leave real exposure through exclusions, legacy protocols, guest paths, or service principals that were never in scope.

This article treats Conditional Access as an evidence problem, not a screenshot problem. The goal is to show what counts as a real gap, which Microsoft signals prove it, how to remediate without locking out legitimate access, and how to validate that the safer state is really enforced after the change. For broader tenant review, start with How to Audit Microsoft Entra ID Security.

What Counts as Entra ID Conditional Access Gaps?

A Conditional Access gap is any mismatch between the access policy you think you enforce and the sign-ins Microsoft Entra actually evaluates. Microsoft describes Conditional Access as a policy engine that brings signals together, applies assignments and conditions, and then grants, blocks, or further constrains access. It is powerful, but it is not self-proving. A policy only reduces risk when it targets the right identities and resources, evaluates the relevant protocol path, and produces evidence in sign-in and audit logs.

In practice, that means a gap can come from several different causes:

• a policy is missing entirely for a sensitive scope
• a policy exists but excludes the users or roles that matter most
• a policy protects users but not workload identities
• a policy is scoped to the wrong resources or client paths
• a policy uses a weaker grant than the resource really needs
• a policy sits in report-only mode and never graduates to enforcement

Microsoft also notes that Conditional Access is evaluated after the first authentication step. That matters because the article should not treat Conditional Access as a magic pre-authentication control. It is a policy decision layer around a sign-in, and the quality of that decision depends on scope, telemetry, and policy design.

Why Conditional Access Can Still Leave Real Exposure

Teams usually think about Conditional Access as a binary state: enabled or not enabled. Real exposure is messier. Microsoft Entra evaluates all policies that apply to a sign-in and the user must satisfy all applicable requirements before access is granted. The hard part is that many sign-ins that should have been governed never become "applicable" in the first place.

A common example is scope drift. Security teams often believe that a broad policy covers everyone because it targets All users. Microsoft documents that All users includes B2B guests, which is useful, but it does not mean every identity path is covered. Workload identities are a separate assignment class, and user-scoped policies do not automatically govern service principals. If a tenant relies on app registrations, automation accounts, or backend integrations, Azure App Registrations: Over-Privileged Tenant Apps is often part of the same review.

Another example is the difference between a broad grant and a strong grant. Require multifactor authentication and Require authentication strength are not the same control. If the business expectation is phishing-resistant authentication for administrator roles or sensitive apps, a generic MFA requirement may be weaker than the written intent. That is why Azure Identity Security: Why MFA Alone Is Not Enough often sits next to a Conditional Access review, and why MFA Fatigue: Detection and Prevention for Microsoft Entra ID should be part of the same authentication discussion.

The last recurring problem is validation drift. Policies accumulate exclusions, report-only stubs, overlapping templates, and emergency exceptions. The portal still shows many policies, but the sign-ins that matter may be slipping through unchallenged or being evaluated by weaker paths than intended.

Scope Gaps: Users, Guests, Roles, Resources, and Workload Identities

Users, directory roles, and exclusions

The first review step is to map who the policies actually target. Conditional Access can include or exclude all users, selected users and groups, directory roles, guests and external users, and workload identities. A tenant with strong user coverage can still leave privileged roles or privileged exclusions under-governed. This is especially relevant where privileged access is already weak, as described in Azure Privileged Access: Too Many Global Admins.

Emergency access accounts are the clearest example of an intentional exclusion. Microsoft recommends excluding emergency access accounts from Conditional Access policies to prevent tenant lockout, but that recommendation does not justify broad convenience exclusions. Each exclusion should have a narrow reason, an owner, and active monitoring. If the same break-glass account is used for normal administration, the control gap is operational, not theoretical.

Guests and external users

Guest and external access deserves its own review, not a quick assumption that All users solved it. Microsoft Entra lets you target specific guest and external user types, and external access behavior is influenced by cross-tenant trust settings. For example, when you use authentication strengths for external users, Microsoft documents that the resource tenant also evaluates MFA trust from the home tenant. That means guest coverage is not just a policy existence question. It is a scope and trust question. This is one reason Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant is often adjacent to Conditional Access findings.

Resources, apps, and user actions

A second scope problem is targeting the wrong resource set. Policies can be assigned to all resources or selected resources. If the tenant protects Microsoft admin portals but not the line-of-business or SaaS applications users actually reach first, the control story is incomplete. The same problem appears when teams focus on one cloud app screenshot instead of the resource path that an attacker would actually reuse after credential theft. Identity attacks that exploit valid sessions or consent paths often chain into these policy gaps, which is why Device Code Phishing: How OAuth Device Flow Compromises Entra ID Accounts belongs in the same review universe.

Workload identities

Service principals and workload identities are the most common blind spot in otherwise mature tenants. Microsoft documents that calls made by service principals are not blocked by Conditional Access policies scoped to users, and that Conditional Access for workload identities must be used when those identities need policy treatment. In practice, this means a tenant can show strong user MFA coverage while leaving automation and application identities outside the Conditional Access model entirely.

That does not mean every workload identity needs the same policy. It means the tenant must prove it knows which workload identities exist, which ones are excluded by design, and which ones still depend on weaker patterns that should be replaced with managed identities where possible.

Control Gaps: MFA, Authentication Strengths, Legacy Authentication, and Risk Policies

MFA coverage is not the same as strong authentication design

A tenant can have many policies that require MFA and still leave high-value access on weaker methods than expected. Microsoft documents authentication strengths as a Conditional Access control that restricts which authentication method combinations can be used to access a resource. That distinction matters whenever the policy goal is stronger than "any MFA will do." For high-value admin roles or sensitive applications, the difference between a broad MFA grant and a phishing-resistant or passwordless strength should be explicit.

Legacy authentication remains a real gap when it is still reachable

Legacy authentication deserves precision because it is often discussed too loosely. Microsoft states that legacy authentication protocols do not support multifactor authentication and do not pass device state information. Microsoft also recommends blocking authentication requests that use legacy protocols and notes that these paths remain heavily used in password spray and credential stuffing activity.

The defensible formulation is this: legacy authentication is a gap when those protocols remain reachable for identities or resources that the tenant believes are protected by modern Conditional Access requirements. Some tenants close that gap with a dedicated block policy. Others rely on broader grant controls that apply to all client apps. The review task is not to memorize a template. It is to prove, with sign-in evidence, that legacy clients are either blocked or absent. If the tenant is already investigating weak first-factor hygiene, tie this review to Password Spraying: Detection and Prevention for Active Directory and Entra ID.

Risk-based policies are not implied by general Conditional Access maturity

A tenant without sign-in risk or user risk policies is not automatically misconfigured, because those policies depend on Microsoft Entra ID Protection capabilities and the relevant licensing tier. But if the security narrative claims risk-adaptive access, the tenant must prove those controls exist and are enforced. Microsoft documents risk-based sign-in policies separately and makes the dependency on P2 clear. If the tenant does not license or use that capability, the article should say so plainly rather than implying a control that is not there. See also Azure Identity Protection: Blocking Leaked Credentials.

Detection

Detection for Entra ID conditional access gaps is a correlation exercise, not a single-field alert.

Review sign-in evidence first

Microsoft Entra sign-in logs are the primary proof source. For interactive and noninteractive sign-ins, review at least these dimensions:

The important nuance is that a single successful sign-in with conditionalAccessStatus = notApplied is not enough by itself. The question is whether that sign-in should have been governed under the tenant's own design.

Review audit logs for policy drift

Audit logs are the second proof source. Use them to review policy creation, updates, enablement changes, report-only transitions, exclusion changes, and deletions. If a tenant repeatedly changes Conditional Access scope without preserving evidence of why, the real gap is governance drift as much as policy design.

Review policy state, not just policy text

Microsoft's report-only mode and What If tool are useful, but they answer different questions. Report-only helps estimate impact without enforcement. The What If tool helps simulate which policies would apply to a user or service principal sign-in. Neither replaces production evidence. A mature review uses both, then confirms the result in real sign-in data.

Remediation

Remediation should close the highest-impact scope and control gaps first.

1. Establish a broad baseline for users and resources. A tenant should be able to point to the baseline policies that protect normal user access across the resources that matter, not just one admin portal or one favored app.

2. Review exclusions before adding new policies. If exclusions already hide administrators, guests, or high-value groups, new policies may create the illusion of progress while leaving the real exposure untouched.

3. Block or eliminate legacy authentication paths. Where Conditional Access is available, use policy scope and validation to block legacy authentication. Where service or application dependencies still exist, document them explicitly and treat them as exceptions to retire, not as permanent design assumptions.

4. Separate user coverage from workload identity coverage. If the tenant relies on service principals, automation, or application identities, create a distinct review path for workload identities. Do not assume user-scoped Conditional Access did that work for you.

5. Use authentication strengths where the access goal is stronger than generic MFA. Sensitive apps, external access, and privileged roles often need more than a blanket MFA grant.

6. Add risk-based policies only when the tenant can actually operate them. If P2-backed risk evaluation is part of the security story, the evidence should show it. If it is not licensed or not deployed, the article should treat that as a conscious limitation, not hidden maturity.

Validation After Policy Changes

Validation is where Conditional Access work usually fails.

First, use the What If tool to verify expected policy application for representative users, administrator roles, guests, and service principals. Second, use report-only mode where appropriate to understand blast radius before enforcement. Third, confirm the live result in sign-in logs after the policy is enabled.

That live validation should answer concrete questions:

• do the intended users hit the intended policies?
• do excluded accounts remain intentionally excluded and monitored?
• do guest sign-ins evaluate the expected policy path?
• do workload identities still sit outside user-scoped controls?
• do legacy client attempts now fail or disappear?
• if authentication strengths were introduced, do the affected sign-ins show the stronger path in practice?

A tenant that cannot answer those questions with sign-in and audit evidence has not finished the remediation.

Evidence to Keep Between Reviews

Conditional Access drifts quietly, so the evidence pack matters.

This evidence is what allows the next review to measure drift instead of restarting from screenshots. If the tenant needs a broader control narrative for auditors or management, NIS2 Identity Security Requirements is the right companion, not a substitute for this technical review.

How EtcSec Helps Measure Conditional Access Gaps

EtcSec should be positioned narrowly here: not as a magical sign-in detector, but as a way to remeasure common Conditional Access gap conditions over time.

For this article, the relevant findings are the ones already tied to real policy design problems:

• CA_NO_MFA_REQUIREMENT
• CA_NO_LEGACY_AUTH_BLOCK
• CA_NO_RISK_BASED_SIGNIN
• LEGACY_AUTH_ALLOWED

That mapping is useful because it supports recurring review. A tenant can re-audit after policy changes and confirm whether the same structural gaps still exist, rather than treating Conditional Access as a one-time setup exercise.

Primary References

• What is Conditional Access?
• Conditional Access: Users, groups, agents, and workload identities
• How to use conditions in Conditional Access policies
• Block legacy authentication with Conditional Access
• Troubleshoot Conditional Access policies with the What If tool
• Analyze Conditional Access policy impact with report-only mode
• How Conditional Access authentication strengths work
• Conditional Access authentication strength for external users
• Conditional Access for workload identities
• Manage emergency access administrative accounts in Microsoft Entra ID
• Require multifactor authentication for elevated sign-in risk
• What are Microsoft Entra sign-in logs?
• signIn resource type - Microsoft Graph v1.0
• Audit logs in Microsoft Entra ID