Conditional Access Policies in Azure AD: Complete Setup Guide [2026]

Passwords verify who someone claims to be. Conditional access determines whether they should actually get in. The difference matters because identity alone is not enough to make a sound access decision. A valid username and password from an unmanaged device in a foreign country at 3:00 AM should not receive the same level of access as the same credentials from a corporate laptop on the office network during business hours. Conditional access policies in Azure AD (now Microsoft Entra ID) let you make those distinctions automatically, enforcing different requirements based on real-time signals about the user, the device, the location, and the risk level of the sign-in.

Without conditional access, you are left with binary choices: either everyone gets MFA prompts every time, or nobody does. Either all devices can access corporate data, or none can. Conditional access replaces those blunt instruments with granular, context-aware policies that adapt to the situation. It is the enforcement engine behind Zero Trust security — the mechanism that turns “never trust, always verify” from a principle into an operational reality.

This guide covers how conditional access works, the licensing you need, the baseline policies every organization should deploy, and how to test and troubleshoot policies without locking anyone out.

How Conditional Access Works

Conditional access policies operate on a simple logic: if a set of conditions is met, then enforce specific controls. Every policy has three components: assignments, conditions, and access controls.

Signals (Assignments and Conditions)

Signals are the inputs that conditional access evaluates when a user attempts to sign in. These include:

• User or group membership — Apply the policy to specific users, groups, roles, or all users. You can also exclude specific accounts, such as break-glass emergency accounts.
• Cloud application — Target specific applications (Exchange Online, SharePoint, Azure portal) or apply the policy to all cloud apps.
• Device platform — Differentiate between Windows, macOS, iOS, Android, and Linux.
• Location — Use named locations (IP ranges or countries) to distinguish corporate network access from external access.
• Client application — Distinguish between modern authentication clients (browser, mobile apps) and legacy authentication protocols (IMAP, POP3, SMTP AUTH).
• Device state — Check whether the device is Intune-compliant, hybrid Azure AD joined, or unmanaged.
• Sign-in risk — With Azure AD P2, evaluate the real-time risk level of a sign-in based on signals like anonymous IP addresses, atypical travel, and compromised credentials.
• User risk — With Azure AD P2, evaluate the cumulative risk level of a user account based on detected compromises or leaked credentials.

Decisions (Access Controls)

Based on the signals evaluated, conditional access applies one of two categories of controls:

Grant controls determine whether access is allowed and under what conditions:

• Block access entirely
• Grant access with requirements: MFA, compliant device, hybrid Azure AD joined device, approved client app, app protection policy, password change, or accepted terms of use
• Require one or all of the selected controls

Session controls restrict the experience after access is granted:

• Limit the session duration (sign-in frequency)
• Use Conditional Access App Control to proxy sessions through Microsoft Defender for Cloud Apps for real-time monitoring
• Enforce application restrictions (e.g., limited web-only access in SharePoint)
• Disable browser persistence (prevent “stay signed in” behavior)

Policy Evaluation Order

Azure AD evaluates all conditional access policies that apply to a given sign-in. Policies are not evaluated in sequence — they all apply simultaneously. If any applicable policy blocks access, the sign-in is blocked regardless of what other policies allow. If multiple policies grant access with different requirements, all requirements must be satisfied. This means the most restrictive combination always wins.

Prerequisites and Licensing

Conditional access requires Azure AD Premium P1 licensing at minimum. This is included in Microsoft 365 Business Premium, Microsoft 365 E3, and EMS E3. Risk-based policies (sign-in risk and user risk) require Azure AD Premium P2, included in Microsoft 365 E5 and EMS E5.

Before building policies, ensure you have:

• Azure AD Premium P1 or P2 licenses assigned to all users who will be in scope of the policies
• Break-glass accounts — at least two cloud-only Global Administrator accounts excluded from all conditional access policies, with strong passwords stored securely offline (see our M365 security hardening checklist for configuration details)
• Security Defaults disabled — conditional access policies and Security Defaults cannot coexist; disable Security Defaults before creating policies
• Baseline device compliance policies configured in Intune if you plan to require compliant devices
• Named locations defined for your corporate offices and any trusted IP ranges

If you are migrating from on-premises Active Directory to Azure AD, plan your conditional access policies as part of the migration. Deploying them after migration is harder because users have already established workflows that may conflict with new access requirements.

Baseline Policies Every Organization Needs

The following policies represent the minimum set that every organization should deploy. They address the most common attack vectors and align with Microsoft’s recommended conditional access policy templates.

Policy 1: Block Legacy Authentication

Legacy authentication protocols — POP3, IMAP, SMTP AUTH, Exchange ActiveSync, and others — do not support MFA. They are the primary vector attackers use to bypass MFA requirements. Blocking legacy authentication is the single highest-impact conditional access policy you can deploy.

