Conditional Access

Conditional Access is the policy engine in Microsoft Entra ID that decides what to do with a sign-in attempt based on signals: the user, the app they're accessing, their device's compliance state, their location, the network they're on, and the risk level of the sign-in. A policy can allow the sign-in, block it, or grant it subject to controls like MFA, a compliant device, a managed app, or a session-policy restriction. Conditional Access requires Entra ID P1 (included with most Microsoft 365 business and enterprise plans). It is the practical mechanism for enforcing zero-trust principles in Microsoft 365.

How a policy is evaluated

Every Conditional Access policy has three parts: assignments (who and what — users/groups, cloud apps or actions, and conditions like device platform, location, or sign-in risk), access controls (grant or block, and if granting, what's required), and session controls (app-enforced restrictions, sign-in frequency, conditional access app control for cloud apps). At sign-in, Entra ID evaluates every applicable enabled policy in parallel — there's no first-match-wins ordering — and applies the most restrictive combination of the results. A single block anywhere in that set blocks the sign-in outright; grant controls from multiple policies (e.g. one requiring MFA, another requiring a compliant device) are combined with AND logic by default.

Worked example

A tenant wants: MFA for every user, everywhere; a stricter requirement of a compliant device for anyone touching finance data; and a hard block on legacy authentication protocols. That's three policies, not one giant policy — a common mistake is trying to encode every condition into a single rule, which becomes unreadable and hard to safely change. Policy 1 targets all users, all cloud apps, and grants access requiring MFA. Policy 2 targets the finance security group, the finance line-of-business app, and grants access requiring a compliant device (Intune-managed and passing compliance policy). Policy 3 targets all users, the "legacy authentication clients" condition, and blocks outright. Because Entra ID evaluates all three and combines the results, a finance user on an unmanaged personal laptop is blocked by Policy 2 even though Policy 1 alone would have let them in with MFA — which is the intended behaviour.

Rollout discipline

New policies should always be created in report-only mode first — Entra ID logs what the policy would have done against real sign-in traffic without enforcing it, surfaced in the sign-in logs' Report-only tab. That catches false positives (a break-glass account that would get locked out, a service account that doesn't do interactive MFA) before they cause an outage. Two named locations deserve almost every tenant's first policies: a trusted named location for the corporate network/VPN ranges, and exclusion of the break-glass emergency-access accounts from every policy that could conceivably lock out all admins simultaneously — those accounts should be excluded from Conditional Access entirely and monitored separately, not protected by the same system they're meant to be a fallback for.

Common pitfalls

Conditional Access has no built-in policy simulator that accounts for every real-world edge case, so the standard practice is: build in report-only, review sign-in logs for a representative period (at least a week, to catch weekly-cadence service accounts), then flip to on. Naming conventions matter at scale — a tenant with 20+ policies without a consistent naming scheme (e.g. CA-nnn-Target-Condition-Control) becomes unmanageable to audit. And because policies combine with AND logic, adding a new broad policy can silently tighten access for everyone already governed by a narrower one — a change to "require compliant device for all apps" doesn't just affect the app it was written for.