Skip to content

Compliance policies

A compliance policy describes what a trustworthy device looks like: encrypted, up to date, not jailbroken, protected by Defender. Intune evaluates each device against its policies and writes the result to the device object in Entra ID, where Conditional Access uses it to allow or block access.

Create policies under Devices > Manage devices > Compliance.

Tenant-wide compliance settings

Before writing any policy, set these two values under Endpoint security > Device compliance > Compliance policy settings:

Setting Default Recommended
Mark devices with no compliance policy assigned as Compliant Not compliant. Otherwise any device that slips through your assignments counts as compliant.
Compliance status validity period (days) 30 Keep 30 (range 1 to 120). A device that doesn't report compliance within this period becomes noncompliant.

Intune also applies a built-in device compliance policy to every device. It checks that the device has a compliance policy assigned, that it's been in contact with Intune within the validity period, and that the enrolled user still exists and has a license.

What to require, per platform

These are sensible starting points. Tighten them as your estate allows.

Setting Suggested value
Require BitLocker Require
Require Secure Boot Require
Require code integrity Require
Minimum OS version The oldest Windows 11 build you still support, for example 10.0.26100.xxxx
Firewall Require
Trusted Platform Module (TPM) Require
Antivirus and antispyware Require
Microsoft Defender Antimalware, up to date, real-time protection Require
Require the device to be at or under the machine risk score Medium (needs Defender for Endpoint)

BitLocker, Secure Boot and code integrity are reported through device health attestation, which updates at boot. A newly encrypted device may stay noncompliant until it restarts. Since September 2026, supported Windows devices can also request a compliance re-evaluation themselves when signals such as firewall, antivirus, BitLocker or Secure Boot change (client-driven compliance evaluation, in preview).

Only add Windows password settings if you also enforce the same requirements with a configuration profile, and test them with Windows Hello users first.

Setting Suggested value
Minimum OS version Your oldest supported macOS
Require system integrity protection Require
Require encryption of data storage (FileVault) Require
Firewall Enable
Gatekeeper Mac App Store and identified developers
Password Require, with your length and inactivity rules
Setting Suggested value
Jailbroken devices Block
Minimum OS version Your oldest supported iOS/iPadOS
Require a password Require, at least 6 digits
Require the device to be at or under the device threat level Your mobile threat defense level, if you use one
Setting Suggested value
Rooted devices Block
Play Integrity verdict Check basic integrity and device integrity (strong integrity only where devices get timely patches)
Minimum security patch level A date about 2 to 3 months back, reviewed quarterly
Minimum OS version Your oldest supported Android version
Require encryption Require
Require a password Require

Actions for noncompliance and grace periods

Each policy has actions for noncompliance. The first action, Mark device noncompliant, has a schedule in days. That schedule is your grace period: during it, the device shows In grace period and keeps its access.

Action When to use
Mark device noncompliant after 0 days Settings that indicate compromise, such as jailbroken or rooted devices or high Defender risk
Mark device noncompliant after 1 to 3 days Settings users can fix themselves, such as OS updates or a passcode
Send email to end user Day 0, to tell people what's wrong and how to fix it. Customize the template with your support links.
Send push notification Day 0, as a nudge on mobile devices
Remotely lock the noncompliant device Rarely. Disruptive, but useful for lost or abandoned mobile devices.
Add device to retire list After a long period (for example 60 to 90 days), so abandoned devices are flagged for an admin to retire

Split policies by grace period

Because the grace period is per policy, not per setting, put "compromise" settings (jailbreak, threat level) in a separate policy with no grace period, and "hygiene" settings (OS version, password) in a policy with a few days' grace.

How the overall status is decided

A device can have several compliance policies. Intune combines their results by severity, and the most severe wins:

Status Severity
Unknown 1
Not applicable 2
Compliant 3
In grace period 4
Not compliant 5
Error 6

If a setting reports Error, the device keeps its previous compliance state for up to seven days while Intune retries. After seven days of errors it becomes noncompliant, or enters the grace period if the policy has one.

Custom compliance (Windows and Linux)

When Intune doesn't have the check you need, custom compliance lets you write it. You provide two things:

  1. A discovery script (PowerShell on Windows, POSIX shell on Linux) that returns the values to check as compact JSON. Add it under Devices > Manage devices > Compliance > Scripts.
  2. A JSON rules file that says what each value must be, plus the message users see if it fails. Upload it in the compliance policy under Custom Compliance.
Discovery script (Windows)
# Report the installed version of a security agent, or 0.0.0 if it's missing.
$key = 'HKLM:\SOFTWARE\Contoso\SecurityAgent'
$version = (Get-ItemProperty -Path $key -Name 'Version' -ErrorAction SilentlyContinue).Version
if (-not $version) { $version = '0.0.0' }

$result = @{ AgentVersion = $version }
return $result | ConvertTo-Json -Compress
Rules file
{
  "Rules": [
    {
      "SettingName": "AgentVersion",
      "Operator": "GreaterEquals",
      "DataType": "Version",
      "Operand": "7.2.0",
      "MoreInfoUrl": "https://intranet.contoso.com/security-agent",
      "RemediationStrings": [
        {
          "Language": "en_US",
          "Title": "Your security agent is out of date",
          "Description": "Install the latest security agent from Company Portal, then select Check status."
        }
      ]
    }
  ]
}

Supported operators include IsEquals, NotEquals, GreaterThan, GreaterEquals, LessThan and LessEquals. Data types include Boolean, Int64, Double, String, DateTime and Version.

Monitoring compliance

Question Where
How many devices are noncompliant, and why? Devices > Manage devices > Compliance > Monitor tab, and Reports > Device compliance
Which setting is failing on this device? Device > Device compliance, then select the policy
Which devices have no compliance policy? The Devices without compliance policy report
Is the device stuck in Not evaluated? Usually a new enrollment, a device without user affinity, or a DEM-enrolled device. Check that a policy is assigned to a group the device or user is in.

Users can check and refresh their own status in Company Portal (Devices > Check status), which triggers a fresh evaluation.

Learn more