Azure Conditional Access Policy Setup Guide (Entra ID)

Conditional Access is the policy engine in Microsoft Entra ID (formerly Azure AD) that decides whether a sign-in gets in, gets challenged, or gets blocked. You configure it in the Microsoft Entra admin center under Entra ID > Conditional Access > Policies, it needs at least a Microsoft Entra ID P1 license, and every new policy should start in Report-only mode. That is the short answer. The rest of this guide is the step-by-step version.

Passwords verify who someone claims to be. Conditional Access determines whether they should actually get in. A valid username and password from an unmanaged device in a foreign country at 3:00 AM should not receive the same access as the same credentials from a corporate laptop on the office network during business hours. Conditional Access policies 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. It is the enforcement engine behind Zero Trust security, the mechanism that turns “never trust, always verify” from a principle into an operational reality.

Quick-Start Checklist

If you only have an hour, do these in order:

1. Confirm licensing. Microsoft Entra ID P1 (included in Microsoft 365 Business Premium and Microsoft 365 E3) for Conditional Access; P2 (included in Microsoft 365 E5) for risk-based policies.
2. Create two break-glass accounts. Cloud-only, Global Administrator, excluded from every policy, and monitored with a sign-in alert.
3. Check what already exists. Open Entra ID > Conditional Access > Policies and look for policies with Microsoft in the Created by column. These are Microsoft-managed policies, and they may already be in Report-only.
4. Turn off security defaults (only when you are ready to replace them): Entra ID > Overview > Properties > Manage security defaults.
5. Deploy the baseline from templates: block legacy authentication, require MFA for admins, require MFA for all users, require MFA for Azure management. Templates are created in Report-only by default.
6. Watch report-only results for 7 to 14 days, using the Policy impact view and the sign-in logs.
7. Switch each policy to On, one at a time, starting with block legacy authentication.

What Is Conditional Access in Azure?

Conditional Access policies are if-then statements: if the assignments (users, target resources, and conditions) match a sign-in, then apply the access controls (grant and session). Microsoft describes it as its Zero Trust policy engine. Policies are evaluated after first-factor authentication completes, so Conditional Access is not a defense against things like denial-of-service attacks; it decides what happens once someone has presented a credential.

Every policy has three parts: assignments, conditions, and access controls.

Signals (Assignments and Conditions)

Signals are the inputs Conditional Access evaluates when a user attempts to sign in:

• Users, groups, and agents: apply the policy to specific users, groups, directory roles, or all users. You can also exclude specific accounts, such as break-glass emergency accounts. Microsoft has added support for targeting agent identities (in preview).
• Target resources: target specific applications (Exchange Online, SharePoint, the Azure portal) or All resources (formerly ‘All cloud apps’).
• Device platform: differentiate between Windows, macOS, iOS, Android, and Linux.
• Network (location): use named locations (IP ranges or countries) to distinguish corporate network access from external access.
• Client apps: distinguish modern authentication clients (browser, mobile and desktop apps) from legacy authentication protocols (IMAP, POP3, SMTP AUTH, Exchange ActiveSync).
• Device state: check whether the device is marked compliant by Intune, Microsoft Entra hybrid joined, or unmanaged. Filters for devices let you target specific devices such as privileged access workstations.
• Sign-in risk: with Microsoft Entra ID P2, evaluate the real-time risk of a sign-in based on signals like anonymous IP addresses, atypical travel, and password spray.
• User risk: with P2, evaluate the likelihood that the account itself is compromised, based on detections such as leaked credentials.

Decisions (Access Controls)

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

• Block access entirely
• Grant access with requirements: require multifactor authentication, require authentication strength, require the device to be marked as compliant, require a Microsoft Entra hybrid joined device, require an approved client app, require an app protection policy, require a password change, or require 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 (for example, limited web-only access in SharePoint)
• Disable browser persistence (prevent “stay signed in” behavior)

Policy Evaluation Order

Entra evaluates all Conditional Access policies that apply to a given sign-in. Policies are not evaluated in sequence; they all apply at once. 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. The most restrictive combination always wins.

Conditional Access License Requirements

