An Intune compliance policy is a set of platform-specific rules that define the minimum security requirements a device must meet to access corporate resources. Rules cover OS version, password requirements, encryption status, firewall state, and threat detection signals. When Intune evaluates a device, it marks it either compliant or noncompliant. That status can then be used by Microsoft Entra Conditional Access to grant or block access to Microsoft 365 apps, Azure, and connected SaaS applications.
- What are compliance policies
- Supported platforms
- How to create a policy
- Security risks
- Auditing with ADAudit Plus
- FAQ
Devices that connect to your corporate network carry risk. A laptop running an outdated OS, a phone without a PIN, or a tablet with encryption disabled can each become an entry point for a breach. Intune compliance policies address this by defining the minimum security bar every managed device must clear.
What are Intune compliance policies?
Intune compliance policies are sets of rules that define the minimum security requirements a managed device must meet. When Intune evaluates a device against its assigned policy, it returns one result: compliant or noncompliant. That status then determines whether the device can access corporate resources.
Rules you can set include requiring a minimum OS version, enforcing disk encryption, mandating a password or PIN, requiring an active firewall, and setting a maximum allowed threat level based on mobile threat defense signals. If a device fails any rule, Intune marks it noncompliant and can trigger a response, from an email notification to a block on resource access.
How Intune compliance works: the two-layer model
Intune compliance is built on two distinct layers that operate independently and affect each other.
Layer 1: Compliance Policy Settings (tenant-wide)
These settings apply across your entire Intune tenant regardless of what per-device policies you create. The most important is the default compliance setting: what happens to a device with no assigned policy?
The default is Compliant: any device without an assigned policy is treated as meeting requirements. This is a deliberate onboarding convenience, but it becomes a security gap in production. Changing it to Not compliant means only devices with an explicitly assigned and passing policy can access resources. You configure this at Endpoint security > Device compliance > Compliance policy settings.
Layer 2: Device Compliance Policies (per-platform)
These are the rule sets you create for specific platforms. A Windows compliance policy checks different things than an iOS policy, so each platform gets its own. You deploy these to user or device groups, and Intune evaluates each device against the rules configured for its platform.
Supported platforms
Compliance policies are platform-specific. You create a separate policy for each operating system you manage.
| Platform | Notes |
|---|---|
| Windows 10 and later | Covers Windows 10 and Windows 11. Supports the widest range of settings: BitLocker, Secure Boot, Windows Defender, and custom compliance via PowerShell scripts. |
| iOS/iPadOS | Covers iPhones and iPads enrolled in Intune. Settings include jailbreak detection, minimum OS version, and passcode requirements. |
| Android Enterprise | Covers corporate-owned and personally owned Android devices. Profile type (fully managed, work profile, etc.) determines available settings. |
| macOS | Covers Mac devices enrolled in Intune. Settings include minimum OS version, password requirements, FileVault encryption, and Gatekeeper. |
| Linux | Supports Ubuntu Desktop 22.04 LTS and 24.04 LTS, and Red Hat Enterprise Linux 8 and 9. Available compliance settings are limited to: allowed distributions, device encryption, password policy, and custom compliance scripts. Configuration policies and app deployment are not supported on Linux. |
Note
Different platforms support different compliance settings. A setting available for Windows may not be available for iOS. When planning your compliance baseline, check platform-specific documentation to confirm which rules apply to each device type.
Intune compliance and Conditional Access
A compliance policy on its own tells you whether a device is compliant. Conditional Access decides what happens to a noncompliant device. Intune evaluates compliance and passes the device status to Microsoft Entra ID, which then applies Conditional Access policies to grant, block, or restrict access.
When Conditional Access requires a compliant device, noncompliant devices are blocked from Microsoft 365 apps, Azure resources, and connected SaaS applications until they remediate. Without Conditional Access, a noncompliant device receives a notification but is not blocked from anything. Conditional Access requires a Microsoft Entra ID P1 or P2 license.
BYOD and personally owned devices
For personally owned devices enrolled in Intune MDM, compliance works the same way as for corporate-owned devices. For personally owned devices not enrolled in Intune MDM, full device compliance cannot be reported. In these cases, use Intune App Protection Policies combined with app-based Conditional Access, which protects corporate data at the application level without requiring full device enrollment.
How to create a compliance policy in Intune
The following steps create a device compliance policy. The process is the same for all platforms: the available settings differ after you select a platform.
Step 1: Open the policy creation wizard
intune.microsoft.com.
Devices > Compliance, then select Create policy.
Create.
Step 2: Basics
- Enter a name that makes the platform and purpose clear, for example: 'Windows – Security Baseline' or 'iOS – Corporate Devices.' Add a description. Select Next.
Step 3: Compliance settings
Expand the available categories and configure the rules. Common settings across platforms:
| Settings category | Examples of what you can configure |
|---|---|
| Device Health | Require BitLocker and Secure Boot (Windows); jailbreak detection (iOS/Android). |
| Device Properties | Minimum and maximum OS version; valid OS build ranges. |
| System Security | Password required, minimum length, complexity; firewall required; antivirus and antispyware required. |
| Microsoft Defender for Endpoint | Maximum allowed machine risk score. Requires Defender for Endpoint integration. |
| Custom Compliance (Windows) | Rules defined by a PowerShell detection script and JSON file, used for third-party app versions or non-standard settings. |
Step 4: Actions for noncompliance
Configure what happens when a device fails the policy. See the next section for available actions. Select Next.
Step 5: Assignments
- Select the user or device groups the policy applies to under Included groups.
- Add exclusion groups for devices or users that need exceptions.
- Select Next, review your settings, then select Create.
The policy takes effect when enrolled devices check in with Intune, typically within 15 minutes to eight hours depending on device type and check-in frequency. Users can trigger an immediate sync from the Company Portal app.
Actions for noncompliance
Every compliance policy includes at least one action: marking the device noncompliant immediately. You can add further time-ordered actions that run after the device remains noncompliant for a defined period.
| Action | What it does |
|---|---|
| Mark device noncompliant | The default immediate action. Sets noncompliant status. If Conditional Access is configured, this triggers access restrictions. |
| Send email to end user | Notifies the user. You can customise the message, include remediation steps, and set a delay (for example, send after three days of noncompliance). |
| Send push notification | Sends a notification to the Company Portal app on the device. |
| Remotely lock device | Locks the device. Useful for devices that remain noncompliant after a grace period. |
| Retire device | Removes company data and unenrols the device from Intune. Use as a final action for persistently noncompliant devices. |
| Add device to retirement list | Queues the device for retirement without immediately retiring it, giving an admin time to review before the action runs. |
A well-designed noncompliance sequence runs in order: mark noncompliant immediately, send an email after three days, send a reminder after seven days, retire after 30 days. This gives users time to remediate without requiring manual admin intervention at each step.
Should compliance policies be assigned to users or devices?
Intune allows you to assign compliance policies to user groups or device groups. The right choice depends on how you want to scope enforcement.
Assign to user groups when:
The policy follows the person: any device the user signs into must pass the policy. This is the standard choice for knowledge workers. If a user signs into a noncompliant device, Conditional Access can block that sign-in.
Assign to device groups when:
Rules apply to the device regardless of who is signed in. Use this for shared devices, kiosks, and dedicated workstations. It is also required for devices enrolled without a primary user.
What is the precedence of compliance policy in Intune?
When a device receives multiple compliance policies (because it belongs to several groups, each with a different policy), Intune uses the more restrictive rule for any conflicting settings. If one policy requires Windows 11 22H2 and another requires 22H1, Intune treats 22H2 as the requirement. A device running 22H1 is noncompliant. Multiple overlapping policies effectively merge into the strictest possible ruleset.
The default compliance behavior (from the tenant-wide settings) only applies to devices with no assigned policy. Once any policy is assigned, the default no longer applies to that device.
Security risks when compliance policies are misconfigured or bypassed
Compliance policies are only effective when they are correctly configured, actively enforced, and regularly audited. These are the most common scenarios where they fail.
Default compliance setting left as 'Compliant'
If the tenant-wide default remains at Compliant, any device without an assigned policy passes all Conditional Access checks. In a large organization, new devices, contractor endpoints, and recently enrolled devices can go unassigned. An attacker who enrolls a device and avoids policy assignment gains unrestricted access to corporate resources.
Policies assigned only to specific user groups
Devices that belong to no assigned group (shared workstations, service accounts, guest devices) are not evaluated. If Conditional Access checks device compliance, an unassigned device may be treated as compliant depending on the default setting.
Conditional Access not enforcing compliance status
A compliance policy without Conditional Access enforcement is advisory only. It marks devices noncompliant but does not restrict access. Many organizations configure compliance policies without completing the Conditional Access integration, leaving noncompliant devices able to reach corporate resources.
Unauthorized changes to compliance policy rules
An attacker with access to an Intune admin account can weaken compliance policies, removing encryption requirements, lowering OS version thresholds, or disabling firewall checks, without triggering any alert. The change takes effect on the next device check-in, and previously noncompliant devices may suddenly pass. Without an audit trail, these changes are difficult to detect.
Grace period exploitation
Actions for noncompliance include grace periods before access is blocked. An attacker operating from a recently noncompliant device may have hours or days of continued access. Shorter grace periods on high-risk actions, combined with real-time alerting on compliance status changes, reduce this window.
Detecting unauthorized changes requires monitoring the Intune audit log for activity in the Compliance category: policy creation, modification, and assignment changes. ManageEngine ADAudit Plus tracks every change made to Intune compliance policies, alerts administrators in real time when settings are modified, and shows before-and-after values so you can see immediately what changed and who changed it.
Auditing Intune compliance policy changes with ADAudit Plus
ManageEngine ADAudit Plus monitors Intune compliance policy changes in real time and captures the full audit record: who made the change, which policy was affected, what the old setting was, and what it is now. You can configure alerts so that any modification triggers an immediate email or SMS notification to your security team.
What ADAudit Plus tracks
With ADAudit Plus, you can monitor and report on:
- Compliance policy creation: who created a new policy, which platform it targets, and when
- Policy modification: setting changes with before-and-after values, including OS version thresholds, encryption requirements, and password rules
- Policy deletion: which policy was deleted and by which account
- Assignment changes: when a policy is assigned to or removed from a user or device group
- Actions for noncompliance changes: modifications to email notifications, grace periods, remote lock, or retire actions
- Tenant-wide compliance setting changes: changes to the default compliance behavior (Compliant vs Not compliant)
How ADAudit Plus extends native Intune compliance monitoring
| Capability | Native Intune admin center | ADAudit Plus |
|---|---|---|
| Policy change alerts | No real-time alerts: must manually check audit logs | Real-time email and SMS alerts on any compliance policy change |
| Before-and-after values | Target(s) field in audit log | Side-by-side old and new values in report view |
| Log retention | 2 years | Configurable archive beyond the 2-year limit |
| Compliance reports | No pre-built reports for SOX, HIPAA, PCI DSS | Out-of-the-box reports for SOX, HIPAA, PCI DSS, GDPR, FISMA, GLBA |
| Cross-platform visibility | Intune portal changes only | Unified view of Intune, Entra ID, on-premises AD, file servers, and workstations |
A one-stop solution for IT auditing, compliance, and threat response
Try ADAudit Plus free for 30 days. No credit card required.
Frequently asked questions
The default compliance policy is a tenant-wide setting that determines how Intune treats devices that have not been assigned any device compliance policy. By default, the setting is Compliant: any device with no assigned policy is considered to meet all requirements and can pass Conditional Access checks.
This default exists to prevent unintended lockouts during rollout, but it is a security risk in a live environment. Changing it to Not compliant means only devices with an explicitly assigned and passing policy can access corporate resources. Configure this at Endpoint security > Device compliance > Compliance policy settings in the Intune admin center.
The Intune standard compliance policy refers to the built-in default device compliance policy that Microsoft Intune maintains for each tenant. Unlike policies you create yourself, this is the tenant-wide baseline that applies when no other policy is assigned to a device. By default it marks unassigned devices as compliant. Changing this default to Not compliant is recommended for any production environment. It ensures that every managed device must have an explicitly assigned and passing policy before it can access corporate resources.
A typical Windows compliance policy for a corporate environment includes: minimum OS version Windows 11 23H2, BitLocker encryption required, Secure Boot required, Windows Defender antivirus required and active, firewall required, minimum password length of eight characters, and a maximum device threat level of Medium based on Microsoft Defender for Endpoint signals. Any device failing one or more of these rules is marked noncompliant and, if Conditional Access is configured, loses access to corporate resources until it remediates.
For iOS, an equivalent policy might require a minimum OS version of iOS 17, jailbreak detection enabled, a passcode required, and a maximum threat level from a mobile threat defense partner.
A grace period in Intune compliance is the time you configure before an action for noncompliance takes effect. When you set up actions (such as sending an email or locking the device), you specify a delay in days. A device marked noncompliant immediately triggers the zero-day action (marking it noncompliant), but subsequent actions like email notifications, remote lock, or device retirement only run after the configured delay has passed.
For example, you might configure: mark noncompliant on day zero, send an email reminder on day three, send a second reminder on day seven, and retire the device on day 30. This gives users time to remediate a failing condition (updating the OS, enabling encryption, or setting a PIN) without immediately losing access. Shortening grace periods on high-risk actions reduces the window an attacker has if operating from a noncompliant device.
A device is marked noncompliant when it fails one or more rules in its assigned compliance policy. Common causes include running an OS version below the minimum required, having encryption disabled (BitLocker on Windows or FileVault on macOS), not having a password or PIN configured, a firewall that is turned off, antivirus that is inactive or out of date, and a threat level from Microsoft Defender for Endpoint that exceeds the maximum allowed in the policy.
A device can also enter a noncompliant state if it has not checked in with Intune within the compliance validity period, a configurable window after which Intune treats an unresponsive device as noncompliant. Additionally, a device with no assigned compliance policy is treated as compliant or noncompliant depending on the tenant-wide default setting.
Sign in to the Microsoft Intune admin center and go to Devices > Compliance. This shows all policies, their platform, the number of assigned devices, and current compliance status. Select any policy to see its settings, assignments, and a per-device compliance report.
To view compliance status for a specific device, go to Devices > All devices, select the device, then select Device compliance under Monitor. To view compliance policy changes in the audit log, go to Tenant administration > Audit logs and filter by the Compliance category.
A compliant device has been evaluated against its assigned compliance policy and meets all configured rules. A noncompliant device has failed one or more rules. When integrated with Conditional Access, a noncompliant device can be blocked from corporate resources until it remediates the failing condition.
A third status, Not evaluated, applies to devices that have enrolled but not yet reported their compliance status, or devices that have not checked in within the validity period. Intune treats these as noncompliant once the validity period expires.
This is covered in full in the 'Should compliance policies be assigned to users or devices?' section above. In short: assign to user groups when you want the policy to follow the person across any device they sign into; assign to device groups for shared devices, kiosks, and devices enrolled without a primary user.
Experience
ADAudit Plus for free
With ADAudit Plus, you can:
- Get full visibility into logons
- Monitor employee attendance
- Detect attacks like Kerberoasting
- Generate logon audit trails
- And much more
