Building a device compliance baseline with Intune

Intune can only judge devices it manages. For company-owned Windows PCs, Windows Autopilot or Microsoft Entra join with automatic enrollment gets new machines into Intune during setup. Company-owned Macs are usually enrolled through Apple Business Manager so enrollment cannot be skipped. Personal phones are a different case: most firms do not enroll them at all and use app protection instead (see our guide on Intune app protection for BYOD).

Before writing policies, get an honest inventory. Every device that reaches email or files should be either enrolled, covered by app protection, or blocked. Devices in none of those groups are your real risk.

You can configure dozens of checks. A baseline that is easy to explain and hard to argue with covers five things:

Two tenant-level settings change how every policy behaves, and they are often left at defaults by accident.

"Mark devices with no compliance policy assigned as" decides what happens to a device that has no policy. If you use compliance in Conditional Access, set this to Not compliant so an unassigned device cannot slip through.

"Compliance status validity period (days)" sets how long a device can go without reporting before Intune treats it as noncompliant. A laptop left in a drawer for a month should have to check in before it touches data again.

On its own, a compliance policy only reports. Enforcement comes from a Conditional Access policy in Microsoft Entra ID that grants access with "Require device to be marked as compliant". Microsoft's template targets all users and all resources, excludes emergency access accounts, and starts in Report-only mode.

Microsoft notes that the compliant-device control does not block Intune enrollment itself, so new devices can still be set up after the policy is on. Phones that are not enrolled need a separate policy: typically "Require app protection policy" for mobile platforms rather than device compliance.

1. 01

   Build compliance policies

   One for Windows, one for macOS, assigned to all users or all devices.

2. 02

   Watch reports for two weeks

   Fix encryption, OS and Defender gaps on the devices that fail.

3. 03

   Create the Conditional Access policy in Report-only

   Review sign-in logs to see who would have been blocked.

4. 04

   Exclude break-glass accounts

   At least one emergency access account stays outside the policy.

5. 05

   Switch to On

   Announce the date in advance and keep IT on hand that morning.

Every compliance policy includes the default action "Mark device noncompliant", scheduled at zero days. You can push that out to give users a grace period, and add actions such as emailing the user, sending a push notification, or adding the device to a retire list.

A short grace period (a few days for encryption or OS updates) and a clear email template saves a lot of help-desk calls. Tell users exactly what to do: restart for updates, open Company Portal, check compliance. Avoid jargon like "device health attestation" in end-user messages.

• Review noncompliant devices weekly; most will be pending updates or offline machines.
• Clear stale device records in Microsoft Entra ID and Intune on a schedule so reports reflect real hardware.
• Re-check the baseline when Microsoft or Apple drop support for an OS version.
• Record exceptions (a lab PC, a kiosk) with an owner and an expiry date rather than excluding them forever.
• Keep the policy settings documented. Cyber insurers and auditors increasingly ask how you enforce encryption and patching, and screenshots from Intune are a good answer.