Almost every tenant I review has Intune compliance policies. Far fewer have compliance policies that actually mean anything. A policy that only checks “is this Windows” will mark every device green, and the moment you link it to Conditional Access you are trusting devices you know nothing about.

This guide covers how to build a compliance baseline that reflects real device health, the tenant-wide settings most people never change, and how to roll it out without locking staff out on day one.

What compliance policies do (and do not do)

A compliance policy is a set of rules a device must meet: encryption on, a minimum OS version, a firewall running, a threat level below a threshold. Intune evaluates each enrolled device against its assigned policies and marks it Compliant, Not compliant or In grace period.

Two important points:

• Compliance checks, it does not configure. A compliance policy that requires BitLocker will not turn BitLocker on. You still need a configuration or endpoint security policy that enables it. Compliance is the audit; configuration is the fix.
• Compliance only matters if something uses it. On its own, a noncompliant status is a report. Combined with Microsoft Entra Conditional Access, it becomes an access decision.

Fix the tenant-wide settings first

Before you write any policy, go to Endpoint security > Device compliance > Compliance policy settings in the Microsoft Intune admin center. Two settings here change the meaning of every policy you build.

The first setting is the one I change most often. With the default, a device that slipped through your group assignments is treated as compliant. Microsoft recommends setting it to Not compliant if you use Conditional Access, and I agree. Before you flip it, check the “Devices without compliance policy” report so you know who will be affected.

A Windows compliance baseline that means something

Here is the starting point I use for company-owned Windows devices. Adjust the versions to your environment, but keep the categories.

The Defender for Endpoint risk score is the most valuable line in that table. It ties compliance to live threat detection, so a device with an active high-severity alert drops out of compliance and loses access until the threat is resolved. It requires the Defender for Endpoint connector in Intune and a license that includes Defender for Endpoint or Defender for Business.

Avoid duplicate password rules

Many tenants require a password in the compliance policy and also enforce Windows Hello for Business. On Entra joined devices, password complexity rules in compliance policies can conflict with how users actually sign in. Enforce sign-in requirements through Windows Hello and configuration policies, and keep compliance focused on device health.

Other platforms

Build one policy per platform and keep them consistent in intent:

• macOS: require FileVault, a minimum macOS version, the firewall, and System Integrity Protection.
• iOS/iPadOS: require a passcode, a minimum iOS version, and block jailbroken devices.
• Android Enterprise: require a passcode, encryption, a minimum security patch level, and Play Integrity checks.

For personal phones you may prefer app protection policies instead of enrollment. Those devices will not have a compliance state, so plan Conditional Access accordingly.

Actions for noncompliance and grace periods

Every compliance policy has a default action, Mark device noncompliant, scheduled at zero days. That means immediate noncompliance, and with Conditional Access, immediate loss of access. For most settings that is too abrupt.

1. Mark device noncompliant: set a grace period of 1 to 3 days for settings users can fix, such as a pending OS update. Keep it at 0 for serious issues like a high machine risk score, by putting those settings in a separate policy.
2. Send email to end user: on day 0 or 1, using a notification template that explains what to do and how to get help.
3. Send a reminder: add a second email action a day or two later.

Splitting “must fix now” and “fix this week” rules into separate policies gives you different schedules without weakening either one.

Rolling it out safely

1. Create the policies and assign them to all devices, but do not link Conditional Access yet.
2. Watch the compliance reports for one to two weeks. Fix the devices that fail, usually BitLocker not enabled or old OS builds.
3. Change “Mark devices with no compliance policy assigned as” to Not compliant.
4. Create a Conditional Access policy in report-only mode that requires a compliant device, and review the results.
5. Enforce, starting with a pilot group and then everyone.

Frequently asked questions

Do Intune compliance policies enforce settings on devices?

No. Compliance policies evaluate devices and report whether they meet your rules. To turn on BitLocker, the firewall or Defender, use configuration profiles or endpoint security policies. Compliance confirms those settings worked.

What happens to devices with no compliance policy assigned?

By default they are marked compliant. Change the tenant-wide setting “Mark devices with no compliance policy assigned as” to Not compliant so unassigned devices cannot pass Conditional Access.

How long until a noncompliant device loses access?

It depends on the Mark device noncompliant schedule in the policy. The default is zero days, which is immediate. You can set a grace period in days, and Conditional Access applies once the device is marked noncompliant.

A compliance baseline is the foundation for device-based access control. Our endpoint security baseline service builds the configuration side, Defender for Endpoint supplies the risk signal, and the Intune health check reviews existing policies. Microsoft’s overview is Use compliance policies to set rules for devices you manage with Intune.

Want to know whether your compliance policies would actually stop an unhealthy device? Get a free Microsoft 365 security assessment.