Configuration:

1. Navigate to Microsoft Entra admin center > Protection > Conditional Access > Policies
2. Create a new policy and name it: “Block Legacy Authentication”
3. Under Assignments > Users, select All users. Exclude your break-glass accounts
4. Under Cloud apps or actions, select All cloud apps
5. Under Conditions > Client apps, select Exchange ActiveSync clients and Other clients
6. Under Access controls > Grant, select Block access
7. Set the policy to Report-only mode first (see testing section below)

Before enforcing this policy, review your Azure AD sign-in logs filtered by client app type. If any legitimate applications or workflows depend on legacy protocols, migrate them to modern authentication first. Common offenders include older versions of Outlook, multifunction printers that scan-to-email, and third-party applications that use SMTP AUTH.

Policy 2: Require MFA for All Administrators

Administrative accounts are the highest-value targets in your environment. A compromised Global Administrator account gives an attacker complete control over your tenant. Requiring MFA for all admin roles is non-negotiable.

Configuration:

1. Create a new policy: “Require MFA for Admins”
2. Under Users, select Directory roles and include: Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Authentication Administrator, Privileged Role Administrator, Billing Administrator, Compliance Administrator, and Conditional Access Administrator
3. Exclude break-glass accounts
4. Under Cloud apps, select All cloud apps
5. Under Grant, select Grant access and check Require multifactor authentication
6. Deploy in Report-only mode, then switch to On after validation

Use phishing-resistant MFA methods for administrators wherever possible. FIDO2 security keys and Windows Hello for Business are significantly more secure than push notifications or SMS codes.

Policy 3: Require MFA for All Users

Once administrative accounts are protected, extend MFA to all users. This single control blocks over 99.9% of account compromise attacks according to Microsoft’s analysis.

Configuration:

1. Create a new policy: “Require MFA for All Users”
2. Under Users, select All users. Exclude break-glass accounts and any service accounts that cannot support MFA (document these exceptions and review them quarterly)
3. Under Cloud apps, select All cloud apps
4. Under Grant, select Require multifactor authentication
5. Consider adding a Conditions > Locations exclusion for your trusted corporate network if you want to reduce MFA friction for on-site users (though Zero Trust principles recommend requiring MFA regardless of location)

Policy 4: Require Compliant Devices for Key Applications

Device compliance ensures that only managed, healthy devices can access corporate data. An unpatched personal laptop with no encryption and no endpoint protection should not be able to download files from SharePoint or read email in Outlook.

Configuration:

1. Create a new policy: “Require Compliant Devices for Office 365”
2. Under Users, select All users. Exclude break-glass accounts
3. Under Cloud apps, select Office 365 (this covers Exchange Online, SharePoint Online, Teams, and OneDrive)
4. Under Grant, select Require device to be marked as compliant or Require hybrid Azure AD joined device — use “Require one of the selected controls” to allow either
5. Under Conditions > Device platforms, consider targeting specific platforms (Windows, macOS, iOS, Android) to phase the rollout

Before enforcing this policy, ensure Intune compliance policies are configured. Key compliance requirements should include: OS version minimums, device encryption enabled, antivirus active and up to date, and no jailbroken or rooted devices. Users with non-compliant devices need a clear path to remediation — otherwise they will call the help desk.

Policy 5: Block High-Risk Sign-Ins

This policy requires Azure AD P2 and leverages Azure AD Identity Protection to detect and block sign-ins that exhibit suspicious characteristics. Risk signals include anonymous IP addresses, password spray attacks, impossible travel, and credential exposure on the dark web.

Configuration:

1. Create a new policy: “Block High-Risk Sign-Ins”
2. Under Users, select All users. Exclude break-glass accounts
3. Under Cloud apps, select All cloud apps
4. Under Conditions > Sign-in risk, select High
5. Under Grant, select Block access
6. Create a second policy: “Require MFA for Medium-Risk Sign-Ins” with the same configuration but selecting Medium sign-in risk and requiring MFA instead of blocking

For user risk, create an additional policy that requires a secure password change when user risk is detected as High. This forces compromised accounts to reset their credentials before regaining access.

Policy 6: Restrict Azure Management Access

The Azure portal, Azure PowerShell, and Azure CLI provide administrative control over your cloud infrastructure. Access to these tools should require both MFA and a compliant device, with shortened session duration.

Configuration:

1. Create a new policy: “Secure Azure Management Access”
2. Under Users, select All users (or scope to users with Azure roles). Exclude break-glass accounts
3. Under Cloud apps, select Microsoft Azure Management
4. Under Grant, select Require multifactor authentication and Require device to be marked as compliant — use “Require all the selected controls”
5. Under Session > Sign-in frequency, set to 4 hours to force periodic re-authentication for administrative sessions

Configuring Named Locations

