How to Set Up Conditional Access in Microsoft Intune [Step-by-Step]

Conditional Access is the backbone of zero trust security in Microsoft 365. It is the policy engine that decides whether a user gets access to corporate resources based on who they are, where they are, what device they are using, and what they are trying to access. Without it, your Intune deployment is managing devices but not actually enforcing access decisions.

The problem is that Conditional Access is easy to get wrong. A misconfigured policy can lock out your entire organization or, worse, create gaps that leave sensitive data exposed while giving you a false sense of security. We have seen both outcomes in production environments, and neither is pleasant to recover from.

This guide walks through the complete process of setting up Conditional Access policies in Microsoft Intune and Entra ID, from initial planning through production deployment. Every step includes the specific settings, the reasoning behind them, and the mistakes we see IT teams make most often.

Prerequisites: What You Need Before Starting

Before you create your first Conditional Access policy, verify that these foundations are in place. Skipping any of them will cause problems during implementation.

Licensing requirements. Conditional Access requires Entra ID P1 at minimum, which is included in Microsoft 365 Business Premium, E3, and E5. If you want risk-based policies (and you should), you need Entra ID P2 for Identity Protection integration. Check your license assignments in the Microsoft 365 admin center under Billing > Licenses. A common mistake is having the licenses purchased but not assigned to the users who need them.

Intune enrollment. Devices must be enrolled in Microsoft Intune for device-based Conditional Access to work. If you are still in the process of enrolling devices, start with user-based policies (MFA, location) and add device compliance requirements as enrollment progresses.

Break-glass accounts. Create at least two emergency access accounts that will be excluded from all Conditional Access policies. These accounts should use long, complex passwords stored in a physical safe, have no MFA requirement, and be monitored with alerts for any sign-in activity. If you lock yourself out of your tenant with a bad CA policy, these accounts are your only way back in.

Directory synchronization. If you are running a hybrid environment, make sure Entra Connect (formerly Azure AD Connect) is healthy and syncing. Conditional Access evaluates against the Entra ID directory, so stale or missing objects will cause unexpected policy behavior.

Application inventory. List every cloud application your organization uses. You need to know what you are protecting before you can write policies. Pay particular attention to third-party SaaS applications that use SAML or OIDC federation with Entra ID, as these are all subject to Conditional Access evaluation.

Step 1: Define Your Access Policies on Paper First

The biggest mistake we see with Conditional Access is jumping straight into the admin center and creating policies ad hoc. This produces an inconsistent, overlapping set of rules that are difficult to troubleshoot and impossible to audit.

Start by defining your policy matrix in a spreadsheet or document. For each policy, specify the target users or groups, the target applications, the conditions (location, device platform, device compliance, sign-in risk), and the controls (block, grant with MFA, grant with compliant device, session controls).

A baseline set of policies for most organizations includes these five:

1. Require MFA for all users on all cloud apps. This is your foundation. Every user, every application, MFA required. Exclude your break-glass accounts.
2. Block legacy authentication. Older protocols (POP, IMAP, SMTP AUTH, older Exchange ActiveSync) do not support MFA and are the primary vector for password spray attacks. Block them entirely.
3. Require compliant devices for corporate data. Users accessing Exchange Online, SharePoint, and Teams must do so from an Intune-managed, compliant device. This is where Intune integration adds real value.
4. Block access from untrusted countries. If your organization does not operate in certain regions, block sign-ins from those countries. This eliminates a large volume of credential-stuffing attempts.
5. Require MFA for administrative actions. Any user with a directory role (Global Admin, Exchange Admin, etc.) must complete MFA every session, with no "remember MFA" grace period.

Document each policy with a clear naming convention. We recommend a format like CA001 - All Users - All Apps - Require MFA where the number provides ordering, followed by the scope and the action. This makes policies easy to identify in the admin center and in audit logs.

Step 2: Configure Device Compliance Policies in Intune

Conditional Access policies that require a compliant device need Intune compliance policies to define what "compliant" means. Without these, the device compliance condition in CA will evaluate to "unknown" for all devices, which typically results in blocked access.

Navigate to the Intune admin center at intune.microsoft.com and go to Devices > Compliance policies. Create separate policies for each platform your organization supports (Windows, macOS, iOS, Android).

Windows compliance policy settings we recommend:

