Intune Default Compliance Policy: The Setting That Silently Bypasses Your Conditional Access Device Requirements
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.
This is one of the most commonly overlooked Intune security configurations and one of the most impactful. Organizations build elaborate Conditional Access policies requiring compliant devices, deploy compliance policies across hundreds of endpoints, and then leave one setting at its default that silently makes any device without a policy appear compliant. The fix is a single dropdown change -- but the operational prep before flipping it is what takes work.
Find and Fix the Setting
The setting is in the Intune admin center (intune.microsoft.com) > Devices > Compliance policies > Compliance policy settings > Mark devices with no compliance policy assigned as. The current value is visible immediately. If it shows 'Compliant' -- change it to 'Not Compliant'. This is a tenant-wide setting that applies to all platforms (Windows, iOS/iPadOS, Android, macOS). After the change takes effect (within minutes), any device enrolled in Intune without a compliance policy assignment will show as Not Compliant in the device compliance blade. If those devices are targeted by a Conditional Access policy requiring compliant devices, they will be blocked from accessing the protected resources. This is the correct behavior -- but you need to verify that all devices that should have policies actually have them before flipping the switch, or you will cause an access outage for devices that were silently passing through.
Audit Devices Without Compliance Policies Before Changing the Setting
Before changing to Not Compliant, identify every device that will be affected. In the Intune admin center: Devices > All devices > filter by Compliance: Not evaluated. 'Not evaluated' means no compliance policy has reported a result for that device -- it is in the current bypass window. Alternatively via Graph API: GET /deviceManagement/managedDevices?$filter=complianceState eq 'unknown' or PowerShell: Get-MgDeviceManagementManagedDevice -Filter "complianceState eq 'unknown'" | Select-Object DeviceName, OperatingSystem, UserPrincipalName, EnrolledDateTime. The result is the list of devices that are currently being waved through Conditional Access. For each device in this list: verify whether a compliance policy exists for its platform and OS version, check the assigned groups for the compliance policy and verify the device is in one of those groups, and check for recent enrollment (new devices may simply not have been evaluated yet -- the first compliance check can take up to 8 hours after enrollment). Fix the root cause for each category before changing the default setting.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Common Reasons Devices Miss Compliance Policy Assignment
Understanding why devices end up without policies prevents recurrence. Group assignment gaps: Intune compliance policies are assigned to Entra ID device groups. If a new device category (new PC model, new OS version, BYOD devices) is enrolled but the device does not land in any group covered by the compliance policy, it gets no policy. Verify group dynamic rules: review the Membership rules for each device group receiving compliance policies -- check for OS version conditions that might exclude new Windows 11 versions, device name patterns that miss new naming conventions, or department filters that exclude contractors. Staging groups: IT teams often enroll devices to a staging group during setup, then move them to production groups. If the staging group has no compliance policy and the move to production is delayed or forgotten, the device has no policy indefinitely. Hybrid Entra join race conditions: for hybrid-joined devices, Entra ID join and Intune enrollment can be asynchronous. A device that is Entra-joined but whose Intune enrollment has not completed has no policy yet. Verify hybrid enrollment completion: Get-MgDeviceManagementManagedDevice -Filter "joinType eq 'hybridAzureADJoined' and complianceState eq 'unknown'".
Create a Catch-All Compliance Policy
A best practice alongside setting the default to Not Compliant is creating a minimal catch-all compliance policy assigned to All Devices (or All Users). This policy has minimal requirements -- just the platform minimum acceptable state -- and ensures every enrolled device has at least one policy reporting against it. For Windows: minimum OS build version (set to a build that is at least 2 years old to catch severely outdated systems without blocking modern systems), require BitLocker (if enforced broadly), require Windows Defender real-time protection enabled. Assign to All Devices with All Device Platforms checked. This catch-all ensures no device ever shows as Not Evaluated -- every device gets at least the catch-all policy result. More specific compliance policies (stricter requirements for specific groups) will override the catch-all via the most restrictive result. With the catch-all in place, the 'Not Evaluated' list should be empty, and changing the default to Not Compliant only affects the brief window between enrollment and the first compliance check.
Verify the Change and Monitor Ongoing Compliance
After changing the default to Not Compliant and addressing all Not Evaluated devices: review the Conditional Access sign-in logs for any new failures with the failure reason 'Device is not compliant'. A spike in this failure reason after the change indicates devices that were previously bypassing the check via the default setting. Investigate each new blocked device and determine whether it should have a compliance policy. Monitor the compliance state dashboard: Intune admin center > Reports > Device compliance > Compliance policies trend. Automated alert: use an Intune compliance status workbook (available in the Intune Reports section) or a Logic App querying the Graph API to alert on any sudden increase in Not Compliant devices -- this catches configuration drift where new devices are enrolled without proper policy assignment. Set a recurring check: monthly PowerShell run of Get-MgDeviceManagementManagedDevice -Filter "complianceState eq 'unknown'" to catch any devices that slipped through.
The bottom line
The Intune default compliance setting is a single dropdown that either enforces or silently bypasses your Conditional Access device compliance requirements. Change it to Not Compliant, but audit and fix all Not Evaluated devices first to prevent an access outage. Create a catch-all compliance policy assigned to All Devices to eliminate the Not Evaluated state entirely. This is a 30-minute fix with a 30-minute audit prep window that closes a gap that can persist for months or years in environments that deployed Intune incrementally.
Frequently asked questions
Does this setting affect Entra ID registered (personal/BYOD) devices as well as Intune-enrolled devices?
The 'Mark devices with no compliance policy as' setting applies to Intune-managed devices. Entra ID registered devices that are not Intune-enrolled have no Intune compliance state at all -- they will appear as 'Not compliant' in Conditional Access by default (because Intune has never evaluated them). This is the correct and safe behavior. The dangerous scenario is Intune-enrolled devices that have no policy assigned -- those are the ones showing as 'Not Evaluated' and being silently passed as Compliant by the default setting.
What is the compliance check grace period and how does it interact with this setting?
Compliance policies can be configured with a grace period -- a time window after enrollment or after a device becomes non-compliant before Conditional Access blocks it. The grace period is configured per compliance policy, not via the default setting. The default setting applies specifically to devices that have no policy assigned at all. A device in a grace period still has a policy assigned -- it just has temporary conditional access relief while it comes into compliance. These are different situations with different fixes.
Will changing to 'Not Compliant' break access for Autopilot devices during setup?
Autopilot-enrolled devices go through an OOBE (Out of Box Experience) phase where Intune enrollment and policy evaluation happen sequentially. During setup, before the first compliance check completes, the device has no compliance state. If Conditional Access is enforced during OOBE, this can block the setup flow. The standard mitigation is to exclude the Autopilot provisioning user (a dedicated service account) from the 'Require compliant device' Conditional Access policy, or to use Enrollment Status Page (ESP) to ensure Intune configuration completes before the user-facing OOBE allows access to company resources.
Can I scope the 'Not Compliant' default to specific platforms only?
No. The setting is tenant-wide and applies to all managed device platforms simultaneously. You cannot set Windows devices to Not Compliant by default while leaving iOS devices at Compliant by default. However, you can mitigate the platform-specific impact by ensuring platform-specific compliance policies exist and are assigned before changing the default. For platforms where a compliance policy rollout is not yet complete, assign a permissive placeholder policy to all devices of that platform before changing the default setting.
What Intune compliance policy settings should be in every organization's baseline?
The minimum baseline for Windows compliance: require BitLocker encryption (ensures data at rest protection on all managed endpoints), require Secure Boot enabled (prevents bootkit attacks), require code integrity enabled (WDAC enforcement at boot), require Microsoft Defender Antivirus to be enabled and with a recent signature (within 24 hours), set minimum OS version to the current Windows 10/11 monthly channel release minus 2 versions (prevents use of unpatched systems). For macOS: require FileVault enabled, require Gatekeeper enabled, require minimum OS version. For mobile (iOS/Android): require device encryption, require a screen lock PIN, set maximum allowed OS version lag. These six settings per platform cover the most impactful compliance gaps without creating excessive false positives.
What happens to a device's Conditional Access compliance state when Intune compliance policy evaluation fails due to a connectivity issue?
When a device cannot communicate with Intune to report compliance status, its compliance state transitions to 'Not evaluated' after a grace period, and then to 'Not compliant' after the compliance status validity period expires (default 30 days, configurable in Intune). The Conditional Access policy sees a non-compliant device and blocks access if the policy requires compliant devices. This is by design -- Intune treats loss of compliance reporting as a compliance failure to avoid indefinite access for a device that may have been wiped, lost, or compromised. Practical impact during network outages: devices that cannot reach Intune endpoints become non-compliant after the grace period, potentially blocking users. Mitigation: ensure devices can reach Intune service endpoints from all expected network paths (corporate network, VPN, direct internet). Use Intune's 'Service endpoints' documentation to allow these URLs through corporate proxies. Do not extend the compliance status validity period beyond 30 days to compensate for poor connectivity -- address the connectivity root cause instead.
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.