This chapter covers Conditional Access policies, the cornerstone of identity security in Microsoft 365. For the MS-102 exam, approximately 20-25% of questions in Domain 2 (Identity Access) focus on Conditional Access, making it one of the most heavily tested topics. You will learn the architecture, policy components, evaluation logic, deployment best practices, and common misconfigurations. Mastering this chapter is essential for passing the exam and for real-world administration.
Jump to a section
Conditional Access works like a hotel key card system. A hotel has many rooms, each with different access levels: guest rooms, executive floors, gym, pool, and staff-only areas. The key card encodes the guest's identity (who they are), the current time (when they are allowed), and the floor/room access (where they can go). When a guest swipes their card at a door, the lock checks three things: the card's validity, the time of day, and the door's access policy. For example, a standard guest card may unlock the room and pool from 6 AM to 10 PM, but not the executive lounge. If a guest tries to enter the executive lounge, the lock denies access because the card does not have that permission. Similarly, if a guest tries to enter their room at 3 AM, the lock checks the time restriction and denies access if the card is only valid until 10 PM. The hotel management can change policies centrally: they can revoke a card instantly if a guest checks out, or grant temporary access to a conference room for a specific time window. This is exactly how Conditional Access works in Azure AD — the 'key card' is the authentication token, the 'locks' are the Conditional Access policies that evaluate signals (user, device, location, app, risk) and enforce access decisions (grant access, require MFA, block access). The central management is the Azure AD Conditional Access engine, which evaluates policies in real-time at every authentication request.
What is Conditional Access?
Conditional Access is the policy engine in Azure Active Directory (Azure AD) that enforces access controls based on signals collected during authentication. It is not a standalone product but a feature of Azure AD Premium P1 or P2. The core idea is to grant access only when conditions meet your organization's security requirements. Instead of a simple allow/deny, Conditional Access can require additional verification (like MFA), restrict access to compliant devices, or block access entirely.
Why Conditional Access Exists
Traditional perimeter-based security assumed that inside the corporate network was safe. With cloud and mobile, the perimeter is gone. Conditional Access shifts security to identity-centric, signal-based decisions. It enables granular control: a user accessing email from a trusted device on the corporate network may have seamless access, while the same user from an unknown device in a foreign country is prompted for MFA or blocked.
How Conditional Access Works: The Evaluation Engine
When a user attempts to access a cloud app (e.g., Exchange Online, SharePoint Online, or any app registered in Azure AD), the following sequence occurs: 1. The user authenticates to Azure AD (provides username/password, or token). 2. Azure AD collects signals: user identity, group membership, device state (compliant, domain-joined), location (IP address), application being accessed, risk level (from Identity Protection), and authentication context. 3. The Conditional Access engine evaluates all enabled policies in policy evaluation order (by policy ID, but effectively all are evaluated unless a blocking policy triggers first). 4. The engine determines the result: grant access, require additional controls (MFA, device compliance, terms of use), or block access. 5. The decision is enforced: if access is granted with controls, the user must satisfy them (e.g., complete MFA) before a token is issued.
Policy Components
Each Conditional Access policy consists of: - Assignments: Who (users/groups), What (cloud apps or actions), Conditions (sign-in risk, device platform, location, client apps, etc.). - Access Controls: Grant (require MFA, require compliant device, require hybrid Azure AD joined, require approved client app, require app protection policy, require password change, require terms of use) or Block. - Session Controls: Control session behavior like app enforced restrictions (Exchange, SharePoint), Conditional Access App Control (for browser sessions), sign-in frequency, persistent browser session.
Default Values and Timers
Session control – Sign-in frequency: Default is 90 days for persistent browser session. You can set from 1 hour to 365 days.
Session control – Persistent browser session: Default is 'Never persistent' (session ends when browser closes). You can set 'Persistent' to keep session across browser close.
Report-only mode: Policies can be enabled in report-only mode to test impact without enforcement. Logs are sent to Sign-in logs and Workbooks.
Policy evaluation order: Policies are evaluated in a specific order: first, all policies that apply to the user and app are gathered. Then, if any policy results in block, access is blocked. Otherwise, the most restrictive grant controls apply (e.g., if one policy requires MFA and another requires compliant device, both must be satisfied).
Location condition: Named locations are defined by IP ranges (IPv4/IPv6) or country/region. Trusted locations are typically corporate network IPs.
Device platform condition: Supports Android, iOS, Windows, macOS, and Linux (for some apps).
Configuration and Verification
To create a policy in Azure Portal: 1. Navigate to Azure AD > Security > Conditional Access > Policies > New policy. 2. Name the policy. 3. Under Assignments, select users/groups (include/exclude). 4. Select cloud apps (include/exclude). 5. Configure conditions (sign-in risk, device platforms, locations, client apps, etc.). 6. Under Access controls, select Grant or Block, and configure required controls (e.g., require MFA). 7. Under Session, configure session controls if needed. 8. Set Enable policy to Report-only or On.
Verification commands using Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Format-ListTo test with the What If tool:
In Azure AD > Security > Conditional Access > What If.
Enter user, app, IP address, device platform, etc.
The tool shows which policies would apply and the resulting controls.
How It Interacts with Related Technologies
Identity Protection: Provides sign-in risk and user risk signals. Conditional Access can require MFA or password change based on risk level (low, medium, high).
Microsoft Intune: Device compliance policies (e.g., require device to be compliant) are evaluated by Conditional Access. The device must be enrolled in Intune and meet compliance rules.
Azure AD Identity Governance: Access reviews and entitlement management integrate with Conditional Access to enforce time-bound access.
Microsoft Defender for Cloud Apps: Conditional Access App Control provides session-level monitoring and control for browser-based apps. It can block downloads, restrict clipboard, etc.
Azure AD B2B: Guest users can be subject to Conditional Access policies, but cross-tenant trust may affect policy application.
Policy Evaluation Logic – Detailed
When multiple policies apply, the evaluation logic is:
If any policy results in Block, access is blocked.
If multiple Grant policies apply, all grant controls must be satisfied (AND logic). For example, Policy A requires MFA, Policy B requires compliant device. The user must do both.
Exception: If a policy uses 'Require one of the selected controls' (OR logic), the user must satisfy at least one. This is configured in Grant by selecting 'Require one of the selected controls'.
Session controls from multiple policies are combined: the most restrictive session control applies. For sign-in frequency, the shortest value wins.
Common Misconfigurations
Excluding break-glass accounts: Always exclude at least one emergency access account from all policies to avoid lockout.
Not using report-only mode: Deploying policies directly in 'On' mode can block legitimate users. Always test with report-only first.
Overly broad exclusions: Excluding all users or all apps defeats the purpose.
Location condition misconfiguration: Using incorrect IP ranges for trusted locations can cause false blocks or allow unintended access.
Device platform condition too broad: Allowing all device platforms without requiring compliance can bypass security.
Exam Tips
Know the difference between Grant controls and Session controls.
Understand the order of evaluation: Block overrides Grant.
Remember that Conditional Access requires Azure AD Premium P1 or P2.
Report-only mode is critical for testing.
The What If tool is used to troubleshoot policy application.
Be aware that Conditional Access policies apply to first-party Microsoft apps (Office 365) and third-party apps integrated with Azure AD.
User initiates authentication
The user attempts to access a cloud application (e.g., Outlook Web App). The browser or client app sends an authentication request to Azure AD. This request includes the username, password (or token), device information, and client app ID. Azure AD begins the sign-in process by validating the credentials and collecting additional signals like IP address, device platform, and application being accessed. At this point, no Conditional Access evaluation has occurred yet; it's just initial authentication.
Azure AD collects signals
After successful primary authentication (password correct), Azure AD gathers signals from multiple sources: user's group memberships (via directory read), device state (from Intune or Azure AD join), sign-in risk (from Identity Protection if Premium P2), location (IP address geolocation or named locations), and client app type (browser, mobile app, legacy auth). These signals are passed to the Conditional Access engine. The engine also checks if the application is included in any policy's app assignments.
Conditional Access engine evaluates policies
The engine retrieves all enabled Conditional Access policies. For each policy, it checks if the user, app, and conditions match. If a policy matches, the engine records the required grant controls (e.g., MFA) and session controls (e.g., sign-in frequency). If any policy specifies Block, the engine immediately sets the result to Block. Otherwise, it aggregates all grant controls from matching policies. If multiple policies require different controls, the user must satisfy all (unless OR is configured). The engine then determines the final decision.
Enforcement of access controls
Based on the engine's decision, Azure AD responds to the client. If the decision is Block, the user receives an access denied error. If Grant with controls, Azure AD issues a token that includes claims indicating required additional verification (e.g., MFA required). The client is redirected to perform MFA, device compliance check, or terms of use acceptance. After the user satisfies the controls, Azure AD issues a final token. If the decision is Grant without controls, a token is issued directly.
Session controls applied
After access is granted, session controls may be enforced. For example, if sign-in frequency is set to 1 hour, the token's lifetime is limited to 1 hour. The client must re-authenticate after that period. If persistent browser session is disabled, the session ends when the browser closes. For app enforced restrictions, the token includes claims that instruct the application (e.g., Exchange Online) to enforce specific policies like restricting download of attachments. Conditional Access App Control may proxy the session to monitor and restrict user actions.
Enterprise Scenario 1: Remote Access with MFA and Device Compliance
A global company with 10,000 users allows remote access to Office 365. They want to require MFA for all external access but allow seamless access from corporate devices on the corporate network. The solution: create a Conditional Access policy that targets all cloud apps, excludes trusted locations (corporate IP ranges), and requires MFA and device compliance. Additionally, they configure session controls to require re-authentication every 8 hours for external access. In production, this policy is first tested in report-only mode for one week to ensure no legitimate users are blocked. The What If tool is used to verify that users on the corporate network are not prompted for MFA. Common issue: if the corporate IP range changes (e.g., VPN changes), users may suddenly be prompted for MFA. The solution is to keep the named location updated.
Enterprise Scenario 2: High-Risk User Blocking
A company uses Azure AD Identity Protection (Premium P2) to detect risky sign-ins. They create a policy that blocks access when sign-in risk is high. For medium risk, they require MFA. This policy is applied to all users except break-glass accounts. In practice, false positives can occur: a user traveling may trigger high risk due to unfamiliar location. The policy blocks them until they contact IT. To mitigate, they configure a risk-based policy with a grace period or use temporary access pass. The sign-in logs are monitored daily to review blocked attempts.
Enterprise Scenario 3: Legacy Authentication Blocking
An organization wants to block legacy authentication (POP, IMAP, SMTP) because it does not support MFA. They create a policy targeting all cloud apps, with condition client apps: Exchange ActiveSync clients, other clients (legacy). The grant control is set to Block. This effectively stops all legacy auth attempts. However, some users may have devices that still use legacy protocols, causing them to lose email access. The IT team must migrate those devices to modern auth (OAuth 2.0). This policy is enforced globally and is a common exam scenario.
Performance and Scale Considerations
Conditional Access policies are evaluated in real-time with minimal latency (typically <1 second per policy). For very large tenants (100k+ users), the number of policies should be kept under 200 to avoid management complexity. The What If tool can be slow for large environments. Use PowerShell or Graph API for bulk operations.
What MS-102 Tests on Conditional Access
Objective 2.3: Implement and manage Conditional Access. The exam focuses on:
Policy components: assignments, conditions, access controls, session controls.
Evaluation logic: block overrides grant, AND logic for multiple grant controls.
Report-only mode and What If tool.
Integration with Identity Protection (sign-in risk, user risk).
Device-based conditions: compliant, hybrid Azure AD joined.
Location condition: named locations, trusted locations.
Client app conditions: modern auth vs legacy auth.
Session controls: sign-in frequency, persistent browser session, app enforced restrictions.
Troubleshooting: using sign-in logs to understand policy application.
Common Wrong Answers
"Conditional Access policies are evaluated in order of priority." – Wrong. There is no priority order; all applicable policies are evaluated. Block policies take precedence over grant policies.
"You can use Conditional Access with Azure AD Free." – Wrong. Requires Azure AD Premium P1 or P2.
"Report-only mode blocks access but logs it." – Wrong. Report-only mode does not block; it only logs what would happen.
"Conditional Access policies apply to guest users by default." – Wrong. They apply to guest users only if the policy includes 'All users' or explicitly includes guest users. Cross-tenant settings can affect.
Specific Numbers and Terms
Sign-in frequency default: 90 days.
Persistent browser session default: Never persistent.
Risk levels: low, medium, high, none.
Named locations: up to 195 named locations per tenant.
Policies: up to 250 policies per tenant.
Edge Cases
If a user is excluded from a policy, they are not subject to it, even if the condition matches.
Device compliance requires Intune enrollment; hybrid Azure AD joined devices are considered compliant if they meet compliance policies.
For B2B collaboration, guest users from other tenants may not satisfy device compliance unless cross-tenant trust is configured.
Legacy authentication (POP, IMAP, SMTP) cannot perform MFA; policies that require MFA will block legacy auth if not excluded.
How to Eliminate Wrong Answers
Understand the underlying mechanism: Conditional Access evaluates all policies simultaneously (not sequentially). Block is a hard stop. Grant controls are additive. Use the What If tool to simulate. Remember that report-only is for testing only. If a question mentions 'priority', it's a trap.
Conditional Access requires Azure AD Premium P1 or P2.
Policies consist of Assignments (who, what, conditions) and Access Controls (grant or block).
Block policies override grant policies; all applicable grant controls must be satisfied (AND logic unless OR is configured).
Report-only mode is essential for testing policies before enforcement.
The What If tool helps simulate policy application for a specific user and scenario.
Named locations are defined by IP ranges or countries; trusted locations are typically corporate networks.
Session controls include sign-in frequency (default 90 days) and persistent browser session (default never).
Device compliance requires Intune enrollment; hybrid Azure AD join alone does not satisfy compliance unless a compliance policy is assigned.
Legacy authentication (POP, IMAP, SMTP) does not support MFA; policies requiring MFA block legacy auth.
Always exclude break-glass accounts from all policies to prevent lockout.
Maximum 250 policies per tenant, 195 named locations.
Conditional Access policies apply at authentication time, not continuously; token lifetime affects re-evaluation.
These come up on the exam all the time. Here's how to tell them apart.
Azure AD Free
No Conditional Access policies
Basic MFA per user (not policy-based)
No risk-based policies
No device compliance integration
No session controls
Azure AD Premium P1
Full Conditional Access policies
Policy-based MFA, location, device conditions
Requires P2 for risk-based policies
Device compliance integration with Intune
Session controls: sign-in frequency, persistent browser
Mistake
Conditional Access policies are evaluated in a priority order, and the first matching policy wins.
Correct
All applicable policies are evaluated. If any policy results in Block, access is blocked. If multiple grant policies apply, all grant controls must be satisfied (unless OR is configured). There is no priority order; policy ID is irrelevant.
Mistake
Conditional Access works without Azure AD Premium licenses.
Correct
Conditional Access requires Azure AD Premium P1 or P2. Azure AD Free or Office 365 apps do not include Conditional Access. However, some basic policies like MFA per user are available but not Conditional Access.
Mistake
Report-only mode blocks access and logs the decision.
Correct
Report-only mode does not enforce any controls; it only logs what would happen if the policy were enabled. Access is not blocked, and no additional controls are required. It is used for testing.
Mistake
Conditional Access policies apply to all users including guests by default.
Correct
Policies apply only to the users and groups specified in the assignments. If 'All users' is selected, it includes guests. But you must explicitly include guests; they are not automatically covered unless included.
Mistake
Device compliance condition works without Intune.
Correct
Device compliance requires that devices are enrolled in Intune (or co-managed with Configuration Manager). The device must have a compliance policy assigned and report as compliant. Hybrid Azure AD joined devices are considered compliant only if they meet compliance policies.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
MFA per user is a simple on/off setting that requires MFA for all sign-ins for a user. Conditional Access allows granular control: you can require MFA only under specific conditions (e.g., from untrusted locations, for specific apps, or when risk is medium). Conditional Access also supports additional controls like device compliance and session limits. For the exam, remember that MFA per user is legacy and less flexible; Conditional Access is the recommended approach.
Use report-only mode. Create the policy and set 'Enable policy' to 'Report-only'. Then use the What If tool to simulate a specific user and conditions. The tool shows which policies would apply and the resulting controls. After testing, review the sign-in logs to see the policy's impact. Once confident, switch the policy to 'On'.
Yes, Conditional Access policies can be applied to applications (service principals) by selecting the app in the cloud apps assignment. However, user conditions (like group membership) still apply. For service principals that run as background services, user-based policies may not be appropriate. There is also a feature called Conditional Access for workload identities (preview) that supports service principals directly.
The user must satisfy both controls. The grant controls are combined with AND logic by default. So the user must complete MFA and have a compliant device. If you want the user to satisfy either one, you can configure the Grant control to 'Require one of the selected controls' (OR logic).
Create a policy that targets all cloud apps, under Conditions > Client apps, select 'Exchange ActiveSync clients' and 'Other clients' (legacy). Set Access control to Block. This will block all legacy authentication attempts. Ensure modern authentication is enabled for your tenant and users are using modern clients.
Sign-in risk is the probability that a specific authentication attempt is not legitimate (e.g., anonymous IP, unfamiliar location). User risk is the probability that a user's identity has been compromised (e.g., leaked credentials). Conditional Access can use both: e.g., require MFA for medium sign-in risk, block for high user risk. Identity Protection (P2) provides these signals.
Yes. You can create a terms of use (ToU) document in Azure AD, then in a Conditional Access policy, under Grant, select 'Require terms of use'. The user must accept the ToU before accessing the app. This is a common control for guest access or sensitive apps.
You've just covered Conditional Access Policies — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?