Conditional Access requires Microsoft Entra ID P1 at minimum. P1 is included in Microsoft 365 Business Premium, Microsoft 365 E3, and EMS E3. Risk-based policies (sign-in risk and user risk) depend on Microsoft Entra ID Protection, which is a Microsoft Entra ID P2 feature included in Microsoft 365 E5 and EMS E5. Other products that plug into Conditional Access, such as Intune (for device compliance), Microsoft Entra Workload ID, and Microsoft Purview (insider risk), need their own licenses.

Two licensing details trip people up:

• If your P1/P2 licenses expire, your policies are not deleted or disabled. Microsoft leaves them enforcing so your security posture does not change overnight, but you can no longer edit them, only view or delete them.
• “Licensing overage” warnings. If the Entra admin center tells you that some Conditional Access policies are protecting more users than your licensing entitlements allow, it means the users in scope of your policies outnumber your P1/P2 licenses. The policies still apply. The fix is to assign licenses to everyone in scope (group-based licensing makes this easier) or narrow the scope. Don’t “fix” it by excluding users from your MFA policy.

Security Defaults vs Conditional Access

Security defaults are free, on-or-off protections available to every tenant. They require all users to register for MFA, require MFA for administrators, require MFA for users when Microsoft decides it is necessary, block legacy authentication, block device code flow, and require MFA for access to the Azure portal, Microsoft Entra admin center, Azure PowerShell, and Azure CLI.

	Security defaults	Conditional Access
License	None (Free tier)	Microsoft Entra ID P1 or higher
Customization	None; it is on or off	Fully customizable per user, app, device, location, and risk
Exclusions	Not possible (sync accounts are excluded automatically)	Any user, group, role, or app
Best for	Small tenants with no premium licenses	Any tenant with P1/P2 or Business Premium

You cannot run both. Microsoft’s own guidance is that if you have P1 or P2 licenses, security defaults are probably not right for you. To switch, sign in as at least a Conditional Access Administrator, go to Entra ID > Overview > Properties > Manage security defaults, and set it to Disabled (not recommended). Then immediately enable Conditional Access policies that replace the same protections. Have the replacement policies built and tested in Report-only before you flip security defaults off, so there is no gap.

How to Get to Conditional Access in the Microsoft Entra Admin Center

The old Azure AD blade paths (“Azure Active Directory > Security > Conditional Access”) are gone. The current path is:

1. Sign in to the Microsoft Entra admin center. Viewing policies needs at least the Security Reader role; creating and editing them needs at least Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access.
3. The Overview page summarizes enabled vs report-only policies and recent activity. The Coverage tab shows which applications had sign-ins without policy coverage over the past seven days. The Policies page lists every policy and holds the New policy, What If, and upload options.

If you live in the Azure portal, searching for “Conditional Access” in the top search bar takes you to the same experience.

How to Configure a Conditional Access Policy in Azure (Step by Step)

These are the generic steps for any custom policy. The baseline policies below fill in the specifics.

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies and select New policy.
3. Give the policy a name that follows a naming standard (for example, CA001-AllUsers-AllResources-RequireMFA).
4. Under Assignments, select Users or workload identities. Choose who to Include, then under Exclude select your break-glass accounts. If you use Microsoft Entra Connect or Cloud Sync, also exclude the Directory Synchronization Accounts directory role.
5. Under Target resources > Resources (formerly cloud apps), choose All resources or specific apps.
6. Under Conditions, add any network, device platform, client app, or risk conditions the policy needs.
7. Under Access controls > Grant, choose Block access or Grant access with the required controls. Add Session controls if needed.
8. Set Enable policy to Report-only and select Create.
9. After reviewing the results, change Enable policy from Report-only to On.

Start From a Template Instead

You do not have to build the baseline by hand. In Entra ID > Conditional Access, select Create new policy from templates. Templates are grouped into categories: Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats, and AI Agents. The Secure foundation set is what Microsoft recommends every organization deploy as a group, and it includes block legacy authentication, MFA for admins, MFA for all users, MFA for Azure management, securing security info registration, and require compliant device.

Two things to know about templates. First, every template policy is created in Report-only mode. Second, a template that targets users excludes only the admin who created it. Edit each one afterward to exclude your break-glass accounts.

