This chapter covers Conditional Access Policies, a cornerstone of identity security in Microsoft Entra ID. For the SC-900 exam, approximately 15-20% of questions in the 'Identity Access' domain touch on Conditional Access concepts. Understanding how policies evaluate signals and enforce controls is critical for passing the exam and for real-world identity security. This chapter will break down the components, flow, and common configurations you need to know.
Jump to a section
Think of Conditional Access as an airport security checkpoint that adapts its screening level based on who you are and how you're traveling. Every passenger approaches the checkpoint with a boarding pass (user identity) and a flight to catch (application access). The security officer (Azure AD) first checks your identity document (primary authentication – username/password). Then, based on your profile, the officer applies different rules: a first-class passenger who flew yesterday (known device, recent sign-in) gets a quick metal detector scan (session control – require compliant device). A passenger on the no-fly list (risky user) gets a full pat-down and baggage search (require MFA, block access). A passenger flying to a high-risk destination (risky location) is asked for additional ID (require MFA). The officer also checks your carry-on bag for prohibited items (device health – require Intune compliance). If you pass all checks, you get a stamped boarding pass (access token) and proceed to the gate. Just like the airport, Conditional Access evaluates signals (user, device, location, risk) and enforces policies (grant access, require MFA, block) before allowing entry to the application.
What is Conditional Access?
Conditional Access is a policy-based engine in Microsoft Entra ID (formerly Azure Active Directory) that evaluates signals from the authentication request and enforces access controls before granting access to applications. It is not a firewall or a VPN; it is an identity-driven decision point that can block access, require multi-factor authentication (MFA), require a compliant device, or restrict session behavior.
The core purpose is to allow organizations to protect resources based on conditions, rather than relying solely on static username/password authentication. The exam tests your understanding of the components and flow, not deep configuration syntax.
How Conditional Access Works – The Evaluation Flow
When a user attempts to access a resource (e.g., Exchange Online, SharePoint, or a custom SaaS app), the following sequence occurs:
Primary Authentication: The user provides credentials (username/password, FIDO2 key, etc.). This happens before Conditional Access policies are evaluated. If primary auth fails, the user is denied immediately.
Policy Collection: Azure AD collects all Conditional Access policies that apply to the user and the target application. Policies are stored in the tenant and can be scoped to users, groups, roles, or all users.
Signal Evaluation: Each policy defines conditions – signals like user/group membership, location (IP address, country), device platform (Windows, iOS, Android), client app (browser, mobile app, legacy auth), sign-in risk (from Identity Protection), and application sensitivity.
Decision: For each applicable policy, Azure AD evaluates whether the conditions are met. If a policy's conditions are satisfied, its access controls are applied. If multiple policies apply, all must be satisfied (logical AND) unless exceptions exist.
5. Access Controls: Two types: - Grant controls: Block access, require MFA, require device to be marked as compliant, require Hybrid Azure AD joined device, require approved client app, require app protection policy. - Session controls: Use app-enforced restrictions (e.g., allow only certain actions in Exchange), use Conditional Access App Control (a reverse proxy that monitors sessions), sign-in frequency, persistent browser session.
Result: The user is either granted access (possibly with restrictions) or blocked. If MFA is required, the user must complete MFA before access is granted.
Key Components and Defaults
Assignments: Who (users/groups), What (cloud apps/actions), and Conditions (sign-in risk, device platforms, locations, client apps).
Locations: Defined by named locations (IP ranges, countries) or by the location detection service. The default location is 'All trusted' or 'All locations' – exam tip: you can create custom named locations.
Client Apps: Browser, mobile apps and desktop clients, Exchange ActiveSync (EAS), Other clients (legacy auth). Legacy auth is a key exam topic – it bypasses many CA policies and is recommended to be blocked.
Sign-in Risk: Requires Azure AD Identity Protection (P2 license). Values: Low, Medium, High, None.
Grant Controls: 'Require multi-factor authentication', 'Require device to be marked as compliant', 'Require Hybrid Azure AD joined device', 'Require approved client app', 'Require app protection policy', 'Require password change', 'Require terms of use', 'Block access'. Multiple controls can be combined with 'Require all' (AND) or 'Require one' (OR).
Session Controls: 'Use app-enforced restrictions' (e.g., Exchange Online's device access rules), 'Use Conditional Access App Control' (Microsoft Defender for Cloud Apps), 'Sign-in frequency' (every N hours), 'Persistent browser session' (allow or block).
Configuration and Verification
Conditional Access policies are configured in the Azure portal under Microsoft Entra ID > Security > Conditional Access. PowerShell cmdlets exist (e.g., Get-AzureADMSConditionalAccessPolicy) but are not tested on SC-900. The exam expects you to know the portal location and the basic structure.
To verify a policy is working, you can use the What If tool in the Azure portal. It simulates a sign-in attempt based on user, app, and conditions, and shows which policies would apply and what controls would be enforced.
Interaction with Related Technologies
Identity Protection: Provides sign-in risk and user risk signals that can be used in Conditional Access policies. For example, if sign-in risk is Medium or High, require MFA.
Microsoft Intune: Provides device compliance status. Conditional Access can require a device to be compliant (managed by Intune) or Hybrid Azure AD joined.
Microsoft Defender for Cloud Apps: Provides session controls via Conditional Access App Control, which can monitor and control user sessions in real time (e.g., block downloads).
Azure AD Multi-Factor Authentication: MFA is often required by Conditional Access policies. The MFA challenge is triggered after policy evaluation.
Exam-Specific Details
Default policy: There is no default policy that blocks all access. However, Microsoft recommends creating a baseline policy to require MFA for all users. The exam may ask about Microsoft's recommended policies (e.g., require MFA for admins, block legacy auth).
Legacy authentication: Protocols like POP, IMAP, SMTP, and older Office clients that do not support modern authentication. Conditional Access policies often cannot enforce MFA on these clients because they cannot present a challenge. Therefore, the recommended action is to block legacy auth entirely.
Report-only mode: Policies can be enabled in report-only mode to test their effect without impacting users. This is part of the 'Enable policy' toggle: Off, On, Report-only.
Policy order: Policies are not ordered. All applicable policies are evaluated. If any policy blocks, the user is blocked. If multiple policies grant with different controls, all must be satisfied (AND) unless 'Require one' is used.
Common Traps
Trap: 'Conditional Access replaces MFA' – Reality: Conditional Access can require MFA, but MFA itself is a separate service. CA policies trigger MFA challenges; they do not replace MFA.
Trap: 'Policies are evaluated in priority order' – Reality: There is no priority. All policies that match are evaluated. If one blocks, the result is block.
Trap: 'Location conditions use GPS' – Reality: Location is based on public IP address and is mapped to named locations. Not GPS.
Trap: 'All CA policies require P2 license' – Reality: Basic CA policies (e.g., require MFA for users) are available with P1. P2 adds risk-based policies via Identity Protection.
Summary of Key Numbers
Named locations: Up to 195 per tenant.
Policies per tenant: Up to 250.
Conditions: Up to 5 per policy? No hard limit, but practical limits exist.
Sign-in frequency default: 90 days for persistent sessions.
Persistent browser session: Default is persistent (unless policy says otherwise).
This depth ensures you understand the mechanism, not just buzzwords. The exam rewards understanding of how signals flow and controls are applied.
User Initiates Authentication
The user attempts to access a cloud application (e.g., Outlook Web Access, SharePoint Online). The client (browser or app) sends an authentication request to Azure AD. This request includes the user's credentials (e.g., username/password) and metadata like client app type, device platform, and IP address. At this point, primary authentication occurs – Azure AD validates the credentials against its directory. If the credentials are invalid, the user receives an error immediately, and Conditional Access policies are never evaluated.
Policy Discovery and Evaluation
After successful primary authentication, Azure AD determines which Conditional Access policies apply to the user and the target application. It checks the policy assignments: user/group membership, cloud app selection, and conditions (locations, device platforms, client apps, sign-in risk). For each policy, it evaluates whether the conditions are met. If the user is excluded from a policy (via 'Exclude' assignment), that policy is skipped. All applicable policies are gathered; there is no priority ordering. If no policies apply, the user is granted access without additional controls.
Grant Controls Enforcement
For each applicable policy, the grant controls are enforced. If a policy requires MFA, Azure AD checks whether the user has already satisfied MFA in the current session. If not, the user is prompted to complete MFA (e.g., via phone call, authenticator app, or SMS). If a policy requires a compliant device, Azure AD checks with Intune for the device compliance status. If the device is not compliant, the user may be blocked or redirected to enroll. Multiple grant controls can be combined – if 'Require all' is selected, all must be satisfied; if 'Require one', at least one must be met.
Session Controls Application
After grant controls are satisfied, session controls may be applied. These controls affect the user's session after access is granted. For example, 'Use app-enforced restrictions' allows the application (like Exchange Online) to enforce its own policies (e.g., device access rules). 'Use Conditional Access App Control' routes the session through Microsoft Defender for Cloud Apps, enabling real-time monitoring and controls like blocking downloads. 'Sign-in frequency' forces the user to re-authenticate after a specified time period (e.g., every 1 hour). 'Persistent browser session' controls whether the session cookie persists across browser closes.
Access Token Issued or Denied
If all grant controls are satisfied and no session controls block access, Azure AD issues an access token to the client. The token is used to authenticate the user to the target application. If any policy blocks access (either via grant control 'Block' or session control that results in block), the user is denied with an error message. The token includes claims that reflect the session controls (e.g., sign-in frequency, app restrictions). The application then enforces the token's claims. This is the final step; the user either gains access with potential restrictions or is blocked.
Enterprise Scenario 1: Requiring MFA for Remote Access
A large enterprise with 10,000 employees wants to require MFA for all users accessing corporate email from outside the corporate network. They configure a Conditional Access policy: Assignments – All users, Cloud apps – Office 365 Exchange Online, Conditions – Locations: All trusted locations excluded (corporate IP range is marked as trusted). Grant – Require multi-factor authentication. When a user logs in from a coffee shop (IP not in trusted location), they must complete MFA. This reduces the risk of credential theft. Common misconfiguration: forgetting to exclude the corporate IP range, causing MFA prompts even inside the office. The solution uses named locations based on IP ranges. Performance consideration: MFA challenges add a few seconds to login; users may complain. The policy is deployed in report-only mode first to verify correct behavior.
Enterprise Scenario 2: Blocking Legacy Authentication
A healthcare organization must comply with HIPAA and wants to block all legacy authentication protocols (POP, IMAP, SMTP) because they cannot enforce MFA. They create a Conditional Access policy: Assignments – All users, Cloud apps – All cloud apps, Conditions – Client apps: Exchange ActiveSync (EAS) and Other clients (legacy auth). Grant – Block access. This prevents any legacy client from accessing Exchange Online. Users who still use Outlook 2010 (which uses legacy auth) will be blocked. The organization must migrate to modern authentication. Common issue: some service accounts use legacy auth for SMTP relay – those must be excluded. The policy is set to 'On' after testing. Note: Blocking legacy auth is a Microsoft best practice and frequently appears on the exam.
Enterprise Scenario 3: Conditional Access App Control for Sensitive Apps
A financial services firm uses a third-party SaaS app (e.g., Salesforce) that contains sensitive customer data. They want to prevent users from downloading files to unmanaged devices. They configure a Conditional Access policy with session control: 'Use Conditional Access App Control' and then configure a policy in Microsoft Defender for Cloud Apps to block downloads. When a user accesses Salesforce from a personal device, the session is proxied through Defender for Cloud Apps. Any attempt to download a file is intercepted and blocked. This requires the user to be licensed for Defender for Cloud Apps. Misconfiguration: if the session control is not applied, users can bypass the restriction. The policy must be targeted correctly (e.g., to specific cloud apps). Performance: proxying adds latency; users may experience slower response times. This scenario is tested on SC-900 as understanding that session controls require additional licensing.
What SC-900 Tests on Conditional Access
The exam objective '2.3 Describe the capabilities of Conditional Access' focuses on understanding the purpose, components, and flow. Specific sub-objectives include:
Describe what Conditional Access is (policy engine that evaluates signals).
Describe the types of signals: user/group, location, device platform, client app, sign-in risk.
Describe common access controls: require MFA, require compliant device, block access.
Understand the concept of session controls (sign-in frequency, app-enforced restrictions).
Recognize that Conditional Access works with other services: Identity Protection, Intune, Defender for Cloud Apps.
Know the difference between Conditional Access and MFA (CA triggers MFA, not replaces it).
Common Wrong Answers and Why
'Conditional Access policies are evaluated in order of priority.' – Wrong. There is no priority; all applicable policies are evaluated. If one blocks, access is blocked. Candidates confuse this with other policy engines (like Group Policy).
'Conditional Access can block access based on user role.' – Partially true, but the exam tests that you can use groups, not roles directly. However, Azure AD roles (like Global Admin) can be used in assignments via 'Directory roles' (preview). The wrong answer often says 'Conditional Access cannot use roles'. Actually, it can, but the classic exam answer emphasizes groups.
'Conditional Access requires Azure AD P2 license.' – Wrong. Basic policies (MFA, device compliance) require P1. Risk-based policies require Identity Protection (P2). Candidates often choose P2 for all CA.
'Session controls are the same as grant controls.' – Wrong. Grant controls decide whether to allow access; session controls modify the session after access is granted.
Specific Numbers and Terms
Named locations: Up to 195 per tenant.
Policies per tenant: Up to 250.
Sign-in frequency default: 90 days for persistent browser sessions.
Legacy authentication: Protocols that do not support modern auth (POP, IMAP, SMTP, etc.).
Report-only mode: Allows testing without enforcement.
What If tool: Simulates policy evaluation.
Edge Cases and Exceptions
Service accounts: Often excluded from policies that require MFA or block legacy auth.
Emergency access accounts: 'Break-glass' admin accounts are typically excluded from all policies to prevent lockout.
Guest users: Conditional Access policies can apply to guest users (B2B collaboration). The exam may test that guest users can be included or excluded.
Device compliance: Requires Intune licensing. If a policy requires a compliant device but the device is not enrolled, the user is blocked unless there is an exception.
How to Eliminate Wrong Answers
If the question mentions 'evaluates signals before granting access', it's likely Conditional Access.
If the answer option says 'replaces MFA', it's wrong.
If it says 'policies are applied in a specific order', it's wrong.
If it says 'requires P2 license for all policies', it's wrong unless risk-based.
Focus on the mechanism: signals → policy evaluation → access controls (grant or session).
Conditional Access is a policy-based engine that evaluates signals (user, device, location, risk) and enforces access controls before granting access to cloud apps.
Key conditions: user/group membership, cloud app, location (IP-based), device platform, client app, sign-in risk (requires P2).
Grant controls: block access, require MFA, require compliant device, require Hybrid Azure AD joined, require approved app, require app protection policy.
Session controls: sign-in frequency, persistent browser session, app-enforced restrictions, Conditional Access App Control.
Legacy authentication protocols (POP, IMAP, SMTP) do not support MFA and should be blocked via Conditional Access.
Policies are not ordered; all applicable policies are evaluated. If any blocks, access is blocked.
Basic CA policies require Azure AD P1; risk-based policies require P2 (Identity Protection).
Use What If tool to simulate policy evaluation and test policies in report-only mode before enabling.
Named locations can be defined by IP ranges or countries; up to 195 per tenant.
Emergency access accounts should be excluded from all policies to prevent lockout.
These come up on the exam all the time. Here's how to tell them apart.
Conditional Access
Policy engine that evaluates signals (user, device, location, risk) to decide access.
Can block access entirely or require additional controls like MFA.
Works with Identity Protection, Intune, Defender for Cloud Apps.
Requires Azure AD P1 or P2 licensing.
Applies to cloud apps and can be scoped to specific users/groups.
MFA (Multi-Factor Authentication)
A specific authentication method that requires two or more verification factors.
Does not block access by itself; it adds a step to authentication.
Can be triggered by Conditional Access policies or enabled per-user.
Included with Azure AD P1 or P2, but also available as a standalone service.
Applies to all applications when enabled per-user, or selectively via Conditional Access.
Mistake
Conditional Access is a firewall that blocks IP addresses.
Correct
Conditional Access is an identity-based policy engine, not a network firewall. It evaluates user identity, device, location, and risk signals, not just IP addresses. Location-based conditions use IP ranges, but the decision is made by Azure AD, not a network device.
Mistake
All Conditional Access policies require Azure AD Premium P2 licensing.
Correct
Basic Conditional Access policies (e.g., requiring MFA, blocking locations) are available with Azure AD Premium P1. Only risk-based policies that use Identity Protection signals (sign-in risk, user risk) require P2.
Mistake
Conditional Access policies are applied in a priority order (first match wins).
Correct
There is no priority. All policies that match the user, app, and conditions are evaluated. If any policy blocks access, the result is block. If multiple policies grant with different controls, all controls must be satisfied (AND) unless configured otherwise.
Mistake
Conditional Access can enforce MFA on legacy authentication clients.
Correct
Legacy authentication protocols (POP, IMAP, SMTP, older Office clients) do not support modern authentication and cannot present MFA challenges. Therefore, Conditional Access policies that require MFA will not work on these clients. The recommended action is to block legacy auth entirely.
Mistake
Session controls and grant controls are the same thing.
Correct
Grant controls decide whether to allow or block access (e.g., require MFA, block). Session controls modify the user session after access is granted (e.g., sign-in frequency, app-enforced restrictions). They are separate settings in a Conditional Access policy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Conditional Access is a policy engine that evaluates conditions and can require MFA as one of its controls. MFA is a specific authentication method that adds a second verification factor. Conditional Access does not replace MFA; it can trigger MFA when certain conditions are met. For example, a policy might require MFA when accessing from an untrusted location. MFA itself can also be enabled per-user, which applies to all sign-ins regardless of conditions.
No. Basic Conditional Access policies (e.g., requiring MFA based on location or device) are available with Azure AD Premium P1. Only policies that use risk signals from Identity Protection (sign-in risk or user risk) require Azure AD Premium P2. The exam may ask which license is needed for risk-based policies.
Yes, you can create a Conditional Access policy that targets 'Other clients' (which includes legacy auth protocols) and set the grant control to 'Block access'. This is a common best practice to prevent attacks that exploit legacy protocols. Note that legacy clients cannot satisfy MFA requirements, so blocking is the only effective control.
The What If tool is a simulation feature in the Azure portal (Microsoft Entra ID > Security > Conditional Access > What If). It allows you to test a hypothetical sign-in by specifying user, app, conditions (location, device, etc.) and see which policies would apply and what controls would be enforced. It helps troubleshoot and validate policy configuration before enabling.
Emergency access accounts (break-glass accounts) should be excluded from all Conditional Access policies to prevent accidental lockout. These accounts are typically used in emergencies and have strong authentication methods. Exclude them in the 'Exclude' section of each policy's user assignment. Microsoft recommends having at least two such accounts.
When you add multiple grant controls (e.g., require MFA and require compliant device), you can choose 'Require all controls' – the user must satisfy every selected control. Alternatively, 'Require one control' means the user can satisfy any one of the selected controls. This is useful when you want to allow either MFA or a compliant device, but not both.
Yes, Conditional Access policies can include or exclude guest users (B2B collaboration users). You can target 'All users' which includes guests, or specifically select 'Guest users' in the assignment. This allows you to enforce MFA or other controls for external collaborators.
You've just covered Conditional Access Policies — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?