Why Your Devices Aren’t Marked Compliant in Microsoft 365: Policy Assignment Explained

Why None of Your Devices Are Marked Compliant (and What to Do About It)

If you’ve ever wondered why some of your endpoints show up as noncompliant in Microsoft 365—even when they look like they meet the rules—this post breaks down a real-world scenario. We’ll walk through three compliance policies, three devices, and explain exactly why each device fails to meet all the requirements. Then you’ll learn how to avoid the same pitfalls in your own environment.

Understanding the Compliance Policies

Imagine your tenant has three policies:

1. Policy1
   1. Requires BitLocker
   1. Requires the device’s risk score to be High or lower
2. Policy2
   1. BitLocker setting not configured (so it doesn’t enforce encryption)
   1. Requires risk score to be Medium or lower
3. Policy3
   1. Requires BitLocker
   1. Requires risk score to be Low or lower

Each policy combines an encryption requirement with a risk threshold. A device must meet both conditions to comply with a given policy.

The Devices in Question

Here are our three devices:

• Device1
  • BitLocker is configured
  • Endpoint risk status is High
  • Assigned policies: Policy1 and Policy3
• Device2
  • BitLocker is not configured
  • Endpoint risk status is Medium
  • Assigned policies: Policy2 and Policy3
• Device3
  • BitLocker is not configured
  • Endpoint risk status is Low
  • Assigned policies: Policy1 and Policy2

Why Each Device Fails

Device1

• Policy1 wants BitLocker enabled (✅) and risk ≤ High (✅).
• Policy3 wants BitLocker enabled (✅) but risk ≤ Low (❌).
• Because it fails Policy3’s risk requirement, Device1 is noncompliant.

Device2

• Policy2 doesn’t require encryption (✅) and risk ≤ Medium (✅).
• Policy3 requires BitLocker (❌) and risk ≤ Low (❌).
• It fails both parts of Policy3, so Device2 is noncompliant.

Device3

• Policy1 requires BitLocker (❌) even though risk ≤ High (✅).
• Policy2 doesn’t require encryption (✅) and risk ≤ Medium (✅).
• Because it fails Policy1’s encryption requirement, Device3 is noncompliant.

Key Takeaways

1. Mixed Policy Assignments Can Bite You
   When you assign multiple policies to a device, it has to meet every single policy. Even if one policy is easy to satisfy, failing any other makes the device noncompliant.
2. Encryption and Risk Are Separate Gates
   Make sure BitLocker is consistently enforced where required. And align your risk thresholds so devices don’t accidentally exceed them.
3. Audit Your Policy Assignments
   Group similar devices under the same policy sets to avoid conflicting rules. If you need different rules for high-risk devices, create separate policy assignments.
4. Test Before Broad Rollout
   Deploy new policies to a pilot group first. Check for failures and adjust encryption or risk settings before your entire fleet feels the sting.

By understanding exactly how each policy condition works—and how they stack—you’ll keep your compliance reports green and your devices truly protected.