Create Device Compliance Policies in Microsoft Intune: Complete Setup Guide

Device compliance policies are the foundation of endpoint security in Microsoft Intune. They establish baseline requirements that devices must meet to access your organization's resources—from OS versions and encryption standards to password complexity and threat detection levels. When a device falls out of compliance, Intune can automatically trigger remediation actions, from sending user notifications to blocking access entirely. This guide walks you through creating, configuring, and verifying a production-ready compliance policy from start to finish.

What You'll Configure

By the end of this walkthrough, you will have created a complete device compliance policy that:

• Defines minimum OS versions and security baselines for a target platform (Windows, iOS, Android, macOS, or Linux)
• Enforces encryption, password requirements, and device threat levels
• Triggers noncompliance actions—including grace periods, email notifications, and access blocks
• Assigns the policy to user or device groups for automated evaluation
• Reports real-time compliance status back to the Intune dashboard

Prerequisites: Active Intune subscription, Global Administrator or Intune Administrator role, at least one device already enrolled in Intune, and target user or device group created in Microsoft Entra ID.

Step-by-Step Configuration

1. Access the Intune Admin Center and Navigate to Compliance

   Open the Microsoft Intune admin center at https://intune.microsoft.com. On the left sidebar, select Devices → Manage devices → Compliance. You will see a list of existing compliance policies (if any). Select the Create policy button.

   

2. Select Your Target Platform

   A panel will open asking you to choose a platform. Select the operating system for which you are creating this policy:

   • Android Device Administrator (deprecated for GMS devices; migration recommended)
   • Android Enterprise (recommended for modern Android)
   • iOS/iPadOS
   • macOS
   • Windows
   • Linux

   For this example, we'll use Windows. Once selected, click Create.

   [SCREENSHOT: Platform selection dialog with radio buttons for Android, iOS, macOS, Windows, Linux]

3. Configure Basic Policy Properties

   You are now in the policy creation wizard. On the Basics tab:

   • Name: Enter a descriptive name (e.g., "Windows 11 Security Baseline – Production").
   • Description (optional): Add context for your IT team (e.g., "Enforces Windows 11 21H2+, BitLocker, and MFA-ready credentials").

   Clear naming is crucial for auditing and long-term policy management. Click Next to continue.

   [SCREENSHOT: Basics tab with Name and Description fields filled in; Next button at bottom]

4. Configure Compliance Settings for Your Platform

   You are now on the Compliance settings tab. This is where you define the rules devices must meet. The available settings vary by platform. For Windows, common settings include:

   • Minimum OS version: Set to your minimum supported version (e.g., Windows 11 21H2, Windows 10 22H2).
   • Encryption: Require BitLocker or equivalent (toggle to Require).
   • Password minimum length: Set to 8 or 12 characters.
   • Password complexity: Require uppercase, lowercase, numbers, and symbols.
   • Device threat level: If using Mobile Threat Defense (MTD), set maximum acceptable threat level (Low, Medium, High).
   • Jailbreak/root detection: Detect if device is rooted (applicable to Android/iOS).

   Expand each category in the left panel and toggle settings to Require or Not required based on your security posture. For production environments, we recommend enabling encryption and OS version checks at minimum.

   [SCREENSHOT: Compliance settings tab showing expanded categories: 'Device Security', 'Encryption', 'Password', 'Threat Management' with toggles and version dropdowns]

5. Add Custom Compliance Rules (Windows & Linux Only)

   ADVANCED If you need to enforce organization-specific checks beyond the built-in rules, you can add Custom Compliance settings. This requires a PowerShell discovery script (Windows) or bash script (Linux) uploaded to Intune beforehand.

   Important: Discovery script output is limited to 2048 characters. If your script outputs more, it will fail with error 65009. Test locally first.

   To add custom compliance:

   1. In the Compliance settings tab, expand the Custom Compliance section.
   2. Set Custom compliance to Require.
   3. Click Click to select and choose your pre-uploaded discovery script (e.g., "Check-SecurityBaseline.ps1").
   4. Upload the JSON rules file by clicking the folder icon.
   5. Intune will validate the JSON automatically; any syntax errors will display on-screen.
   6. Once valid, the rules populate in a table for review.
   [SCREENSHOT: Custom Compliance section with script selector and JSON file upload dialog; validation success message]

