2.1.2. Conditional Access Policies
💡 First Principle: A Conditional Access policy is an if/then statement evaluated on every sign-in: if these conditions match (user, app, location, device state, sign-in risk), then apply these grant or session controls (require MFA, require compliant device, block entirely). It's the mechanism that turns "verify explicitly" from Phase 1 into an enforceable rule.
Policies are built from two halves. Assignments define the if — which users/groups, which cloud apps, and optionally which conditions (named locations, sign-in risk level, device platform) narrow the scope further. Access controls define the then — grant controls like requiring MFA or a compliant device, or session controls like limiting a session's lifetime or restricting what a browser session can do without being fully trusted.
| Condition Signal | Example Use |
|---|---|
| Named locations | Require MFA for sign-ins outside trusted corporate IP ranges |
| Sign-in risk (Identity Protection) | Block or require MFA when a sign-in looks anomalous |
| Device platform / compliance | Require a compliant, Intune-managed device for sensitive apps |
| Client app type | Apply stricter controls to legacy authentication protocols |
⚠️ Exam Trap: Conditional Access policies are evaluated together, and by default a user is subject to every policy that matches their sign-in — there's no implicit "most specific policy wins." A scenario with overlapping policies (one requiring MFA, another blocking a location) both apply; the most restrictive combined result governs the outcome.
Reflection Question: If a Conditional Access policy targets "All cloud apps" but excludes a specific service principal, what real-world scenario is that exclusion usually protecting against?
