Entra ID Conditional Access — The Gaps Attackers Look For

From an admin who's built and reviewed CA policies in enterprise tenants — common bypass conditions and how to build policies that actually hold under pressure.

⚠️ Updated October 2026: Microsoft has finished closing the OIDC enforcement gap (Gap 03), but tenants that opted out are still exposed. Gap 01 now focuses on SMTP AUTH, where Basic auth is disabled by default at the end of December 2026. The baseline adds a user-risk policy, because the legacy Identity Protection risk policies retired on October 1, 2026.

Most organizations believe they are protected once Conditional Access is enabled. The board gets a reassuring slide: "MFA deployed, identity secured." That is a dangerous oversimplification. I've spent years building CA policies for enterprises and auditing them for the weak spots an attacker would look for. The gaps are predictable, consistent, and surprisingly easy to miss from the inside.

GAP 01 — Legacy Authentication — MFA's Blind Spot Severity: Critical

🔍 What It Is

Legacy authentication protocols — SMTP AUTH, IMAP, POP3, Exchange ActiveSync over Basic auth — authenticate with username and password only. They can't process an MFA challenge, so Conditional Access can only block them, never challenge them.

In Exchange Online, Microsoft turned off Basic auth for IMAP, POP, ActiveSync and EWS back in October 2022, so the classic IMAP password spray no longer works there. The big exception is SMTP AUTH (client submission): Basic auth still works in tenants that haven't switched it off. Microsoft will disable it by default at the end of December 2026 and plans to announce final removal in the second half of 2027. Legacy auth also still matters for hybrid on-premises Exchange and third-party apps.

💀 How Attackers Exploit It

Attack path — Password Spray via SMTP AUTH:

Attacker builds a list of valid usernames from LinkedIn and the company's email format
Runs a password spray against SMTP AUTH (smtp.office365.com:587) — one password attempt per account avoids lockout
A successful Basic auth login bypasses MFA entirely — unless a CA policy blocks legacy auth, nothing stops it
Attacker sends phishing or BEC email from a real internal mailbox — it passes SPF, DKIM and DMARC because it genuinely is your domain

⚠️ December 2026 deadline: When Microsoft disables SMTP AUTH Basic auth by default, anything still relying on it — printers, scanners, line-of-business apps — will stop sending mail. Find them now with the query below and move them to OAuth or a connector. Otherwise the quick fix under pressure will be to switch Basic auth back on.

🔎 Detection — KQL (Log Analytics):

SigninLogs
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP4", "POP3", "SMTP", "Other clients", "Authenticated SMTP")
| where ResultType == "0"
| summarize LastSeen=max(TimeGenerated), Count=count() by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by LastSeen desc

SigninLogs
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP4", "POP3", "SMTP", "Other clients", "Authenticated SMTP")
| where ResultType == "0"
| summarize LastSeen=max(TimeGenerated), Count=count() by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by LastSeen desc

Run for 30 days minimum before blocking. Any result here = active legacy auth usage = active bypass risk.

✅ Fix — Block via CA Policy (Entra ID → Conditional Access → Policies → New policy):

Name: "BLOCK — Legacy Authentication"
Users: All | Exclude: Break-glass accounts only
Conditions → Client apps: Exchange ActiveSync clients + Other clients
Grant: Block access
Start in Report-only for 2 weeks, then enforce

GAP 02 — Exclusion Groups — The Unmaintained Backdoor Severity: Critical

🔍 What It Is

Every CA policy has an exclusion list — accounts or groups that bypass the policy entirely. In every mature tenant I've reviewed, these exclusion groups have grown silently over years. Break-glass accounts, service accounts, vendor accounts, VIP user requests, "temporary" exceptions that became permanent.

💀 How Attackers Exploit It

Attack path — Exclusion Group Abuse:

Attacker compromises any Global Admin or Privileged Role Admin account
Enumerates CA policy exclusion groups via Microsoft Graph API
Adds a controlled account to the exclusion group — that account now bypasses all CA policies
Operates from the excluded account with no MFA, no device compliance, no location restrictions

⚠️ The real risk: Exclusion groups are rarely monitored. An attacker who adds a user to an exclusion group and removes themselves hours later may never be caught — unless you have an alert on group membership changes.

🔎 Detection — PowerShell:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State,
  @{N='ExcludedUsers';E={$_.Conditions.Users.ExcludeUsers}},
  @{N='ExcludedGroups';E={$_.Conditions.Users.ExcludeGroups}}

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State,
  @{N='ExcludedUsers';E={$_.Conditions.Users.ExcludeUsers}},
  @{N='ExcludedGroups';E={$_.Conditions.Users.ExcludeGroups}}

✅ Fix:

Keep a single named group per policy for exclusions — never add individual accounts directly
Enable Entra ID Access Reviews on every CA exclusion group — quarterly, auto-remove if no response
Set a Sentinel alert on any membership change to exclusion groups — 15-minute response SLA
Document every exclusion with a justification and expiry date

