🎯 Entra ID Course · Module 6 of 8
Conditional Access Policies
SC-300 Exam Alignment
SC-300
Implement authentication and access management — Conditional Access: Plan and implement Conditional Access policies. Configure named locations, report-only mode, sign-in frequency, session controls, and Continuous Access Evaluation (CAE).
- Know the full CA policy anatomy: Assignments (Users/Groups, Cloud apps/actions, Conditions) + Access controls (Grant, Session)
- Know that CA requires Entra ID P1 and that break-glass accounts must always be excluded from all CA policies
- Know when to use Report-only mode — test impact before enforcing, view results in sign-in logs
- Know the difference between Grant controls: Block vs Allow with requirements (MFA, compliant device, hybrid joined device)
- Know that Legacy authentication (basic auth) bypasses CA and should be blocked by policy
Exam Tip: CA policies use implicit deny — if no policy grants access, access is blocked. But if no policy applies at all (user/app not in scope), access is allowed. The exam tests the logic: a policy set to Block always wins over a policy set to Grant when both match. Also know: the All users assignment includes guests and external users unless explicitly excluded.
Conditional Access is Microsoft Entra ID's policy engine — it evaluates real-time signals from users, devices, locations, and apps to decide whether to allow access, block access, or require additional verification. Think of it as: If [signal conditions are met] → enforce [access control]. A well-designed CA policy set is the core of a Zero Trust access strategy.
🏗️ Conditional Access Policy Anatomy
Every CA policy has two parts: Assignments (what the policy applies to) and Access controls (what happens when the policy triggers).
Entra admin center › Protection › Conditional Access › + New policy
🛡️ Protection
Conditional Access
Named locations
Auth strengths
Auth methods
ASSIGNMENTS
Users: All users excl. Break-glass
Cloud apps: Office 365
Conditions:
• Sign-in risk: Medium, High
• Client apps: Browser + Mobile apps
• Sign-in risk: Medium, High
• Client apps: Browser + Mobile apps
ACCESS CONTROLS
Grant: Allow access
☑ Require MFA
☑ Require compliant device
☑ Require MFA
☑ Require compliant device
Session: Sign-in frequency: 8 hours
Enable policy: Report-only →
Assignments — What the Policy Applies To
| Assignment | Options | Key Notes |
|---|---|---|
| Users | All users, Specific users/groups, Roles (e.g., all Global Admins), Guest/external, Workload identities | Always exclude break-glass accounts. "All users" includes guests. You can include roles (targets anyone holding that role) |
| Cloud apps or actions | All cloud apps, specific apps (by name), User actions (Register security info, Register or join devices) | "All cloud apps" is the broadest scope. "User actions" lets you protect MFA registration itself |
| Conditions: Sign-in risk | High, Medium, Low, No risk (requires Identity Protection / P2) | Based on real-time risk signals — impossible travel, anonymous IP, leaked credentials |
| Conditions: User risk | High, Medium, Low (requires P2) | Cumulative risk for the user account — based on risk detections over time |
| Conditions: Device platforms | Android, iOS, Windows, macOS, Linux | Useful to enforce different controls per platform (stricter on mobile) |
| Conditions: Locations | Any location, All trusted locations, Specific named locations | Named locations defined by IP ranges or countries. Trusted IPs are flagged as "trusted" |
| Conditions: Client apps | Browser, Mobile apps and desktop clients, Exchange ActiveSync, Other clients | "Other clients" catches legacy auth protocols (IMAP, POP, SMTP AUTH) — used to block legacy auth |
| Conditions: Filter for devices | Device attribute filter (e.g., device.isCompliant -eq True) | More granular than device platform — can filter on specific device properties |
Access Controls — What Happens When the Policy Matches
| Control Type | Options | Notes |
|---|---|---|
| Grant | Block access | Completely denies the request. Overrides all Grant controls in other policies |
| Require multifactor authentication | User must complete MFA. Uses whichever methods are registered in their Authentication Methods | |
| Require authentication strength | Requires a specific named strength (e.g., "Phishing-resistant MFA" = FIDO2 or Windows Hello or CBA only) | |
| Require device to be marked as compliant | Device must pass Intune compliance policy evaluation. Requires Intune enrolment | |
| Require hybrid Azure AD joined device | Device must be joined to both on-prem AD and Entra ID. Legacy option before Intune compliance | |
| Require approved client app | App must be on Microsoft's approved list (e.g., Outlook mobile, not just any IMAP client) | |
| Require password change | Forces the user to change their password before accessing — used in user risk policies | |
| Session | Sign-in frequency | How often the user must reauthenticate. Options: specific hours/days, or "Every time" (always prompt). Overrides token lifetime |
| Persistent browser session | Controls whether "Stay signed in" applies. Set to Not persistent for shared/kiosk devices | |
| Conditional Access App Control | Routes session through Microsoft Defender for Cloud Apps proxy for real-time session monitoring | |
| Continuous Access Evaluation (CAE) | Enables near-real-time token revocation when risk changes (user disabled, IP changes, etc.) |
📍 Named Locations
| Location Type | Definition | Use Case |
|---|---|---|
| IP ranges location | Define by IPv4/IPv6 CIDR ranges. Can be marked as "Trusted" | Mark office IP ranges as trusted — policies can exempt trusted locations from MFA or require MFA outside them |
| Countries/regions location | Select countries by geography — GPS or IP-based detection | Block access from countries where your org has no presence |
🔬 Report-Only Mode
💡 Always Test with Report-Only First
Report-only mode evaluates a CA policy against real sign-in traffic without enforcing it. The result appears in Sign-in logs under Conditional Access — showing "Report-only: Success" or "Report-only: Failure" for each sign-in. Run every new CA policy in report-only mode for at least 2–5 business days before switching to On.
🚫 Blocking Legacy Authentication
⚠️ Legacy Auth Bypass Risk
Legacy authentication protocols (IMAP, POP3, SMTP AUTH) cannot pass MFA challenges — they bypass all CA policies that require MFA. Create a Block policy: Conditions → Client apps → "Exchange ActiveSync clients" + "Other clients" → Grant: Block access.
⚡ Continuous Access Evaluation (CAE)
CAE enables near-real-time communication between resource services (Exchange Online, SharePoint, Teams) and Entra ID. When a critical event occurs — user account disabled, password changed — the resource immediately requests a fresh token evaluation rather than waiting up to 1 hour for token expiry.
PowerShell — Conditional Access Management
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess','Policy.Read.All' # List all Conditional Access policies and their state Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName,State,Id | Sort-Object DisplayName # Enable a policy (report-only → on) Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId '<policy-id>' -State 'enabled' # List named locations Get-MgIdentityConditionalAccessNamedLocation | Select-Object DisplayName,Id
💡 Best Practices
- Always exclude break-glass accounts from all CA policies — without this exclusion, a misconfigured CA policy can lock everyone out of the tenant
- Deploy every new CA policy in Report-only mode first — review sign-in logs for 2–5 days before enabling enforcement
- Start with: Require MFA for all administrators and Block legacy authentication — these together block the most common attack vectors
- Enable Continuous Access Evaluation in session controls for critical apps — ensures access is revoked near-real-time when users are terminated
🎓 Interview Q&A
Q: A CA policy is set to require MFA for all users accessing Office 365. A user successfully authenticates from a trusted office IP without being prompted for MFA. Why?
The CA policy likely has a condition under Conditions → Locations that excludes trusted locations. When the office IP is defined as a Named Location and marked as trusted, and the policy condition specifies it applies only outside "All trusted locations," sign-ins from the office IP are excluded from the policy trigger — MFA is not required. This is a common configuration for reducing MFA friction for office workers while requiring MFA for remote access.
🎯 SC-300 Mock Test
Module 6 — Conditional Access Policies
5 questions · Scenario-based · Pass mark: 70%
Q1 of 5
An organisation has a CA policy requiring MFA for Office 365 with state "Report-only." Users report they are not being prompted for MFA. Is this expected?
ANo — Report-only still enforces MFA but logs the result silently
BNo — there must be an error in the policy configuration
CNo — Report-only only works for Block policies, not MFA requirements
DYes — Report-only evaluates the policy against real traffic but does not enforce it. Results appear in Sign-in logs
Q2 of 5
A user is terminated. Their account is disabled in Entra ID. However, they continue to read emails in Outlook for 45 minutes. What explains this?
AThe account disable did not replicate to Exchange Online immediately
BThe user's OAuth access token was still valid (up to 1 hour). Without CAE, Exchange does not check token validity on every request
CThe account must be blocked via CA policy — disabling alone has no effect
DOutlook always has a 60-minute grace period after account changes
Q3 of 5
Users bypass MFA by connecting via IMAP with username/password. Which CA condition blocks this?
AConditions → Locations: Block all non-trusted locations
BConditions → Device platforms: Block Android and iOS
CConditions → Client apps: Select "Exchange ActiveSync clients" and "Other clients" → Grant: Block access
DConditions → Sign-in risk: Block all High risk sign-ins
Q4 of 5
An admin accidentally creates a CA policy blocking All users from All cloud apps. Everyone is locked out. What is the solution?
ASign in with a break-glass account excluded from all CA policies, then disable the problematic policy
BWait 24 hours — CA policies automatically expire if they lock out all admins
CContact Microsoft Support — only Microsoft can override a CA block policy
DUse PowerShell with app credentials — CA doesn't apply to service principals
Q5 of 5
A CA policy requires compliant devices for SharePoint. A user on a personal unmanaged laptop tries to access SharePoint from a browser. What happens?
AAccess is granted — compliant device checks only apply to native apps
BAccess is blocked — the device is not enrolled in Intune and cannot be marked as compliant
CThe user is prompted to enrol their personal device in Intune
DMFA is required instead since compliant device check cannot be performed
🔒
Locked — Complete Module 5 first.
Pass the quiz (70%+) to unlock Module 7: External Identities & B2B