Conditional Access: Smart Access Decisions
If-then policies that make real-time access decisions based on signals like location, device health, and risk level — the engine behind Zero Trust enforcement.
What is Conditional Access?
Think of a nightclub bouncer who makes decisions based on context.
A basic bouncer checks one thing: are you on the guest list? But a smart bouncer also checks: What time is it? Are you wearing appropriate shoes? Do you look sober? Different conditions lead to different decisions.
Conditional Access works the same way. Instead of just checking your password, it looks at the full picture: Where are you? What device are you using? How risky is this sign-in? Then it makes a decision: let you in, block you, or ask for extra proof.
These decisions are automatic. An admin writes the rules once. From then on, every sign-in is evaluated in real time.
The if/then model
Every Conditional Access policy has two parts:
| Part | What It Contains | Examples |
|---|---|---|
| Assignments (IF) | The conditions that trigger the policy | Specific users or groups, target apps, device platforms, locations, sign-in risk level |
| Access controls (THEN) | The action to enforce when conditions are met | Block access, require MFA, require compliant device, require app protection policy, limit session |
How it flows:
- User signs in to an application
- Microsoft Entra evaluates ALL Conditional Access policies that apply
- If a policy’s conditions match, its controls are enforced
- If multiple policies match, ALL controls from every matching policy are combined (most restrictive wins)
Key exam concept: Conditional Access policies are not first-match. ALL matching policies apply, and the most restrictive combined result is enforced.
Signals: what Conditional Access checks
Conditional Access can evaluate several signals when deciding whether to allow or restrict access:
| Signal | What It Checks | Example |
|---|---|---|
| User or group | Which user or group is signing in | All members of the Finance team |
| Cloud app | Which application the user is accessing | SharePoint Online, Exchange Online |
| Location | Where the sign-in originates (IP address/named location) | Corporate office IP range vs unknown country |
| Device platform | The operating system of the device | Windows, iOS, Android, macOS |
| Device state | Whether the device is compliant or managed | Intune-managed and compliant vs personal unmanaged device |
| Sign-in risk | Real-time risk level from Identity Protection | Anonymous IP address, impossible travel detected |
| User risk | Overall risk level of the user account | Leaked credentials detected |
Scenario: Raj builds Lakewood's first CA policy
Raj notices that student workers occasionally sign in from public computers at the campus library. These machines are unmanaged and could have keyloggers.
He creates a Conditional Access policy:
- IF: User is in the “Student Workers” group AND the device is not Intune-compliant
- THEN: Require MFA and limit to browser-only access (no downloading files)
Now, when a student worker signs in from the library, they must approve an MFA prompt and can only view documents in the browser — they cannot download sensitive HR files to an unmanaged PC.
“Same user, same app, different decision,” Raj explains to Professor Chen. “Context matters.”
Decisions: what Conditional Access can do
When conditions are met, Conditional Access can enforce these controls:
| Decision | What Happens |
|---|---|
| Block access | Sign-in is denied completely |
| Grant access | Sign-in is allowed (optionally with extra requirements) |
| Require MFA | User must complete multi-factor authentication |
| Require compliant device | Device must be Intune-compliant |
| Require Entra hybrid joined device | Device must be joined to both on-premises AD and Entra ID |
| Require approved client app | Only approved mobile apps can access the resource |
| Session controls | Limit what users can do after sign-in (e.g., block downloads, enforce sign-in frequency) |
Common Conditional Access policies
These are the policies you will see most often in real life and on the exam:
| Policy | What It Does | Why It Matters |
|---|---|---|
| Require MFA for all admins | Any admin role sign-in requires MFA — no exceptions | Admin accounts are the highest-value targets |
| Block legacy authentication | Block sign-in attempts using older protocols (SMTP, POP3, IMAP) | Legacy protocols cannot do MFA — they bypass your policies |
| Require compliant devices for sensitive apps | Only Intune-managed devices can access HR or finance apps | Prevents data leaks to personal or compromised devices |
| Block access from untrusted locations | Sign-ins from outside named locations are blocked | Reduces exposure from unfamiliar networks |
| Require MFA for risky sign-ins | If sign-in risk is medium or high, require MFA | Stops compromised credentials from being used |
Why blocking legacy auth matters
Legacy authentication protocols (like POP3 and IMAP for email) were built before MFA existed. They send credentials in a simple request — there is no way to interrupt them with an MFA prompt.
This means an attacker with stolen credentials can bypass all your MFA policies simply by using a legacy protocol. Blocking legacy auth closes this gap.
On the exam, if a question mentions “users are bypassing MFA,” the answer is almost always related to legacy authentication not being blocked.
Named locations
Named locations let you define trusted or untrusted IP ranges and countries so Conditional Access can use location as a signal.
| Type | What It Is | Example |
|---|---|---|
| IP ranges | Specific public IP address ranges marked as trusted | Lakewood’s campus network: 203.0.113.0/24 |
| Countries/regions | Geographic locations based on IP geolocation | Allow sign-ins only from New Zealand and Australia |
Key exam concept: Named locations are not policies themselves — they are signal definitions that policies reference. You create a named location, then use it as a condition in a Conditional Access policy.
Conditional Access and Zero Trust
Conditional Access is the enforcement engine for Zero Trust in Microsoft 365:
| Zero Trust Principle | How Conditional Access Enforces It |
|---|---|
| Verify explicitly | Evaluates multiple signals (identity, device, location, risk) before every access decision |
| Least privilege | Session controls limit what users can do (read-only, no downloads, time-limited sessions) |
| Assume breach | Risk-based policies detect compromised accounts and force re-authentication or block access |
Scenario: Sam protects BrightStar's POS system
Sam learns about Conditional Access from Raj and wants to protect BrightStar’s point-of-sale data.
He sets up two policies:
- IF user is in the “Store Managers” group AND device is not compliant → THEN block access to the inventory app
- IF sign-in risk is high for any user → THEN block access entirely
Tina, the store manager, tries to check inventory from her personal phone. Access denied — her phone is not Intune-managed. She switches to the store tablet (managed and compliant) and gets in immediately.
“Same person, different device, different outcome,” Sam says. “That’s the point.”
🎬 Video walkthrough
Flashcards
Knowledge Check
Raj creates a Conditional Access policy: IF the user is in the 'Student Workers' group AND the device is not compliant, THEN require MFA. A student worker signs in from a compliant university laptop. What happens?
Several users report they can access Exchange Online without MFA, even though a Conditional Access policy requires MFA for all users. What is the most likely cause?
Which Zero Trust principle does Conditional Access primarily enforce when it evaluates user identity, device compliance, and location before granting access?