GAP 03 — OIDC Scope Bypass — The Silent 2026 Fix Severity: Critical · Closed mid-2026 (enforcement began June 15, 2026)

🔍 What It Was

This is the gap most enterprise admins didn't know existed. When a CA policy targets "All resources" with at least one resource exclusion, and an application requests only low-privilege OIDC or directory scopes (openid, profile, email, User.Read), the policy was silently skipped entirely. No MFA prompt. No device compliance check. Nothing.

Your policy said "require MFA for all cloud apps." The reality was "require MFA for all cloud apps, except when an app requests only basic scopes and your policy has any resource exclusion."

🚨 Who was affected: Any tenant with a CA policy targeting "All cloud apps" or "All resources" that had at least one resource exclusion — almost every mature enterprise tenant. Developer tools and vendor apps that request only OIDC scopes were bypassing those policies silently. Microsoft let tenants opt out of the fix, and tenants that opted out are still exposed.

💀 Attack Scenario Before the Fix:

Attacker has valid credentials for a user in your tenant
Signs in through a custom or third-party app requesting only openid + profile + User.Read
Because your "All resources" policy has a resource exclusion, the OIDC sign-in bypasses the policy entirely
Attacker obtains a valid token without MFA or device compliance — confirming the password works and reading the user's profile through Microsoft Graph

🔎 Detection — Sentinel KQL:

SigninLogs
| where ConditionalAccessStatus == "notApplied"
| where AuthenticationRequirement == "singleFactorAuthentication"
| where TimeGenerated > ago(30d)
| summarize Count=count(), LastSeen=max(TimeGenerated) by UserPrincipalName, AppDisplayName, ClientAppUsed
| order by Count desc

SigninLogs
| where ConditionalAccessStatus == "notApplied"
| where AuthenticationRequirement == "singleFactorAuthentication"
| where TimeGenerated > ago(30d)
| summarize Count=count(), LastSeen=max(TimeGenerated) by UserPrincipalName, AppDisplayName, ClientAppUsed
| order by Count desc

Since the rollout, these sign-ins should show CA applied. If they don't, check for an opt-out.

✅ What To Do Now:

Check whether your tenant opted out of or customized the change (Message Center: MC1223829 and MC1418116) — an opt-out leaves the bypass open
Run the detection query for the period since rollout — single-factor, "notApplied" sign-ins into apps your "All resources" policy should cover need investigating
Review exclusions added since mid-June 2026 — apps that broke when enforcement arrived were often "fixed" with a quick new exclusion
For apps that legitimately need OIDC-only flows, explicitly exclude them and document why
Review and minimize resource exclusions — every exclusion is a surface you have to keep justifying

GAP 04 — Device Compliance Spoofing Severity: High

🔍 What It Is

CA policies requiring "compliant device" rely on Intune's verdict, and that verdict is only as strong as the settings behind it. Two weaknesses show up again and again: the tenant-wide setting "Mark devices with no compliance policy assigned as" left at its default of Compliant, and compliance policies that check little more than OS version.

💀 How Attackers Exploit It

An attacker with a user's credentials registers or enrolls a device they control. If any user can register devices, and the device lands outside the scope of your compliance policies, or those policies only check OS version, it can be marked compliant without BitLocker, Secure Boot or antivirus. A "require compliant device" grant then waves the attacker straight through.

🚨 Key insight: "Compliant device" means "Intune says this device meets your policies" — not "this device is actually secure."

✅ Fix:

In Intune's tenant-wide compliance settings, set "Mark devices with no compliance policy assigned as" to Not compliant
Require BitLocker, Secure Boot, and Code Integrity as compliance requirements
Enable Microsoft Defender for Endpoint integration with Intune — device risk score becomes a compliance dimension
For hybrid environments: require Entra hybrid join AND Intune compliance — not either/or
Set compliance policy grace period to 0 days for high-risk device categories
Restrict device registration — only IT-managed devices should be able to register

GAP 05 — Token Lifetime & Session Control Gaps Severity: High

🔍 What It Is

Conditional Access protects the moment of authentication — not the lifetime of the session. A valid access token continues to work until it expires, regardless of policy changes after issuance.

⚠️ February 2026 change: The new "Revoke sessions" action replaces "Revoke MFA sessions" and invalidates all user sessions including MFA, regardless of whether MFA is enforced via CA or per-user policy. Update your IR playbooks to the new control name. Note that it revokes refresh tokens and session cookies — access tokens already issued stay valid until they expire, unless the app supports Continuous Access Evaluation.

💀 AiTM (Adversary-in-the-Middle) Token Theft:

Attacker sends phishing link to an AiTM proxy (e.g., Evilginx) that relays the real Microsoft sign-in
Victim completes legitimate MFA through the proxy — attacker captures the session cookie and access token
Attacker replays the token — MFA is already satisfied, CA policies are bypassed
Attacker has full access until the token expires — typically 60–90 minutes for access tokens, up to 90 days for refresh tokens

✅ Fix:

Enable Sign-in frequency in CA: 1 hour for privileged roles, 4–8 hours for standard users
Enable Continuous Access Evaluation (CAE) — forces near-real-time policy re-evaluation
Require phishing-resistant MFA (FIDO2 / Windows Hello) for all admins — cannot be replayed by AiTM
Enable Token Protection in CA — binds sign-in tokens to the device. Generally available on Windows for Exchange, SharePoint, Teams, Azure Virtual Desktop and Windows 365; preview on macOS and iOS; browsers not supported
In IR scenarios, use "Revoke sessions" together with a password reset — it kills refresh tokens and sessions, and CAE-capable apps also cut off access tokens in near real time

GAP 06 — Report-Only Policies That Never Got Enforced Severity: High

🔍 What It Is

Every good CA deployment starts in Report-only mode. The problem: in many tenants, policies stay in Report-only indefinitely. "We'll enforce it after we review" becomes "we never reviewed." I've seen tenants with 12–15 CA policies in Report-only mode sitting there for over a year, providing zero actual protection.

From an attacker's perspective, Report-only policies are invisible. They generate log entries, but block nothing.

🔎 Detection — PowerShell:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State, CreatedDateTime, ModifiedDateTime |
  Sort-Object State | Format-Table
States: "enabled" | "disabled" | "enabledForReportingButNotEnforcing"

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State, CreatedDateTime, ModifiedDateTime |
  Sort-Object State | Format-Table
States: "enabled" | "disabled" | "enabledForReportingButNotEnforcing"

Any policy in "enabledForReportingButNotEnforcing" = report-only = not blocking.

✅ Fix:

Set a 30-day hard deadline for every new CA policy to move from Report-only to Enforced
Review all current Report-only policies — any older than 90 days should be enforced or deleted
Use the CA What If tool to validate before enforcement — not indefinite report-only
Never disable a CA policy — document why and delete it instead

Detection & The What If Tool

The CA What If tool (Entra ID → Conditional Access → Policies → What If) lets you simulate any sign-in scenario and shows exactly which policies apply.

Test these scenarios at minimum:

User + legacy auth client
User + unknown IP
User + non-compliant device
Service account + any app

Any scenario returning "0 policies applied" or only report-only policies = gap in your coverage.

Enterprise CA Baseline That Actually Holds

POLICY 1: BLOCK — Legacy Authentication Users: All | Exclude: Break-glass only Conditions: Other clients + Exchange ActiveSync | Grant: Block

POLICY 2: REQUIRE — MFA for All Users Users: All | Exclude: Break-glass, monitored service accounts Apps: All resources | Grant: Require authentication strength → Multifactor authentication

POLICY 3: REQUIRE — Phishing-Resistant MFA for Admins Users: All privileged roles | Apps: All resources Grant: Require authentication strength → Phishing-resistant MFA Session: Sign-in frequency 1 hour

POLICY 4: REQUIRE — Compliant Device for Corporate Apps Users: All | Apps: Exchange, SharePoint, Teams Grant: Require compliant device OR Microsoft Entra hybrid joined device

POLICY 5: BLOCK — High-Risk Sign-ins Users: All | Apps: All resources Conditions: Sign-in risk = High | Grant: Block (requires Entra ID P2)

POLICY 6: REQUIRE — Secure Password Change for High-Risk Users Users: All | Exclude: Break-glass | Apps: All resources Conditions: User risk = High Grant: Require authentication strength (MFA) + Require password change Session: Sign-in frequency = Every time (Replaces the legacy Identity Protection user-risk policy, retired October 1, 2026)

POLICY 7: REQUIRE — MFA Registration from Trusted Location Users: All | Target resources: User actions → Register security information Conditions: Location = not named location | Grant: Require MFA

✅ Deployment rule: Always start in Report-only, review for 2 weeks, identify impacted accounts, add necessary exclusions — then enforce. One wrong click can lock out your entire organization.

📌The Bottom Line

The gap between "Conditional Access enabled" and "identity secured" is enormous. Every policy has conditions, exclusions, and edge cases. Attackers don't need to break your encryption — they need to find the single sign-in flow you didn't account for.

The 2026 OIDC enforcement change is a reminder that even Microsoft's own platform had silent bypass conditions that persisted for years. Your job isn't to configure CA once and move on — it's to treat it as a living architecture that requires continuous review, monitoring, and testing.

Run the What If tool. Audit your exclusion groups. Check your Report-only policies. Then do it again next quarter. The attackers are checking.

Full styled version: Entra ID Conditional Access — The Gaps Attackers Look For

Contents

📌The Bottom Line