How to configure Intune compliance policies: step-by-step guide for all platforms

This guide covers how to configure Intune compliance policies for every major platform, how to wire them to Conditional Access, and how to monitor compliance across your fleet. For the business case and organizational impact, see Intune compliance policies: what they actually change in your organization.

Prerequisites: what you need before you start

Before creating compliance policies, verify these prerequisites are in place:

Licensing:

• Microsoft Intune (standalone) or Microsoft 365 Business Premium / E3 / E5
• Microsoft Entra ID P1 or P2 (required for Conditional Access integration, included in M365 E3/E5)

Roles required:

• Intune Administrator or Global Administrator to create and assign policies
• Security Administrator or Conditional Access Administrator to configure Entra CA policies

Devices must be enrolled: Compliance policies only apply to enrolled devices. If a device is not enrolled in Intune, the policy cannot reach it. Verify enrollment status in the Intune admin center → Devices → All devices before proceeding.

Know your current fleet state first: Before setting requirements, understand what your devices actually look like today. Check OS versions, antivirus states, and encryption status across your fleet. Setting a compliance requirement that a large portion of your devices already fail will lock out those users on day one, before you’ve had a chance to fix anything.

How to create a compliance policy in Microsoft Intune

Open the Microsoft Intune admin center at intune.microsoft.com. You’ll work primarily in Devices → Compliance.

Step 1: Navigate to compliance policies

1. In the left navigation, select Devices
2. Under Manage devices, click Compliance
3. Select Policies → + Create policy

Step 2: Select platform

Choose the platform this policy applies to:

• Windows 10 and later (covers Windows 10 and Windows 11)
• macOS
• iOS/iPadOS
• Android device administrator or Android Enterprise
• Linux (Ubuntu)

Each platform has its own compliance settings. You’ll create a separate policy per platform.

Step 3: Configure compliance settings

Each platform has its own available settings. Select the tab below that matches the platform you chose in Step 2.

Windows 10/11

Settings are organized across several categories:

Device Health:

Device Properties:

System Security:

Microsoft Defender for Endpoint (if licensed):

With Defender for Endpoint (included in M365 E5), you can add a Machine Risk Score requirement. Devices flagged as High or Critical risk are automatically marked non-compliant, even if all other settings pass.

macOS

System Security:

• Minimum OS version: 15.0 (Sequoia), the oldest version you’re willing to support
• Require password: Yes, minimum 8 characters
• Encryption: Require FileVault

Device Health:

• Require Gatekeeper: Yes (prevents apps from unidentified developers from running)
• System Integrity Protection: Require

iOS/iPadOS

Device Security:

• Minimum OS version: 18.x
• Passcode required: Yes, minimum 6 digits
• Screen lock timeout before passcode required: 5 minutes
• Jailbroken devices: Block

Device Health (requires Defender for Endpoint on iOS):

• Machine risk score: Low or Clear

Android Enterprise

Device Security:

• Minimum OS version: Android 13
• Password type: Numeric complex, minimum 6 digits
• Inactivity before password required: 5 minutes
• Rooted devices: Block

System Security:

• Require encryption of data storage: Yes
• Google Play Protect: Require

Step 4: Configure actions for noncompliance

Marking a device non-compliant does nothing on its own without defining what should happen next.

Click Actions for noncompliance and build an escalation sequence:

The window between Day 0 and Day 7 gives users time to self-remediate without being locked out. Adjust based on your organization’s risk tolerance: tighter for regulated industries, more relaxed for general staff.

Step 5: Define scope tags (optional)

Scope tags control which Intune administrators can see and manage this policy. Use them if your IT organization has separate teams per region or department.

Step 6: Assign the policy

1. Click Assignments
2. Under Included groups, select the Microsoft Entra ID groups this policy applies to
3. Under Excluded groups, add service accounts, kiosk devices, and shared devices that shouldn’t be subject to compliance checks
4. Click Next → Create

