Azure AD Conditional Access: Complete Policy Guide for IT Teams in 2026

Published March 23, 2026 - 18 min read

Conditional Access is the policy engine at the heart of Microsoft's zero-trust security model. Every authentication request to Azure AD (now Microsoft Entra ID) passes through Conditional Access, where it is evaluated against your policies and either granted, challenged with additional verification, or blocked. For IT teams managing hybrid or cloud-first environments, Conditional Access is the single most impactful security control you can deploy. It replaces the outdated perimeter model - where being on the corporate network meant being trusted - with continuous, context-aware access decisions. If you are still hardening your on-premises directory, start with our Active Directory management guide before layering on cloud policies.

The challenge is that Conditional Access is powerful enough to lock out your entire organization if misconfigured. Policies interact in complex ways, licensing requirements vary by feature, and the gap between a well-designed policy set and a fragile one is significant. This guide walks through every major Conditional Access capability with specific, implementable policy configurations. Read more about related security considerations in our backup strategy guide for comprehensive IT protection.

Understanding the Conditional Access Policy Model

Every Conditional Access policy follows the same structure: assignments define who and what the policy applies to, conditions define the circumstances under which the policy activates, and access controls define what happens when the policy matches. Understanding this structure prevents the most common configuration mistakes.

Assignments: Users and Applications

Assignments determine the scope of a policy. You target users by individual accounts, group membership, directory roles, or all users. You target applications by selecting specific cloud apps, all cloud apps, or user actions like registering security information. The critical rule: always exclude at least two break-glass emergency access accounts from every policy. These accounts use long, random passwords stored in a physical safe and are monitored for any usage. Without them, a misconfigured policy can lock out every administrator.

Group-based targeting is the recommended approach. Create security groups like "CA-MFA-Required" or "CA-DeviceCompliance-Required" and use them as policy targets. This decouples policy configuration from user management - when someone joins or leaves a team, you update their group membership, not your Conditional Access policies.

Conditions: Context Signals

Conditions are the contextual signals that determine when a policy activates. The available conditions include:

MFA Enforcement Policies

Multi-factor authentication is the highest-impact security control available. Microsoft's data shows that MFA blocks over 99.9% of account compromise attacks. The goal is to require MFA for every authentication while minimizing user friction through smart policy design.

Baseline MFA Policy

Create a policy targeting all users (excluding break-glass accounts) for all cloud apps. Set the grant control to "Require multifactor authentication." Set the session control to "Sign-in frequency: 90 days" for compliant devices and "1 day" for unmanaged devices. This ensures every user proves their identity with a second factor while allowing compliant devices to maintain longer sessions.

Policy configuration: Users = All users, Exclude = Break-glass accounts group. Cloud apps = All cloud apps. Grant = Require multifactor authentication. Session = Sign-in frequency 90 days (compliant) / 1 day (non-compliant).

Blocking Legacy Authentication

Legacy authentication protocols - POP3, IMAP, SMTP AUTH, Exchange ActiveSync basic auth - cannot perform MFA and are the most common attack vector for credential stuffing. Block them with a dedicated policy before enabling MFA everywhere. Target all users for all cloud apps with the client apps condition set to "Exchange ActiveSync clients" and "Other clients." Set the grant control to "Block." This forces all authentication through modern protocols that support MFA.

MFA Registration Policy

Control where and how users register MFA methods. Create a policy targeting the user action "Register security information" with a location condition requiring registration from trusted corporate locations only. This prevents attackers who obtain a password from registering their own MFA method from an external location - a common attack technique where the attacker races to register MFA before the legitimate user.

Device Compliance Policies

Device compliance ensures that only devices meeting your security standards can access corporate data. Compliance policies are defined in Microsoft Intune and referenced by Conditional Access. A device is "compliant" when it passes all assigned Intune compliance policies - encryption enabled, OS version minimum met, antivirus active, no jailbreak detected.

Require Compliant Devices for Desktop Access

Create a policy targeting all users for all cloud apps with platform conditions set to Windows and macOS. Set the grant control to "Require device to be marked as compliant." This ensures that desktop and laptop access only occurs from managed, encrypted, up-to-date devices. Users on personal or unmanaged computers are blocked from accessing cloud apps entirely.

Mobile Device Policies: MAM vs MDM

