Intune Compliance

Intune Misunderstanding #3: “Compliance Policies Make Devices Secure”

A device is marked Compliant in Microsoft Intune. Does that mean the device is secure?
No. And understanding why is important when designing endpoint security.

One of the most common misunderstandings about Microsoft Intune is that compliance policies are security configuration policies. They are not.

Compliance policies evaluate whether devices meet defined requirements. They do not, by themselves, implement the security configurations needed to protect those devices.

Let's examine what that means in practice.

What does an Intune compliance policy actually do?

A compliance policy defines conditions that a device must satisfy to be considered compliant.

For Windows devices, these conditions can include:

• Whether BitLocker encryption is enabled.

• Whether a firewall is enabled.

• Whether antivirus protection is active.

• Whether Microsoft Defender reports an acceptable device risk level, when integrated.

• Whether the operating system meets minimum version requirements.

• Whether Secure Boot is enabled.

Intune evaluates the device against the configured requirements and reports a compliance state.

But evaluating a setting is not the same as configuring it.

For example, a compliance policy can require BitLocker encryption.
If BitLocker is disabled, the device may be marked noncompliant.
The compliance policy does not automatically enable BitLocker simply because encryption is required.

That requires a separate configuration mechanism.

Compliance policies vs. configuration policies

These two policy types serve different purposes.

Configuration policies define how devices should be configured.

Using Intune, administrators can deploy security settings through mechanisms such as:

• Settings Catalog policies.

• Endpoint Security policies.

• Security baselines.

• Custom configuration profiles.

These policies use supported Windows management mechanisms to configure settings such as BitLocker, Microsoft Defender Antivirus, Windows Firewall, and other security controls.

Compliance policies evaluate whether devices meet specific requirements.

They provide an assessment that can be used for reporting and access decisions.

The distinction is fundamental:

Configuration establishes the intended security state. Compliance evaluates selected conditions against that state.

Example: BitLocker encryption

Consider an organization that requires BitLocker encryption on every corporate Windows laptop.

The administrator creates a compliance policy requiring encryption.

A laptop checks in with Intune.

If the device does not meet the encryption requirement, Intune can report it as noncompliant.

But the compliance policy does not deploy the BitLocker configuration required to encrypt the device.

To implement the requirement, the administrator must separately configure BitLocker using an appropriate policy.

The correct design uses both:

1. An Endpoint Security disk encryption policy to configure BitLocker.

2. A compliance policy to evaluate whether the encryption requirement is satisfied.
   

This creates two separate layers: configuration and verification.
Even then, administrators should verify the actual encryption state on the endpoint when troubleshooting or validating deployment.

Where Conditional Access fits in

Compliance becomes particularly valuable when combined with Microsoft Entra Conditional Access.

Consider a Conditional Access policy that requires a device to be marked compliant before accessing a protected resource.

The process is conceptually straightforward:

1. Intune evaluates the device against its assigned compliance requirements.

2. The resulting compliance state is made available to Microsoft Entra.

3. Conditional Access evaluates the applicable access policy.

4. Access is granted or blocked based on the policy conditions and available signals.
   

However, there is an important limitation.
Conditional Access does not independently verify every security configuration on the device.

It relies on the device compliance signal when a policy requires a compliant device.
If the compliance policy checks only a small number of requirements, a device can be compliant while other important security settings remain incorrectly configured.

A compliant device is not necessarily a secure device

Compliance is a result of the configured evaluation criteria, not a comprehensive security assessment.

Another important detail: the default compliance state

Intune includes a tenant-level compliance policy setting that determines how devices without an assigned compliance policy are treated.

Depending on its configuration, devices without an assigned compliance policy can be considered compliant or noncompliant. This setting deserves particular attention in environments where Conditional Access relies on device compliance. Administrators should explicitly review it rather than assume every compliant device has passed a meaningful set of security checks.

How should organizations design this correctly?

A stronger endpoint security design separates three responsibilities.

1. Configure security

Use Intune configuration and Endpoint Security policies to implement the required security controls.

2. Evaluate compliance

Use compliance policies to assess selected device requirements, including relevant security and health signals.

3. Control access

Use Microsoft Entra Conditional Access to make access decisions based on compliance and other applicable conditions.
These mechanisms complement each other, but they are not interchangeable. Organizations should also independently validate important endpoint configurations rather than relying exclusively on the compliance indicator in the Intune admin center.

Key takeaways

• Compliance policies evaluate requirements. They do not automatically configure the security settings they assess.

• A compliant device is not automatically secure. Compliance reflects the configured checks and their reported results.

• Endpoint security requires multiple layers. Configuration, verification, and access enforcement serve different purposes.

Final thought

The green Compliant indicator in Intune answers a specific question:
Does this device meet the compliance requirements we configured?
It does not answer a much broader question:
Is this device securely configured?

Understanding that distinction is essential when designing and troubleshooting Microsoft Intune environments.