“Not evaluated” status after first assignment After you assign a policy to a device group, newly in-scope devices will briefly show a status of Not evaluated in the compliance dashboard. This is normal. It means the device hasn’t completed its first evaluation cycle yet. Intune needs up to 8 hours for the next scheduled check-in, or you can trigger an immediate sync from the Company Portal app. “Not evaluated” is not the same as Non-compliant: these devices are not blocked by Conditional Access. Don’t act on this status until it resolves to Compliant or Non-compliant.

What happens when multiple policies target the same device?

In most environments, users belong to multiple Microsoft Entra ID groups, and compliance policies get assigned to groups. This means a single device can fall under more than one compliance policy at the same time.

Intune’s rule in this case is simple: most restrictive wins. If Policy A requires BitLocker and Policy B doesn’t mention it, the device still must have BitLocker enabled. If Policy A requires minimum OS 10.0.22631 and Policy B requires 10.0.26100, the device must meet the higher requirement. Any individual setting that appears in at least one assigned policy applies in its strictest form.

There is one important exception: if a device has no compliance policy assigned at all, Intune marks it compliant by default. This default can be changed in Compliance → Compliance policy settings → “Mark devices with no compliance policy assigned as”: set this to Not compliant for any production environment. Leaving the default in place means unenrolled or unassigned devices pass Conditional Access silently.

Practical recommendation: Assign at least one baseline compliance policy to all device groups, even if it only enforces encryption and password. Layer stricter policies on top for specific groups such as IT staff, finance, or privileged users. Test group membership carefully before rollout. Overlapping groups are the most common source of unexpected compliance failures.

How to connect compliance policies to Conditional Access

Without a Conditional Access policy referencing the compliance status, Intune evaluates devices but nothing is enforced. This section covers how to connect the two.

Step 1: Open the Entra admin center

Go to entra.microsoft.com → Protection → Conditional Access → + New policy.

Step 2: Name the policy

Use a consistent naming convention: CA-Require-CompliantDevice-AllApps or CA-Block-NonCompliant-M365.

Step 3: Assign users and configure device filters

Under Users, start with a pilot group of 100 to 200 users rather than selecting All users immediately. This lets you validate behavior before org-wide enforcement. Always exclude break-glass emergency access accounts from every Conditional Access policy.

Under Conditions → Filter for devices, you can target (or exclude) specific device types using attribute-based rules. This is useful in mixed environments:

Device filters let you apply different Conditional Access logic to different parts of your fleet without managing separate user groups for each scenario.

Step 4: Assign cloud apps

Under Target resources:

• Start with specific apps: Office 365, SharePoint Online, Exchange Online
• Expand to All cloud apps once behavior is validated

Step 5: Configure grant controls

Under Grant, select Require device to be marked as compliant. Optionally combine it with Require multifactor authentication depending on your risk posture.

Step 6: Test before enforcing: how to read report-only results

Set the policy to Report-only mode for 7–14 days before switching to On. During this window, go to Monitoring → Insights and reporting in the Conditional Access blade and review the impact data daily.

What to look for:

• Users that would be blocked: Any user appearing in the “Failure” column would be denied access if the policy were live. Investigate each account before enforcing.
• Service accounts triggering failures: Service accounts authenticating from servers are never Intune-enrolled and will always appear as non-compliant. Exclude them from this policy, but cover every exclusion with a separate CA policy that enforces compensating controls.
• Unexpected devices: Look for personal devices, kiosk machines, or shared accounts appearing in impact results. Handle each differently:
  • Personal/BYOD devices: Enroll via Intune MDM, or deploy MAM-only App Protection Policies so users access corporate data through managed apps without full enrollment.
  • Kiosk and shared devices: Enroll using Intune’s Shared PC mode or dedicated device mode. Apply device-based compliance policies rather than user-based ones to avoid orphaned compliance states on shared accounts.
  • Shared accounts (generic logins like reception@company.com): Treat like service accounts. Exclude from this policy, but cover the exclusion with a device filter or a separate CA policy enforcing compensating controls.
• App coverage: Verify that the apps you intended to protect (Exchange Online, SharePoint, Teams) appear in the impact results. If an app is missing, check your Target resources assignment.

Switch from Report-only to On only once no legitimate users, service accounts, or business-critical devices remain in the Failure column. The goal is not to decide which accounts to block. It’s to confirm that nothing essential would break.

