This chapter covers Azure AD Conditional Access, a critical policy engine for enforcing access controls in Microsoft 365 and Azure. For the AZ-500 exam, Conditional Access is a high-weight topic appearing in at least 15-20% of questions across the Identity domain (Objective 1.4). You will be tested on policy components, assignment conditions, access controls, and how to troubleshoot common misconfigurations. Mastering this topic requires understanding the evaluation engine, signal types, and the exact order of policy processing.
Jump to a section
Imagine a nightclub with a smart bouncer at the door. The bouncer doesn't just check ID; he evaluates a set of conditions before granting entry. First, he checks if the person is on the guest list (user identity). Then, he looks at the time of night—if it's before 10 PM, anyone on the list can enter; after 10 PM, only VIP members can enter (location or time condition). He also checks the device: if the person is using a phone that's not on the approved list, they are denied (device compliance). If the person passes all conditions, they get a wristband (access token). The bouncer logs every decision and can apply additional requirements, like a secondary ID check for certain guests (MFA). This bouncer doesn't just block or allow; he can also redirect guests to a special queue for further verification (block vs. grant with controls). The club owner (administrator) configures the bouncer's rules via a policy engine (Azure AD Conditional Access). The bouncer's decisions are based on signals from multiple sources: the guest list (Azure AD), the door camera (location from IP), and the device database (Intune compliance). This mirrors how Conditional Access evaluates signals—user, device, location, application—and then enforces access controls by granting, blocking, or requiring additional authentication.
What is Conditional Access and Why It Exists
Azure AD Conditional Access is an identity-driven policy engine that evaluates signals from user, device, location, and application context to enforce access decisions. It sits between the user and the resource, acting as a gatekeeper that can block access, grant access, or require additional verification (like MFA or device compliance). Conditional Access is the primary mechanism for implementing Zero Trust principles—never trust, always verify—by ensuring that every access request is evaluated against policy before reaching the resource.
Conditional Access policies are enforced at the Azure AD authentication layer, meaning they apply to any application that uses Azure AD as its identity provider, including Office 365, Azure portal, SaaS apps, and custom line-of-business applications. They do not replace firewall rules or network-level security; they complement them by adding identity-based controls.
How Conditional Access Works Internally
The Conditional Access evaluation engine operates in a specific sequence during every authentication request. Here is the step-by-step mechanism:
Signal Collection: When a user attempts to access a resource, Azure AD collects signals from multiple sources: user identity (from the token), device state (from Intune or third-party MDM), location (from IP address geo-location), application ID, and risk level (from Identity Protection). These signals are gathered in real-time during the authentication flow.
Policy Evaluation: The engine evaluates all enabled Conditional Access policies in a specific order:
First, it checks if the user and application are included in any policy's assignments. Policies can target specific users, groups, or all users (except external identities).
Then, it evaluates conditions: location (trusted IPs or countries), device platform (Windows, iOS, Android), client apps (browser, mobile app, legacy auth), and sign-in risk (from Identity Protection).
If all conditions match, the policy is considered applicable.
3. Policy Enforcement: For each applicable policy, the engine determines the access control to apply: - Block: Deny access immediately. The user sees an access denied message. - Grant: Allow access, but only if the user satisfies additional requirements, such as MFA, device compliance, or approved client app. Multiple grant controls can be combined with AND/OR logic. - Session: Apply session-level controls, like app-enforced restrictions (e.g., limiting download in SharePoint) or Conditional Access App Control (a Microsoft Defender for Cloud Apps feature).
Result Aggregation: If multiple policies apply, the most restrictive outcome wins. For example, if one policy grants access with MFA and another blocks access, the block takes precedence. If all policies grant access with different requirements, the user must satisfy all grant controls (AND logic across policies).
Token Issuance or Denial: Based on the aggregated decision, Azure AD either issues a token (with any session controls embedded) or denies the request.
Key Components, Values, Defaults, and Timers
- Policy States: Each policy has three states: On (enabled), Off (disabled), and Report-only (evaluated but not enforced). Report-only logs the result without blocking access, useful for testing. - Assignments: - Users and groups: Can include/exclude specific users, groups, directory roles, or guest users. Exclusions take precedence over inclusions. - Cloud apps or actions: Select target applications or user actions (like registering security info). You can also select 'All cloud apps' to cover everything. - Conditions: - User risk: From Identity Protection, levels: Low, Medium, High. Default: None. - Sign-in risk: From Identity Protection, levels: Low, Medium, High. Default: None. - Device platforms: Android, iOS, Windows Phone, Windows, macOS, Linux. Default: All platforms. - Locations: Named locations (IP ranges, countries) or trusted/untrusted. Default: Any location. - Client apps: Browser, Mobile apps and desktop clients, Exchange ActiveSync, Other clients (legacy auth). Default: All. - Filter for devices: Advanced condition using device attributes like device compliance or device type. - Access controls: - Grant: Require MFA, 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. Multiple controls can be combined with 'Require all the selected controls' (AND) or 'Require one of the selected controls' (OR). - Session: Use app-enforced restrictions, Use Conditional Access App Control, Sign-in frequency (in hours), Persistent browser session (never or configurable). - Timers: - Session sign-in frequency: This is a sliding window. Once the user authenticates, the token is valid for the specified duration (e.g., 1 hour). After that, the user must re-authenticate. The timer resets on each successful re-authentication. - Persistent browser session: Controls whether the session cookie persists across browser closes. Default is 'Never persistent'. - Default values:
By default, no Conditional Access policies exist. Microsoft recommends creating a baseline policy like 'Require MFA for all users'.
The default report-only mode is 'Off'.
Configuration and Verification Commands
Conditional Access policies are configured via the Azure portal (Azure AD > Security > Conditional Access) or via Microsoft Graph API. There is no PowerShell cmdlet for creating policies, but you can use the Microsoft Graph PowerShell SDK.
Example Microsoft Graph API request to list policies:
GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policiesExample PowerShell using Graph:
Connect-MgGraph -Scopes 'Policy.Read.All'
Get-MgIdentityConditionalAccessPolicy | Format-ListTo verify policy results, use the What If tool in the Azure portal (Conditional Access > What If). It simulates a sign-in and shows which policies apply and the resulting controls. Also, check the Sign-in logs (Azure AD > Monitoring > Sign-ins) to see the Conditional Access status and applied policies.
Interaction with Related Technologies
Conditional Access works closely with: - Azure AD Identity Protection: Provides user and sign-in risk signals. Policies can require MFA or password change when risk is detected. - Microsoft Intune: Provides device compliance and device health signals. Policies can require a compliant device. - Microsoft Defender for Cloud Apps: Provides app-enforced restrictions and Conditional Access App Control for session monitoring. - Azure AD Multi-Factor Authentication: The most common grant control; Conditional Access can trigger MFA based on conditions. - Terms of Use (TOU): Conditional Access can require acceptance of TOU before access.
Important Exam Details
Report-only mode: Policies in report-only mode are evaluated but not enforced. Results appear in the sign-in logs with 'Report-only' status. This is critical for testing before enabling.
Exclusions: Exclusions in assignments override inclusions. Always consider excluding emergency access accounts (break-glass accounts) from policies that could lock them out.
Legacy authentication: Legacy authentication protocols (e.g., POP, IMAP, SMTP) do not support MFA. A common best practice is to create a policy that blocks all legacy authentication.
Policy order: All policies are evaluated simultaneously, not sequentially. The most restrictive outcome is applied. There is no priority order; instead, the engine aggregates results.
Device platforms: The condition 'Device platforms' uses user-agent strings. For example, Windows includes Windows 10 and later. Windows Phone is separate. macOS includes Mac OS X.
Client apps condition: 'Other clients' refers to apps using legacy authentication. This is often used to block them.
Filter for devices: This advanced condition allows policies to target devices based on attributes like device trust type (Azure AD joined, Hybrid Azure AD joined) or device compliance state. It uses device filters with expressions like device.isCompliant eq true.
User attempts resource access
The user initiates a request to access a cloud application (e.g., Outlook Web App, Azure portal). The request is intercepted by Azure AD before reaching the resource. Azure AD begins the authentication flow by collecting the user principal name (UPN) and the application ID from the request. This step triggers the Conditional Access evaluation engine.
Signal collection from sources
Azure AD gathers signals from various sources: user identity from the token, device state (e.g., compliance from Intune), location (IP address geolocation), application ID, and risk scores from Identity Protection. These signals are assembled into a context object that the policy engine uses for evaluation. The collection happens in milliseconds and is transparent to the user.
Policy evaluation against signals
The engine evaluates all enabled Conditional Access policies. For each policy, it checks if the user (or group) is included and not excluded, if the application matches, and if all conditions (location, device platform, client app, risk) are satisfied. The evaluation is logical AND within each policy's conditions. If a policy's conditions are not fully met, the policy is skipped.
Determination of access controls
For each applicable policy, the engine determines the access control: block, grant (with requirements), or session controls. If multiple policies apply, the engine aggregates the results: any block overrides all grants; if all are grants, the user must satisfy all grant controls (AND across policies). For session controls, the most restrictive is applied.
Enforcement and token issuance
Azure AD enforces the final decision. If block, the user receives an access denied message. If grant with requirements (e.g., MFA), the user is prompted to satisfy those requirements. If successful, a token is issued with any session controls embedded. The token is then used to access the resource. The entire process is logged in the Azure AD sign-in logs with the Conditional Access policy status.
Scenario 1: Enforcing MFA for All External Access
A global company with 10,000 employees wants to require MFA for all access from outside the corporate network. They create a Conditional Access policy targeting all users, all cloud apps, with condition Location: All trusted IPs (the corporate IP range) excluded. The grant control is 'Require multi-factor authentication'. In production, this policy is first set to report-only for two weeks to verify that no legitimate users are blocked. After confirming, the policy is enabled. The company also excludes break-glass accounts (emergency admin accounts) from the policy to avoid lockout. Common issues include users on VPN with IPs not recognized as trusted, causing MFA prompts even from inside. The solution is to ensure VPN egress IPs are added to the trusted IPs list.
Scenario 2: Blocking Legacy Authentication
A healthcare organization needs to block legacy authentication protocols (POP, IMAP, SMTP) because they do not support MFA, violating compliance requirements. They create a policy targeting all users, all cloud apps, condition Client apps: Other clients (legacy auth) selected, and grant control: Block access. They also create a separate policy to allow only modern authentication apps. In production, some users complain that their email clients stop working. The IT team must migrate those users to modern clients (Outlook 2016+ or Outlook mobile). The policy is tested in report-only mode first to identify affected users. Performance is not an issue because the policy is evaluated at authentication time.
Scenario 3: Requiring Compliant Devices for SaaS Apps
A technology company uses Salesforce and requires that only Intune-compliant devices can access it. They create a Conditional Access policy targeting the Salesforce app, all users, condition Device platforms: Windows, iOS, Android, and grant control: Require device to be marked as compliant. They also require Hybrid Azure AD joined for Windows devices. In production, users on non-compliant devices are blocked and see a message to enroll their device in Intune. The policy uses the 'Filter for devices' condition to only apply to devices that are not already compliant. Common misconfiguration: forgetting to exclude service accounts or guest users, causing unexpected blocks. The solution is to properly scope the policy to user groups and exclude break-glass accounts.
Exactly What AZ-500 Tests
Objective 1.4: Configure and manage Azure AD identity protection and conditional access. The exam focuses on:
Designing and implementing Conditional Access policies (assignments, conditions, access controls)
Understanding policy evaluation order (simultaneous evaluation, most restrictive) and report-only vs. enabled
Integrating with Identity Protection (user risk, sign-in risk)
Managing device-based conditions (compliant, Hybrid Azure AD joined)
Troubleshooting using sign-in logs and What If tool
Implementing session controls (sign-in frequency, persistent browser session)
Common Wrong Answers and Why Candidates Choose Them
'Policies are evaluated in order of priority' – This is false. All applicable policies are evaluated simultaneously, and the most restrictive outcome applies. There is no priority number. Candidates confuse this with Azure Policy or RBAC.
'Report-only mode blocks access but logs it' – Report-only mode does NOT block access; it only logs what would have happened. Candidates think it's like a 'test block.'
'Exclusions have lower priority than inclusions' – Exclusions always override inclusions. If a user is in both an included group and an excluded group, they are excluded.
'Conditional Access policies apply to on-premises resources' – They only apply to Azure AD integrated apps, not on-prem AD or network resources.
Specific Numbers and Terms on the Exam
Sign-in frequency: Default is 90 days for Azure AD, but Conditional Access can override. Common values: 1 hour, 24 hours.
Persistent browser session: Default is 'Never persistent'. Can be set to 'Always persistent' or a specific number of hours.
Trusted IPs: Up to 50 IP ranges can be configured in the MFA service settings.
Named locations: Can include up to 2000 IP ranges per location.
Device platforms: The exam tests that Windows Phone is a separate platform from Windows.
Client apps: 'Other clients' specifically means legacy authentication (POP, IMAP, SMTP, etc.).
Edge Cases and Exceptions
Guest users: By default, policies apply to guest users. You can exclude them via 'External users' in assignments.
Service principals: Conditional Access does not apply to service principals; it applies only to user sign-ins.
B2B collaboration: Policies apply to guest users from other tenants. They may be subject to the home tenant's policies.
Emergency access accounts: Always excluded to prevent lockout. Typically two cloud-only accounts with permanent MFA exemption.
How to Eliminate Wrong Answers
If a question mentions 'most restrictive' or 'aggregate', think about simultaneous evaluation.
If it says 'test without impacting users', the answer is report-only mode.
For device conditions, remember that 'Require device to be compliant' requires Intune enrollment; 'Require Hybrid Azure AD joined' requires domain-joined devices.
For session controls, 'Sign-in frequency' controls how often re-authentication is required; 'Persistent browser session' controls whether the session cookie survives browser close.
Conditional Access policies are evaluated simultaneously; the most restrictive outcome is applied.
Report-only mode is essential for testing policies without impacting users.
Exclusions override inclusions in user and group assignments.
Legacy authentication protocols cannot enforce MFA; block them with a policy targeting 'Other clients'.
Sign-in frequency controls how often re-authentication is required; default is 90 days but can be overridden.
Device conditions require Intune or Hybrid Azure AD join; 'Require device to be compliant' is different from 'Require Hybrid Azure AD joined'.
Always exclude break-glass accounts from all Conditional Access policies to prevent lockout.
These come up on the exam all the time. Here's how to tell them apart.
Report-only mode
Evaluates policy but does not enforce it
Logs results in sign-in logs as 'Report-only'
Used for testing and validation
User experience is unchanged
No impact on access
Enabled mode
Evaluates and enforces policy
Logs results as 'Success' or 'Failure'
Used for production enforcement
User may be blocked or prompted for MFA
Directly impacts access
Require MFA
Triggers MFA challenge (phone call, app, SMS)
Works with any device
No dependency on Intune
More friction for users
Common for high-risk locations
Require device compliance
Requires device to be compliant with Intune policies
Requires device enrollment in Intune
Integrates with device health attestation
Less friction once enrolled
Common for corporate devices
Mistake
Conditional Access policies are evaluated in a sequential order based on priority.
Correct
All applicable policies are evaluated simultaneously. The engine aggregates the results and applies the most restrictive outcome. There is no priority number; the order in the UI is irrelevant.
Mistake
Report-only mode blocks access and logs the decision.
Correct
Report-only mode does NOT block access. It evaluates the policy and logs what would have happened, but the user is allowed through. It is used for testing before enabling.
Mistake
Conditional Access policies can be applied to on-premises resources.
Correct
Conditional Access only applies to cloud applications that use Azure AD for authentication. It does not protect on-premises apps unless they are published via Azure AD Application Proxy.
Mistake
Exclusions in a policy are overridden by inclusions.
Correct
Exclusions always take precedence over inclusions. If a user is in an excluded group, they are not subject to the policy even if they are in an included group.
Mistake
Conditional Access policies require a premium license for all users.
Correct
Conditional Access is available with Azure AD Premium P1 or P2 licenses. However, some features like risk-based policies require P2. Basic/Free tier does not support Conditional Access.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'Require device to be marked as compliant' means the device must be enrolled in Intune and meet compliance policies (e.g., encryption, antivirus). 'Require Hybrid Azure AD joined device' means the device must be joined to both on-premises AD and Azure AD (i.e., domain-joined and registered). The first is about device health, the second about domain membership. They can be used together or separately. On the exam, remember that 'compliant' requires Intune, while 'Hybrid Azure AD joined' requires domain join.
No, Conditional Access policies apply only to user sign-ins. Service principals and managed identities authenticate via client credentials and are not subject to Conditional Access. For service principals, use conditional access policies for applications (app consent and permissions) but not sign-in policies. The exam may test this distinction.
Set the policy to 'Report-only' mode. Then, have test users sign in to the target applications. Check the Azure AD sign-in logs; the 'Conditional Access' tab shows which policies applied and the result (Report-only: success). You can also use the 'What If' tool to simulate sign-ins. After testing, set the policy to 'On'.
All applicable policies are evaluated simultaneously. The most restrictive outcome is applied. If any policy blocks access, the user is blocked. If multiple policies require different grant controls, the user must satisfy all of them (AND logic across policies). For session controls, the most restrictive session control is applied.
Create a policy targeting all users and all cloud apps. Under Conditions > Client apps, select 'Other clients' (which represents legacy authentication). Set the grant control to 'Block access'. Enable the policy. This will block all legacy authentication attempts. Note that modern clients (browser, mobile app) are not affected.
The default sign-in frequency for Azure AD is 90 days for access tokens. However, Conditional Access can override this with a session control 'Sign-in frequency' that can be set to a specific number of hours. If no Conditional Access policy specifies sign-in frequency, the default of 90 days applies. The exam may test that the default is 90 days.
Yes. In the 'Users and groups' assignment, under 'Include', you can select 'All guest users' or specific groups. Under 'Exclude', you can also exclude guest users. The exam often tests that guest users are included by default unless explicitly excluded.
You've just covered Conditional Access Policies — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?