Check for Microsoft-Managed Policies First

Microsoft now deploys Microsoft-managed Conditional Access policies directly into eligible tenants. They arrive in Report-only state, and Microsoft turns them on no less than 30 days later if you leave them there (you get an email and a Message center post two weeks before). Current managed policies include block legacy authentication, block device code flow, MFA for admins accessing Microsoft admin portals, MFA for all users, MFA for per-user MFA users, MFA and reauthentication for risky sign-ins, and two high-risk user policies (P2).

You can change their state and exclusions, but you cannot rename or delete them. If you need a different scope or control, use Duplicate to make an editable copy. Before you build your own baseline, check the Created by column so you do not end up with two policies doing the same job.

Baseline Policies Every Organization Needs

The following policies are the minimum set every organization should deploy. They address the most common attack vectors and align with Microsoft’s Conditional Access templates.

Policy 1: Block Legacy Authentication

Legacy authentication protocols such as POP3, IMAP, SMTP AUTH, and older Exchange ActiveSync clients do not support MFA. Microsoft reports that more than 99 percent of password spray attacks use legacy authentication. Blocking it is the single highest-impact policy you can deploy.

Configuration:

1. Browse to Entra ID > Conditional Access > Policies and select New policy. Name it “Block Legacy Authentication”.
2. Under Users or workload identities, include All users. Exclude your break-glass accounts and any account that still must use legacy auth while you migrate it.
3. Under Target resources > Resources, include All resources.
4. Under Conditions > Client apps, set Configure to Yes and check only Exchange ActiveSync clients and Other clients.
5. Under Access controls > Grant, select Block access.
6. Set Enable policy to Report-only.

Before enforcing, find out who still uses legacy auth. In Entra ID > Monitoring & health > Sign-in logs, add the Client App column, filter on the legacy protocols, and repeat on the User sign-ins (non-interactive) tab. Common offenders are older Outlook versions, multifunction printers that scan to email, and third-party apps using SMTP AUTH.

Policy 2: Require Phishing-Resistant MFA for Administrators

Administrative accounts are the highest-value targets in your environment. A compromised Global Administrator gives an attacker complete control of your tenant. Requiring MFA for all admin roles is non-negotiable, and for admins you should go a step further with an authentication strength.

Configuration:

1. Create a new policy: “Require Phishing-Resistant MFA for Admins”.
2. Under Users or workload identities, select Directory roles and include at least: Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Authentication Administrator, Application Administrator, Cloud Application Administrator, Helpdesk Administrator, Password Administrator, and Billing Administrator.
3. Exclude break-glass accounts.
4. Under Target resources, include All resources.
5. Under Grant, select Grant access, then Require authentication strength and pick the built-in Phishing-resistant MFA strength.
6. Deploy in Report-only, confirm every admin has registered a FIDO2 security key, passkey, Windows Hello for Business, or certificate-based authentication, then switch to On.

If your admins have not registered phishing-resistant methods yet, start with the built-in Multifactor authentication strength and tighten it later.

Policy 3: Require MFA for All Users

Once administrative accounts are protected, extend MFA to everyone. Microsoft’s research says an account is more than 99.9% less likely to be compromised when it uses MFA. Microsoft’s recommended baseline is a policy that targets all users and all resources with no app exclusions.

Configuration:

1. Create a new policy: “Require MFA for All Users”.
2. Under Users or workload identities, include All users. Exclude break-glass accounts and the Directory Synchronization Accounts role. Service accounts that cannot do MFA should be moved to managed identities or service principals rather than excluded indefinitely; document any exception and review it quarterly.
3. Under Target resources, include All resources.
4. Under Grant, select Require authentication strength > Multifactor authentication strength. If you use external authentication methods, use Require multifactor authentication instead, because external methods are not compatible with authentication strength.
5. Optionally, under Network, exclude All trusted networks and locations to reduce prompts on-site (Zero Trust guidance recommends requiring MFA regardless of location).

If you run hybrid identity and the sync account gets caught by a policy, sync fails. Our guide to fixing Azure AD (Entra Connect) sync errors covers what that looks like.

Policy 4: Require Compliant Devices for Key Applications