Observed pattern: The most common Conditional Access misconfiguration is forgetting to handle service accounts and shared accounts on kiosk or frontline devices. Service accounts are non-interactive — they can never be Intune-enrolled and will always appear as non-compliant. Accounts used on shared or kiosk devices face the same problem when the device isn’t properly enrolled.

The second most common mistake is excluding these accounts without any compensating control. An excluded account bypasses the compliant device requirement entirely.

For service accounts: the recommended path is replacing them with Managed Identities, or targeting them with a separate Conditional Access policy for workload identities. If exclusion is unavoidable, restrict access to specific named locations (IP restrictions). MFA is not a valid compensating control for non-interactive accounts — they cannot perform it.

For human shared accounts: pair the exclusion with a separate CA policy enforcing MFA and IP restrictions. For shared devices: enroll them in Intune using Shared PC mode so they can reach compliant status rather than requiring exclusion at all.

An exclusion without a compensating control is a gap, not a solution.

How to monitor compliance status across your endpoint fleet

Compliance dashboard

In the Intune admin center: Devices → Compliance → Overview. This shows:

• Total compliant vs. non-compliant devices
• Platform breakdown
• 30-day trend line
• Top non-compliance reasons

The top non-compliance reasons list is your most actionable view. “BitLocker not enabled” topping the list tells you exactly where to focus remediation first.

Device compliance reports

For detailed exports:

1. Go to Reports → Device compliance
2. Select All devices for a full snapshot
3. Export to CSV for compliance documentation or integration with your reporting tools

Intune advanced analytics (if licensed)

Microsoft Intune Suite includes Advanced Analytics. From July 2026, Intune Suite capabilities are included in Microsoft 365 E3 and E5 at no extra cost:

• Anomaly detection: flags devices with unexpected compliance pattern changes
• Battery and performance health: catches hardware issues before they cause failures
• Device query: run on-demand queries against specific devices to verify configuration state in real time

Compliance alerts

Set up proactive notifications so you don’t rely on manual dashboard checks:

1. Go to Tenant administration → notifications
2. Create alert rules for: newly non-compliant devices, compliance rate dropping below a threshold (e.g., 95%), or sustained non-compliance on priority user accounts

Frequently asked questions

What happens to a device the moment it’s marked non-compliant?

Intune marks the device non-compliant immediately, but the Conditional Access block only activates at the next authentication attempt, typically within minutes. The device keeps working until the user tries to access a CA-protected resource. This is why grace periods matter: users get time to fix the issue before losing access, rather than being blocked silently.

Can I apply compliance policies to personally owned BYOD devices?

Yes, for enrolled BYOD devices, compliance policies apply the same way as they do for corporate devices. For iOS and Android devices that users prefer not to fully enroll in MDM, Microsoft Intune App Protection Policies offer a lighter approach: they enforce data protection within managed apps without requiring full device enrollment or visibility into personal data. This does not apply to Windows. BYOD Windows machines need to be enrolled in Intune before any compliance policy can reach them.

How often does Intune re-evaluate device compliance?

Intune evaluates compliance at enrollment, then rechecks on a scheduled cycle. For Windows, the default interval is every 8 hours. You can trigger an immediate sync from the Company Portal app or from the Intune admin center. Conditional Access re-evaluates the compliance status at every new authentication token request.

Do compliance policies apply to on-premises Active Directory joined devices?

Not directly. Compliance policies require Intune enrollment. For hybrid Microsoft Entra joined devices (joined to both on-premises AD and Microsoft Entra ID), you can use co-management to bring them under Intune compliance. Pure on-premises devices with no Entra join are not reachable by Intune compliance policies.

What’s the difference between a compliance policy and a configuration profile?

A compliance policy checks whether a device meets your requirements and reports a pass/fail used by Conditional Access. A configuration profile actively pushes settings to a device. It turns BitLocker on, rather than checking whether it is on. They work together: configuration profiles enforce the desired state, compliance policies verify it’s in place and block access when it’s not.

Where to start

Open intune.microsoft.com, go to Devices → Compliance → Overview, and check the top non-compliance reasons. That list is your week-one remediation plan. Everything else follows from there.