# Microsoft Intune compliance: design the signal before enforcing access > Intune compliance policies evaluate whether managed devices meet defined requirements. Blocking access requires a coordinated Microsoft Entra Conditional Access policy, suitable licensing, representative testing, and a supportable path back to compliance. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-intune-compliance-design-before-enforcement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:57+00:00 - Modified: 2026-07-19T19:29:33+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Intune compliance policies evaluate whether managed devices meet defined requirements. Blocking access requires a coordinated Microsoft Entra Conditional Access policy, suitable licensing, representative testing, and a supportable path back to compliance. ## Potentially affected Organizations using Microsoft Intune to evaluate Windows, macOS, iOS, iPadOS, Android, Linux, or supported partner-managed device signals for access decisions. ## DSE recommendation Define platform-specific requirements, configure tenant compliance behavior, pilot notifications and grace periods, then test Conditional Access in report-only mode before enforcement. ## Article ## Compliance reports posture; Conditional Access enforces access An Intune compliance policy defines conditions a device must meet and reports the resulting status to Intune and Microsoft Entra ID. Examples can include operating-system version, encryption, password requirements, device health, or a threat level supplied by Microsoft Defender for Endpoint or a supported mobile-threat-defense partner. The available settings vary by platform. Compliance by itself does not automatically block a device from Microsoft 365. Microsoft Entra Conditional Access uses the compliance signal to make an access decision when a policy requires a device to be marked compliant. That separation matters during design and troubleshooting: Intune evaluates the device, while Entra enforces the sign-in control. ## Decide how unknown and failing devices should behave Review the tenant-wide compliance settings before creating platform policies. In particular, decide how devices with no assigned compliance policy should be classified. A permissive choice can admit unmanaged gaps; an immediate restrictive choice can interrupt users before enrollment and assignments are ready. Every compliance policy includes an action that marks a failing device noncompliant. Microsoft documents an immediate default, but administrators can define grace periods and add supported actions such as user email or push notifications, remote lock, or placing a device on a retire list. Not every action is available on every platform. A notification should explain the failed requirement, safe remediation steps, the enforcement time, and how to obtain support. - Inventory device platforms, ownership models, enrollment methods, and business-critical applications. - Create the minimum common requirements first, then add platform-specific controls after measuring the result. - Assign policies to a test group and examine errors, conflicts, devices without a policy, and check-in timing. - Configure noncompliance notifications and a realistic grace period for issues users can fix. - Create the corresponding Conditional Access policy in report-only mode and test managed, unmanaged, compliant, noncompliant, guest, and emergency-access scenarios. - Enforce in phases while monitoring sign-in and compliance reports. ## Confirm licensing and management boundaries Users or devices benefiting from Intune generally require an appropriate Intune license. Device-only licensing has limitations, including no Conditional Access or user-based app protection. Device-based Conditional Access requires eligible Microsoft Entra ID P1 or P2 licensing; risk-based controls require additional P2 capabilities. Exact entitlements depend on the subscriptions and workload, so verify the tenant’s current licensing before promising a control. Compliance is a point-in-time service signal, not proof that a device is permanently secure. Check-in frequency, stale records, duplicate enrollments, operating-system support, and third-party integrations affect the result. Maintain exception ownership, remove retired devices, and test the path from noncompliant back to compliant so enforcement remains both protective and recoverable. ## Official references - [Device compliance policies in Microsoft Intune](https://learn.microsoft.com/en-us/intune/device-security/compliance/overview) — compliance concepts, settings, and platform scope. - [Actions for noncompliant devices](https://learn.microsoft.com/en-us/intune/device-security/compliance/configure-noncompliance-actions) — default timing, grace periods, notifications, and supported actions. - [Microsoft Intune licensing](https://learn.microsoft.com/en-us/intune/fundamentals/licensing) — user, device, and device-only license boundaries. - [Device-based Conditional Access](https://learn.microsoft.com/en-us/intune/device-security/conditional-access-integration/device-based-policies) — Entra licensing and the compliance-signal enforcement flow. ## Primary reference - Name: Microsoft Learn: Device compliance policies in Microsoft Intune - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/intune/device-security/compliance/overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft Intune compliance: design the signal before enforcing access,” DSE Security, https://update.dsesecurity.com/updates/microsoft-intune-compliance-design-before-enforcement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.