• OS version: Set a minimum OS version that corresponds to a supported, patched Windows build. For Windows 11, require at least the current servicing baseline.
• BitLocker: Require BitLocker encryption. This protects data at rest if a device is lost or stolen.
• Antivirus: Require Microsoft Defender Antivirus to be enabled and up to date. If you are using a third-party AV, configure the health attestation check instead.
• Firewall: Require Windows Firewall to be enabled.
• TPM: Require a TPM 2.0 module. This is necessary for proper attestation and BitLocker key protection.
• Microsoft Defender for Endpoint risk level: If you have Defender for Endpoint (included in M365 E5), set the maximum allowed machine risk level to "Low." This blocks access from devices that Defender has flagged as compromised.

Grace period configuration. Set the "Mark device noncompliant" schedule thoughtfully. We typically configure an immediate mark for critical settings (BitLocker, antivirus) and a 24-72 hour grace period for OS version requirements. This gives users time to install updates without losing access mid-workday.

Actions for noncompliance. Configure at least two actions: send a notification email to the user when their device becomes noncompliant, and mark the device noncompliant after the grace period. The notification email should include clear instructions on how to remediate (run Windows Update, enable BitLocker, etc.).

A common mistake here is making compliance policies too strict too fast. If you require the latest OS build on day one and half your fleet is two versions behind, you will lock out half your organization when you enforce the CA policy. Start with a minimum OS version that 95% of your devices already meet, then tighten it gradually.

Step 3: Set Up Named Locations

Named locations define trusted and untrusted network locations that Conditional Access policies can reference. This is how you implement location-based access controls without hardcoding IP addresses into individual policies.

In the Entra admin center, navigate to Protection > Conditional Access > Named locations. You will create two types:

IP-based locations. These define trusted network ranges using IPv4 or IPv6 CIDR notation. Create named locations for your corporate office networks, VPN exit points, and any partner or datacenter networks where you expect legitimate sign-ins. Mark these as "trusted locations." When a sign-in originates from a trusted location, you can apply less restrictive policies (such as skipping MFA for compliant devices on the corporate network).

Country-based locations. These use GeoIP data to identify the country of origin for a sign-in. Create a named location for countries where your organization operates (for example, "Allowed Countries" containing United States, Canada, and United Kingdom). Create another for countries you want to block.

Important considerations for named locations:

• VPN users. If employees use a VPN, their sign-ins will appear to originate from the VPN provider's exit IP, not their physical location. Make sure your VPN provider's IP ranges are included in your trusted locations.
• Cloud proxies. Services like Zscaler or Netskope route traffic through their cloud infrastructure. Include those proxy IP ranges in your trusted locations, or your CA policies will treat all proxied traffic as untrusted.
• IPv6. Do not forget to include IPv6 ranges if your network uses them. Missing IPv6 entries are a common cause of false positives in location-based policies.
• Dynamic IPs. If your office has a dynamic public IP from the ISP, you will need to update the named location whenever it changes. Consider setting up an automation to detect and update this, or negotiate a static IP with your ISP.

Step 4: Create Your Conditional Access Policies

Now you build the actual policies. Navigate to Protection > Conditional Access > Policies and click "New policy." We will walk through creating the baseline MFA policy as an example, then cover the specifics for other policy types.

Policy: CA001 - All Users - All Apps - Require MFA

Assignments - Users: Select "All users." Then under Exclude, add your break-glass emergency access accounts and any service accounts that cannot perform MFA (these should be tightly scoped with other controls). Do not exclude regular admin accounts from MFA. Admins should have stronger MFA requirements, not weaker ones.

Assignments - Target resources: Select "All cloud apps." This is intentional. You want MFA across everything, not just Exchange and SharePoint. Shadow IT applications that users federate through Entra ID are also covered when you target all cloud apps.

Conditions: For the baseline MFA policy, do not set any conditions. You want this to apply universally. Conditions narrow the scope, which is useful for other policies but counterproductive for your MFA baseline.

Grant controls: Select "Grant access" and check "Require multifactor authentication." If you have multiple grant controls, choose "Require all the selected controls" for maximum security or "Require one of the selected controls" if you want flexibility (for example, MFA OR compliant device).

Session controls: For this baseline policy, leave session controls at defaults. Session controls are more relevant for policies targeting unmanaged devices or sensitive applications.

Enable policy: Set to "Report-only" initially. Never set a new policy to "On" without testing.

Policy: CA002 - All Users - All Apps - Block Legacy Auth

Assignments: All users (excluding break-glass accounts). Target resources: All cloud apps. Conditions: Client apps > select only "Exchange ActiveSync clients" and "Other clients." Grant: Block access. This policy specifically targets authentication attempts using legacy protocols and blocks them regardless of credential validity.

