2.3.2. Conditional Access Policies

💡 First Principle: Conditional Access is a policy engine that evaluates signals about a sign-in attempt — who is signing in, from what device, from where, at what risk level — and then decides: grant access, grant with additional requirements, or block. It's the automated security checkpoint that enforces context-aware access decisions at scale.

Without Conditional Access, every user who passes authentication gets the same level of access, regardless of whether they're on a managed corporate device or an unknown personal machine in a foreign country. Conditional Access lets you say: "Users signing in from trusted locations on compliant devices get seamless access. Everyone else must complete MFA. Users signing in at high risk level are blocked entirely."

A Conditional Access policy has two parts:

Conditions (the "if" side):

• Users or groups targeted
• Cloud apps included or excluded
• Sign-in risk level (low / medium / high — from Entra ID Protection)
• Device platform (Windows, iOS, Android)
• Location (named locations, countries)
• Device compliance state (Intune-managed, compliant)

Controls (the "then" side):

• Require MFA
• Require compliant device
• Require Entra hybrid joined device
• Block access
• Require approved client app
• Require password change (for high-risk sign-ins)

⚠️ Exam Trap: Conditional Access policies are evaluated at sign-in time — they don't retroactively revoke active sessions. If a user is already signed in when a new policy is applied, they may retain access until their token expires or they sign in again.

Reflection Question: You create a Conditional Access policy that requires MFA for all users when signing in from outside the corporate office. A user complains they are being asked for MFA even when inside the office. What configuration element is most likely missing from your policy?