Intune: Compliance Policies vs Configuration Profiles

Table of Contents

The Core Conceptual Difference
Compliance Policies — Deep Dive
Configuration Profiles — Deep Dive
Conditional Access Integration
Real-World Examples
Naming & Assignment Strategy

The Core Conceptual Difference

This is the most common source of confusion for new Intune administrators. Here's the one-sentence rule:

Compliance policies EVALUATE the device state and report Pass/Fail. Configuration profiles CHANGE the device state by pushing settings.

A compliance policy asks: "Is BitLocker enabled?" A configuration profile says: "Enable BitLocker." These are fundamentally different operations — one is a check, the other is an enforcement action.

Compliance Policy

Reports compliant / non-compliant
Gates Conditional Access
Does NOT change device settings
Has a grace period (in-built)
Triggers notification emails
Evaluated periodically (default 8h)
Assigned to users or devices

Configuration Profile

Actively pushes settings to device
No CA integration
DOES change device settings
No grace period concept
Applied at enrollment & on sync
Evaluated at check-in (default 8h)
Assigned to users or devices

Compliance Policies — Deep Dive

A compliance policy is a set of rules your device must meet to be considered "healthy." If the device fails any rule, it becomes Non-compliant — and if you have a Conditional Access policy requiring a compliant device, that user gets blocked from corporate resources.

What compliance policies can check (Windows example)

Category	Rules you can set
Device Health	Require BitLocker, Secure Boot, Code Integrity
Device Properties	Minimum/maximum OS version, OS build range
System Security	Require password, minimum length, complexity
Microsoft Defender	Require antimalware, real-time protection, signature up to date
Microsoft Defender ATP	Require machine risk score (Low, Medium, High, Clear)
Configuration Manager	Require co-management compliance (hybrid)

Non-compliance actions

When a device fails compliance, you can chain actions with time delays:

Immediately (0 days): Mark device non-compliant
After X days: Send email notification to user
After Y days: Send push notification to Company Portal
After Z days: Retire (wipe) the device

The grace period on a compliance policy (default 0 days) delays the non-compliant status. If you set it to 3 days, the device has 3 days to become compliant before CA blocks access. This is useful for new deployments — set it to 7 days for the first rollout, then tighten it.

Configuration Profiles — Deep Dive

Configuration profiles are the workhorse of Intune. They push settings directly to devices using MDM policies (CSPs — Configuration Service Providers). There are multiple profile types available:

Profile Type	Best For	Notes
Settings Catalog	Modern Windows settings (recommended)	Replaces Device Restrictions and most legacy profiles
Templates → Device Restrictions	Quick toggle-based hardening	Older UI; Settings Catalog covers same settings
Templates → Endpoint Protection	Defender, BitLocker, Windows Firewall	Use for security configuration
Templates → Identity Protection	Windows Hello for Business	WHfB config including PIN requirements
Custom (OMA-URI)	Settings not yet in Settings Catalog	Requires knowing the exact CSP URI
Scripts (PowerShell)	Complex one-time configurations	Runs as SYSTEM; no remediation loop
Proactive Remediation	Detect & fix drift	Requires Intune P2 / M365 E5

Settings Catalog — the modern way

The Settings Catalog is Microsoft's unified interface for all Windows MDM settings. It's searchable and supports thousands of settings across Windows Update, Defender, Edge, Office, and Windows configuration areas. For any new profile, start here before falling back to OMA-URI.

Conditional Access Integration

Here's the architectural flow that ties everything together:

A configuration profile pushes BitLocker encryption to the device
A compliance policy checks that BitLocker is enabled
If compliant → the device gets the Compliant attribute in Entra ID
A CA policy requires a compliant device to access Exchange Online
Non-compliant devices are blocked from Exchange

The configuration profile and compliance policy for the same setting are independent. You can have a config profile enforcing BitLocker AND a compliance policy checking for BitLocker. The config profile ensures the setting is applied; the compliance policy ensures CA blocks access if somehow it isn't.

Real-World Examples

Example 1: Password Policy

Configuration Profile (Settings Catalog): Push "Minimum password length = 12" — this actually sets the password policy on the device.
Compliance Policy: Check "Minimum password length ≥ 12" — this gates CA. If a local admin bypasses the config profile, this blocks the user.
Result: Belt and suspenders. The profile tries to enforce it; the compliance policy catches the gaps.

Example 2: Microsoft Defender

Configuration Profile (Endpoint Security → Antivirus): Enable real-time protection, cloud-delivered protection, automatic sample submission.
Compliance Policy: Require "Real-time protection = Enabled" and "Signature version no older than X days".

Example 3: OS Version Gates

Configuration Profile (Windows Update rings): Define update rings that keep devices on approved builds.
Compliance Policy: Require "Minimum OS version = 10.0.22621.0" (Windows 11 22H2). Devices that haven't updated get blocked from M365.

Naming & Assignment Strategy

With dozens of profiles and policies in a mature tenant, naming conventions are critical. A consistent scheme I use in production:

Object Type	Naming Pattern	Example
Compliance Policy	`CP-[Platform]-[Scope]-[Description]`	`CP-WIN-Corp-Security-Baseline`
Configuration Profile	`CFG-[Platform]-[Area]-[Description]`	`CFG-WIN-Security-BitLocker`
App Config	`APP-[AppName]-[Platform]-[Scope]`	`APP-Outlook-iOS-Corp`
Autopilot Profile	`AP-[JoinType]-[Scope]`	`AP-AADJ-StandardUsers`

Assign compliance policies to user groups (because compliance follows the user, not the device). Assign configuration profiles to device groups (because settings are applied to the device, regardless of who is signed in). This rule prevents settings gaps when a device is shared or re-enrolled.

Badra Ali Diakite

Senior IT Consultant specialising in Microsoft 365, Intune, Zero Trust architecture and network infrastructure. 15+ years across 28+ countries in both military and enterprise environments.