Device compliance ensures only managed, healthy devices can reach corporate data. An unpatched personal laptop with no encryption should not be able to download files from SharePoint.

Configuration:

1. Create a new policy: “Require Compliant Device for Office 365”.
2. Under Users or workload identities, include All users. Exclude break-glass accounts.
3. Under Target resources, select Office 365 (covers Exchange Online, SharePoint Online, Teams, and OneDrive).
4. Under Grant, select Require device to be marked as compliant and Require Microsoft Entra hybrid joined device, with Require one of the selected controls.
5. Under Conditions > Device platforms, consider targeting one platform at a time to phase the rollout.

This policy only works if Intune compliance policies already exist and devices are enrolled. Our Intune setup guide walks through enrollment and compliance policies step by step. Typical compliance requirements: minimum OS version, encryption on, antivirus active and current, 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 (P2)

This policy uses Microsoft Entra ID Protection to detect and respond to sign-ins with suspicious characteristics: anonymous IP addresses, password spray, impossible travel, and token replay.

Configuration:

1. Create a new policy: “Block High-Risk Sign-Ins”.
2. Include All users. Exclude break-glass accounts.
3. Under Target resources, include All resources.
4. Under Conditions > Sign-in risk, select High.
5. Under Grant, select Block access.
6. Create a second policy for Medium sign-in risk that requires MFA instead of blocking.

For user risk, add a policy that requires a secure password change (or risk remediation) when user risk is High. Check for the Microsoft-managed risk policies first, since eligible P2 tenants may already have them in Report-only.

Policy 6: Require MFA for Azure Management

The Azure portal, Microsoft Entra admin center, Azure PowerShell, and Azure CLI give administrative control over your cloud. Microsoft already enforces mandatory MFA for Azure sign-ins, but you still want your own policy with device and session requirements.

Configuration:

1. Create a new policy: “Secure Azure Management Access”.
2. Include All users (or users with Azure roles). Exclude break-glass accounts.
3. Under Target resources, select Windows Azure Service Management API.
4. Under Grant, select Require multifactor authentication and Require device to be marked as compliant, with Require all the selected controls.
5. Under Session > Sign-in frequency, set 4 hours to force periodic re-authentication.

Classic Policies

If your tenant is old enough to have classic Conditional Access policies, they stopped enforcing after July 10, 2024. Find them under Entra ID > Conditional Access > Classic policies, document their settings, recreate them as modern policies, and disable them.

Configuring Named Locations

Named locations define trusted networks and geographic boundaries. You use them as conditions to differentiate internal from external access.

IP-Based Named Locations

1. Browse to Entra ID > Conditional Access > Named locations.
2. Create a new IP ranges location.
3. Enter a name (for example, “Corporate Offices: Chicago”) and add the public IP CIDR ranges of your offices, VPN egress, and data centers.
4. Optionally mark it as a trusted location, which Identity Protection uses to reduce false positives.

Country-Based Named Locations

1. Create a new Countries/Regions location.
2. Select the countries to include.
3. Use it in a policy under Conditions > Network > Include/Exclude.

A common pattern is an “Allowed Countries” named location and a policy that blocks sign-ins from anywhere not in that list. It cuts down noise from credential-stuffing botnets that operate 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, Entra uses a rolling 90-day window before asking users to sign in again. For sensitive resources, that is too long. Sign-in frequency forces re-authentication at a defined interval.

• Set 1 to 4 hours for the Azure portal and administrative tools
• Set 8 to 12 hours for general Office 365 access on unmanaged devices
• Leave compliant corporate devices on the defaults and rely on Continuous Access Evaluation (CAE), which lets supported apps such as Exchange Online and SharePoint revoke sessions in near real time when an account is disabled or a password is reset

Persistent Browser Session

1. In the policy, under Session, select Persistent browser session and set it to Never persistent.
2. Apply this only to sign-ins from unmanaged devices so you do not frustrate users on corporate machines.

Conditional Access App Control

For apps integrated with Microsoft Defender for Cloud Apps, you can proxy sessions to block downloads, block copy/paste of sensitive data, or watermark documents. It is the middle ground between full access and blocking unmanaged devices entirely.

Testing Policies with Report-Only Mode

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

How Report-Only Mode Works

