The most common Entra ID Conditional Access gaps are not exotic. They are policies that exclude too many people, sit in report-only mode forever, never block legacy authentication, ignore device and sign-in-risk signals, and leave break-glass accounts unmonitored. Each one quietly lets a user — or an attacker with a stolen password — reach resources without the MFA you assume is enforced. This guide walks through the ten gaps we see most often, why each matters, and how to close it without locking yourself out.
What a "gap" actually means in Conditional Access
Conditional Access (CA) is an allow/deny engine: for a given sign-in, Entra ID evaluates the assignments (users, target resources, conditions) and applies the access controls (grant, block, session). A gap is any sign-in path that reaches a resource without hitting the control you intended. Gaps come from three places: assignments that are too narrow (a policy that doesn't apply where it should), exclusions that are too broad (people or apps carved out of enforcement), and conditions that miss a real-world scenario (a protocol or client your policy never considered). The fix is almost always tightening scope and removing assumptions — not buying anything new.
The 10 Conditional Access gaps to hunt down
1. Legacy authentication is still allowed
Legacy protocols — POP, IMAP, SMTP AUTH, MAPI over HTTP with basic auth, ActiveSync with basic auth — cannot perform modern authentication and therefore cannot satisfy an MFA grant. If you require MFA for everything but never block legacy auth, an attacker with a valid password signs in through the side door. Fix: create a policy targeting "Other clients" (legacy auth) and set it to Block. Microsoft now ships a Microsoft-managed policy that does this in report-only; don't wait for it — own the policy yourself and move it to enforce after a short monitoring window.
2. Report-only policies that never graduate
Report-only is the right way to test a policy, but a policy stuck in report-only enforces nothing. It is extremely common to find an entire MFA or device-compliance policy that has been "testing" for a year. Fix: set a hard review date when you create a report-only policy. Check the sign-in logs' report-only tab, confirm it would not break legitimate sign-ins, then switch it On.
3. Over-broad exclusions
Exclusion groups are where enforcement goes to die. A "CA-Exclusions" group created for one contractor in 2023 often holds dozens of accounts no one remembers adding. Excluded guests, synced service accounts, and "VIP" executives are classic blind spots. Fix: audit every exclusion group quarterly, justify each member, and prefer narrowly-scoped policies over broad ones with big carve-outs.
4. Break-glass accounts that are unmanaged or unmonitored
Emergency-access ("break-glass") accounts must be excluded from CA so a bad policy can't lock you out — but an excluded admin account with a weak password and no alerting is a gift to an attacker. Fix: keep two cloud-only accounts on the .onmicrosoft.com domain, protect them with FIDO2 keys or long passphrases, exclude them from policy, and alert on every sign-in to them.
5. No device compliance or device-filter requirement
MFA proves who is signing in, not what from. Without a "require compliant device" or device-filter control, a user can authenticate from an unmanaged, possibly compromised machine. Fix: require Intune-compliant or Hybrid-Entra-joined devices for sensitive apps; use device filters to separate corporate from personal access.
6. "All cloud apps" assumptions that leak new apps
Targeting individual apps feels precise, but every new enterprise app you register is then unprotected by default until someone remembers to add it. Fix: baseline policies (require MFA, block legacy auth) should target All resources (All cloud apps), with deliberate, documented exclusions — not an app allow-list you must maintain by hand.
7. Still relying on per-user MFA
Microsoft retired the legacy per-user MFA and SSPR management policies on 30 September 2025. Per-user "enabled/enforced" flags are opaque, can't carry conditions, and conflict confusingly with CA. Fix: enforce MFA through Conditional Access and define permitted methods in the modern Authentication methods policy; convert any remaining per-user state.
8. No Identity Protection risk policies
CA can consume sign-in risk and user risk signals from Entra ID Protection — but only if you create policies that use them. Without them, an impossible-travel or leaked-credential sign-in is treated like any other. Fix (P2 licensing): require MFA on medium+ sign-in risk and require secure password change on high user risk.
9. Phishable MFA for privileged accounts
SMS and voice MFA satisfy a grant but are phishable and SIM-swappable. Admins protected only by SMS are a weak link. Fix: require phishing-resistant methods (FIDO2, Windows Hello for Business, or certificate-based) via an Authentication Strength grant for all privileged roles.
10. Missing session controls
A satisfied MFA prompt issues tokens that can be stolen and replayed. Policies with no session controls leave a wide replay window. Fix: set sign-in frequency for sensitive access, disable persistent browser sessions on unmanaged devices, and enable Continuous Access Evaluation (CAE) so revocation and risk events take effect in near-real-time.
A 60-second self-audit
Run through this table against your tenant. Any "no" is a gap worth a ticket.
| Check | Why it matters |
|---|---|
| Legacy auth is blocked by an enforced policy | Closes the #1 MFA-bypass route |
| No policy has been in report-only > 30 days | Report-only enforces nothing |
| Every exclusion group member is justified | Stale exclusions silently disable MFA |
| 2 break-glass accounts, excluded and alerted on | Lockout insurance without a soft target |
| Baseline MFA policy targets All resources | New apps are protected by default |
| Admins require phishing-resistant MFA | SMS is phishable and SIM-swappable |
| Per-user MFA fully migrated to CA | Legacy policies retired 30 Sep 2025 |
Close the gaps without locking yourself out
Tighten policy the same way every time: (1) build the policy scoped to a pilot group, (2) run it in report-only and read the sign-in logs, (3) confirm break-glass exclusions, (4) expand the pilot, then (5) flip to On and watch failures for 48 hours. Always verify your emergency-access accounts are excluded before enforcing anything that could deny interactive sign-in. Document each policy's intent so the next admin doesn't add an exclusion that quietly reopens a gap.
If you want a fast read on where your tenant stands, our browser-based x365 Microsoft 365 & Entra audit tool surfaces Conditional Access coverage, legacy-auth exposure and MFA posture without sending tenant data off your device. For the broader identity picture, pair this with our Active Directory Hardening Guide and the Zero Trust Architecture Cheat Sheet.
Frequently asked questions
What is a Conditional Access gap?
A Conditional Access gap is any path a user or attacker can take to reach a resource without satisfying the controls you think are in place — for example, a legacy protocol that bypasses MFA, an app not covered by 'All cloud apps', or an over-broad exclusion group. Gaps are usually configuration oversights, not product flaws.
Does Conditional Access replace per-user MFA?
Yes. Microsoft retired the legacy per-user MFA and SSPR management policies on 30 September 2025. MFA should be enforced through Conditional Access, with allowed methods defined in the modern Authentication methods policy. If you still rely on per-user 'enabled/enforced' flags, migrating is now mandatory, not optional.
Why is blocking legacy authentication so important?
Legacy protocols such as POP, IMAP, SMTP AUTH and older MAPI clients cannot perform MFA. An attacker with a valid password can use them to sign in even when you require MFA everywhere else. Blocking legacy auth closes the single most common MFA-bypass route.
How many break-glass accounts should I have?
At least two cloud-only emergency-access accounts on the *.onmicrosoft.com domain, excluded from every Conditional Access policy, using long passphrases or FIDO2 keys stored securely, and alerted on every sign-in. They are your insurance against locking yourself out when you tighten policies.
Can Conditional Access stop token theft?
Partly. Session controls — sign-in frequency, no persistent browser session for risky access, and Continuous Access Evaluation (CAE) — reduce the window a stolen token is useful. Combine them with phishing-resistant MFA and device compliance to meaningfully cut token-replay risk.