By default, a device with no compliance policy assigned counts as compliant. Check that setting today.
Microsoft states the default value of "mark devices with no compliance policy assigned as" is compliant, and describes that as the security feature being off. If your Conditional Access requires a compliant device and this is still at default, a device nobody has ever assessed passes the check.
- 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.
It takes two minutes to check and it is the most consequential single setting in Intune compliance. Microsoft documents both the default and the instruction.
- The setting is under Endpoint security, then Device compliance, then Compliance policy settings. It is called mark devices with no compliance policy assigned as, and its two values are compliant and not compliant.
- The default is compliant, and Microsoft describes that value explicitly as the security feature being off. A device that has never been assigned any compliance policy is therefore treated as compliant by the service.
- Microsoft then states the fix directly: if you use Conditional Access with your device compliance policies, change this setting to not compliant to ensure that only devices confirmed as compliant can access your resources. Leaving it at default while relying on Conditional Access is a gap, not a preference.
- Change it carefully rather than casually. Flipping it to not compliant will block any device that has no policy assigned, which is exactly the point, and also exactly why you want to know which devices those are before you do it. That is a report, not a guess, and it is where we usually start.
Eight things about compliance policies that decide whether the control is real.
The unassigned device default, which is the finding we make most often
The tenant-wide setting for how to treat a device with no compliance policy assigned defaults to compliant, and Microsoft describes that as the security feature being off. Microsoft then instructs directly: if you use Conditional Access with device compliance policies, change this to not compliant so that only devices confirmed as compliant can access resources. In most tenants we assess, it is still at the default.
The validity period, which quietly decides what stale means
Devices must successfully report on all their received compliance policies within a period, and a device that fails to report before it expires is treated as noncompliant. The default is thirty days and it is configurable from one to one hundred and twenty. Thirty days is a long time for a device to have gone silent and still be treated as compliant, and shortening it is usually the right call.
What a policy can actually check
Rules include requiring a minimum operating system version, the device not being jailbroken or rooted, and being at or under a threat level reported by threat management software integrated with Intune. Available settings depend on the platform, and Microsoft is explicit that each platform type requires a separate policy, which is why a partial rollout usually means one platform was forgotten.
Remediated versus quarantined, which is not the same thing
Microsoft distinguishes them clearly. Remediated means the operating system enforces compliance, giving the example of a user being forced to set a PIN. Quarantined means it does not, giving the example that Android devices do not force the user to encrypt. In the quarantined case the device is blocked if a Conditional Access policy applies and the Company Portal notifies the user. Encryption is quarantined on Android, macOS, Linux and Windows.
Actions that escalate rather than just flag
Every policy marks a device noncompliant by default, and further actions can be added by platform: email alerts to users and groups, sent immediately and then periodically until the device becomes compliant, remote lock after a device has been noncompliant for some time, and retirement. That escalation ladder is what turns a compliance report into something that actually gets fixed.
Retirement, which needs an explicit human action
The retire action marks a qualifying device as ready to be retired, an administrator then reviews the list of devices marked for retirement, and must take an explicit action to retire one or more of them. Retiring removes the device from Intune management and removes all company data. Microsoft has deliberately made this a two-step process, and that design is worth preserving in how you operate it.
Custom compliance settings, for what is not built in
Custom compliance settings let you base compliance on settings available on a device without waiting for Intune to add them, supported on Windows, macOS and Linux, specifically Ubuntu Desktop 24.04 or 26.04 LTS and Red Hat Enterprise Linux 9 or 10. For organisations with a specific requirement that no built-in setting covers, this is the escape hatch that avoids a wait.
Evaluation timing, and a Windows improvement in preview
Compliance evaluation depends on when a device checks in and on the policy refresh cycles, which is why a change does not take effect immediately. For Windows, Microsoft has a client-driven compliance evaluation capability in preview, where supported devices proactively request re-evaluation when local state changes are detected. That shortens the gap between fixing something and being marked compliant.
Four things we check that most compliance deployments miss.
We check the unassigned device setting first, every time
It is the difference between Conditional Access enforcing device compliance and Conditional Access appearing to. Microsoft documents the default as compliant, describes it as the security feature being off, and instructs you to change it if you use Conditional Access. We check it before looking at anything else, and it is wrong in most tenants we see.
We find the devices with no policy before flipping the switch
Changing the setting to not compliant will block every device that has no policy assigned, which is the intended behaviour and also a support incident if you do not know who they are first. We produce that list, work out why those devices were missed, usually a platform without a policy, and fix the cause before changing the default.
We cover every platform, including the ones nobody mentions
Each platform type requires its own policy, and settings references exist for Android device administrator, Android Enterprise, Android Open Source Project, iOS, Linux, macOS, Windows Holographic for Business and Windows. The Linux and macOS estates are the ones consistently forgotten, and they are also the ones most likely to be running without a policy at all.
We design the escalation rather than only marking devices
Every policy marks a device noncompliant by default and that alone changes nothing. Email to the user immediately and then periodically until it is fixed, remote lock after a defined period where appropriate, and retirement as a deliberate last step reviewed by a person. Without that ladder, a compliance dashboard just accumulates red.
Six UAE situations where compliance policy configuration is the gap.
A regulated firm relying on device-based Conditional Access
Where the control being described to a regulator, an auditor or a client is that only compliant devices can access company resources, the unassigned device setting determines whether that statement is true. Left at default, a device that has never been assessed satisfies the requirement, which makes the assurance inaccurate rather than merely weak.
An organisation whose Intune deployment grew platform by platform
Windows first, then iPhones, then somebody brought a Mac. Because each platform type requires its own policy, the platforms added later frequently have no compliance policy at all. Those devices then pass the compliance check by default, and the gap is invisible on a dashboard that only shows what has been assessed.
A distributed estate where devices go quiet
Site offices, retail units, seasonal operations where a device may not check in for weeks. The thirty day default validity period means a device silent for four weeks is still treated as compliant. Shortening that period is a small change with a real effect on how accurate your compliance picture is.
A business that has never acted on a noncompliant device
The dashboard shows a number, nobody does anything, and it grows. Configuring email alerts to the user immediately and then periodically until the device is fixed puts the remediation where it belongs, with the person who can restart their machine or accept an update, rather than with an IT queue.
An estate including Linux or macOS servers and workstations
Both are supported by compliance policies, both support custom compliance settings, and both are routinely outside the scope of whatever was configured for Windows. For organisations with engineering, development or media teams, this is usually where the unassessed devices actually are.
An organisation frustrated by slow compliance evaluation
Somebody fixes their device, and it stays marked noncompliant until the next check-in, which generates a support call. For Windows, the client-driven compliance evaluation capability in preview lets supported devices proactively request re-evaluation when local state changes, which shortens that gap considerably.
How device compliance is actually configured in UAE tenants.
| 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 | Strong | Misleading | None |
Frequency in the UAE market | Uncommon | Very common | Common in SMEs |
Remediated or quarantined, by setting and platform.
| Setting | What happens | |
|---|---|---|
| PIN or password configuration | Remediated on iOS, macOS and Windows. Quarantined on Android and Linux. | |
| Device encryption | Remediated on iOS by setting a PIN. Quarantined on Android, Android Enterprise, macOS, Linux and Windows. | |
| Minimum or maximum OS version | Quarantined on every platform. The user is blocked and told, not upgraded. | |
| Jailbroken or rooted device | Quarantined on Android and iOS. Not a configurable setting, and not applicable to macOS, Linux or Windows. | |
| Email profile | Quarantined on iOS and macOS. Not applicable on Android, Linux or Windows. | |
| Windows health attestation | Quarantined, and applicable to Windows only. | |
| Allowed distributions | Linux only, quarantined. |
Five steps, and the first one takes two minutes.
- 1
Check the tenant-wide compliance policy settings
How unassigned devices are treated, and what the compliance status validity period is set to. Two settings, two minutes, and they determine whether everything else in the deployment produces a real control or an appearance of one.
- 2
Find the devices with no policy assigned
Before changing anything, because switching the default to not compliant will block them. Usually this reveals an entire platform that was never covered, which is a policy to write rather than a set of devices to chase.
- 3
Write or complete a policy for every platform
Windows, iOS, macOS, Android in its relevant flavours, and Linux where present, since each platform type requires its own policy. Custom compliance settings where a requirement is not covered by a built-in setting, which is supported on Windows, macOS and Linux.
- 4
Configure the escalation ladder
Email to the user immediately on noncompliance and then periodically until fixed, remote lock after a defined period where that is appropriate to the population, and retirement as a deliberate final step. Retirement removes management and all company data, and requires an explicit administrator action.
- 5
Change the default, then monitor
With the platform gaps closed and the population understood, switch unassigned devices to not compliant so Conditional Access enforces what everybody already believes it enforces. Then a regular review of the compliance dashboard, because the picture drifts as devices and platforms are added.
What organisations 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 defence 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 enrolment, 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
Entra Conditional Access
The control that decides who reaches your data
Microsoft Intune
Device management and endpoint security
App Protection Policies
Protect company data on a phone you will never be allowed to manage
MDM Solutions Dubai
Device management across Windows, Apple and Android
Endpoint Security
Defender for Endpoint and Intune managed
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you
Intune Suite
Eight advanced capabilities, and one trial each per tenant
Microsoft 365 Security Audit
Tenant review, and how far back your evidence really goes