Microsoft Intune Compliance Policies and Conditional Access: Blocking Non-Compliant Devices from Corporate Resources
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The Intune and conditional access architecture is frequently deployed incompletely: compliance policies are configured, the Intune dashboard shows non-compliant devices, but those devices continue to access Exchange and Teams because no conditional access policy enforces the compliance requirement. The result is a compliance dashboard that reports security problems that are not actually being enforced.
The complete architecture requires both pieces: compliance policies that define the health requirements and conditional access policies that block access from devices that do not meet them. Deploying in report-only mode first reveals the enforcement gap without causing disruption, and the transition to enforcement mode with a grace period prevents legitimate users from being locked out while their devices reach compliance.
Deployment sequence: policy before enforcement
Moving from no compliance enforcement to active blocking requires a staged sequence that identifies impact before applying it. The core risk during deployment is blocking legitimate users on devices that are enrolled and should be compliant but show stale status due to sync issues or a compliance policy misconfiguration. Running conditional access in report-only mode for two weeks surfaces these cases in the sign-in logs before any user is locked out. This section covers the sequence from creating compliance policies through testing and switching to Enabled, including the exclusions that must be in place before enforcement goes live.
Deploy compliance policies and run conditional access in report-only for two weeks before enforcing
Create compliance policies for each device platform (Windows, iOS, Android, macOS) targeting your full device fleet. Create the conditional access policy requiring device compliance but set it to Report-only mode rather than Enabled. For two weeks, review the conditional access sign-in logs filtering for Status: Report-only - Failure to identify sign-ins that would be blocked. Investigate each failure category: devices not enrolled in Intune (unmanaged devices that need enrollment or BYOD exemption), devices with stale compliance status (sync issue requiring Company Portal refresh), and genuinely non-compliant devices (OS too old, encryption not enabled). Resolve the enrollment and stale status issues before switching the policy to Enabled to avoid blocking legitimate users.
Exclude break-glass accounts and enrollment service principals before enabling enforcement
Before switching conditional access to Enabled mode, configure exclusions for accounts that must remain accessible even if the policy misconfigures: break-glass emergency admin accounts that bypass all conditional access, the Intune device enrollment service account, and the Microsoft Intune Enrollment cloud app (which must be excluded from the device compliance requirement to allow new device enrollment). Add these exclusions to the conditional access policy's Exclude section before enabling. Without the enrollment service exclusion, new devices cannot enroll in Intune because the enrollment flow itself is blocked by the policy requiring a compliance status that can only be established after enrollment.
Common misconfigurations and their enforcement gaps
Two specific configuration gaps account for the majority of environments where compliance policies are deployed but non-compliant devices still access corporate resources. The first is a conditional access policy that requires MFA but lacks the device compliance grant condition, which was common in organizations that deployed MFA before Intune and never updated the policy. The second is legacy authentication protocols that bypass conditional access entirely because they predate the modern authentication framework. Both gaps require targeted policy additions rather than changes to the existing compliance policy configuration.
Missing conditional access grant condition produces reports but no blocking
Verify that each conditional access policy protecting corporate applications has Require device to be marked as compliant selected under Grant, not just MFA. A conditional access policy that requires MFA but does not require device compliance allows any device with valid credentials and MFA to access resources regardless of compliance status. The common gap is organizations that deployed MFA conditional access before deploying Intune and never added the device compliance requirement to the existing policy — check every conditional access policy targeting Exchange, SharePoint, and Teams for the device compliance grant condition.
Legacy authentication protocols bypass conditional access entirely
Conditional access policies apply only to modern authentication protocols. IMAP, POP3, SMTP Auth, and Exchange ActiveSync legacy protocols bypass conditional access and allow any device with valid credentials to access mailboxes and send email regardless of compliance status or MFA requirements. Block legacy authentication with a separate conditional access policy that targets All cloud apps, sets the Client apps condition to Exchange ActiveSync clients and Other clients, and blocks access. Monitor the Exchange admin center for mailboxes using legacy protocol connections before blocking to identify applications and devices that will break and need to be migrated to modern authentication.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Intune compliance policy enforcement requires compliance policies that define health requirements AND conditional access policies that block non-compliant devices from corporate resources. Compliance policies without conditional access produce dashboards that show problems but do not fix them. The deployment sequence is: configure compliance policies, add the device compliance grant condition to conditional access in report-only mode, investigate the sign-ins that would be blocked, resolve enrollment and stale status issues, then switch to Enabled with a grace period. Block legacy authentication protocols separately because they bypass conditional access entirely. For BYOD scenarios where full enrollment is not possible, use MAM app protection policies with the require approved client app conditional access grant to enforce data protection at the app layer without requiring MDM enrollment.
Frequently asked questions
How do Intune compliance policies and conditional access work together?
Intune compliance policies define what makes a device compliant: they specify requirements like minimum OS version, BitLocker or FileVault encryption, password complexity, jailbreak detection for iOS, and Microsoft Defender health status. When a device is checked against these requirements, Intune marks it as compliant or non-compliant. Conditional access policies in Azure AD (Entra ID) then use this compliance status as a signal: a conditional access policy with a grant control of Require device to be marked as compliant will block authentication to the targeted applications (Exchange Online, SharePoint, Teams, or all cloud apps) from devices that Intune has marked non-compliant or from devices not enrolled in Intune at all. Both pieces are required for enforcement — compliance policy without conditional access produces reports but no access control, and conditional access requiring compliance without compliance policies means all devices are non-compliant by default.
What should I include in an Intune compliance policy for Windows devices?
A Windows Intune compliance policy should include: minimum OS version requirement matching your patch management target (currently Windows 11 22H2 or 23H2 for new deployments), BitLocker encryption required (Require BitLocker), password requirements including minimum length (8 characters) and complexity, Secure Boot required, Code Integrity required, Microsoft Defender Antimalware and Antivirus enabled, real-time protection enabled, and if you have Defender for Endpoint integration configured, a maximum allowed threat level setting (Medium or Compliant). The most impactful single setting for security is BitLocker required combined with conditional access, as it ensures every Windows device accessing corporate resources has disk encryption enabled.
How do I block jailbroken iOS and rooted Android devices with Intune?
Intune compliance policies for iOS include a Jailbroken devices setting: when set to Block, Intune marks any iOS device that the Company Portal app detects as jailbroken as non-compliant. For Android, the equivalent setting is Rooted devices under Device Health. The Company Portal app performs jailbreak and root detection using a combination of file system checks and API calls that differ between detection versions. Enable these settings in the iOS and Android compliance policy platforms separately, then configure a conditional access policy requiring device compliance for Exchange Online, Teams, and SharePoint to ensure that jailbroken devices are blocked from corporate resources. Note that jailbreak detection can be bypassed by sophisticated users with advanced jailbreaks, so this is a baseline control rather than a guarantee.
How do I configure conditional access to block access from non-compliant devices?
Create a conditional access policy in the Entra ID portal under Security, Conditional Access. Set Assignments to All users (or a specific group), Cloud apps to the applications you want to protect (Exchange Online, SharePoint Online, Microsoft Teams, or All cloud apps for comprehensive coverage). Under Conditions, set Device platforms to the platforms you manage. Under Grant, select Grant access and check Require device to be marked as compliant. Exclude a break-glass account and the Intune enrollment service accounts from the policy scope. Set the policy to Report-only mode first to assess the impact — the sign-in logs will show which sign-ins would have been blocked. Review the report-only results for 1-2 weeks before switching to Enabled to avoid accidental lockout of legitimate users on devices that should be compliant but have a stale compliance status.
How do I handle BYOD devices where users do not want full MDM enrollment?
For BYOD scenarios where users do not want to enroll personal devices in Intune MDM, use app protection policies (MAM without MDM enrollment) combined with conditional access grant controls targeting approved client apps. Configure an Intune app protection policy for iOS and Android Outlook, Teams, and OneDrive that enforces PIN on app open, blocks copy and paste to unmanaged apps, requires encryption, and wipes the managed app data on device retirement. Create a conditional access policy for Exchange Online that grants access with the require approved client app or require app protection policy condition, which allows access from the Outlook app with an app protection policy applied without requiring the device to be enrolled in MDM. This gives users access to corporate email on personal devices while enforcing data protection policies at the app level.
What compliance policy grace period should I configure?
The compliance policy grace period defines how long a device can be non-compliant before it is blocked from resources. A 3-day grace period is appropriate for most organizations: it gives users time to install pending OS updates (the most common compliance failure), allows IT to investigate and resolve MDM agent issues, and prevents helpdesk escalations from users locked out while traveling without reliable internet. For high-security environments, a 1-day grace period is tighter but increases helpdesk load for transient compliance failures. Set non-compliance actions in the policy to send an email notification to the user on day 1 of non-compliance, which gives them advance warning before the access block takes effect on day 3. Configure remote device lock as a non-compliance action for severe violations such as jailbreak detection.
How do I monitor Intune compliance status and investigate compliance failures?
Monitor compliance status in the Intune admin center under Reports, Device Compliance. The Compliance trends report shows compliance percentage over time across your device fleet. The Noncompliant devices report lists each non-compliant device with the specific policy settings that failed. For investigating individual device compliance failures, open the device in Devices, All Devices, select the device, and review the Device compliance page that shows each compliance policy and the specific settings that passed or failed. Compliance check-in occurs when the Intune management extension or Company Portal syncs with the Intune service, typically every 8 hours for enrolled devices. If a device shows as non-compliant for a setting you believe should pass, trigger a manual sync from the Company Portal app on the device and wait for the compliance status to refresh before investigating further.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.