Conditional Access Policies

Conditional Access is the decision engine at the heart of Microsoft's zero-trust strategy. It evaluates signals during sign-in — such as user identity, device state, location, and application — and enforces policies that grant, block, or require additional verification before allowing access.

---

What Is Conditional Access?

Conditional Access policies are if-then rules:

• If a set of conditions is met (who, where, what, when)
• Then apply a set of access controls (allow, block, require MFA, etc.)

For example: "If a user is signing in from outside the corporate network, then require multi-factor authentication."

Conditional Access requires Microsoft Entra ID P1 or higher.

---

How Conditional Access Works

The evaluation flow:

1. A user attempts to sign in to a cloud application
2. Entra ID authenticates the user (first factor)
3. The Conditional Access engine evaluates all policies that apply
4. If multiple policies apply, all policies must be satisfied (AND logic)
5. The strictest access controls are enforced

User Sign-In
  |
  v
Authentication (First Factor)
  |
  v
Conditional Access Engine
  |-- Evaluate Conditions (signals)
  |-- Match Policies
  |-- Apply Controls
  |
  v
Access Granted / Blocked / MFA Required

---

Signals (Conditions)

Conditional Access evaluates the following signals:

User or Group Membership

• Target specific users or groups
• Exclude emergency access (break-glass) accounts
• Include or exclude guest users

Cloud Application

• Apply policies to specific applications (e.g., Azure portal, Exchange Online, SharePoint)
• Use "All cloud apps" for broad coverage

Location

• Named locations — define trusted networks by IP range or country
• Trusted locations — corporate office IPs, VPN ranges
• Example: require MFA for all sign-ins outside trusted locations

Device Platform

• Target specific platforms: Windows, macOS, iOS, Android, Linux
• Example: block access from unmanaged Linux devices

Device State

• Compliant device — the device meets Intune compliance policies
• Hybrid Entra joined — the device is joined to both on-premises AD and Entra ID
• Example: require a compliant device to access sensitive applications

Client Application

• Browser — sign-ins from web browsers
• Mobile apps and desktop clients — native applications
• Legacy authentication — older protocols (POP, IMAP, SMTP) that do not support MFA

Sign-In Risk and User Risk

Available with Entra ID P2 and Identity Protection:

• Sign-in risk — real-time assessment of whether the sign-in is suspicious (e.g., impossible travel, anonymous IP)
• User risk — cumulative assessment of whether the user's account is compromised (e.g., leaked credentials)

---

Access Controls

When conditions are met, you can apply the following controls:

Grant Controls