Intune device compliance policies evaluate managed devices against rules you define and report a pass or fail status back to Microsoft Entra ID. That status determines whether Conditional Access lets the device through or blocks it, whether Intune sends a notification or triggers a remote lock, and what shows up on your compliance dashboards. Get the tenant defaults wrong, and you either lock out legitimate users or let unmanaged devices walk right past your security controls.
TL;DR:
- Default tenant settings often treat unenforced devices as compliant, risking unauthorized access if not changed to noncompliant.
- Noncompliant devices are flagged immediately by default, but customizing action schedules helps prevent user overwhelm and support overloads.
- Creating effective policies requires platform-specific rules, clear naming conventions, and assigning policies to device groups rather than users.
- Regular monitoring of compliance trends and setting appropriate check-in validity periods are crucial for maintaining security and reducing false noncompliance.
- Most issues stem from unenrolled devices, outdated policies, or incorrect group assignments, making thorough validation before deployment essential.
Table of Contents
- What Is Intune Device Compliance and How Does It Fit Together?
- Compliance Policy Settings: Tenant-Wide Defaults That Change Everything
- How Do You Create a Device Compliance Policy in Intune?
- What Happens When a Device Becomes Noncompliant?
- How Does Compliance Status Affect Conditional Access?
- How Do You Monitor Device Compliance in Intune?
- When Should You Use Custom Compliance Settings?
- Troubleshooting Checklist and Deployment Best Practices
- What SMBs Get Wrong About Intune Compliance Rollouts
- Get Help Designing and Managing Intune Compliance Policies
- Sources
What Is Intune Device Compliance and How Does It Fit Together?
Intune compliance policies check specific conditions on a managed device, things like minimum OS version, encryption status, password complexity, or jailbreak/root detection, and assign one of several states. Understanding the vocabulary matters before you touch a single setting.
A device is compliant when it meets every rule in every assigned policy. It's noncompliant the moment it fails one rule, and Intune can then trigger the actions you've configured. Remediated means a previously noncompliant device fixed the underlying issue and passed on its next check-in. A quarantined or "lost contact" device is one that hasn't checked in within its window and gets flagged separately from a rule failure.
There's also a distinction worth sitting with: tenant-wide compliance policy settings control default behavior across your entire environment, while individual compliance policies define the specific rules for a platform or device group. They work together, not interchangeably.
Supported platforms include:
- Windows 10/11
- iOS/iPadOS
- Android (Enterprise and personally owned)
- macOS
- Linux (Ubuntu Desktop, with more limited rule sets)
A device has to be enrolled in Intune before it can report a compliance status at all. Unenrolled devices simply have nothing to evaluate, which is a common source of confusion during rollout.
Compliance Policy Settings: Tenant-Wide Defaults That Change Everything
Two tenant-wide settings quietly decide how forgiving your environment is, and most admins never touch them during initial setup. That's a mistake.
The first is "Mark devices with no compliance policy assigned as." It defaults to Compliant, meaning any enrolled device without an explicit policy assigned to it is treated as trustworthy by Conditional Access. For most SMB environments, that's backwards. If a device slips through without a policy, letting it access email and SharePoint without meeting any bar defeats the purpose of enforcing compliance elsewhere. Switching this default to Not compliant is one of the simplest, highest-impact hardening moves you can make in Intune.
The second is the compliance status validity period, which has a default and a configurable range that can be adjusted according to organizational needs. This controls how often a device has to check in and re-confirm its status before Intune considers the data stale.
Both settings live under Devices > Compliance policies > Compliance policy settings in the Intune admin center. Before you flip the default to Not compliant, run through this checklist:
- Confirm every production device group has an assigned compliance policy.
- Check your Conditional Access policies for exclusions that might mask gaps.
- Set a validity period short enough to catch stale devices, but not so short it generates check-in noise.
- Pilot the change on a test group for a few days before applying it tenant-wide.
Pro Tip: Run a pilot group with the default left at Compliant while you validate policy logic, then flip production to Not compliant once you've confirmed no legitimate devices are missing an assignment. Flipping the default before your assignments are clean is the single most common cause of accidental lockouts.
How Do You Create a Device Compliance Policy in Intune?
Building a policy in the Intune admin center follows a consistent sequence regardless of platform:
- Navigate to Devices > Compliance policies > Policies > Create policy.
- Choose the platform (Windows 10/11, iOS/iPadOS, Android Enterprise, macOS, or Linux).
- Name the policy clearly, including the platform and purpose (for example, "Win11 - Encryption and Password Baseline").
- Configure the compliance settings themselves, minimum OS version, disk encryption, password requirements, jailbreak/root detection, threat level thresholds if you're integrating Microsoft Defender.
- Set actions for noncompliance and their schedules.
- Apply scope tags if you use role-based delegation.
- Assign the policy to device or user groups.
- Review and save.
Platform quirks matter here. Android Enterprise splits rules by enrollment type (fully managed, work profile, dedicated), so a rule set built for corporate-owned devices won't map cleanly onto BYOD. iOS compliance leans heavily on supervised-device capabilities that unsupervised personal devices simply can't satisfy. Windows offers the deepest rule set, including Microsoft Defender for Endpoint risk score integration. Linux support, meanwhile, is newer and narrower, mostly OS version and disk encryption checks on Ubuntu Desktop.
A few practices consistently save headaches:
- Use device groups rather than user groups for compliance assignment. Reporting maps more cleanly to hardware, especially when one person has multiple devices.
- Adopt a naming convention early: platform, purpose, and version number in every policy name.
- Use scope tags to delegate policy visibility to regional or departmental IT teams without exposing the whole tenant.
What Happens When a Device Becomes Noncompliant?
Every compliance policy includes a built-in action: mark device noncompliant, scheduled at 0 days by default. That means the instant a device fails a rule, Intune flags it immediately, no grace period unless you add one.
If Conditional Access is enforcing "require device to be marked as compliant," that zero-day default has real teeth: the device loses access to protected resources the moment it fails a check. That's exactly the point for something like a missing disk encryption flag, but it can feel abrupt for a device that's simply a few days behind on an OS update.
Beyond the default action, you can layer in:
- Send an email notification to the user, with a customizable message pointing them to remediation steps.
- Send a push notification through the Company Portal app.
- Remotely lock the device.
- Add the device to a retire list after a defined noncompliance window.
Schedules for these actions can run anywhere from 0 to 365 days after the initial failure, and platform support varies. Remote lock, for instance, behaves differently on Windows versus iOS.
Risk profile should drive your schedule choices. A healthcare organization handling PHI might keep the noncompliance-to-lock window at 3 to 5 days for encryption failures. A professional services firm with lower regulatory exposure might extend email-first grace periods to 14 days for OS version lag, reserving harsher enforcement for password and encryption rules.
Pro Tip: Stagger your actions instead of firing them all at 0 days. Send an email at day 0, a push notification at day 3, and reserve remote lock or retirement for day 7 or beyond. Users fix most issues themselves once they're actually notified, and staggering avoids flooding your help desk with same-day panic calls.
How Does Compliance Status Affect Conditional Access?
Compliance status flows from Intune to Microsoft Entra ID, where Conditional Access policies use it as a signal for access decisions. A device marked compliant satisfies the "require device to be marked as compliant" grant control; a noncompliant one gets blocked from whatever resource that policy protects, Exchange Online, SharePoint, or a custom app.
This is where tenant defaults and Conditional Access design have to be considered together, not separately. Getting the mapping right takes a few deliberate steps:
- Pilot every new Conditional Access policy tied to compliance on a small group before tenant-wide rollout.
- Build a break-glass exclusion group for emergency access, and audit it regularly so it doesn't become a permanent bypass.
- Match each compliance rule to the specific resource it's meant to protect, rather than applying one blanket policy everywhere.
- Confirm your Microsoft Entra licensing covers the Conditional Access features you're planning to use, since some controls require Entra ID P1 or P2.
The most common failure mode isn't a misconfigured rule. It's the tenant default treating unassigned devices as Compliant, combined with a check-in frequency long enough that a device can drift out of compliance for days before Conditional Access ever notices. Both are fixable with the settings covered earlier, but only if you check for them before go-live, not after a security incident forces the question.
How Do You Monitor Device Compliance in Intune?
The Device compliance dashboard under Reports > Device compliance gives you the tenant-wide view: how many devices are compliant, noncompliant, in grace period, or not evaluated. The Noncompliant devices and settings report goes a level deeper, breaking down failures by the specific setting that tripped them, encryption, password, OS version, so you're not guessing what to fix.
Turning that data into an actual workflow takes structure:
- Assign an owner for the weekly compliance review, not just a shared inbox that everyone ignores.
- Set an alerting cadence: daily for Conditional Access-tied policies, weekly for lower-risk baseline checks.
- Drill into per-setting failure counts before broadcasting a fix to your whole user base. A spike in one setting usually points to a single root cause, like a delayed OS rollout, rather than scattered individual problems.
- Track trend lines over weeks, not just point-in-time snapshots, to catch policies that are quietly degrading.
Monitoring per-setting failure trends helps you prioritize which rule to fix first instead of enforcing everything at once and generating a wave of help desk tickets you can't triage fast enough. A device that stops checking in entirely triggers a separate "lost contact" flow, and if it fails to re-enroll after a follow-up check, Intune can issue a retire command so the user can start clean.
When Should You Use Custom Compliance Settings?
Built-in settings cover most standard checks, but they don't reach into third-party software versions, custom registry keys, or organization-specific hardening requirements. That's where custom compliance settings come in.
The workflow has four parts:
- Write a discovery script, PowerShell for Windows, POSIX shell for Linux and macOS, that outputs the values you want to evaluate.
- Author a JSON rule file defining the acceptable values, operators, and remediation messages tied to those outputs.
- Upload both the script and the JSON file to Intune.
- Select the custom compliance script when building or editing a compliance policy.
Windows relies on the Intune Management Extension to run the discovery script, and if that extension isn't installed or the script errors out, you'll see failure codes in the 65007 to 65010 range. Most of those trace back to script syntax issues or a missing extension rather than a genuine device failure, so check the script output logs before assuming a widespread compliance problem.
Custom checks can take longer to reflect on the dashboard, sometimes up to 8 hours for the status to fully propagate, so don't panic if a fix doesn't show as remediated within minutes.
Pro Tip: Test every discovery script against a small pilot device before deploying it tenant-wide. A script that works flawlessly in your own PowerShell session can still fail silently under the Intune Management Extension's execution context, and you don't want to discover that on 200 production laptops.
Troubleshooting Checklist and Deployment Best Practices
Most compliance issues Secure Techies encounters during client rollouts trace back to a short list of root causes, not exotic edge cases. Work through these before escalating:
- Confirm the device is actually enrolled; unenrolled devices report nothing.
- Verify the compliance policy is assigned to the correct device or user group, not a stale test group.
- Check the last check-in timestamp against your validity period. A device outside that window shows as noncompliant even if it technically meets every rule.
- Have the user open Company Portal and confirm the device shows up with current sync status.
- Confirm Conditional Access licensing (Entra ID P1/P2) is active for any policy that gates access on compliance.
For security-focused SMBs, our platform and enrollment guidance generally recommends: tenant default set to Not compliant, validity period around 14 to 30 days depending on device check-in frequency, and staged noncompliance actions rather than immediate hard blocks.
Change management discipline prevents the worst outcomes. Use consistent scope tags before delegating anything to regional teams, document every policy name with its intended purpose, and never push a compliance-tied Conditional Access change to "All Users" without a pilot group first.
Pro Tip: Keep a rollback plan documented before every Conditional Access change tied to compliance. If a mass lockout happens anyway, being able to disable the policy in under five minutes is the difference between a minor incident and a help desk fire drill.
What SMBs Get Wrong About Intune Compliance Rollouts
Most small and mid-size organizations we've worked with treat compliance policy as a checkbox exercise: turn it on, apply a template, move on. That's how tenants end up with the "no policy assigned" default left at Compliant for months, quietly undermining every Conditional Access rule layered on top of it.
The organizations that get this right treat Intune compliance as an operational program, not a one-time configuration task. Our Intune rollout case study walks through how that looks in practice for an SMB environment. If your current setup hasn't been reviewed since initial deployment, it's worth having someone take a second look.
— Alex
Get Help Designing and Managing Intune Compliance Policies
Securetechie is the practical alternative to piecing together Intune policy design on your own between other IT priorities. For Southern California businesses juggling HIPAA, CMMC, or SOC 2 requirements alongside day-to-day device management, getting tenant defaults, Conditional Access mapping, and noncompliance schedules right the first time saves you from the trial-and-error most teams go through.
We design compliance policies matched to your actual risk profile, run pilot deployments before anything touches production, and monitor the results to help ensure noncompliant devices get caught and remediated promptly. That includes compliance audit support for organizations that need their Intune configuration to hold up under HIPAA, CMMC, or SOC 2 review.
If your current policies were set up years ago, or never got past the default template, request an assessment through our managed IT services page and find out exactly where your compliance posture stands today.