Key takeaways
- Each platform needs its own compliance policy. Windows, macOS, iOS and Android settings differ, and a policy cannot mix them.
- Intune treats a device with no assigned compliance policy as compliant by default. If you use Conditional Access to require compliant devices, change that tenant-wide setting to Not compliant, or an unmanaged gap becomes an open door.
- A device that fails to report its compliance status within the validity period, 30 days by default and between 1 and 120 days, is treated as noncompliant.
- Every policy marks a failing device noncompliant at zero days. Change that schedule to give users a grace period, and add an email action so they know what to fix.
- Keep the baseline short: encryption, a supported and patched operating system, a screen lock, malware and firewall health on computers, and jailbreak or root detection on phones.
- Compliance does nothing by itself. The access decision happens in Microsoft Entra Conditional Access, so build the compliance policies first, then require them in report-only mode.
What a compliance policy is, and what it is not
Microsoft's definition is short. Compliance policies are sets of rules and conditions that evaluate the configuration of managed devices, so that devices meeting the conditions count as compliant. Intune reports the result, and Microsoft Entra Conditional Access can use it to allow or block access to company resources. A compliance policy checks a device. It does not configure it. Settings you want pushed to devices go in configuration profiles, and some compliance rules can override configuration settings that you also manage, so the two should be planned together.
Set the tenant-wide settings first
Intune has two areas. Compliance policy settings apply to the whole tenant, and device compliance policies apply to groups. Microsoft Learn lists two tenant settings that matter for small fleets.
- Mark devices with no compliance policy assigned as. The default is Compliant, which means the security feature is off and devices that did not receive a policy are considered compliant. Microsoft says that if you use Conditional Access with compliance, change it to Not compliant, so only devices confirmed as compliant can reach your resources.
- Compliance status validity period. The default is 30 days, adjustable from 1 to 120. If a device does not report its status for a policy before the period ends, it is treated as noncompliant. A phone left in a drawer for a month will drop out by itself.
The baseline, platform by platform
Start with settings that reflect real, common risks and that users can fix. The lists below are drawn from what each Microsoft Learn platform page offers.
Windows. Use the Windows 10 and later platform. Require BitLocker, Secure Boot and code integrity under device health. Microsoft notes that BitLocker status is measured at boot, so a device needs a reboot after encryption finishes before it shows as compliant. Set a minimum operating system version. The page also lets you list valid build ranges, which helps when you need to enforce specific patch levels across several Windows releases. Under system security, turn on the Windows firewall requirement, require antivirus registered with Windows Security Center, and require Microsoft Defender Antimalware with a minimum version, current security intelligence and real-time protection. Require a password to unlock.
macOS. Require System Integrity Protection and a minimum operating system version, and set a minimum build version, since Apple security updates usually change the build number rather than the version. Require encryption of data storage, the firewall, and a Gatekeeper setting that limits installs to the Mac App Store and identified developers. Note two details from Microsoft. Compliance evaluation is not supported for userless macOS devices. And requiring a password in a compliance policy automatically expires the existing password for all accounts on the device, including those made by LAPS and Platform SSO, so Microsoft recommends managing device passwords with a settings catalog policy with Change at next auth set to False. Read that warning before you enable the password rule.
iOS and iPadOS. Block jailbroken devices, set a minimum operating system version, and require a passcode with a minimum length and a short time before the passcode is required after the screen locks. If you use a mobile threat defense service, you can require the device to be at or under a chosen threat level. Several of these settings are marked as supported for iOS 17.0 and later in the Learn article, so check the current page for your fleet.
Android. Microsoft states that Android device administrator management is deprecated and no longer available on devices with Google Mobile Services, so build the baseline on Android Enterprise: fully managed, personally owned work profile or corporate-owned work profile. Block rooted devices, require a minimum security patch level in YYYY-MM-DD format, require a password and encryption, and use Google Play Protect checks and a device threat level or Defender for Endpoint risk score if you have those tools. For dedicated devices, such as a shared tablet, target the policy at device groups, not user groups, and use Entra shared device mode if people need to sign in to protected resources.
Grace periods and actions for noncompliance
Every compliance policy has a built-in action, Mark device noncompliant, scheduled at zero days, so a failing device is marked at once and Conditional Access can block it. Microsoft's guidance is that you can change that schedule to give users a grace period in which to fix the problem before they are marked noncompliant. Pick the grace period to match the problem. A device missing an update might get a few days. A rooted or jailbroken phone should get none.
Add more actions to the same policy. Send email to end user uses a notification template you create and goes to the address in the user's profile. Microsoft says notification emails are expected within 6 hours after a device is marked noncompliant, and that your mail rules must not block the sender, microsoft-noreply@microsoft.com. A remote lock action is available on iOS, macOS and several Android management types. An Add device to retire list action marks a device for retirement, but nothing happens until an administrator confirms; retiring removes company data and Intune management. The schedule accepts whole days and fractions in 0.25 steps, so 0.25 means six hours.
A sensible small-fleet schedule is: mark noncompliant after a short grace period, email on day zero, email again a few days later, and review the retire list monthly rather than acting automatically.
The Conditional Access tie-in
Intune compliance only matters when something reads it. Microsoft Learn describes the pairing: Intune evaluates compliance and reports the status to Intune and to Microsoft Entra ID, where Conditional Access policies use it to allow or block access to email, Microsoft 365 services and other apps. Device-based Conditional Access is one of two types, and app-based protection is the other, which suits personal phones where you do not want to manage the whole device.
The order that avoids lockouts is: create and assign the compliance policies, wait until at least some devices report compliant, change the tenant default to Not compliant, then create a Conditional Access policy that requires a compliant device, in report-only mode first. Read the sign-in logs, fix the failures, and only then switch it on. Exclude your emergency access accounts from the policy.
Rollout in four steps
- Group the devices. Make one device group per platform and assign each policy to it, so reports are clean.
- Assign the policies in monitoring mode. Leave the grace period long and the Conditional Access policy in report-only for two weeks.
- Fix the common failures: unencrypted disks, old operating systems, devices that never rebooted, missing passcodes.
- Tighten. Shorten the grace periods, switch the tenant default and enforce the Conditional Access policy.
Our team builds and runs these baselines for small and mid-size organizations, including device enrollment, the notification wording and the Conditional Access rollout.
Sources
- Use compliance policies to set rules for devices you manage with Intune (Microsoft Learn)
- Configure actions for noncompliant devices in Intune (Microsoft Learn)
- Windows 10/11 compliance settings in Intune (Microsoft Learn)
- macOS compliance settings in Intune (Microsoft Learn)
- iOS/iPadOS compliance settings in Intune (Microsoft Learn)
- Android Enterprise compliance settings in Intune (Microsoft Learn)
- Common ways to use Conditional Access with Intune (Microsoft Learn)
This article is general information, not legal or technical advice for your environment. Product menus, license names and provider rules change; check the vendor's current documentation before you act. Last reviewed .
Next article
Next · InfrastructureRPKI and ROAs for Regional Networks: What a ROA Says, Route-Origin Validation and ARIN Hosted RPKIInternet routing was built on trust: a network announces an address block, and its neighbors believe it. The Resource Public Key Infrastructure (RPKI) adds a signed statement of who may originate which prefix. For a regional ISP or any network with its own address space, the first step is small: publish accurate Route Origin Authorizations and then start checking what you receive. This article explains the pieces using ARIN's pages and the RFCs.8 min readRelated reading
- InfrastructureWi-Fi Segmentation for Small Offices: Guest, IoT and Staff Networks, WPA3 and Isolation7 min
- InfrastructureBuilding Systems Security for Property Managers: BACnet/IP, Access Control, Cameras and Vendor Remote Access8 min
Need help with this?
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Managed IT Services