Conditional Access in Microsoft 365 — 5 Configuration Mistakes That Lock Out Users (and How to Fix Them)

TL;DR: Conditional Access evaluates all policies simultaneously — one misconfiguration can lock an entire tenant. This article covers 5 specific traps: Intune enrollment blocked by "All cloud apps," unblocked legacy authentication, IPv6 breaking Named Locations, invisible app service dependencies, and skipping What-If testing before enforcement. Each comes with error codes, PowerShell diagnostics, and concrete fixes.

The Problem

Conditional Access looks straightforward on paper — define conditions, define what happens when they're not met, enable the policy. In practice, M365 admins regularly hit invisible traps that only surface once users start calling to ask why they can't sign in.

A scenario that plays out repeatedly on Microsoft TechCommunity: a new admin is tasked with "securing the tenant" — enforce MFA and device compliance. They create a CA policy targeting all users, all cloud apps, requiring Intune-compliant devices. Policy goes straight to enabled. The next morning, 30% of the workforce can't sign in because their devices aren't enrolled in Intune. Worse, they can't enroll because the CA policy blocks access to the Intune enrollment portal. A perfect chicken-and-egg deadlock.

This isn't a hypothetical. Variations of this scenario appear multiple times a week on Microsoft community forums. The root cause is a fundamental misunderstanding of how CA evaluates policies — they are all assessed in parallel, not sequentially. There is no "first match wins" logic. Every active policy must either pass or be irrelevant for access to be granted.

Another common failure mode is deploying policies with no testing phase. A policy goes directly from "Off" to "Enabled," skipping Report-Only mode entirely. The admin learns from the sign-in logs — after the fact — who got blocked and why.

Why This Happens

Conditional Access operates on a "default deny" model. If any active policy returns "Block" or requires a condition that cannot be met in the current context, access is denied. The evaluation is parallel — all enabled policies apply simultaneously, and there is no priority ordering or rule hierarchy.

Service dependencies are the second major source of unexpected blocks. When a user opens Microsoft Teams, Teams requests tokens for Exchange Online (calendar and mail), SharePoint Online (files and channels), and Office 365 (licensing). If a CA policy blocks access to SharePoint Online, Teams stops working — even though the policy isn't scoped to Teams. In sign-in logs you'll see "Microsoft Teams" as the application, but the blocked resource is "SharePoint Online." Without understanding service dependencies, this looks like a random failure.

IPv6 is the third silent problem. Entra ID cannot geolocate IPv6 addresses — they are classified as "unknown location." If your policy blocks access from countries outside an allowed list, any user connecting via IPv6 (increasingly common as ISPs roll out dual-stack) gets blocked because their address doesn't match any permitted country. The user is sitting at their desk in the office; CA sees them as coming from an unknown location.

Step-by-Step Fixes

Mistake #1 — "All cloud apps" blocks Intune enrollment

The problematic configuration:

• Users: All users
• Target resources: All cloud apps
• Access controls: Require device to be marked as compliant

The trap: a device can only be "compliant" after it's enrolled in Intune. Enrollment requires access to the Microsoft Intune portal and Microsoft Intune Enrollment app. A policy of "all apps + require compliance" blocks exactly those endpoints. The device cannot enroll because access is denied; access is denied because the device isn't enrolled. Error code in sign-in logs: AADSTS53000 (DeviceNotCompliant).

Fix: Exclude Microsoft Intune (AppId: 0000000a-0000-0000-c000-000000000000) and Microsoft Intune Enrollment (AppId: d4ebce55-015a-49b5-a083-c84d1797ae8c) from the policy scope. Find affected policies with PowerShell:

# Find CA policies that may block Intune enrollment
Connect-MgGraph -Scopes "Policy.Read.All"

$policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($policy in $policies) {
    $apps = $policy.Conditions.Applications
    $allApps = $apps.IncludeApplications -contains "All"
    $intuneExcluded = $apps.ExcludeApplications -contains "0000000a-0000-0000-c000-000000000000"
    $enrollExcluded = $apps.ExcludeApplications -contains "d4ebce55-015a-49b5-a083-c84d1797ae8c"
    $grants = $policy.GrantControls.BuiltInControls

    if ($allApps -and ($grants -contains "compliantDevice") -and (-not $intuneExcluded -or -not $enrollExcluded)) {
        Write-Warning "Policy '$($policy.DisplayName)' requires compliance and may block Intune enrollment"
        Write-Host "  Microsoft Intune excluded: $intuneExcluded"
        Write-Host "  Microsoft Intune Enrollment excluded: $enrollExcluded"
    }
}