Policy: CA003 - All Users - Office 365 - Require Compliant Device

Assignments: All users (excluding break-glass accounts). Target resources: Select "Office 365" (this is a pre-built app group covering Exchange, SharePoint, Teams, and other M365 services). Conditions: Optionally exclude trusted locations if you want to allow browser-only access from the corporate network without a managed device. Grant: Require device to be marked as compliant. This is where your Intune compliance policies come into play.

Policy: CA004 - All Users - All Apps - Block Untrusted Countries

Assignments: All users (excluding break-glass accounts). Target resources: All cloud apps. Conditions: Locations > Include "Any location" > Exclude your "Allowed Countries" named location. Grant: Block access. This blocks any sign-in attempt from a country not on your allowed list.

Policy: CA005 - Admins - All Apps - Require MFA Every Session

Assignments: Select "Directory roles" and include all admin roles (Global Administrator, Exchange Administrator, SharePoint Administrator, Security Administrator, etc.). Target resources: All cloud apps. Grant: Require multifactor authentication. Session controls: Set sign-in frequency to "Every time." This ensures admins cannot rely on cached MFA tokens.

Step 5: Test with Report-Only Mode

Report-only mode is the most important safety feature in Conditional Access. When a policy is in report-only mode, it evaluates every sign-in against the policy conditions and logs what it would have done (grant, block, require MFA) without actually enforcing anything.

After creating your policies in report-only mode, let them run for at least one to two weeks before enforcement. During this period, check the results daily.

Where to find report-only results: In the Entra admin center, go to Protection > Conditional Access > Insights and reporting. This workbook shows you how each policy would have affected sign-ins. You can filter by policy, user, application, and outcome.

What to look for during the report-only period:

• False blocks. Are there legitimate sign-ins that would have been blocked? Common causes include service accounts that cannot perform MFA, automated processes using legacy authentication, or users signing in from a VPN whose IP range you did not include in trusted locations.
• Scope gaps. Are there sign-ins that should be covered by a policy but are not? This usually means a user is not in the targeted group or an application is not included in the target resources.
• Compliance readiness. For policies requiring compliant devices, how many sign-ins come from non-compliant or unmanaged devices? If the number is high, you need to either accelerate device enrollment or phase in the policy with exceptions.

Sign-in log analysis. For deeper investigation, check individual sign-in logs under Monitoring > Sign-in logs. Each log entry has a "Conditional Access" tab showing which policies evaluated and their report-only results. This is invaluable for troubleshooting specific user issues.

Do not rush this phase. Two weeks of data gives you a representative sample that includes users who sign in infrequently (weekly report runners, monthly auditors, external collaborators). If you only wait two days, you will miss these edge cases and encounter them as production incidents after enforcement.

Step 6: Deploy Gradually

Once report-only analysis looks clean, move to enforcement in phases. Never flip all policies to "On" simultaneously.

Phase 1: Pilot group (Week 1-2). Create a security group called "CA-Pilot" containing IT staff and technically capable users who can report issues quickly. Modify your policies to target this group instead of "All users." Switch from report-only to "On." Monitor for one to two weeks. The pilot group should include users from different offices, different device types, and different roles to maximize coverage.

Phase 2: Early adopters (Week 3-4). Expand to include one or two business departments. Choose departments with good IT relationships who will escalate issues promptly rather than working around them silently. Keep monitoring.

Phase 3: General availability (Week 5+). Switch the policy targeting back to "All users." Communicate the change to the organization before enforcement. Include clear instructions for what users should expect (MFA prompts, compliance requirements) and who to contact if they have issues.

Communication is critical. Users who are suddenly prompted for MFA without warning will flood your helpdesk. Send emails explaining what is changing, why it matters for security, and what they need to do. If users need to set up MFA methods, give them a self-service registration link and a deadline.

If a policy causes unexpected lockouts after going live, switch it back to report-only immediately. Do not delete the policy or try to fix it while users are locked out. Switch to report-only, restore access, investigate, and then re-enable.

Step 7: Monitor and Refine

Conditional Access is not a set-and-forget configuration. Your policies need ongoing monitoring and adjustment as your organization changes.

Weekly monitoring tasks:

• Review the CA Insights workbook for unexpected blocks or failures.
• Check for users repeatedly failing MFA, which may indicate compromised accounts or usability issues.
• Verify that new applications added to Entra ID are covered by appropriate policies.
• Confirm break-glass accounts have not been accidentally included in any policy.

Monthly monitoring tasks:

• Audit named locations to ensure IP ranges are current (especially if your ISP assigns dynamic IPs).
• Review compliance policy settings and tighten OS version requirements as patches are released.
• Check for new Entra ID features or changes that affect CA behavior (Microsoft updates these regularly).
• Review excluded users and groups to ensure exceptions are still justified.

Alerting. Configure alerts in Entra ID for suspicious activity: sign-ins from break-glass accounts, unusual MFA failure rates, and sign-ins from blocked locations that succeed (which indicates a policy gap). Use Azure Monitor or Microsoft Sentinel if you have them, or at minimum configure the built-in Entra ID alert rules.

Common Mistakes That Undermine Conditional Access

After deploying Conditional Access for dozens of organizations, these are the mistakes we encounter repeatedly:

Excluding too many users. Every exclusion is a security gap. We have seen organizations with more users excluded from CA than covered by it. If a user or service account needs an exception, document why, set a review date, and apply compensating controls.

Not blocking legacy authentication. This is the single most impactful security policy you can deploy, yet many organizations skip it because "someone might need POP/IMAP." In 2026, there is no legitimate reason for legacy auth in most environments. Block it.

Targeting specific apps instead of all cloud apps. If you only require MFA for Exchange and SharePoint, attackers will target whatever application you did not protect. Target all cloud apps for baseline policies and only narrow scope for additional policies that add extra controls.

No break-glass accounts. We have been called in to help organizations that locked themselves out of their own tenants because they did not have emergency access accounts. Setting these up takes 15 minutes. Not having them can take days to recover from.

Forgetting about guest users. Guest users (B2B collaboration) are subject to Conditional Access policies that target "All users." If you require compliant devices and your guests are on unmanaged devices, they will be blocked. Create specific policies for guest users with appropriate controls (MFA plus session restrictions instead of device compliance).

Conflicting policies. When multiple CA policies apply to the same sign-in, all policies must be satisfied. This is not an "any match wins" evaluation. If Policy A grants access with MFA and Policy B blocks access, the block wins. Map out your policy interactions before deployment.

Troubleshooting Conditional Access

When users report access issues and you suspect Conditional Access, follow this troubleshooting workflow:

Step 1: Check the sign-in logs. In the Entra admin center, go to Monitoring > Sign-in logs. Find the user's failed sign-in and click on it. Open the "Conditional Access" tab to see exactly which policies evaluated, which conditions matched, and what the outcome was.

Step 2: Use the What If tool. Under Protection > Conditional Access > Policies, click "What If." Enter the user, application, device platform, location, and other conditions. The tool shows which policies would apply and what outcome they would produce. This is essential for debugging policy interactions.

Step 3: Check device compliance status. If the policy requires a compliant device, go to the Intune admin center and look up the user's device. Check the compliance status and see which settings are failing. Common issues include expired OS versions, disabled BitLocker, or stale compliance evaluation (force a sync from the device).

Step 4: Verify MFA registration. If MFA is required but the user has not registered any methods, they will be prompted to register (if allowed by your authentication methods policy) or blocked if registration is not permitted from their current context. Check the user's authentication methods in Entra ID > Users > [User] > Authentication methods.

Step 5: Check for token caching. Conditional Access evaluates at token issuance, not during an active session. If a user signed in before a policy was enforced, they may have a cached token that grants access until it expires. Sign-in frequency policies and continuous access evaluation (CAE) help reduce this gap.

For complex environments, consider integrating CA sign-in data into Microsoft Sentinel or a SIEM for centralized analysis and automated alerting. The built-in sign-in logs retain data for 30 days (P1) or 30 days (P2 with diagnostic settings can export to Log Analytics for longer retention).

Next Steps

Once your baseline Conditional Access policies are enforced and stable, consider these enhancements:

• Risk-based policies: With Entra ID P2, add user risk and sign-in risk conditions to your policies. This automatically blocks or challenges sign-ins that Identity Protection flags as suspicious.
• Token protection: Enable token binding to prevent token theft attacks where an adversary steals a session token and replays it from a different device.
• Continuous access evaluation (CAE): Enable CAE for supported applications to ensure policy changes and account revocations take effect in near real-time rather than waiting for token expiry.
• Authentication context: Use authentication contexts to require step-up authentication for specific actions within an application (such as downloading sensitive files from SharePoint) without requiring it for all access.

Conditional Access combined with Intune device compliance creates a security baseline that protects your organization without creating excessive friction for users. The key is proper planning, gradual rollout, and ongoing monitoring.