6. Configure Actions for Noncompliance

   Now select the Actions for noncompliance tab. This is where you define what happens when a device fails a compliance check.

   Default action: "Mark device noncompliant" is always applied—you cannot disable it. This immediately sets the device's status to NonCompliant in the Intune dashboard.

   Add additional remediation actions in sequence:

   • Send email notification: Notify the user that their device is noncompliant. Configure:
     • Recipients (user, IT contact, etc.)
     • Email template / custom message
     • Schedule (immediate, daily, weekly, or after grace period)
   • Block access to organizational resources: Enforce via Conditional Access (requires Entra ID P1/P2).
   • Retire the device: Remove the device from Intune management (last resort).

   Grace Period: Configure a grace period (e.g., 1 day, 7 days) to allow users time to remediate before enforcement kicks in. During this window, the device shows InGracePeriod status but is not yet blocked.

   [SCREENSHOT: Actions for noncompliance tab showing action tiles: Mark Noncompliant, Send Email (with grace period slider), Block Access, Retire Device]

7. Apply Scope Tags (Optional)

   On the Scope tags tab, select tags to control which administrative teams can see and manage this policy. This is useful for delegated administration in large organizations. If you do not use scope tags, the policy is visible to all admins with appropriate RBAC roles. Select Next to proceed.

   [SCREENSHOT: Scope tags tab with available tags listed; checkboxes for selection]

8. Assign the Policy to Groups

   On the Assignments tab, select Add groups to choose which users or devices will be subject to this policy.

   Critical Note for Linux: Only device group assignments are supported for Linux compliance policies. User-based assignments will fail silently.

   For other platforms:

   • Select User groups to apply the policy to all devices owned by those users.
   • Select Device groups to target specific devices by group membership.

   After selecting groups, choose Include or Exclude to refine scope. The policy will deploy to assigned devices on their next check-in (usually within 1 hour for active devices).

   [SCREENSHOT: Assignments tab with 'Add groups' button; group selection pane showing user and device groups with checkboxes]

9. Review and Create the Policy

   On the Review + create tab, verify all your settings:

   • Policy name and description
   • Platform and compliance rules
   • Noncompliance actions and grace periods
   • Assigned groups

   If everything looks correct, select Create. The policy is now active and will begin evaluating assigned devices on their next check-in.

   [SCREENSHOT: Review + create tab with summary cards for each section; Create button at bottom]

Understanding Compliance Status States

After your policy is deployed, devices will report one of six compliance states. Understanding these states is essential for troubleshooting and auditing.

Verification

Visual Verification in Intune

1. Navigate to Devices → Manage devices → Compliance.
2. Select your newly created policy by name.
3. On the Overview tab, you will see a dashboard showing:
   • Compliant (green): Device count meeting all requirements
   • InGracePeriod (yellow): Device count in grace window
   • NonCompliant (red): Device count violating policy
   • Unknown (gray): Device count not yet evaluated
4. Select Device compliance status to see individual device states and last check-in time.
5. For detailed remediation history, select a device and view the Noncompliance status tab.

PowerShell / Graph API Verification

To verify policy compliance status programmatically, use the Microsoft Graph API:

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes DeviceManagementConfiguration.Read.All

# Get all device compliance policies
Get-MgDeviceManagementDeviceCompliancePolicy | Select-Object -Property Id, DisplayName

# Get compliance status for a specific policy
$policyId = "YOUR-POLICY-ID-HERE"
Get-MgDeviceManagementDeviceCompliancePolicy -DeviceCompliancePolicyId $policyId

# Get device compliance details (requires beta endpoint)
Get-MgBetaDeviceManagementDeviceComplianceDeviceStatus -DeviceCompliancePolicyId $policyId | Select-Object -Property DeviceDisplayName, Status, LastReportedDateTime

Example output:

# Device compliance status from Graph API
DeviceDisplayName        Status           LastReportedDateTime
LAPTOP-JD2K9X1A          compliant        2026-05-10T14:32:18.000Z
WIN-MARKETING-02        noncompliant     2026-05-10T13:45:06.000Z
DEVICE-GRACE-PERIOD     inGracePeriod    2026-05-10T14:18:22.000Z

Common Issues and Troubleshooting

1. Devices Remain in "Unknown" Status for Hours

Symptom: Newly assigned devices show "Unknown" compliance status even after 2+ hours.

Cause: Devices check in on a staggered refresh cycle (typically 1–4 hours depending on platform). New enrollments may take longer on first sync.

Fix:

• Ask the user to manually sync the device via the Company Portal app ("Sync" button).
• For Windows: Open Settings → Accounts → Access work or school → select device → Info → Sync.
• For iOS: Open Company Portal app → Devices → select device → Check settings.
• For Android: Open Company Portal app → Devices → select device → Check device settings.
• Wait 10–15 minutes after manual sync; status should update.

2. Custom Compliance Script Fails with Error 65009

Symptom: Devices show "Error" status after deploying a custom compliance policy. Admin audit logs show error code 65009.

Cause: PowerShell discovery script output exceeds 2048 characters. Intune cannot parse the JSON response.

Fix:

• Test your discovery script locally. Pipe output to Write-Host and count character length:

  $output = & .\MyScript.ps1
  [int]$length = ($output | Measure-Object -Character).Characters
  Write-Host "Output length: $length characters"
  

  Copy
• If output exceeds 2048 characters, reduce verbosity:
  • Output only pass/fail results, not full registry dumps.
  • Compress JSON keys (use "v" instead of "version").
  • Split large rule sets into multiple compliance policies.
• Re-upload the corrected script and republish the policy.

3. NonCompliant Devices Are Not Being Blocked in Conditional Access

Symptom: Devices show "NonCompliant" in Intune, but users can still access Exchange Online and SharePoint.

Cause: Compliance policies alone do not block access. You must configure a Conditional Access policy that references the device compliance status. Additionally, Conditional Access requires Microsoft Entra ID P1 or P2 licensing.

Fix:

• Navigate to Microsoft Entra admin center (https://entra.microsoft.com).
• Go to Protection → Conditional Access → New policy.
• Configure:
  • Assignments: Target cloud apps (Exchange Online, SharePoint, Teams, etc.).
  • Conditions: Leave device platforms unchecked to apply to all.
  • Device state: Set to Require device to be marked as compliant.
  • Grant controls: Select Require compliant device or Require approved client app.
  • Enable policy: Set to On.
• Verify that target users have Entra ID P1/P2 licensing assigned.
• Test with a non-compliant test device to confirm the block is working.

4. Linux Devices Fail Assignment (User-Based Assignment)

Symptom: Linux devices do not receive the compliance policy even after user group assignment.

Cause: Linux compliance policies support device group assignments only. User-based assignments are not supported and fail silently.

Fix:

• Remove all user group assignments for the policy.
• Create a device group in Microsoft Entra ID containing the target Linux devices.
• Re-assign the compliance policy to the device group.
• For supported Linux versions, ensure devices are running Ubuntu 24.04 LTS, 26.04 LTS, RHEL 8, or RHEL 9.

5. Android Device Administrator Policy (Deprecated Devices)

Symptom: You have legacy Android Device Administrator (DA) enrolled devices with Google Mobile Services (GMS), and compliance policies are not applying.

Cause: Android Device Administrator management is deprecated for GMS devices. Microsoft no longer issues new compliance rules for DA-enrolled devices.

Fix:

• Plan migration from DA to Android Enterprise (fully managed or work profile).
• Unenroll existing DA devices and re-enroll under Android Enterprise framework.
• Create new compliance policies targeting Android Enterprise instead.
• For a transition timeline, contact Microsoft Support or consult your Intune licensing agreement.

Best Practices and Recommendations

Quick Reference: Compliance Policy Lifecycle

Updated May 10, 2026 – This guide reflects current Intune platform behavior, including Android Device Administrator deprecation and Linux compliance support. For the latest changes, consult the official Microsoft Intune compliance documentation.