Mistake #2 — Legacy authentication is not blocked

Legacy authentication protocols — IMAP, POP3, Authenticated SMTP, MAPI over HTTP, Basic Auth, Exchange ActiveSync with Basic — do not support Conditional Access or modern MFA. If your policy requires MFA for all users but doesn't explicitly block legacy auth, an attacker with a valid password can authenticate via IMAP or POP3 with no MFA challenge. CA policies are completely bypassed.

Audit legacy auth activity from the past 30 days before blocking anything:

Connect-MgGraph -Scopes "AuditLog.Read.All"

$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
$legacyClients = @("IMAP4", "POP3", "MAPI", "Exchange ActiveSync", "Other clients", "Authenticated SMTP")

$signIns = Get-MgAuditLogSignIn `
    -Filter "createdDateTime ge $startDate and status/errorCode eq 0" `
    -All -PageSize 500 |
    Where-Object { $legacyClients -contains $_.ClientAppUsed }

Write-Host "Successful legacy auth sessions in last 30 days: $($signIns.Count)"
$signIns | Group-Object UserPrincipalName, ClientAppUsed |
    Sort-Object Count -Descending |
    Select-Object -First 20 Name, Count |
    Format-Table -AutoSize

Run the blocking policy in Report-Only mode for at least 2 weeks first. Common casualties of a sudden legacy auth block: multifunction printers sending mail via SMTP AUTH, legacy CRM applications, line-of-business apps with hardcoded credentials, automation scripts. For printers and scanners, migrate to Microsoft 365 SMTP relay (no per-user authentication required) rather than SMTP AUTH.

Note: Microsoft began globally disabling Basic Auth for Exchange Online in October 2022, but Authenticated SMTP for client devices remains configurable and must be handled separately via a CA policy or per-mailbox SMTP AUTH settings.

Mistake #3 — IPv6 defeats Named Locations

Location-based CA policies work reliably for IPv4. With IPv6, Entra ID has no geolocation data — addresses are classified as "unknown location." A policy blocking "all countries except US, UK, and Canada" will block a user connecting from their London office over IPv6, because their IPv6 address doesn't match any named location.

Three approaches, ranked:

1. Replace location conditions with "Require compliant device" — this is the right long-term solution. An Intune-enrolled device carries a certificate; compliance doesn't depend on the source IP address at all.
2. Add your ISP's IPv6 prefixes to a Named Location — works, but requires updates whenever you change providers or your ISP reblocks.
3. Enable "Include unknown countries/regions" — effectively makes your allow-list useless since all IPv6 connections also pass through.

Mistake #4 — Invisible service dependencies

CA doesn't evaluate user intent — it evaluates which resources are requested during sign-in. Teams, Outlook, SharePoint, and OneDrive all silently request tokens to multiple backend resources.

Real-world example: an admin scopes a CA policy to "managed devices only" for SharePoint Online. A user opens Teams from a personal unmanaged device — Teams stops loading files in channels. The user reports "Teams is broken." The sign-in log shows the blocked resource is SharePoint Online, not Teams. Without understanding the Teams → SharePoint dependency, this is confusing.

Always check Audience reporting in sign-in logs. Entra ID shows all resources (audiences) requested during a single sign-in event. Key dependencies to know:

• Exchange Online: blocks Outlook, Teams (mail and calendar tabs), Power Automate mail connectors
• Office 365 (app group): blocks Teams, Word, Excel, OneDrive — anything that needs a license token
• Azure Resource Manager: blocks Azure Portal, Azure CLI, Terraform, PowerShell Az module
• SharePoint Online: blocks Teams file sharing, OneDrive sync, SharePoint sites

Mistake #5 — No What-If simulation before enforcement

The What-If tool (Entra admin center → Conditional Access → Policies → What If) simulates how all active policies apply to a specific sign-in scenario. You specify a user, app, location, platform, and client — and get a report of which policies would apply, which would block, and which wouldn't trigger at all.

Critical limitation: What-If does not simulate service dependencies. Simulating sign-in to Teams will not evaluate policies that apply to Exchange Online or SharePoint — only to Teams directly. Always simulate each dependent resource separately.

What-If and Report-Only mode serve different purposes. What-If is a point-in-time simulation for a single hypothetical scenario. Report-Only monitors actual user sign-ins over days or weeks and captures edge cases you'd never think to simulate. Both are required before enforcing any policy that affects all users.