In Report-only, Entra evaluates the policy during every applicable sign-in and records the result in the sign-in log, but does not enforce grant or session controls. You see whether the policy would have granted access, blocked access, or required more authentication, and the user’s experience is unchanged.

Using Report-Only Effectively

1. Deploy every new policy in Report-only first. No exceptions. Simple policies still interact with other policies in unexpected ways.
2. Let it run for at least 7 days to capture a full business cycle (weekday and weekend, office and remote, mobile and desktop).
3. Review the Policy impact view on the policy itself for a summary, then drill into the sign-in logs for specific users who would have been blocked or challenged.
4. Iterate. Adjust exclusions, conditions, or scope. Add groups gradually if needed.
5. Switch to On only when you are confident the policy will not disrupt legitimate access. Watch sign-in logs closely for the first 48 hours.

How to Check Conditional Access Policies in Azure

“Which policies apply to this user, and why?” comes up constantly. There are three ways to answer it.

1. The What If Tool

The What If tool simulates a sign-in and reports which policies would apply.

1. Browse to Entra ID > Conditional Access > Policies > What If.
2. Provide the required conditions: the identity (user, agent identity, or single tenant service principal), the target resource, the device platform, and the client app.
3. Optionally add IP address or country, device state, sign-in risk, and user risk.
4. Select What If.

The result lists policies that apply (with the grant and session controls that must be satisfied) and policies that do not apply, with the first condition that did not match. Two caveats: only enabled and report-only policies are evaluated, and you must specify an app by its App ID, because groupings like Office 365 do not match.

2. Sign-In Logs

When users report blocked access or unexpected MFA prompts, the sign-in logs are the source of truth.

1. Browse to Entra ID > Monitoring & health > Sign-in logs (Reports Reader is enough).
2. Filter by username, application, date, or Conditional Access status.
3. Open the sign-in event and select the Conditional Access tab.
4. Each policy shows Success (applied and satisfied), Failure (applied and not satisfied), or Not applied (assignments did not match). Report-only policies show their would-be result separately.
5. Select the policy name to see which conditions matched.

If a policy is blocking unexpectedly, check group membership, device platform and client app matching, and location evaluation (VPN split tunneling is a frequent culprit). For deeper sign-in errors, see our guide to troubleshooting Azure single sign-on.

3. Audit Logs

To see who changed a policy and when, browse to Entra ID > Monitoring & health > Audit logs and set the Service filter to Conditional Access. Microsoft-managed policy changes appear with names starting “Microsoft-managed:”.

Common Sign-In Error Codes

• AADSTS53003: access blocked by a Conditional Access policy. The sign-in log shows which policy and control caused it.
• AADSTS53000: the device is not in the required state (not compliant, or not registered).
• AADSTS50076: MFA is required but was not completed, often a dismissed prompt or a timeout.
• AADSTS50105: the user is not assigned to the application. This is an app assignment issue, not Conditional Access, but it shows up in the same workflow.
• AADSTS700016: the application was not found in the tenant. Check the app registration.

Common Mistakes to Avoid

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

Not Excluding (and Not Monitoring) Break-Glass Accounts

If every account is locked out, including your emergency access accounts, you may need Microsoft Support to regain access. Microsoft recommends two cloud-only emergency access accounts with the Global Administrator role, excluded from your policies. The exclusion is only half the job. An excluded account is an account that skips MFA, so under the Zero Trust principle of “assume breach” it must be monitored: alert on every sign-in to those accounts, and test them quarterly.

Deploying Directly to All Users

Never assign a new policy to “All users” and switch it to “On” at the same time. Start with a pilot group, validate in Report-only, and expand gradually. A policy that blocks non-compliant devices will lock out every user who hasn’t enrolled in Intune, including executives who will call your CIO before they call the help desk.

Forgetting Service Accounts and Automated Workflows

Service accounts, scripts, and third-party integrations that sign in as users will break under an “All users” MFA policy. Identify them in advance, move them to managed identities or service principals where possible (calls made by service principals aren’t blocked by user-scoped policies), and document any exclusion.

Conflicting Policies

Because all applicable policies apply at once and the most restrictive result wins, a policy that grants with MFA and another that blocks results in a block. Use the What If tool to find conflicts before users do.