Named locations allow you to define trusted networks and geographic boundaries. They are used as conditions in conditional access policies to differentiate internal from external access.

IP-Based Named Locations

Define your corporate network by specifying the public IP ranges of your offices, VPN concentrators, and data centers.

1. Navigate to Microsoft Entra admin center > Protection > Conditional Access > Named locations
2. Create a new IP ranges location
3. Enter a name (e.g., “Corporate Offices - Chicago”) and add the public IP CIDR ranges
4. Optionally mark it as a trusted location — this is used by MFA and Identity Protection to reduce false positives

Country-Based Named Locations

If your organization operates exclusively in specific countries, create a named location for countries where you have no employees or business operations, then use it to block or restrict access.

1. Create a new Countries/Regions location
2. Select the countries to include (or exclude)
3. Use this named location in a conditional access policy under Conditions > Locations > Exclude/Include

A common pattern is creating an “Allowed Countries” named location and a conditional access policy that blocks sign-ins from any location not in that list. This dramatically reduces the attack surface from credential stuffing botnets, which typically operate from geographies far from your users.

Session Controls in Practice

Session controls govern what happens after a user gains access. They are underused but powerful.

Sign-In Frequency

By default, Azure AD maintains persistent sessions that can last up to 90 days. For sensitive resources, this is too long. Sign-in frequency forces re-authentication at a defined interval.

• Set to 1 hour for the Azure portal and administrative tools
• Set to 8-12 hours for general Office 365 access on unmanaged devices
• On compliant devices, you can use the “Every time” option cautiously — or allow Azure AD to manage token lifetimes dynamically by selecting Revoke on risk event with Continuous Access Evaluation (CAE)

Persistent Browser Session

By default, users can choose “Stay signed in?” after authentication. Disabling persistent browser sessions on unmanaged devices ensures that closing the browser ends the session.

1. In your conditional access policy, under Session, select Persistent browser session and set it to Never persistent
2. Apply this only to sign-ins from non-compliant or unmanaged devices to avoid frustrating users on corporate machines

Conditional Access App Control

For applications integrated with Microsoft Defender for Cloud Apps, you can proxy sessions to enforce real-time controls like preventing downloads, blocking copy/paste of sensitive data, or watermarking documents. This is particularly valuable for providing limited access to sensitive data from unmanaged devices without blocking access entirely.

Testing Policies with Report-Only Mode

Deploying conditional access policies without testing them first is a recipe for lockouts, help desk floods, and executive frustration. Report-only mode lets you see what a policy would do without actually enforcing it.

How Report-Only Mode Works

When a policy is set to Report-only, Azure AD evaluates the policy during every applicable sign-in and records the result in the sign-in log, but does not enforce the grant or session controls. You can see whether the policy would have granted access, blocked access, or required additional authentication — without affecting the user’s experience.

Using Report-Only Effectively

1. Deploy every new policy in Report-only mode first. No exceptions. Even simple policies can have unexpected consequences when they interact with other policies.
2. Let it run for at least 7 days to capture sign-in patterns across a full business cycle (weekday vs. weekend, in-office vs. remote, mobile vs. desktop).
3. Review results in the sign-in logs. Filter by the policy name and look for sign-ins that would have been blocked or required MFA. Investigate each one to determine if it represents a legitimate user who would be disrupted or an actual threat that would be mitigated.
4. Iterate. Adjust exclusions, conditions, or scope based on what you observe. Add groups of users gradually if needed.
5. Switch to On only when you are confident the policy will not disrupt legitimate access.

Navigate to Microsoft Entra admin center > Protection > Conditional Access > Policies, select the policy, and change the mode from Report-only to On. Monitor sign-in logs closely for the first 48 hours after enforcement.

The What If Tool

The What If tool is your best friend for pre-deployment testing and troubleshooting. It lets you simulate a sign-in scenario and see which policies would apply and what the outcome would be.

How to Use What If

1. Navigate to Microsoft Entra admin center > Protection > Conditional Access > Policies > What If
2. Specify the simulation parameters:
   • User: select the user you want to test
   • Cloud app: select the application
   • IP address: enter the source IP to test location conditions
   • Device platform: select the device OS
   • Client app: choose browser, mobile app, or legacy client
   • Sign-in risk and User risk: set risk levels to test risk-based policies
   • Device state: specify compliant, hybrid joined, or non-compliant
3. Click What If to see the results

The tool displays which policies would apply and whether the outcome is “Grant” (with requirements) or “Block.” It also shows policies that would not apply and explains why — this is equally valuable for understanding gaps in your policy coverage.

Use What If before deploying any new policy to verify it targets the intended users and scenarios. Use it again during troubleshooting when a user reports unexpected access behavior.

Troubleshooting: Sign-In Log Analysis

