The Intune device that passes Conditional Access without ever being checked

A device enrolls in Intune, lands in no group any compliance policy targets, and reports up to Entra as Compliant. Your Conditional Access policy reads that status, sees the green bit, and lets it through the “require device to be marked as compliant” gate. The device was never checked against a single rule. It didn’t fail your BitLocker requirement or your minimum-OS floor. Those rules never ran on it, and the tenant handed it a passing grade anyway.

That’s the default behavior, not a bug. This installment of Checks you can run today is one tenant-wide setting, the platform-coverage checks around it, and the safe way to flip it.

What you’re dealing with

Intune splits compliance into two layers. The layer you work in daily is the set of per-platform device compliance policies you author and assign. Underneath sits a tenant-wide layer, the compliance policy settings, that acts like a built-in policy every enrolled device receives automatically. That lower layer decides the fate of a device no assigned policy ever targeted. Its controlling toggle, Mark devices with no compliance policy assigned as, ships set to Compliant, which Microsoft’s own doc describes as “this security feature is off.” Conditional Access reads only the compliant/non-compliant bit; it has no visibility into whether a policy was ever evaluated. So an unpoliced device fails open, not closed.

The check: the tenant setting itself

Location: Endpoint security > Device compliance > Compliance policy settings. (Older docs route through Devices > Compliance policies > Compliance policy settings. Same setting.)

• Bad: Mark devices with no compliance policy assigned as is set to Compliant. Unpoliced devices clear “require compliant device” CA rules without evaluation.
• Good: Set to Not compliant. Unpoliced devices are blocked by those same rules. This is what the Maester security baseline encodes as MT.1054: “Not compliant” is the expected secure configuration.
• Fix: Flip it. But not blind. Flipping it carelessly locks out every device on a platform you forgot to write a policy for. The procedure below stages it.

While you’re on that blade, note the Compliance status validity period (default 30 days, range 1-120, same doc). A device that goes dark past that window is treated as noncompliant regardless of last known state. It’s a useful grace buffer when you stage the change.

The checks: coverage and assignment

The tenant setting is worthless if your policies don’t reach every device to begin with. Four gaps let devices ride the default even after you flip it. Run each check.

• Platform coverage. For every platform enrolled (Windows, macOS, iOS/iPadOS, Android, Linux), confirm at least one device compliance policy exists and is assigned.

  • Bad: a platform with zero policies. Every device on it is permanently unpoliced.
  • Good: every enrolled platform has an assigned policy.
  • Fix: author a baseline policy for the bare platform before you flip the tenant switch, or those devices flip to blocked the moment you save.

• Assignment target type. Built-in compliance evaluation runs per device, while many custom policies get assigned to user groups. A shared kiosk, a device with no primary user, or a bulk-enrolled machine can end up compliance-blind.

  • Bad: Surface Hub, bulk-enrolled, or Device Enrollment Manager Windows devices assigned only through user groups. Microsoft confirms these need device-group assignment or CA evaluation breaks.
  • Good: userless and bulk-enrolled devices covered by a device-group-targeted policy.
  • Fix: add a device-group assignment for the userless population.

• Filters and exclusions. Check each policy’s Assignments for excluded groups and filters. An excluded user is never evaluated regardless of the tenant switch, and a filter meant to carve out test devices can widen and drop production machines out of scope.

  • Bad: a production group sitting inside an exclusion or filtered out.
  • Good: exclusions scoped tight to genuine test/break-glass accounts.
  • Fix: narrow the exclusion, or confirm the excluded population is one you actually intend to leave unevaluated.

The safe flip, in order

Do not toggle the setting and walk away. Stage it.

A. Audit before you touch anything

1. Endpoint security > Device compliance > Compliance policy settings. Read the current value of Mark devices with no compliance policy assigned as and note the validity period.
2. Devices > Monitor > Setting compliance. The tenant default surfaces per device as the Is active row in the Setting column. This is your count of devices riding the default instead of a real policy.
3. Work the three coverage checks above (platforms, target type, exclusions). Anything you find here becomes a device that gets blocked the instant you flip the switch, so fix coverage first.

B. Stage so you don’t lock anyone out

4. Put the relevant Conditional Access policy into Report-only first. Report-only mode evaluates policies but never enforces grant controls, so you see who would be blocked without blocking them.
5. Watch Conditional Access > Insights and reporting for roughly 7 to 14 days. Optionally pilot with a scoped test group and lean on the validity-period window as an added buffer.

C. Flip and verify

6. In Compliance policy settings, set the toggle to Not compliant. Save.
7. Re-check Devices > Monitor > Setting compliance (the Is active row), then drill into Devices > All devices > [device] > Device compliance to watch unpoliced devices flip to noncompliant.
8. Confirm the report-only logs (or the sign-in log’s Conditional Access tab) show the allow/block outcomes you expect. Then switch the CA policy from Report-only to On.

Rollback: revert the setting to Compliant. Propagation follows normal policy and device check-in cadence. Microsoft publishes no SLA for it, so don’t promise a five-minute rollback to a panicking help desk.

Auditing at scale, and what you can’t do

There’s no Graph property for the toggle itself. deviceCompliancePolicySettingStateSummary is a reporting resource (setting name, platform type, compliant/noncompliant/unknown device counts). It reads the effect of the setting across your fleet, not the switch’s value, and no Graph resource for the switch itself is documented. If you want a standing detection rather than a one-time audit, glueckkanja publishes a KQL query that surfaces devices marked compliant via the default rather than an evaluated policy. Worth wiring into a monitored tenant. Not a substitute for the flip.

When this bites you

No named breach traces to this default. The risk is well-documented and latent, a misconfiguration sitting quiet, not an incident anyone has published. That’s exactly why it survives audits. Nobody gets paged for it.

It’s also not the only Intune default that fails open. Conditional Access policies sit in report-only until someone switches them On. Enrollment restrictions apply a permissive default until a higher-priority policy overrides it. Disabling Security Defaults and building Conditional Access aren’t one atomic step, so a tenant can run with no baseline MFA in the gap between them. The through-line is worth pinning to the wall: a policy you configured is not the same as a policy that’s enforced, and the fallback for anything you haven’t locked down is usually “allow.” Audit not just which policies exist, but what happens to the device that none of them touch.

Sources

• Device compliance policies in Microsoft Intune
• Troubleshoot Intune Conditional Access
• Conditional Access report-only mode
• Overview of enrollment restrictions in Microsoft Intune
• Configure Security Defaults for Microsoft Entra ID
• deviceCompliancePolicySettingStateSummary resource type (Microsoft Graph)
• Maester MT.1054 — devices with no compliance policy marked Not compliant
• Call4Cloud — Not Compliant: the built-in Default Device Compliance Policy
• glueckkanja — Compliant Device Bypass in Microsoft Intune