For mobile devices, you have two approaches. Full MDM (Mobile Device Management) enrolls the device in Intune and enforces compliance like desktops. MAM (Mobile Application Management) protects data within specific apps without enrolling the device. MAM is the better choice for BYOD scenarios where employees use personal phones.

Create a policy targeting iOS and Android platforms with the grant control "Require approved client app" or "Require app protection policy." This allows access through Outlook, Teams, and OneDrive apps that have Intune app protection policies applied, even on personal devices. Corporate data is encrypted within the app container, and IT can remotely wipe app data without touching personal content.

Compliance Policy Design

Define Intune compliance policies that match your security requirements:

Set a grace period (typically 24-72 hours) for newly non-compliant devices before blocking access. This prevents users from being locked out during Windows Update restarts or other temporary compliance lapses.

Location-Based Access Policies

Named locations allow you to make access decisions based on where authentication originates. Configure them carefully - overly broad trusted locations weaken security, while overly narrow ones create friction.

Configuring Named Locations

Define named locations for every network your organization controls: corporate office IP ranges, VPN concentrator exit IPs, branch office IPs, and data center management networks. Mark corporate and VPN locations as "trusted" - this designation is referenced by risk-based policies and reduces false positive risk detections for on-premise users.

For country-based locations, define the countries where your organization operates and where your employees travel. Create a separate location group for high-risk countries (based on your threat intelligence) that you may want to block entirely.

Reduce MFA Friction for Trusted Locations

Modify your baseline MFA policy to exclude trusted named locations from the MFA requirement. Users authenticating from the corporate network still receive MFA challenges on their first sign-in but get longer session windows (90 days) before re-authentication. Users from untrusted locations are challenged every session. This balances security with usability - the office network is not fully trusted, but it is lower risk than a random coffee shop.

Block Access from Specific Countries

If your organization has no legitimate users in certain countries, block access entirely with a location-based policy. Target all users for all cloud apps with a location condition of "Selected locations: High-risk countries." Set the grant control to "Block." Monitor the sign-in logs for blocks from unexpected locations - they often indicate credential compromise or unauthorized access attempts.

Important: Country-based blocking uses IP geolocation which is not 100% accurate. VPN users and travelers may trigger blocks. Always pair country blocks with an exception process and monitor for false positives. Never block countries where your own VPN exit nodes or cloud services are located.

Risk-Based Conditional Access

Risk-based policies use Microsoft Entra ID Protection (P2 license required) to evaluate the real-time risk of each sign-in and the cumulative risk profile of each user. These are the most sophisticated Conditional Access controls and form the core of a zero-trust access strategy.

Sign-In Risk Policies

Sign-in risk evaluates each authentication attempt for indicators of compromise. Microsoft's threat intelligence processes trillions of signals to classify sign-ins as no risk, low, medium, or high. Risk signals include: anonymous proxy or Tor usage, impossible travel (authentication from two distant locations in an impossibly short time), malware-linked IP addresses, unfamiliar sign-in properties, and password spray attack patterns.

Create a tiered response: for medium sign-in risk, require MFA (the user proves their identity, and if successful, the risk is remediated). For high sign-in risk, block access entirely and require an administrator to investigate before granting access. This graduated response catches most attacks with MFA while stopping the most suspicious attempts completely.

User Risk Policies

User risk reflects the overall likelihood that a user's account is compromised, based on accumulated signals over time. High user risk triggers include leaked credentials found on the dark web, anomalous user activity patterns, and confirmed compromise indicators from Microsoft's security operations.

For high user risk, require a secure password change through a Conditional Access policy. The user must complete MFA and then change their password before accessing any resource. This remediates the compromised credential automatically. For medium user risk, require MFA on every sign-in (no session persistence) until the risk is resolved.

Continuous Access Evaluation

Continuous Access Evaluation (CAE) extends Conditional Access beyond the initial authentication. Traditional token-based access grants a session token that remains valid for its lifetime (typically 1 hour) even if the user's risk changes. CAE enables near-real-time revocation: if a user is disabled, their location changes to a blocked country, or their risk level increases, active sessions are terminated within minutes rather than waiting for token expiry.

CAE is enabled by default for supported Microsoft applications (Exchange Online, SharePoint Online, Teams). Ensure your Conditional Access policies are compatible by avoiding session controls that conflict with CAE. The combination of risk-based policies and CAE creates a genuinely continuous evaluation model rather than point-in-time authentication.

