Intune compliance policies, and how they feed Conditional Access

Two layers: tenant settings and policies

Intune compliance has a tenant-wide layer and a per-policy layer. The tenant settings are under Endpoint security > Device compliance > Compliance policy settings, and two of them matter a great deal:

• Mark devices with no compliance policy assigned as. The default is Compliant, which means a device nobody has written a policy for is treated as fine. Microsoft says that if you use Conditional Access with compliance, you should change this to Not compliant. Do it at the right moment (see the sequence below), not on day one.
• Compliance status validity period. A device that doesn't report its compliance within this period is treated as not compliant. The default is 30 days, adjustable from 1 to 120.

Below that sit the device compliance policies themselves: one or more per platform, assigned to groups, each with its own rules and its own actions for noncompliance.

What a Windows compliance policy can check

There is also a password section. Microsoft notes that changing password rules affects users at their next sign-in, and users can be asked to change a password even when it already meets the new rule. Add password rules only if you intend to enforce them on every device in scope.

Windows re-evaluates some settings as soon as they change on the device: firewall, antivirus, BitLocker, Defender status, operating system build, real-time protection and Secure Boot. Other settings are picked up at the next check-in.

Mac, iPhone and Android

Each platform needs its own policy, and the checks differ:

• macOS: minimum OS version, a password to unlock, encryption of data storage, firewall and Gatekeeper (where apps may be downloaded from).
• iPhone and iPad: block jailbroken devices, minimum and maximum OS version, require a passcode (Microsoft notes that iOS devices with a passcode are encrypted) and a device threat level from a connected threat service.
• Android Enterprise: separate settings for company-owned devices (fully managed, dedicated, corporate-owned work profile) and for personally owned devices enrolled with a work profile.

Microsoft distinguishes between settings the platform remediates and settings it only reports. On iPhone, a missing passcode is remediated: the user is made to set one. On Windows, missing encryption is not; the device is marked not compliant and, if Conditional Access applies, blocked until it is fixed.

Personal phones that aren't enrolled can't report compliance at all. Most businesses don't need to enrol phones. Where work data on personal phones genuinely needs protecting, app protection is the lighter option; see our optional guide to protecting work data on personal phones.

Actions for noncompliance and grace periods

Every compliance policy includes the action Mark device noncompliant, scheduled at zero days. Changing that schedule is how you give people a grace period. Schedules run from 0 to 365 days and accept quarter-day steps in the admin centre, so 0.25 is six hours. Other actions you can add:

• Send email to end user, from a notification template you create. Intune uses the email address on the user's profile, not their sign-in name, and sends from [email protected], so make sure mail rules don't block it. Microsoft expects these emails within six hours.
• Remotely lock the device (Mac, iPhone and Android, not Windows).
• Add device to retire list. Nothing happens until an admin retires the device from that list.
• Push notification through the Company Portal on iPhone and Android. Microsoft says delivery isn't guaranteed, so don't rely on it for anything urgent.

Because the grace period belongs to the policy, it pays to split rules by how urgent they are. One way to do that is two Windows policies:

A device that misses a monthly update gets a few days and two reminders. A device with an active threat or encryption switched off loses access straight away.

How compliance feeds Conditional Access

When a device enrols in Intune it is registered in Microsoft Entra ID, and its compliance status is reported there. A Conditional Access policy with the grant control Require device to be marked as compliant then allows or blocks access to email, files and other resources based on that status. Points from Microsoft's documentation that shape the rollout:

• Without a compliance policy in Intune, the Conditional Access policy won't work as intended. Microsoft says to create one and have at least one compliant device before you start.
• Requiring a compliant device doesn't block Intune enrolment, so new laptops can still enrol. It also doesn't stop the Authenticator app from registering.
• On iPhone, Android, macOS and some third-party browsers, Entra identifies the device with a certificate, and the user is asked to pick it the first time they sign in through a browser.
• Exclude your emergency access accounts and, if you sync from on-premises Active Directory, the Directory Synchronization Accounts role.
• If you aren't ready to require compliance for everyone, Microsoft suggests intermediate steps: require a compliant device for administrators, or require a compliant device or MFA for all users, and block unknown device platforms.

The order to switch it on

1. Create and assign the compliance policies, leaving "Mark devices with no compliance policy assigned as" on Compliant for now.
2. Watch the reports for a week. Devices > Monitor shows noncompliant devices and setting-level compliance. Fix what you find: devices waiting for a restart after encryption, old Group Policy, stale devices that never check in.
3. Switch "no compliance policy" to Not compliant once every device you care about has a policy and reports.
4. Create the Conditional Access policy in report-only mode: all users, all resources, require a compliant device, with the exclusions above.
5. Review the report-only results for at least a working week, including people who travel or work part time.
6. Turn it on, tell staff what to do if they are blocked, and keep an eye on the noncompliant devices report for the first few days.

The same report-only approach is described in our Conditional Access baseline.

Pitfalls we see

• Turning on Conditional Access before devices report. People get locked out on a Monday.
• Laptops left in a drawer. A device that hasn't checked in within the validity period goes not compliant. If a device hasn't checked in for 30 days or more, the Company Portal can walk the user through re-enrolling it.
• BitLocker shown as not compliant after encryption finishes. Restart it.
• Overlapping policies. When two compliance policies check the same setting, the most restrictive value applies, which can surprise whoever wrote the gentler one.
• Unassigned policies that still apply. A removed compliance policy stays in effect until the device next syncs. That is by design.
• Notification emails that never arrive because the user's profile has no email address, or a mail rule blocks Microsoft's no-reply address.

How 365msp runs compliance

Compliance reporting and device-based access are part of our Intune device management service and our Conditional Access service, both inside the flat $150 per user monthly fee. Every device we manage runs Microsoft Defender for Endpoint Plan 2, the service the machine risk score setting reads from, and its alerts are triaged by our 24/7 cybersecurity remediation SOC.