The most common compliance policy failure I see isn’t misconfiguration – it’s compliance theater. Rules that look thorough on paper but don’t actually reflect meaningful trust requirements. Environments where the compliance dashboard is green, but the signal feeding Conditional Access is too weak to tell the difference between a healthy device and a compromised one.
The question compliance rules should answer is specific: what does a device need to demonstrate for us to trust it with access to corporate resources right now? Not what would look good in an audit. Not what the default template suggests. What actually reflects your minimum bar for trust, given what you know about your environment and your risk tolerance.
That question is harder than it sounds, because the temptation is to add everything available. Require BitLocker. Require a minimum OS version. Require Defender. Require a PIN. Require real-time protection. Require the machine risk score to be clear. All of those requirements have merit. Some of them, applied without thought, produce constant non-compliance for reasons that have nothing to do with actual risk – and a non-compliance signal that fires constantly trains everyone to ignore it.
A compliance policy that marks half your devices non-compliant for spurious reasons isn’t strict – it’s broken. The signal becomes noise, and noise gets ignored.
The requirements worth enforcing in most environments fall into a short list. BitLocker encryption – a device without disk encryption is a data breach waiting to happen if it’s lost or stolen, and silent enablement through Intune makes this a low-friction requirement for modern hardware. A minimum OS build – not always the absolute latest, but within a defined window that reflects your patching cadence. Defender Antivirus active and reporting – not as a proxy for full security, but as a baseline signal that the device’s core protection is running.
The Defender for Endpoint machine risk score is worth addressing specifically because it’s frequently recommended and frequently problematic in practice. The concept is sound – wiring real threat detection directly into compliance decisions is architecturally correct. The operational reality is that devices inactive for seven days or more stop reporting to Defender’s active monitoring window, and Intune marks them non-compliant even when nothing is actually wrong. At scale this produces a steady stream of spurious non-compliance events from users returning from leave, devices that weren’t powered on over a long weekend, or laptops sitting in a bag during travel. The signal becomes noise, and noise gets ignored or suppressed – which defeats the purpose entirely. I rarely use the MDE risk score as a compliance requirement for this reason. If you do use it, validate the inactivity behavior in your environment thoroughly before connecting it to Conditional Access enforcement.
Requirements that often create more noise than signal: requiring the absolute latest OS build in environments with any deferral configured, requiring specific firewall states that can be disrupted by VPN clients or network configuration tools, requiring third-party security tools that have their own update and reporting cadences outside your control. These aren’t wrong requirements – they may be exactly right for your environment – but they need to be validated against your actual device state before you commit them to a policy that feeds Conditional Access enforcement.
Platform differences require honest acknowledgment. Windows compliance policies have the deepest available setting set. macOS compliance is meaningfully shallower – you can require FileVault, a minimum OS version, and a password policy, but many of the granular controls available on Windows don’t exist on macOS through Intune. iOS and Android have their own constraints. Designing compliance policies as if every platform can meet the same requirements leads to either false non-compliance on platforms that can’t satisfy specific rules, or a false sense of parity where the actual enforcement depth varies significantly by platform.
Design platform-specific compliance policies that reflect what each platform can actually demonstrate, rather than a single policy applied across all platforms with the same requirements. The trust bar can be the same – the rules that get you there will differ.
Validate compliance policy requirements against your actual device fleet before connecting them to Conditional Access enforcement. The gap between what you think your devices can satisfy and what they actually report is often surprising.
The rollout sequence matters as much as the rules themselves. Configure compliance policies in report-only mode first – or assign them without connecting Conditional Access enforcement – and spend time in the compliance dashboard understanding what your actual device state looks like. Which devices are non-compliant and why? Are those legitimate security gaps or configuration issues in the compliance policy itself? Answering those questions before enforcement goes live is the difference between a controlled rollout and an access outage that generates emergency tickets on a Friday afternoon.
When the rules are validated and the device state is understood, connect compliance to Conditional Access enforcement with a grace period that gives IT and users time to remediate before access is blocked. Expand the enforcement gradually – start with lower-sensitivity applications and work toward the crown jewels. Compliance enforcement that rolls out in stages is measurably less disruptive than enforcement that applies everywhere simultaneously and reveals problems at full scale.
Intune Deployment Guide · Phase 6: Compliance
‹ Previous: [6.1.1] Building Compliance Policies in Practice
