Conditional Access: the most common configuration mistakes

Conditional Access is Entra ID's most powerful access control, but also one of the easiest to silently misconfigure: a policy that looks correct can have a gap that renders it ineffective for a subset of users or scenarios, and that gap isn't discovered until someone exploits it.

Exclusions that become permanent holes

It's common to temporarily exclude a user or group from a Conditional Access policy to fix a one-off issue — a failing service account, an administrator needing urgent access without MFA — intending to revert it later. In practice, those exclusions are rarely removed: they pile up over months or years, and each one is an exception to the security policies that no one remembers the reason for. A Conditional Access audit should always start by listing and justifying every active exclusion.

Not covering every application or authentication flow

A policy applying "to all cloud apps" may look complete, but many tenants have legacy applications or legacy protocols (POP, IMAP, SMTP AUTH) that don't go through the same modern authentication flow and therefore don't evaluate Conditional Access the same way. If legacy authentication isn't explicitly blocked, it remains an MFA-free access path even if every "modern" policy is well configured — it's in fact one of the most exploited vectors in Microsoft 365 compromises.

"Report-only" policies that never get enforced

Microsoft recommends deploying new policies in "report-only" mode to validate their impact before enforcing them. The problem appears when that testing phase drags on indefinitely: the policy keeps logging events without blocking anything, giving a false sense of protection. It's essential to set a review date to move each policy from "report-only" to "enabled" once you've confirmed it doesn't break legitimate flows.

How to audit your Conditional Access policies

A full review covers: (1) inventorying all active, report-only and disabled policies with their actual user and application coverage; (2) verifying legacy authentication is blocked globally; (3) listing and justifying every user or group exclusion; (4) simulating access scenarios (new user, unmanaged device, location outside Spain) to detect coverage gaps; (5) using Entra ID's "What If" simulator to verify policies behave as expected before and after any change.

FAQ

Is a single MFA policy for all users enough?

No. A single broad MFA policy doesn't cover legacy authentication, doesn't differentiate by session risk or device, and doesn't protect against token theft. A robust design combines several specific policies: legacy auth blocking, phishing-resistant MFA on critical accounts, and risk-based policies (Identity Protection).

How do I test a policy without risking locking out legitimate users?

Deploy it first in "report-only" mode on a small pilot group, review sign-in logs for at least one or two weeks, and use Entra ID's "What If" tool to simulate its effect before enforcing it in production for all users.