Intune Compliance Policies Masterclass: Conditional Access & Grace Periods
Design compliance policies that scale: the no-policy default, grace periods that match your patch cadence, and exactly how device state gates sign-ins through Conditional Access.
C
CloudEngineerHub Team
Published: August 28, 2026· Last Updated: September 24, 2026·10 min read
Intune Compliance Policies Masterclass: Conditional Access & Grace Periods
A compliance policy is more than a checklist on a device — it is the signal that Conditional Access (CA) uses to allow or block corporate access. Designed well, it becomes your least-privilege backbone; designed badly, it either locks out half the fleet or is so loose it means nothing. This is how to get it right.
Visual Walkthrough
Grace periods decoded: when "non-compliant" actually cuts access.
Decision TreeCompliance → Conditional Access — The Handshake5/5
Decision gate
Device evaluates compliance
Compliance is a signal; Conditional Access is the consequence.
Compliant
1
All settings pass
Encryption, AV health, OS version, jailbreak checks green.
2
Device marked compliant
State published to Entra for CA to consume.
3
CA grants access
Mail/files open — the compliant experience is frictionless.
Non-compliant
1
Grace period runs
Actions: mark non-compliant after N days — a designed buffer.
Compliance → Conditional Access — The Handshake. Gate: Device evaluates compliance — Compliant: All settings pass — Compliant: Device marked compliant — Compliant: CA grants access — Non-compliant: Grace period runs — Non-compliant: User notified — Non-compliant: CA blocks after grace — Non-compliant: Remediation restores
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Intune licenses for every user whose device will be evaluated, and devices enrolled on supported platforms (Windows, iOS/iPadOS, macOS, Android).
A Conditional Access license (part of Microsoft Entra ID P1) — compliance state does nothing by itself until a CA policy consumes it.
The Intune Service Administrator or Compliance Administrator role for policy work, and an Entra Conditional Access Administrator for the enforcement side.
A deployment decision on the tenant-wide toggle: what happens to devices with no compliance policy (below — this one is a security boundary, not a preference).
Notification email templates configured before you schedule email actions.
How Compliance and Conditional Access Work Together
Intune evaluates each device against its assigned policy on check-in and writes the result — compliant, non-compliant, in grace period — onto the device object in Microsoft Entra ID. Conditional Access then treats that state as a grant condition: a policy requiring compliant device for Exchange Online, SharePoint, or Teams will simply refuse tokens to devices whose state is non-compliant. With Continuous Access Evaluation (CAE) enabled, that state change propagates in near real time — the user is blocked on their next request, not at their next token refresh.
Two consequences shape everything else. First, the default state matters: under intune.microsoft.com → Devices → Compliance → Compliance policy settings, "Mark devices with no compliance policy assigned as" should be Not compliant — otherwise every unmanaged or out-of-scope device is compliant by default, which quietly defeats the entire model. Second, evaluation latency is real: a device that just fixed itself needs to check in and re-evaluate before Entra sees the new state, so "I fixed it, why am I still blocked?" is usually answered with a sync, not a ticket escalation.
Step-by-Step: Building the Policy Framework
Set the tenant defaults first. No-policy = Not compliant. Configure the compliance status validity period if your cadence demands it.
Create one minimal policy per platform. Password/credential requirements, device encryption, and for sensitive platforms Defender for Endpoint machine risk. Treat OS version rules as optional — a max-OS rule that fires after a rushed patch Tuesday will block more work than a vulnerability ever would.
Keep policies platform-wide with exclusions, not dozens of narrow ones; every extra policy multiplies the chance of a conflict you will debug at midnight.
Configure Actions for noncompliance per policy — this is where grace periods live (deep dive below).
Create the CA policy in Entra (entra.microsoft.com → Protection → Conditional Access): target user groups, condition device platforms as needed, grant = require compliant device. Exclude break-glass accounts.
Report before you enforce. Run the non-compliant report below for a week before flipping CA on, and fix the population that would be blocked on day one.
Configuration Deep Dive: Grace Periods and Actions for Noncompliance
Grace periods live in each policy under Actions for noncompliance. The default "Mark device noncompliant" action can be scheduled for a number of days after the device first fails — that window is your grace period, and the Company Portal app nags the user the whole time. You can stack additional actions in sequence: send an email (from a configured notification template), remote lock, and eventually retire the device for devices that never come home.
A workable production pattern: immediate non-compliance for encryption and root/jailbreak, 7 days for OS version rules aligned to your Windows update ring cadence, and an email action at day 0 so users know before access dies. Note the mechanics carefully: the grace clock starts when the device first becomes non-compliant and does not pause because the user is on vacation — schedule retire actions with that in mind, and never attach auto-retire to a rule with a short grace period on devices holding local data.
Real-World Enterprise Scenario
A 1,400-consultant firm enforced a max-OS compliance rule the same week a vendor patch broke their accounting suite; IT deferred the OS update, and 300 field laptops immediately sailed past the rule's grace period — CA cut them off mid-engagement. The remediation redesigned the framework rather than the exception: encryption and jailbreak rules stayed immediate, the OS rule moved to a 7-day grace period explicitly aligned to the update rings, and a new exception process allowed scoped, time-boxed policy exclusions approved by security instead of ad-hoc deferrals. Blocked-device tickets fell 80 percent, and the audit team — reviewing the same controls — passed the design with the comment that grace periods finally "matched operational reality."
PowerShell: Reporting the Real State
Do not wait for a blocked user to find out what is failing. Pull the fleet view from Graph:
PowerShell
1
2
3
4
5
6
7
8
Connect-MgGraph -Scopes"DeviceManagementManagedDevices.Read.All"# Non-compliant devices and when their grace period expires
Get-MgDeviceManagementManagedDevice -All -Filter"complianceState eq 'noncompliant'" |
Select-Object DeviceName, UserPrincipalName, OSVersion, ComplianceGracePeriodExpirationDateTime |
Sort-Object ComplianceGracePeriodExpirationDateTime |
Format-Table -AutoSize# Expected: devices ordered by who loses access next
PowerShell
1
2
3
4
5
# Inventory the compliance policies themselves
Connect-MgGraph -Scopes"DeviceManagementConfiguration.Read.All"
Get-MgDeviceManagementDeviceCompliancePolicy -All |
Select-Object DisplayName, '@odata.type'# Expected: one line per policy — instantly exposes accidental duplicates
Pair this with the per-policy device status report in the console to see exactly which setting failed on which platform.
Troubleshooting Matrix
Symptom
Cause
Fix
User blocked, device shows compliant
Stale state; device has not re-evaluated since fix
Trigger sync; verify check-in time on the device record
Device compliant but CA still refuses
CA policy targets the user, device state, or app differently than assumed
Diff the CA assignment and grant controls; test with What If
Grace period "expired" with no warning
No email action at day 0; user never notified
Add notification template action at day 0
Unmanaged personal device bypasses checks
No-policy devices marked compliant
Flip the tenant default to Not compliant
macOS device unknown state
Enrollment type lacks required signals (e.g., user-enrolled limits)
Match rule set to enrollment type; re-enroll corporate Macs via ADE
Retire fired on an on-leave user's device
Short grace period plus auto-retire action
Remove auto-retire from short-grace policies
Common Errors
"Access denied" despite green compliance — the CA policy and the compliance evaluation target different identities (shared device, secondary account) or the state has not propagated; check the device's last evaluation time.
Policies applied but no enforcement — no CA policy requires a compliant device; compliance without CA is telemetry, not control.
Everyone suddenly non-compliant after a policy edit — a strictened rule hit the whole platform at once; stage changes with pilot groups.
Duplicate policies fighting silently — two policies for the same platform with overlapping rules; consolidate to one per platform.
Best Practices
Set no-policy = Not compliant on day one; audit the "no policy assigned" population regularly.
One minimal policy per platform; push complexity into exclusions and filters, not more policies.
Match grace periods to your patch cadence — 7 days behind update rings is a coherent story.
Email at day 0 for every grace period; users cannot fix what they never knew broke.
Never pair auto-retire with short grace periods on devices holding local data.
Run the Graph non-compliance report weekly and treat grace-period expiries as an upcoming-outage forecast.
Visual Walkthrough
The gate every sign-in passes: collect signals, AND the policies, decide.
Decision TreeConditional Access — Signals In, Decision Out5/5
Decision gate
Evaluate all matching policies (AND)
One failing control blocks; grants must be earned in full.
Treat the no-policy default as a security boundary: compliant-by-default means unmanaged-by-default.
Keep encryption and root/jailbreak evaluations immediate — these are not negotiable settings.
Integrate Defender for Endpoint machine risk into compliance so CA reacts to actual behavioral signal, not just configuration.
Exclude break-glass accounts from the CA policy deliberately, monitor their use, and never leave the exclusions broad enough for daily work.
Grace periods are a business-cadence decision, not a security weakness — but document them so auditors see the rationale.
FAQ
What is the difference between a compliance policy and a configuration profile?
Compliance evaluates state and reports pass/fail (and can gate access via CA); configuration profiles set settings. You usually need both — the profile fixes the drift, the policy flags it.
How long can a grace period be?
Scheduled non-compliance actions support multi-day windows; the right number is whichever matches your patch cadence, typically 3–7 days for OS rules.
Does compliance apply to devices without users (kiosks)?
Yes — device-targeted compliance works, but ensure CA policies that require compliant users are not attached to shared-device flows.
Why is a device "in grace period" instead of non-compliant?
The scheduled mark-noncompliant action has not fired yet; the device is failing now and will flip on the schedule.
Can users see why they are blocked?
Yes — Company Portal shows the failing settings, which is why keeping rules minimal matters: legible failure states mean faster self-service.
Conclusion
Compliance plus Conditional Access is the heart of least-privilege endpoint management: Intune measures, Entra enforces, and grace periods translate security intent into a cadence real humans can follow. Set the defaults with intent, keep the rules minimal, wire the notifications, and report the drift before it becomes a lockout.
Compliance + Conditional Access is the heart of MD-102: drill it with the practice tests on /mock, inspect policy signals with the free tools on /tools, and grab the study bundles on /store.
Comments
0No comments yet — be the first to share your thoughts.