The most common pattern we find when we audit a Microsoft 365 tenant's device security posture is this: Intune is deployed. Devices are enrolled. Compliance policies exist. The Endpoint Manager dashboard shows a healthy mix of compliant and non-compliant devices. And no Conditional Access policy in the tenant actually references device compliance state. Users sign in from compliant laptops, non-compliant laptops, personal phones, and unknown devices, and the access path treats them all the same.
The compliance work was done. The enforcement work was not. The investment in Intune is generating reports nobody acts on, and the security posture leadership thinks they have is materially weaker than the dashboard suggests.
This post is about the specific integration between Intune compliance policies and Conditional Access that turns Intune from a configuration tool into an actual access control. It is one of the highest-leverage gaps we close in tenant audits, and one of the most consistently overlooked even in environments where the rest of the security stack is otherwise well-managed.
If you have not read our post on the Conditional Access mistakes that leave your tenant exposed, the patterns we covered there pair with what follows.
What Intune compliance policies actually do
An Intune compliance policy is a set of rules a device must meet to be considered "compliant." Common requirements:
- Operating system minimum version (Windows 11 23H2 or later, macOS 14+, iOS 17+).
- Disk encryption enabled (BitLocker for Windows, FileVault for macOS).
- Antivirus running and up to date (Microsoft Defender or third-party AV reporting healthy state).
- Firewall enabled.
- Secure boot or device integrity attestation passing.
- Password policy applied (length, complexity, lockout).
- Jailbreak or root detection for mobile devices.
- Specific apps required or prohibited.
- Last check-in within a defined window (e.g., 7 days).
When a device meets every requirement, Intune marks it as compliant. When it fails any rule, Intune marks it non-compliant and (depending on the configuration) gives the user a grace period to remediate before access consequences kick in.
This much, most MSPs configure correctly. Where the chain breaks is what happens next.
The gap: what compliance state does NOT do by default
Marking a device non-compliant in Intune does not, by itself, block the device from accessing anything. The compliance state is data. Without a Conditional Access policy that reads that data and acts on it, the state is informational, not enforcement.
This is the part that surprises many SMB IT teams. The mental model is "Intune says non-compliant, therefore non-compliant device cannot access tenant resources." The actual behavior is "Intune says non-compliant, the device continues to access everything, and nobody is told."
The bridge that turns Intune compliance into actual access control is a Conditional Access policy with the grant control "Require device to be marked as compliant." Without that policy, the entire device management program operates at suggestion-level instead of enforcement-level.
What the integration actually looks like
A correctly configured device compliance enforcement looks like this:
- Intune compliance policy evaluates each enrolled device continuously. Compliant or non-compliant flag is updated in real time.
- Microsoft Entra device record receives the compliance state from Intune. The device's
isCompliantproperty reflects the current status.
- Conditional Access policy is configured with:
- Users: All users (with break-glass exclusions).
- Cloud apps: All cloud apps, or specifically the ones you want to protect.
- Conditions: Device platforms, locations, and client apps as appropriate.
- Access controls: Grant access, Require device to be marked as compliant (OR hybrid Azure AD joined, depending on the architecture).
- At sign-in time, Entra checks the device's compliance state. If compliant, access proceeds. If non-compliant, the user is blocked from the protected resources and presented with remediation guidance.
- The user can remediate (run pending updates, enable encryption, fix the failing condition), the device re-evaluates, and access is restored.
This is the loop. Intune evaluates. Entra records. Conditional Access enforces. The user remediates. The loop closes.
When any link in this chain is missing, the loop is open and the device management investment is producing visibility without consequence.
What goes wrong in the integration
Even in tenants where the basic shape of this integration exists, we see specific failure patterns:
1. The compliance policy and the Conditional Access policy don't agree
A compliance policy might require BitLocker. The Conditional Access policy might require "compliant device." If BitLocker is not actually being enforced because the compliance policy is in audit mode or has a long grace period, devices that should be non-compliant are reporting as compliant, and the Conditional Access policy is granting access based on bad data.
The fix is to verify that compliance policies are actually in active enforcement mode (not just configured), that grace periods are short enough to be meaningful (24-72 hours, not 30 days), and that the rules in the compliance policy match the security requirements the organization is trying to enforce.
2. macOS, iOS, and Android are excluded from the Conditional Access policy
We frequently find tenants where the Conditional Access policy requiring compliant device applies only to Windows. macOS users, iPhone users, and Android users continue to access tenant resources without compliance evaluation. The IT team assumed the policy was universal. The Device Platforms condition was actually scoped to Windows only.
Multi-platform organizations need device compliance enforced across every platform the workforce uses. Each platform requires its own Intune compliance policy. The Conditional Access policy that ties them together should be platform-agnostic or include explicit policies per platform.
3. The policy excludes "modern auth" applications
When the Conditional Access policy is scoped to "all cloud apps" but excludes Microsoft Graph, Microsoft 365 web apps, or "modern authentication clients," the enforcement gap is large. Most actual user activity flows through these applications. Excluding them from compliance enforcement means the policy is technically active but practically inert.
The correct approach is to include all cloud apps with explicit exclusions only for apps that genuinely require non-compliant access (rare) or specific service accounts.
4. BYOD devices treated identically to corporate devices
Personal devices accessing corporate email and Teams need a different posture than corporate-owned laptops. The Intune capability that handles this is Mobile Application Management (MAM) without enrollment: the device is not fully managed, but Intune applies app-level controls (data containerization, copy-paste restrictions, conditional access at app level).
In tenants we audit, BYOD is frequently either fully unmanaged (Conditional Access policy excludes "personal devices" entirely) or fully blocked (no BYOD allowed at all). The middle ground (MAM with app-level CA policies) is rarely deployed even though it is included in Business Premium and above.
5. No alerting on compliance drift at scale
Even with the integration working, compliance status changes over time as users disable updates, swap devices, or work offline. Without alerting on the rate of compliance drift, the IT team learns about problems only when users complain about access. By that point, the same problem usually exists on many devices.
The Intune dashboard surfaces this data. Few teams have a structured weekly review of it. The compliance enforcement is reactive instead of operational.
The deployment sequence that works
For tenants starting from "Intune deployed, no CA enforcement," the sequence we use:
Week 1: Audit current state. Pull the list of all Conditional Access policies and identify which (if any) reference device compliance. Pull the list of all Intune compliance policies and verify each is in active enforcement mode with reasonable grace periods.
Week 2: Create the foundational policy in report-only mode. New Conditional Access policy: "Require compliant device or hybrid Azure AD joined" applied to all users (excluding break-glass) and all cloud apps. Set to report-only. This generates data without breaking production.
Weeks 3-4: Monitor sign-in logs. Filter sign-ins by "Conditional Access result: Report-only failure" and identify which users and devices would have been blocked. For each, decide: is this device legitimately non-compliant (should be blocked when policy enforces) or is the compliance state wrong (compliance policy is too strict, grace period too short, or rule is misconfigured)? Fix compliance policies as needed.
Week 5: Promote to enforce for a pilot group. Move the policy from report-only to enforce, scoped to a pilot group (typically IT staff and one volunteer department, 10-20 users). This catches edge cases without breaking the entire tenant.
Weeks 6-8: Expand the pilot. Add departments incrementally. Each expansion catches a few more edge cases. Communicate clearly with users about what to expect.
Week 9 onward: Full enforcement plus alerting. Move policy scope to all users. Establish weekly review of compliance drift and Conditional Access failures. The integration is now operational.
This sequence takes about 2 months end-to-end for a 200-user SMB. Shorter sequences are possible but produce more support tickets and erode trust in the project.
The link to broader Zero Trust
Device compliance enforcement is one of the foundational controls of a Zero Trust architecture. The principle "verify explicitly" applies to the device just as much as it does to the user. We discussed the broader picture in our post on from patching to risk management and in our overcoming digital crises walkthrough of how Zero Trust controls would have changed the Air-e ransomware outcome.
Without the Intune-to-CA integration, the device side of Zero Trust is a story leadership tells stakeholders, not a control protecting the environment.
How NeoDefender helps
Our Device Protection service treats the Intune deployment and the Conditional Access integration as a single workstream rather than two separate projects. Intune without enforcement is a configuration platform without consequences. The two have to be designed together to deliver the security outcome leadership expects.
If your tenant has Intune deployed but you are not certain whether compliance state is actually controlling access, schedule a Reality Check with the NeoDefender team. We will review your compliance policies, your Conditional Access policies, and the sign-in logs that show whether the loop is actually closing the way the dashboard suggests it is.