When users report issues — blocked access, unexpected MFA prompts, inability to access specific applications — the Azure AD sign-in logs are the definitive source of truth.

Reading Sign-In Logs for Conditional Access

1. Navigate to Microsoft Entra admin center > Identity > Monitoring & health > Sign-in logs
2. Locate the sign-in event for the affected user (filter by username, application, and time range)
3. Open the sign-in event and navigate to the Conditional Access tab
4. For each policy listed, you will see one of three outcomes:
   • Success — the policy applied and the user satisfied all requirements
   • Failure — the policy applied and the user did not satisfy the requirements (access was blocked or the user did not complete MFA)
   • Not applied — the policy was not relevant to this sign-in (the user, app, or conditions did not match the policy assignments)
5. Click on a specific policy to see which conditions were matched and which grant controls were required

If you see a policy unexpectedly blocking access, check whether the user is a member of a group that is in scope, whether the device platform or client app conditions are matching in a way you did not anticipate, or whether a location condition is evaluating differently than expected (common with VPN split tunneling).

For deeper SSO troubleshooting related to conditional access failures, see our guide on troubleshooting Azure Single Sign-On.

Common Sign-In Error Codes

• AADSTS53003 — Access blocked by conditional access policy. The sign-in log will show which policy and which grant control caused the block.
• AADSTS53000 — Device is not in the required device state (not compliant or not hybrid joined).
• AADSTS50076 — MFA is required but was not completed. Often caused by a user dismissing the MFA prompt or a timeout.
• AADSTS50105 — The user is not assigned to the application. This is an app assignment issue, not a conditional access issue, but it surfaces in the same workflow.
• AADSTS700016 — The application was not found in the tenant directory. Check the application registration.

Common Mistakes to Avoid

Conditional access is powerful but unforgiving. These are the mistakes that cause the most operational pain.

Not Excluding Break-Glass Accounts

If you lock every account out of the tenant — including your emergency access accounts — you may need to contact Microsoft Support to regain access. Always exclude at least two break-glass accounts from every conditional access policy. Monitor those accounts with alerts so you know immediately if they are used.

Deploying Directly to All Users

Never deploy a new policy to “All users” and switch it to “On” simultaneously. Start with a pilot group, validate in Report-only mode, and expand scope gradually. Even well-intentioned policies can have cascading effects. A policy that blocks access on non-compliant devices will lock out every user who hasn’t enrolled their device in Intune — including executives who will call your CIO before they call the help desk.

Forgetting Service Accounts and Automated Workflows

Service accounts, automated scripts, and third-party integrations authenticate to Azure AD just like users do. A policy that requires MFA for “All users” will break any service account that authenticates non-interactively. Identify these accounts in advance, move them to managed identities or service principals where possible, and create targeted exclusions where necessary. Document every exclusion and review them quarterly.

Conflicting Policies

Because all applicable policies are evaluated simultaneously and the most restrictive result wins, conflicting policies can produce unexpected behavior. A policy that grants access with MFA and another policy that blocks access will result in a block. Use the What If tool to detect conflicts before they affect users.

Ignoring Legacy Authentication Before Blocking It

Blocking legacy authentication without first verifying that no legitimate applications depend on it is the most common source of conditional access incidents. Some organizations still have older mail clients, line-of-business applications, or multifunction printers that rely on legacy protocols. Audit the sign-in logs for legacy authentication activity for at least 30 days before enforcing the block.

Overly Broad Location Blocks

Blocking entire countries may seem like a clean security measure, but it breaks access for employees traveling abroad, remote workers using VPNs that exit in different countries, and third-party vendors. If you implement geographic restrictions, ensure your travel policy includes a process for temporary exceptions and that your help desk knows how to handle these requests.

Not Monitoring Policy Changes

Conditional access policies are high-impact configurations. Any change — whether adding a policy, modifying conditions, or changing the mode from Report-only to On — should be logged, reviewed, and approved through a change management process. Enable Azure AD audit logs and set up alerts for conditional access policy modifications. An unauthorized policy change could silently weaken your security posture or lock out entire departments.

Bringing It All Together

Conditional access is not a set-it-and-forget-it tool. It requires ongoing attention as your organization changes — new applications are onboarded, new offices open, new device types are introduced, and new threat patterns emerge. Schedule quarterly reviews of your conditional access policies to verify they still align with your security requirements and are not causing unnecessary friction for legitimate users.

Start with the six baseline policies described in this guide, deployed in Report-only mode. Use the What If tool and sign-in logs to validate behavior. Switch to enforcement one policy at a time, starting with the lowest-risk policy (block legacy authentication, since most organizations have already moved away from legacy protocols). Build from there.

Conditional access is the enforcement mechanism that makes Zero Trust operational, MFA contextual, and M365 security hardening enforceable. Without it, security policies are recommendations. With it, they are requirements.