🎯 Intune Course · Module 3 of 7
Compliance Policies & Conditional Access
📂 Course: Intune & Endpoint Management
📦 Module: 3 of 7
🎯 Exam: MD-102
⏱ Read time: ~22 min
📦 Module: 3 of 7
🎯 Exam: MD-102
⏱ Read time: ~22 min
MD-102 Exam Alignment
MD-102
- Know that a compliance policy defines rules a device must meet to be considered compliant — it does NOT enforce settings itself (that’s configuration profiles). A non-compliant device triggers actions you define
- Know that non-compliance actions include: mark device non-compliant immediately or after a grace period, send notification email to user, remotely lock the device, or retire/wipe the device
- Know that Intune integrates with Entra ID Conditional Access — a CA policy can require “device must be marked compliant” as a grant control, blocking non-compliant devices from accessing M365 resources
- Know the grace period: you can configure a number of days before a non-compliant device is blocked — giving users time to fix compliance issues without immediate lockout
Exam Tip: Compliance policies and configuration profiles are commonly confused. Compliance policy = evaluates the device against rules and reports compliant/non-compliant. Configuration profile = actively pushes settings to the device (Wi-Fi, VPN, restrictions). A compliance policy cannot configure a device; it can only check and report on its state.
Compliance policies are Intune’s mechanism for checking whether devices meet your security requirements — minimum OS version, encryption enabled, screen lock configured, no jailbreak detected. Unlike configuration profiles, compliance policies don’t enforce settings; they evaluate whether the device already meets the criteria. The compliance state feeds into Entra ID Conditional Access, enabling you to block non-compliant devices from accessing company resources like Exchange Online, SharePoint, and Teams.
📋 What Is a Compliance Policy?
A compliance policy is a set of rules and conditions assigned to devices (via user or device groups). Intune evaluates each enrolled device against all applicable policies and marks the device as Compliant or Not compliant.
💡 Key distinction: Compliance vs Configuration
- Configuration profile → pushes a setting TO the device (e.g., enables BitLocker, sets minimum PIN length)
- Compliance policy → checks if the device HAS a setting (e.g., is BitLocker enabled? is a PIN set?)
- A device can be compliant even without a configuration profile — as long as the device natively meets the compliance requirements
- A device with a configuration profile applied but that hasn’t yet applied the settings would be non-compliant during the grace period
⚙️ Common Compliance Policy Settings
| Category | Setting | Example Requirement |
|---|---|---|
| Device Health | Jailbreak / root detection | Block jailbroken iOS or rooted Android devices — these have had OS security protections removed |
| Windows Health Attestation | Require Secure Boot, code integrity, BitLocker reported via TPM health attestation service | |
| Defender for Endpoint risk score | Block devices with Machine Risk Score above Medium — integrates with Defender threat intelligence | |
| OS Version | Minimum OS version | Windows 11 22H2 minimum — devices running older OS versions are non-compliant |
| Maximum OS version | Block devices running newer OS not yet validated by IT (rarely used) | |
| Valid operating system builds | Allow only specific Windows build ranges for strict enterprise environments | |
| Security | Password / PIN required | Require screen lock with PIN, password, or biometric |
| Password complexity | Minimum 8 characters, alphanumeric, no simple passwords | |
| Encryption | Require device storage to be encrypted (BitLocker on Windows, FileVault on Mac) |
⏱️ Non-Compliance Actions & Grace Period
| Action | When It Fires | Description |
|---|---|---|
| Mark device non-compliant | Immediately (0 days) or after grace period | Changes the compliance state. This is the trigger for Conditional Access to block resource access. Default action — always present. |
| Send email to end user | Day 1 (e.g., immediately on non-compliance) | Sends a notification email to the device’s primary user listing the non-compliance reasons and remediation steps. |
| Remotely lock device | Day 7 (e.g., after a week without remediation) | Locks the device screen remotely. For Windows, requires a PIN to unlock. Prompts user to remediate compliance without wiping data. |
| Retire | Day 30 (escalation) | Removes company data and un-enrolls the device from Intune. Less destructive than wipe — leaves the device functional but removes corporate access. |
| Wipe | As a final escalation | Factory resets the device. Use with care. More common for lost/stolen devices via device-level action than as a scheduled compliance action. |
🔒 Intune + Entra ID Conditional Access Integration
Compliance policies alone don’t block access — they only report the compliance state. To block non-compliant devices from accessing resources, you need a Conditional Access policy in Entra ID that uses Require device to be marked as compliant as a grant control.
| Flow Step | What Happens |
|---|---|
| 1. Device enrolled | Device is enrolled in Intune and a compliance policy is assigned |
| 2. Compliance evaluated | Intune evaluates the device against the policy — device is Compliant or Not compliant. This state is reported to Entra ID. |
| 3. User accesses resource | User tries to open Outlook or SharePoint on their device |
| 4. Conditional Access checks | Entra ID evaluates the CA policy — checks if the device is marked compliant in Intune |
| 5. Outcome | ✅ Compliant → Access granted. ❌ Non-compliant → Access blocked with “You can’t get there from here” error and remediation link |
💡 Best Practices
- Always configure a grace period of at least 3–7 days for the “mark non-compliant” action before Conditional Access blocks access — new devices need time to complete all compliance checks after enrolment
- Pair compliance policies with notification message templates (Devices → Compliance → Notifications) that include clear remediation steps — users should understand exactly why they’re blocked and how to fix it
- Start Conditional Access policies in Report-only mode first — this logs who would have been blocked without actually blocking anyone, allowing you to assess impact before enforcing
🎓 Interview Q&A
Q: A user’s iPhone is enrolled in Intune but does not have a passcode configured, which violates the compliance policy. The user tries to access SharePoint. What is the outcome, and what must the admin have configured for this to work?
The user’s access to SharePoint is blocked — provided the admin has configured: (1) a Compliance Policy for iOS requiring a passcode, AND (2) a Conditional Access policy in Entra ID requiring devices to be marked compliant for the Office 365 cloud app. The compliance policy marks the device as non-compliant (no passcode). The CA policy checks Entra ID for the device’s compliance state — sees non-compliant — and blocks the access token request. Once the user sets a passcode and Intune re-evaluates (within ~15 minutes), the device is marked compliant and SharePoint access is restored.
🎯 MD-102 Mock Test
Module 3 — Compliance Policies & Conditional Access
5 questions · Pass mark: 70%
Q1 OF 5
An Intune compliance policy requires BitLocker encryption on Windows devices. A laptop without BitLocker enabled tries to access Exchange Online. A Conditional Access policy requires devices to be compliant. What is the outcome?
✅ D. The compliance policy detects that BitLocker is not enabled → marks the device non-compliant → Conditional Access sees the non-compliant state → blocks Exchange Online access. The compliance policy does NOT enable BitLocker (A) — that’s a configuration profile’s job. To fix this, the admin should deploy a separate configuration profile to enable BitLocker AND the compliance policy to require it.
Q2 OF 5
You create a compliance policy with a 7-day grace period for the “mark device non-compliant” action. A device fails compliance evaluation on Day 1. What happens on Day 1 vs Day 8?
✅ B. During the grace period, the device’s compliance state is shown as In grace period in Intune. Conditional Access policies that require “marked compliant” still allow access during this period. On Day 8 (after the 7-day grace period expires), the device is formally marked Non-compliant and Conditional Access begins blocking access. This gives users time to remediate compliance issues without immediate lockout.
Q3 OF 5
Where is the Conditional Access policy that requires device compliance configured — in Intune or Entra ID?
✅ C. Conditional Access policies are configured in Entra ID → Protection → Conditional Access. The Intune compliance policy defines WHAT makes a device compliant. The Entra ID CA policy defines the CONSEQUENCE — requiring compliant devices as a grant control for specific cloud apps. Intune doesn’t create CA policies; it only provides the compliance signal that CA uses.
Q4 OF 5
An admin deploys a new compliance policy requiring OS version Windows 11 22H2 minimum. Devices running Windows 10 are immediately blocked from accessing Microsoft 365. How should the admin have rolled this out to avoid sudden user lockouts?
✅ D. All three are valid best practices and should be used together: (A) A grace period prevents immediate lockout when the policy first applies; (B) phased group rollout limits blast radius; (C) CA in Report-only mode shows who would be blocked without actually blocking them. In practice, a major OS version compliance change should use a 30–60 day grace period AND be rolled out gradually, with CA in report-only until confidence is high.
Q5 OF 5
A compliance policy has been assigned to a user group. A device not enrolled in Intune belongs to a user in that group. What is the device’s compliance state from Intune’s perspective?
✅ B. An unenrolled device is unknown to Intune and has no compliance state. From a Conditional Access perspective, a device that is not enrolled and cannot report compliance is treated as non-compliant when a CA policy requires “device marked as compliant.” This is intentional — it ensures that unmanaged personal devices cannot bypass compliance requirements simply by not enrolling.
🔒
Module locked — Complete Module 2 first.