Blocking Legacy Authentication Blind

Blocking legacy auth without checking who depends on it is the most common source of Conditional Access incidents. Audit at least 30 days of sign-in logs first, including non-interactive sign-ins.

Overly Broad Location Blocks

Country blocks break access for traveling employees, remote workers whose VPN exits elsewhere, and vendors. If you use them, have a documented process for temporary exceptions.

Not Monitoring Policy Changes

Any change to a Conditional Access policy, whether adding one, editing conditions, or switching from Report-only to On, should go through change management. Use the Entra audit logs and alert on Conditional Access modifications. An unauthorized change can silently weaken your posture or lock out a department.

Frequently Asked Questions

What license do I need to use Conditional Access?

Conditional Access requires Microsoft Entra ID P1 at minimum, which is included in Microsoft 365 Business Premium and Microsoft 365 E3. Risk-based policies that use sign-in risk or user risk need Microsoft Entra ID P2, included in Microsoft 365 E5. Both can also be purchased standalone.

Where is Conditional Access in the Microsoft Entra admin center?

Sign in to entra.microsoft.com and browse to Entra ID, then Conditional Access. The Policies page lists every policy and is where you create new ones, run the What If tool, and upload policy files. You need at least the Conditional Access Administrator role to create or edit policies.

What is the difference between Conditional Access and security defaults?

Security defaults are a free, on-or-off baseline that requires MFA registration for everyone, MFA for admins, and blocks legacy authentication and device code flow. They cannot be customized. Conditional Access needs Entra ID P1 and lets you control which users, apps, locations, devices, and risk levels each policy targets. You must disable security defaults before using Conditional Access.

What are Microsoft-managed Conditional Access policies?

They are policies Microsoft creates in eligible tenants, such as requiring MFA for admins and blocking legacy authentication. They start in report-only mode and Microsoft turns them on no less than 30 days later unless you turn them off. You can edit their state and exclusions but cannot rename or delete them.

What does the Conditional Access licensing overage warning mean?

It means your policies cover more users than you have Entra ID P1 or P2 licenses for. The policies keep working, but you are out of compliance with licensing terms. Assign licenses to every user in scope or narrow the scope of your policies.

How do I test a Conditional Access policy without affecting users?

Create every new policy in report-only mode. Report-only logs what would have happened without blocking or prompting anyone. After 7 to 14 days of reviewing the policy impact view and sign-in logs, switch the policy to On. The What If tool also simulates which policies apply to a specific user, app, and set of conditions.

What happens if all my admins get locked out by a misconfigured policy?

This is why every tenant needs two break-glass accounts: cloud-only Global Administrator accounts excluded from Conditional Access. Store the credentials securely offline, alert on every sign-in to them, and test them quarterly. Because they skip your policies, unmonitored break-glass accounts are a gap in a Zero Trust design.

Should I use named locations or trusted IPs?

IP-range named locations are useful for known office networks. Country-based named locations help with travel restrictions. Do not use location as the only grant condition, because attackers can route through VPNs anywhere. Treat location as one signal alongside MFA and device compliance.

How does Conditional Access work with Intune compliance policies?

Intune evaluates each enrolled device against your compliance policies (encryption, OS version, threat level, jailbreak detection) and reports the result to Entra ID. A Conditional Access policy with the “Require device to be marked as compliant” control then allows or blocks access at sign-in. Without the Conditional Access policy, Intune compliance only reports.

How Exodata Helps

Conditional Access is not set-and-forget. New apps, new offices, new device types, and new Microsoft-managed policies all change the picture, so review your policies quarterly. Start with the baseline above in Report-only, validate with What If and the sign-in logs, and enforce one policy at a time, beginning with block legacy authentication.

It is the enforcement layer that makes Zero Trust operational, MFA contextual, and Microsoft 365 security hardening enforceable. Pair it with Intune device compliance so “require a compliant device” actually means something. If you are still migrating from on-premises Active Directory, plan these policies as part of the migration rather than after it.

Exodata designs, tests, and rolls out Conditional Access for SMBs and mid-market teams without the lockouts. Contact us to review your current policies or build a baseline from scratch.