Why Your Intune Compliance Policies Don’t Actually Improve Security (And What to Fix in 2026)

I’ve lost count of how many times I’ve opened an Intune tenant and seen what looks like a well-configured environment—compliance policies defined, devices reporting as compliant, dashboards all green.

On the surface, everything appears secure.

But when you actually test it—when you simulate real-world scenarios or dig into device state—you quickly realise something uncomfortable:

Compliance doesn’t mean security.

Devices can be marked compliant while:

• BitLocker isn’t fully enforced
• The firewall is disabled
• Users still have local admin rights
• Critical controls are simply not being validated

The issue isn’t that Intune compliance policies are useless—they’re not. The problem is how they’re commonly used: as a checkbox, rather than a control that actively enforces security.

In this article, I’ll break down why compliance policies often fail to improve security, where the real gaps are, and what you should be doing instead if you actually want to reduce risk.

Quick Fix Summary

If you want to turn compliance into real security:

• ✅ Link compliance policies to Conditional Access (no CA = no enforcement)
• ✅ Validate controls with configuration profiles, not just compliance checks
• ✅ Remove persistent local admin access across all endpoints
• ✅ Regularly audit “compliant” devices for real-world state
• ✅ Treat compliance as a signal—not a security control

The Core Problem: Compliance Is a Signal, Not a Control

The biggest misunderstanding I see is this: people expect compliance policies to enforce security settings.

They don’t.

Compliance policies in Intune are designed to evaluate device state, not enforce it. They check conditions like:

• Is BitLocker enabled?
• Is the firewall turned on?
• Is the OS version up to date?

But they don’t guarantee those settings were applied correctly—or that they haven’t been bypassed.

In other words, compliance is just a snapshot, and sometimes it’s an outdated or inaccurate one.

Where Things Go Wrong in Real Environments

1. Policies Exist… But Nothing Enforces Them

One of the most common issues is simple: compliance policies are configured, but they’re not tied to anything.

No Conditional Access. No blocking. No consequences.

So even if a device is non-compliant, it can still:

• Access Exchange Online
• Sync OneDrive
• Connect to Teams

At that point, compliance becomes a reporting tool—not a security control.

2. You’re Checking the Wrong Things

Another issue is relying too heavily on default or minimal checks.

For example:

• BitLocker = “required”
• Firewall = “required”

That sounds fine—until you realise:

• BitLocker might be suspended
• Firewall profiles might be partially disabled
• Exceptions may allow wide-open access

The compliance policy says “yes,” but the device isn’t actually secure.

3. Configuration Drift Is Real (And Constant)

Even if everything starts correctly, devices don’t stay that way.

Users:

• Disable settings for troubleshooting
• Install conflicting software
• Modify configurations locally

And unless you’re continuously enforcing and validating those settings, devices drift away from your baseline.

Compliance might catch some of it—but not all, and not always in real time.

Real-World Example: The “Compliant but Vulnerable” Device

In one environment I worked on, every device was showing as compliant.

On paper, it was a success.

But when we tested:

• Firewall was disabled on multiple endpoints
• Local admin rights were still widely assigned
• BitLocker keys existed—but protection was inconsistent

The reason?
Compliance policies were checking presence—not effectiveness.

That’s a critical difference.

How to Fix It (Without Rebuilding Everything)

Step 1: Enforce Compliance with Conditional Access

This is non-negotiable.

If compliance isn’t tied to Conditional Access, it’s not doing much for security.

In the Microsoft Entra admin center:

• Go to Conditional Access
• Create a policy targeting:
  • All users (with exclusions where required)
  • All cloud apps

Set:

• Grant access → Require device to be marked as compliant

This is what turns compliance from a report into a gate.

Step 2: Use Configuration Profiles for Enforcement

Compliance checks state. Configuration profiles enforce it.

For example:

• BitLocker → enforce via Endpoint Security policy
• Firewall → enforce via Firewall profile
• Defender settings → enforce via security baselines

If you rely on compliance alone, you’re trusting the device to behave.

That’s not a strategy.

Step 3: Validate What “Compliant” Actually Means

Don’t trust the dashboard blindly.

Pick a sample device and check:

Get-BitLockerVolume

Get-NetFirewallProfile

Get-LocalGroupMember -Group "Administrators"

You’ll often find discrepancies between reported compliance and actual state.

Step 4: Remove Persistent Local Admin Access

This is one of the biggest gaps in most environments.

Even if everything else is configured correctly, a user with local admin rights can:

• Disable security controls
• Install risky software
• Bypass restrictions

Use Intune:

• Endpoint Security → Account Protection
• Define strict membership for the Administrators group

Then pair it with:

• Windows LAPS
• Privilege elevation tools

Step 5: Monitor and Reassess Regularly

Security isn’t static.

Set a process to:

• Review compliance reports
• Audit configurations
• Test enforcement

Because what works today won’t necessarily hold up in six months.

Additional Tips / Pro Tips

Don’t confuse green dashboards with real security
A “compliant” device is only as secure as the policies behind it.

Test like an attacker would
Try to:

• Disable firewall
• Access data from a non-compliant device
• Install unauthorised apps

That’s where the truth shows up.

Watch out for hybrid environments
GPO and Intune conflicts can create inconsistent results. Always check which policy wins.

Use reporting—but don’t rely on it alone
Intune reports are useful, but they don’t replace validation.

FAQ Section

Why don’t Intune compliance policies enforce settings?

Because they are designed to evaluate device state, not enforce configurations. Enforcement must be done through configuration profiles and security policies.

Is compliance useless without Conditional Access?

Not useless—but significantly limited. Without Conditional Access, there’s no consequence for non-compliance.

Why is a device compliant but still insecure?

Because compliance checks may not validate the effectiveness of a control—only its presence or reported state.

How often should I review compliance policies?

At least quarterly, but ideally as part of ongoing security reviews or after major changes.

What’s the biggest mistake with Intune compliance?

Treating it as a security control instead of a signal that needs enforcement and validation.

Conclusion / Actionable Takeaways

If there’s one shift you need to make, it’s this:

👉 Stop treating compliance as security.

Compliance policies are useful—but only when they’re part of a broader strategy that includes enforcement, validation, and monitoring.

What to do next:

1. Link all compliance policies to Conditional Access
2. Ensure critical controls are enforced via configuration profiles
3. Remove local admin rights across endpoints
4. Validate device state manually (don’t trust dashboards blindly)
5. Build an ongoing review process

From experience, the organisations that get this right aren’t the ones with the most policies—they’re the ones that understand what those policies actually do.

And more importantly, what they don’t.

Last Updated

April 2026 – Reflects current Microsoft Intune, Windows 11, and Microsoft 365 compliance and Conditional Access capabilities.

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.