Recommended deployment workflow:

1. Report-Only mode for a minimum of 5 business days (include a Monday — weekend-to-Monday is when stale tokens expire and re-auth spikes)
2. Review Conditional Access Insights Workbook in Entra admin center daily
3. What-If for service accounts, break-glass accounts, and users with non-standard roles
4. Pilot enforcement on 5-10% of users for 48 hours
5. Full enforcement with rollback plan documented

Common Traps and Edge Cases

Token caching means changes aren't instant. When you modify a CA policy, users with active tokens don't feel the change until token expiry — access tokens expire in ~1 hour by default, but refresh tokens in persistent sessions can last up to 90 days. If you remove a blocking policy during an incident, some users may remain blocked for hours. Don't assume the fix didn't work just because the effect isn't immediate.

Break-glass accounts must be excluded from every CA policy without exception. Admins often exclude break-glass from MFA policies but forget location policies, compliance requirements, or device platform filters. One policy that includes the emergency account neutralizes it. Audit this regularly:

$bgUPN = "breakglass@yourdomain.com"
$bgUser = Get-MgUser -Filter "userPrincipalName eq '$bgUPN'"

$activePolicies = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.State -eq "enabled" }
$exposed = $activePolicies | Where-Object {
    $_.Conditions.Users.ExcludeUsers -notcontains $bgUser.Id -and
    ($_.Conditions.Users.IncludeUsers -contains "All" -or
     $_.Conditions.Users.IncludeGroups.Count -gt 0)
}

if ($exposed) {
    Write-Warning "Break-glass is NOT excluded from $($exposed.Count) active policies:"
    $exposed | Select-Object DisplayName, State | Format-Table
}

Workload identities (service principals) are not covered by user CA policies. Standard CA policies apply only to human accounts. Service principals, Managed Identities, and app registrations require separate "Conditional Access for workload identities" policies, available with Entra ID P2 licensing. Most organizations leave service principals completely unrestricted — no location filters, no IP restrictions, no risk-based controls.

Office 2013 and unpatched Office 2016 (builds below 16.0.7167) use legacy auth with no option to switch to modern authentication. Before enforcing legacy auth blocks, audit Office versions in your environment via Microsoft 365 Apps telemetry in the admin center or through Configuration Manager/Intune.

CA policy changes propagate to all Microsoft datacenters in approximately 5 minutes. If a change is wrong, you have about 5 minutes before it reaches all users globally. Always make CA changes in a maintenance window with someone standing by to revert. Never make CA changes right before a meeting or end-of-day.

Microsoft-managed CA policies can appear without warning. Since late 2023, Microsoft has been rolling out automatically applied CA policies (requiring MFA for admins and other scenarios) to tenants with default security settings. These appear in your tenant and affect sign-ins even if you didn't create them. Check Entra admin center → Conditional Access → Microsoft-managed policies and make sure they don't conflict with your configuration.

How We Handle This at Evolit

At Evolit, we always deploy Conditional Access alongside Intune device management, never in isolation. We use Nexma to automate new employee onboarding — when HR approves an access request, the system automatically creates the account, assigns an Autopilot enrollment profile, and queues the device for Intune enrollment. By the time the user logs in for the first time, their device is already compliant, which eliminates the chicken-and-egg problem entirely.

Nexma also handles M365 resource access requests — instead of manually managing CA policy exclusions per user, conditional access is enforced through group membership that Nexma manages automatically based on approved requests. The alternative approach is Privileged Identity Management (PIM) in Entra, which provides JIT role activation and requires Entra ID P2 licensing and per-role manual configuration. For teams that need a more automated, request-based workflow, nexma.app covers that use case.

Summary

• Conditional Access evaluates all policies simultaneously — there is no rule ordering; a single unmet condition blocks access regardless of other policies
• "All cloud apps + require compliant device" must exclude Intune enrollment AppIds or new devices are trapped in an unbreakable loop (AADSTS53000)
• Legacy authentication bypasses CA and MFA entirely — block it with a dedicated policy, but only after 2+ weeks in Report-Only to identify dependent applications
• IPv6 addresses map to "unknown location" in Named Locations — migrating to "require compliant device" instead of IP-based location conditions solves this permanently
• What-If doesn't simulate service dependencies — always test each dependent resource (Exchange, SharePoint, Azure RM) separately, and run Report-Only in production before enforcing