In this blog post Enforce Device Compliance with Microsoft Intune for Safer Access we will walk through how to use Microsoft Intune to define “good device hygiene,” measure it continuously, and then enforce it at sign-in time. The goal is simple: let productive work happen quickly, while quietly blocking devices that are outdated, jailbroken, unencrypted, or missing security controls.
At a high level, device compliance is about proving a device is in an acceptable state before it touches corporate data. Intune evaluates each enrolled device against your rules (OS version, encryption, password strength, threat level, and more). Then Microsoft Entra ID (formerly Azure AD) uses that compliance signal in Conditional Access to allow or deny access to Microsoft 365 and other apps. This “measure + enforce” loop is what turns policies into real security outcomes.
What is device compliance in Intune
Intune device compliance policies are a set of requirements a device must meet to be considered compliant. Intune regularly checks devices and assigns a compliance status. If a device falls out of compliance (for example, encryption is turned off or the OS is too old), Intune marks it noncompliant and can trigger follow-up actions like notifying the user or locking the device.
Compliance is not the same as configuration. Configuration profiles set the desired state. Compliance policies verify the state and produce a pass/fail signal. In real deployments you typically use both: configuration profiles to enforce settings, and compliance policies to confirm the settings remain in place.
The main technology behind it: Intune + Entra Conditional Access
The technology stack behind “enforce compliance” has three moving parts:
- Microsoft Intune: enrolls devices, applies configuration, evaluates compliance, and records compliance state.
- Device identity in Microsoft Entra ID: the device is registered/joined so Entra can identify it during sign-in.
- Conditional Access: an Entra policy that can require “device is marked as compliant” before granting access to apps.
When you turn on a Conditional Access rule with Require device to be marked as compliant, Entra checks the device’s compliance status coming from Intune. If the device is noncompliant, access can be blocked. This is the key enforcement step—without Conditional Access, compliance is mostly reporting.
One detail many teams learn the hard way: on some platforms and browsers, Entra identifies the device using a client certificate provisioned during device registration, and users may be prompted to select that certificate in the browser. It’s normal, but it’s worth warning your helpdesk and users ahead of time.
Before you start: plan your compliance baseline
Keep your first compliance rollout small and predictable. A good baseline usually includes:
- Minimum OS version (and ideally a maximum “age” in practice, via update rings/configuration).
- Disk encryption required (BitLocker/FileVault).
- Device lock requirements (PIN/password complexity and timeout).
- Block jailbroken/rooted devices on mobile.
- (Optional) Integrate Microsoft Defender for Endpoint signals such as device risk or threat level, if you use it.
Also decide who goes first. Start with IT, security champions, and a pilot group. Then expand gradually.
Step-by-step: create and enforce a compliance policy
1) Create a compliance policy per platform
In the Intune admin center, go to Devices > Compliance and create a policy for each platform you manage (Windows, macOS, iOS/iPadOS, Android). Set requirements that match your baseline.
Practical tip: don’t try to make one “mega policy.” Platform differences matter, and smaller policies are easier to troubleshoot.
2) Configure Actions for noncompliance (your remediation workflow)
Intune compliance becomes much more usable when you pair enforcement with a humane remediation path. Each compliance policy includes a default action to mark a device noncompliant immediately (0 days). You can change the schedule to create a grace period, and add additional actions like sending email, push notifications, remotely locking, or retiring the device.
A common pattern looks like this:
- Day 0: Mark noncompliant (but don’t necessarily block access yet if you use a grace period).
- Day 1: Send push notification.
- Day 2: Send email with clear steps to remediate.
- Day 7: Retire device (only for corporate-owned devices and only if you’re confident).
Intune’s UI schedules actions in days, and more granular schedules can be done via Microsoft Graph in some cases (for example using decimal day values). ([learn.microsoft.com](https://learn.microsoft.com/en-us/intune/intune-service/protect/actions-for-noncompliance?utm_source=openai))
3) Assign the compliance policy to the right groups
Target user or device groups consistently. Many organisations find it simplest to target users (because users move between devices), but targeting devices can be useful for shared or kiosk scenarios. Keep pilot and production groups separate so you can safely test changes.
4) Create an Entra Conditional Access policy to require compliant devices
Now enforce it. In Microsoft Entra ID Conditional Access, create a policy that grants access only when the control Require device to be marked as compliant is satisfied. Microsoft’s current guidance is to start in Report-only mode, confirm impact, and then switch to On.
Practical rollout guidance:
- Exclude break-glass accounts (emergency access) from the policy.
- Start with a smaller set of cloud apps (or user groups), then broaden scope.
- Confirm you already have compliant devices in the pilot before turning enforcement on.
5) Validate user experience and fix the “gotchas”
Test with real workflows: Outlook, Teams, SharePoint, line-of-business apps, and browser access. Pay attention to:
- Whether users can still enroll devices (Microsoft notes that “require compliant device” doesn’t block Intune enrollment in common scenarios).
- Browser certificate prompts on mobile/macOS and some browsers. ([learn.microsoft.com]
- Devices that are “compliant” but still can’t access due to other Conditional Access controls (MFA, location, sign-in risk, etc.).
Example baseline: what many teams enforce first
Here’s a simple “v1” baseline you can implement quickly:
- Windows: require BitLocker, require Secure Boot (where applicable), minimum OS version, password/PIN policies.
- macOS: require FileVault, minimum OS version, password policy.
- iOS/iPadOS: require passcode, block jailbroken devices, minimum OS version.
- Android: require a screen lock, block rooted devices, minimum OS version.
Then iterate: integrate Defender signals, add platform-specific controls, and tune your grace periods based on real remediation time.
Operational tips that reduce tickets
- Write remediation messages like a runbook: “Open Company Portal > Devices > This device > Check status.”
- Keep policy names explicit: “WIN-COMP-BaseSecurity-v1”.
- Separate ‘monitor’ and ‘enforce’: use Report-only in Conditional Access first, then enforce.
- Use staged rollouts: IT → pilot → one business unit → all users.
Optional automation: audit compliance via Microsoft Graph
If you want reporting in CI/CD pipelines or internal dashboards, Microsoft Graph is the usual route. Below is a simple example using PowerShell to list devices and their compliance state (you can filter to noncompliant devices and alert on trends):
# Requires Microsoft.Graph PowerShell module
# Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
$devices = Get-MgDeviceManagementManagedDevice -All |
Select-Object DeviceName, OperatingSystem, OsVersion, ComplianceState, LastSyncDateTime
$devices | Sort-Object ComplianceState, DeviceName | Format-Table -AutoSize
Use this for visibility, not enforcement. Enforcement should remain in Intune + Conditional Access so it stays consistent and supportable.
Wrap-up: what “good” looks like
When you’ve enforced compliance properly, three things happen:
- Users with healthy devices sign in normally.
- Users with unhealthy devices get clear guidance to fix issues before being blocked (or after a short grace period).
- Your critical apps become meaningfully harder to access from risky endpoints.
If you’d like, tell us your mix of platforms (Windows/macOS/iOS/Android), whether devices are BYOD or corporate-owned, and which apps you need to protect first. We can suggest a clean v1 compliance baseline and a rollout plan that won’t overwhelm your service desk.
Discover more from CPI Consulting -Specialist Azure Consultancy
Subscribe to get the latest posts sent to your email.