By default, a device with no compliance policy assigned counts as compliant. Check that setting today.
The documented default for how unassigned devices are treated is compliant, and the documentation itself characterizes that value as the security feature being switched off. Now line up three things. Your access policies demand a compliant device. Your insurance application states that only managed hardware reaches company data. And this setting has never been touched. A machine nobody has ever evaluated sails through.
- CompliantThe default for unassigned devices
- 30 daysDefault compliance reporting validity period
- Per platformEach platform needs its own policy
- QuarantinedWhat most non-iOS settings actually do
The default setting that lets unassessed devices through Conditional Access.
Two minutes to verify, and it is comfortably the most consequential single value in the entire compliance area. Both the default and the recommended change are documented, so nobody has to take our word for any of this.
- Navigate to Endpoint security, then Device compliance, then Compliance policy settings. You are looking for the setting governing how devices with no compliance policy assigned should be marked. It offers exactly two values.
- It ships set to compliant, and that value is described in the documentation as the security feature being off. So any machine that has never had a compliance policy assigned to it is, as far as the service is concerned, compliant.
- The prescribed fix is stated without ambiguity: anyone combining Conditional Access with compliance policies should switch it, so that only confirmed-compliant devices reach company resources. Leaving it alone while depending on Conditional Access is not a configuration preference, it is a hole.
- Do change it, but do it with your eyes open. Switching the value blocks every device currently lacking a policy, which is precisely the intent and precisely why you want that list in front of you beforehand. Pull the report rather than estimating, because in our experience the number is never what people guess.
Eight things about compliance policies that decide whether the control is real.
The unassigned device default, which is the finding we make most often
There is one tenant-wide setting deciding what happens to a machine nobody assigned a policy to, and out of the box it says compliant, a value the documentation itself equates to the feature being off. The instruction that follows is direct: anyone using Conditional Access alongside compliance policies should change it, so that only confirmed devices get through. In the overwhelming majority of tenants we assess, nobody ever has.
The validity period, which quietly decides what stale means
Every machine has to report back on the policies it received inside a defined window, and one that goes quiet past that window flips to noncompliant. You get thirty days by default, adjustable anywhere from one to a hundred and twenty. Sit with thirty for a moment. A laptop can be unreachable for a calendar month and still be counted as compliant throughout, which is why shortening this is usually the right instinct.
What a policy can actually check
Typical rules cover a floor on the operating system version, confirmation the device has not been jailbroken or rooted, and a ceiling on the threat level reported by whatever defense product you have integrated. Which settings exist varies by platform, and since each platform demands its own separate policy, a rollout that only half worked almost always means somebody forgot a platform entirely.
Remediated versus quarantined, which is not the same thing
The distinction is drawn clearly and it matters enormously. Remediation means the operating system itself makes the fix happen, the canonical example being a user compelled to set a PIN. Quarantine means it does not, the example given being that Android will not force encryption on anybody. In the quarantine case the machine simply gets blocked wherever a Conditional Access policy reaches it, and the Company Portal explains why. Encryption falls into quarantine on Android, macOS, Linux and Windows alike.
Actions that escalate rather than just flag
Marking a device noncompliant happens automatically in every policy, and by itself accomplishes very little. What you can add on top, varying by platform, is email to the user and to groups, going out immediately and then repeating until the problem is resolved, a remote lock once a machine has been failing for a defined stretch, and eventually retirement. That ladder is the difference between a report full of red rows and problems that actually get closed.
Retirement, which needs an explicit human action
The action flags a qualifying machine as ready to retire and then stops. Somebody has to open that list, look at it, and deliberately act before anything happens, at which point the device leaves management and all company data comes off it. That two-step design is intentional, and the way you operate the process should preserve the intent rather than automating the second step away because it feels like friction.
Custom compliance settings, for what is not built in
Where a requirement exists that no built-in setting expresses, custom compliance lets you evaluate against settings present on the device without waiting for the product to catch up. Support covers Windows, macOS and Linux, the latter specifically meaning Ubuntu Desktop 24.04 or 26.04 LTS and Red Hat Enterprise Linux 9 or 10. It is the escape hatch, and knowing it exists saves organizations from designing around a gap unnecessarily.
Evaluation timing, and a Windows improvement in preview
When evaluation happens depends on device check-in and on the refresh cycles, which explains why fixing something does not immediately clear the status and why your service desk fields calls about it. On Windows there is a client-driven capability in preview where a device notices its own state has changed and asks to be re-evaluated, closing much of the gap between somebody resolving a problem and the console agreeing they did.
Four things we check that most compliance deployments miss.
We check the unassigned device setting first, every time
This one value separates Conditional Access genuinely enforcing compliance from Conditional Access giving a convincing impression of it. The default is documented, the documentation calls that default the feature being off, and it tells you to change it when Conditional Access is in play. So it is the first thing we open, ahead of anything else, and in most tenants we find it untouched.
We find the devices with no policy before flipping the switch
Making that change blocks every machine currently without a policy. That is the intended behavior and it is also a Monday morning full of tickets if nobody established the list first. So we produce it, establish why those devices slipped through, which nine times out of ten is a platform that never got a policy at all, and correct the cause before touching the setting.
We cover every platform, including the ones nobody mentions
Since every platform type needs a policy of its own, and references exist across the full range from the various Android flavors through iOS, Linux, macOS, Windows and Windows Holographic for Business, the gaps are usually gaps of attention rather than intent. It is consistently Linux and macOS that get overlooked, and consistently those same populations running with no policy at all.
We design the escalation rather than only marking devices
Marking a device noncompliant is automatic and, on its own, changes nothing about anybody behavior. What changes behavior is mail reaching the user straight away and again periodically until they act, a remote lock after a defined interval where that is proportionate, and retirement as a final step a human being signs off. Without that sequence, your dashboard simply accumulates red rows that everybody learns to scroll past.
Six situations where compliance policy configuration is the gap.
A firm relying on device-based Conditional Access for compliance evidence
You have told a SOC 2 auditor, a HIPAA risk assessment, an insurance carrier or a large customer that only compliant devices reach company resources. Whether that sentence is true rests entirely on one setting. At its default, hardware nobody has ever evaluated meets the requirement, which does not make your assurance weak. It makes it inaccurate, and those are different problems with different consequences.
An organization whose Intune deployment grew platform by platform
Windows came first, phones followed, and eventually a designer turned up with a Mac. Since every platform type demands its own policy, whatever arrived latest very often has none at all. Those machines then clear the compliance check by default, and nothing on a dashboard that only displays assessed devices will ever draw your attention to them.
A distributed estate where devices go quiet
Branches, store locations, field crews, seasonal operations where hardware genuinely does not connect for weeks at a stretch. With the default validity window, a machine that has said nothing for a month still counts as compliant the entire time. Tightening that window is a two minute change that materially improves how honest your compliance picture is.
A business that has never acted on a noncompliant device
There is a number on a dashboard, nobody owns it, and it climbs quarter after quarter. Sending mail to the user the moment they fail and then again periodically until they act moves the work to the only person who can actually do it, namely the one who needs to restart their laptop or accept an update, instead of parking it in an IT queue where it will sit.
An estate including Linux or macOS workstations
Compliance policies cover both, custom compliance settings cover both, and both sit routinely outside whatever scope somebody defined for Windows years ago. Anywhere there is an engineering group, a development team or a creative department, this is reliably where your unassessed machines turn out to be hiding.
An organization frustrated by slow compliance evaluation
A user does exactly what they were asked, their machine stays red until the next check-in, and they call the service desk to complain about it. On Windows the client-driven evaluation capability currently in preview has supported devices notice their own state has changed and ask to be reassessed, which shrinks that window substantially and takes a recurring irritation off your desk.
How device compliance is actually configured in the tenants we see.
| Feature | Configured properly | Policies exist, default left on | No compliance policies |
|---|---|---|---|
Compliance policies deployed | Yes | Yes | No |
Unassigned devices treated as not compliant | Yes | No | Not applicable |
Conditional Access actually blocks unassessed devices | Yes | No | No |
A policy exists for every platform in use | Yes | Usually not | No |
Validity period set deliberately | Yes | Default 30 days | Not applicable |
Users notified when their device fails | Yes | Sometimes | No |
Escalation beyond marking noncompliant | Yes | Rarely | No |
Devices ready to retire reviewed | Yes | No | Not applicable |
Evidence for an auditor or insurer | Strong | Misleading | None |
How common this is | Uncommon | Very common | Common in small businesses |
Remediated or quarantined, by setting and platform.
Setting
PIN or password configuration
- What happens
- Remediated on iOS, macOS and Windows. Quarantined on Android and Linux.
Setting
Device encryption
- What happens
- Remediated on iOS by setting a PIN. Quarantined on Android, Android Enterprise, macOS, Linux and Windows.
Setting
Minimum or maximum OS version
- What happens
- Quarantined on every platform. The user is blocked and told, not upgraded.
Setting
Jailbroken or rooted device
- What happens
- Quarantined on Android and iOS. Not a configurable setting, and not applicable to macOS, Linux or Windows.
Setting
Email profile
- What happens
- Quarantined on iOS and macOS. Not applicable on Android, Linux or Windows.
Setting
Windows health attestation
- What happens
- Quarantined, and applicable to Windows only.
Setting
Allowed distributions
- What happens
- Linux only, quarantined.
Five steps, and the first one takes two minutes.
- 1
Check the tenant-wide compliance policy settings
Two values get opened: how unassigned hardware is marked, and how long a device may stay silent before its status expires. It takes about two minutes, and between them those two settings decide whether everything else in your deployment amounts to a control or to a convincing impression of one.
- 2
Find the devices with no policy assigned
This happens before anything is changed, since flipping the default is going to block every one of them. What it typically exposes is not scattered stragglers but a whole platform that was never covered, and that is a single policy to write rather than a list of individuals to chase around the building.
- 3
Write or complete a policy for every platform
One each for Windows, iOS, macOS, whichever Android variants you run, and Linux wherever it exists, because the product requires it that way. Anywhere a genuine requirement has no built-in setting behind it, custom compliance fills the gap, which is available on Windows, macOS and Linux.
- 4
Configure the escalation ladder
Mail goes to the user the moment they fail and repeats until they act. A remote lock follows after a defined interval, where that is proportionate for the population in question. Retirement sits at the end as a deliberate final step, removing management and all company data, and it does not happen without an administrator explicitly choosing it.
- 5
Change the default, then monitor
Platform gaps closed and the affected population understood, the setting finally moves, and Conditional Access begins enforcing what everyone in the organization already assumed it was enforcing. After that it becomes a standing review of the dashboard, because the picture starts drifting again the moment somebody adds a device or a platform.
What organizations ask about Intune compliance policies.
Fifteen questions worth answering.
Tenant-wide settings
- Is unassigned treated as compliant or not compliant?Default is compliant, which Microsoft calls the feature being off.
- Do you rely on Conditional Access for device compliance?If so, Microsoft says change that setting.
- What is your compliance status validity period?Default 30 days, configurable from 1 to 120.
- How many devices currently have no policy assigned?Get the number before changing the setting.
- Who reviews the compliance dashboard, and how often?A report nobody reads changes nothing.
Policy design
- Do you have a policy for every platform in use?Each platform type requires a separate policy.
- Have you included Linux and macOS?Both are supported and both are usually forgotten.
- Is threat level from a defense product included?Compliance can consume it.
- Do any requirements need custom compliance settings?Supported on Windows, macOS and Linux.
- Could a compliance setting conflict with a configuration profile?Microsoft warns compliance can override configuration.
When a device fails
- Does the user get told, and how quickly?Email can be immediate then periodic.
- Is remote lock configured, and after how long?A significant step, so choose the delay deliberately.
- Is retirement configured?It removes management and all company data.
- Who reviews devices marked ready to retire?An explicit human action is required.
- What happens to a device silent for 30 days?The Company Portal remediation flow may issue a retire command.
The pages around this one.
Conditional Access
The policy layer that consumes compliance status, and where the require compliant device control actually lives.
Microsoft Intune
The platform this sits in, covering enrollment, configuration profiles and application deployment.
App protection policies
The complementary control for devices you do not manage at all, where compliance policies do not apply.
Open Endpoint security, Device compliance, Compliance policy settings.
Look at how devices with no compliance policy assigned are treated. If it says compliant, and you rely on Conditional Access, that is a gap Microsoft documents and instructs you to close. Finding the affected devices first is the part worth getting help with.
Related Services
Explore more solutions that work great with this service