macOS compliance policies in Intune are shallower than Windows compliance policies. Not broken – just shallower. Knowing where the boundaries are before you design your compliance rules prevents the frustration of configuring requirements the platform can’t actually evaluate.
The available compliance settings for macOS cover the essentials: minimum OS version, FileVault disk encryption, Gatekeeper – which controls whether applications from unidentified developers can run – system integrity protection, firewall state, and password requirements. For environments running Platform SSO and Defender for Endpoint, the device risk score can also be evaluated, with the same inactivity caveats that apply on Windows.
What’s missing compared to Windows is significant. There’s no TPM equivalent check, no secure boot verification, no BitLocker-equivalent recovery key escrow confirmation in the compliance policy itself – FileVault compliance confirms the drive is encrypted but not that the recovery key has been escrowed to Intune. There’s no equivalent to the Windows device health attestation service that validates boot integrity at a hardware level. The compliance signal for macOS is meaningful but narrower than what Windows provides.
macOS compliance in Intune confirms device configuration state – encryption, OS version, firewall. It doesn’t validate boot integrity or hardware security posture the way Windows compliance does. Design your CA policies with that difference in mind.
FileVault is the compliance requirement that matters most on macOS. A Mac without FileVault enabled is a data breach waiting to happen if the device is lost or stolen – just like an unencrypted Windows device. FileVault compliance is straightforward to configure and enforce. The recovery key escrow to Intune – ensuring you can recover access if a user forgets their password – is configured through a separate Endpoint Security policy for FileVault, not through the compliance policy itself. Escrow Buddy, which is included in the intune-my-macs scripts, handles cases where recovery key escrow needs to be validated and rotated.
Minimum OS version is the second meaningful compliance requirement. macOS updates default to user-initiated, and although Declarative Device Management now lets you pace them with deferrals and enforce them with deadlines rather than leaving the timing to the user, Apple still ships frequent security updates that a fleet without that enforcement falls behind on. Requiring a minimum build version in compliance ensures that devices running significantly outdated OS versions can be identified and – when combined with Conditional Access enforcement – restricted until updated. The challenge is that macOS updates can be disruptive for users with specific application dependencies, so the minimum version window needs to reflect your actual update cadence rather than requiring the absolute latest build.
Gatekeeper and system integrity protection are binary settings – enabled or not. They should both be required. Gatekeeper prevents execution of unsigned applications from unidentified developers. System integrity protection prevents modification of protected system files and directories. Disabling either represents a meaningful reduction in security posture that compliance should catch and Conditional Access should respond to.
The same design principles from Phase 6 apply here: validate compliance requirements against your actual device fleet before connecting to Conditional Access enforcement, use a grace period for non-compliance actions that gives users and IT time to remediate, and design separate compliance policies for macOS rather than attempting to apply Windows compliance logic to a platform with different available settings.
Intune Deployment Guide · Phase 11: Mac Management
‹ Previous: [11.2.1] Implementing Platform SSO on macOS with Intune
Next: [11.4] Mac Application Deployment: PKG, DMG, and the App Store ›