Zero-Trust Implementation with Conditional Access

Zero trust means "never trust, always verify." Conditional Access is the enforcement point. A mature zero-trust implementation layers multiple policies that work together:

  1. Identity verification: MFA required for all users, all apps, all locations. No exceptions except break-glass accounts.
  2. Device health: Compliant devices required for desktop access. App protection required for mobile BYOD.
  3. Location intelligence: Trusted locations reduce friction but do not eliminate verification. Unknown locations trigger additional controls. Blocked countries prevent access entirely.
  4. Risk awareness: Real-time risk assessment adjusts controls dynamically. Medium risk escalates to MFA. High risk blocks pending investigation.
  5. Session management: Compliant devices get longer sessions. Unmanaged devices get restricted sessions with shorter timeouts and no persistent browser sessions.
  6. Application controls: Sensitive applications (HR, finance, admin portals) require additional verification steps regardless of other conditions.

Policy Ordering and Conflict Resolution

Conditional Access policies are additive - all matching policies apply, and the most restrictive control wins. If one policy requires MFA and another blocks access, the block takes effect. Design your policies with this in mind: start with broad baseline policies (MFA everywhere, block legacy auth) and layer targeted policies for specific scenarios (compliant devices for desktops, app protection for mobile, extra controls for sensitive apps).

Document every policy in a policy matrix that shows the target users, applications, conditions, and controls. Review the matrix quarterly to remove stale policies, adjust conditions for new office locations or applications, and ensure the policy set remains coherent as your environment evolves.

Monitoring and Troubleshooting

The sign-in logs in Entra ID are your primary diagnostic tool. Every authentication shows which Conditional Access policies were evaluated, which matched, and whether they were enforced or in report-only mode. When a user reports access problems, the sign-in log for their authentication attempt tells you exactly which policy blocked or challenged them.

Common Troubleshooting Scenarios

Audit and Reporting

Set up diagnostic settings to export sign-in logs and audit logs to a Log Analytics workspace. Create workbook dashboards that track: total MFA challenges per day (detect spikes that indicate attacks), blocked sign-ins by location (identify targeted countries), compliance failures by device type (spot patching gaps), and risk detections by type (understand your threat landscape). Automate alerts for critical events: break-glass account usage, high-risk sign-ins, and mass block events that might indicate a misconfigured policy.

Frequently Asked Questions

What is Azure AD Conditional Access and how does it work?

Azure AD Conditional Access (now Microsoft Entra ID Conditional Access) is a policy engine that evaluates every authentication request against a set of conditions - user identity, device state, location, application, and risk level - and applies access controls based on the result. Policies follow if-then logic: IF a user matches certain conditions, THEN apply specific controls. Policies are evaluated in real time during authentication and can be combined for granular access decisions.

What licenses are required for Conditional Access?

Conditional Access requires Microsoft Entra ID P1 at minimum, included in Microsoft 365 E3, E5, Business Premium, and EMS E3/E5 licenses. Risk-based policies require Entra ID P2, included in Microsoft 365 E5 and EMS E5. P1 covers location-based policies, device compliance, MFA enforcement, and app-based conditions. P2 adds real-time risk evaluation.

How do I enforce MFA without blocking legacy authentication?

Create two policies. First, block legacy authentication protocols by targeting "Client apps: Other clients" with a Block grant control. Second, require MFA for all cloud apps targeting "Client apps: Browser and Mobile apps and desktop clients." Apply the block policy first, then roll out MFA in report-only mode before enforcement. Exclude break-glass emergency accounts from both policies.

What are named locations and how should I configure them?

Named locations define trusted IP ranges or countries that policies reference. Configure them for corporate office IPs, VPN exit IPs, and partner networks. Mark corporate locations as trusted. For country-based policies, define operating countries and high-risk countries to block. Validate IP ranges regularly since stale entries create security gaps.

How do I test policies without locking users out?

Use report-only mode. Every policy can be set to report-only, which evaluates without enforcing. Sign-in logs show what would have happened. Run policies in report-only for two to four weeks before enforcement. Always maintain at least two break-glass emergency accounts excluded from all policies.

Automate IT security with HelpBot

AI-powered IT helpdesk that handles Conditional Access troubleshooting, device compliance queries, and access requests automatically - freeing your team for policy design and strategic security work.

Start Free Trial