Why the Default Behavior Is the Problem

Intune's compliance engine has a default that most admins never change: when a device has no compliance policy assigned, it is marked compliant by default.

This setting lives in Intune > Devices > Compliance policies > Compliance policy settings. The toggle is called Mark devices with no compliance policy assigned as. The default value is Compliant.

Read that again. A device with zero compliance policies applied is, by Microsoft's default configuration, considered compliant. This means it passes Conditional Access checks. It can access Exchange Online, SharePoint, Teams, and any other resource protected by a Conditional Access policy requiring a compliant device.

This default exists for practical reasons: organizations rolling out Intune incrementally need time to assign policies without immediately locking out users. The problem is that this default is almost never revisited after the rollout phase ends. It persists in production tenants for years, silently granting compliant status to devices that have never been evaluated.

---

The Assignment Gap That Multiplies the Risk

The compliance default becomes a fleet-wide problem when combined with a second common pattern: dynamic group misconfiguration.

Most organizations use dynamic device groups to assign compliance policies. A typical query targets enrolled devices:

(device.deviceOSType -eq "Windows") and (device.managementType -eq "MDM")

This looks correct. In practice, it has a timing gap. Dynamic group membership evaluation in Entra ID is not instantaneous — it can lag by minutes to hours depending on tenant size and directory activity. During that window, a newly enrolled device is in Intune, has no group membership, and therefore has no compliance policy assigned.

Under the default configuration, that device is compliant. It can authenticate through Conditional Access. A user can log in, access corporate data, and complete an entire work session before the compliance policy ever applies.

For most devices, this is a brief window. But consider these scenarios where the window extends or becomes permanent:

• A device is enrolled but the dynamic group query has a syntax error that silently excludes it
• A device attribute used in the query (like deviceOSType) is populated incorrectly by the enrollment method
• A device is enrolled via a bulk enrollment token and lands in a different device category than expected
• A Hybrid Entra Join device appears in Intune before its Entra ID object is fully synchronized

In each case, the device never receives a compliance policy. It remains permanently compliant by default. The Intune console shows it as managed. Conditional Access treats it as compliant. Nothing flags it as a problem.

---

How Conflict Resolution Makes It Worse

When a device does receive multiple compliance policies — which happens frequently in organizations that have layered policies over time — Intune's conflict resolution behavior introduces a second failure mode.

Intune evaluates all compliance policies assigned to a device and applies the most restrictive setting across all policies. This sounds correct. The problem is what happens when two policies have conflicting settings that cannot be reconciled — for example, one policy requires BitLocker and another has no BitLocker requirement.

Intune does not error. It does not alert. It marks the specific setting as Not applicable and continues evaluating the rest of the policy. If the overall compliance result is still "compliant" because the conflicting setting was the only non-compliant one, the device passes.

This behavior is documented by Microsoft but not prominently flagged as a risk. The practical result is that a device missing BitLocker encryption can be marked compliant because a policy conflict caused the BitLocker check to be skipped.

Combined with the grace period setting — which defaults to 0 days but is frequently changed to 3, 7, or even 30 days during pilot phases and never reverted — non-compliant devices can remain in a "compliant within grace period" state that Conditional Access treats identically to genuine compliance.

---

Detection: Querying Your Tenant Right Now

The following queries identify devices affected by this misconfiguration pattern. Run these immediately against your own tenant before reading further.

KQL — Devices with no compliance policy assigned (Microsoft Defender for Endpoint / Intune integration via Log Analytics):

// Identify managed devices reporting no compliance policy assignment
// Requires Intune Data Warehouse or MDE integration with Log Analytics
IntuneDevices
| where isnotempty(DeviceId)
| where CompliancePolicyCount == 0
| project DeviceName, DeviceId, OSVersion, LastSyncDateTime, EnrollmentType
| order by LastSyncDateTime desc

KQL — Devices in grace period treated as compliant by Conditional Access:

// Surface devices where compliance state is GracePeriod but CA sees Compliant
SigninLogs
| where TimeGenerated > ago(7d)
| where DeviceDetail.isCompliant == true
| join kind=leftouter (
    IntuneDevices
    | where ComplianceState == "InGracePeriod"
    | project DeviceId, ComplianceState, GracePeriodEndDate
) on $left.DeviceDetail.deviceId == $right.DeviceId
| where isnotempty(ComplianceState)
| project TimeGenerated, UserPrincipalName, DeviceName = DeviceDetail.displayName, ComplianceState, GracePeriodEndDate
| order by TimeGenerated desc

PowerShell — Audit the compliance default setting via Microsoft Graph:

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

$complianceSettings = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/settings"

$defaultCompliance = $complianceSettings.deviceComplianceCheckinThresholdDays
$noCompliancePolicyBehavior = $complianceSettings.isScheduledActionEnabled

Write-Host "Devices with no policy assigned treated as: $($complianceSettings.secureByDefault)"
Write-Host "Check-in threshold (days before non-compliant): $defaultCompliance"

$policies = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies?`$expand=assignments"

foreach ($policy in $policies.value) {
    $assignmentCount = $policy.assignments.Count
    Write-Host "Policy: $($policy.displayName) | Assignments: $assignmentCount | GracePeriod: $($policy.scheduledActionsForRule.gracePeriodHours)"
}

Run the PowerShell block and look specifically at the secureByDefault property. If it returns false, your tenant is in the vulnerable default state. Every device without a compliance policy assignment is currently compliant.

---

The Audit Exposure This Creates

From a governance perspective, this misconfiguration pattern creates three distinct audit findings.

SOC 2 Type II — CC6.1 (Logical and Physical Access Controls): The control requires that access to systems is restricted to authorized users. A device that bypasses compliance evaluation due to a default setting or group assignment gap does not satisfy this control. Auditors reviewing Conditional Access policies will ask for evidence that all devices accessing corporate resources are evaluated — not just that policies exist.

ISO 27001 — A.9.4.1 (Information Access Restriction): Access to information must be restricted according to the access control policy. Devices in a permanent "compliant by default" state have never had their access restricted by a compliance evaluation. The policy exists on paper; the enforcement does not.

NIST SP 800-53 — AC-17 (Remote Access): Remote access requires monitoring and control. A device that is never evaluated by a compliance policy is, by definition, unmonitored from a policy enforcement standpoint — regardless of what the Intune console displays.

The critical audit risk is not that these findings exist. It is that they are invisible in standard reporting. An auditor pulling a compliance report from Intune will see devices listed as "Compliant" — because they are, by default. The finding only surfaces when an auditor asks specifically how compliance status is determined and whether devices with no policy assigned are included in the compliant count.

---

Remediation Steps That Don't Break Production

Fixing this requires sequencing. Changing the compliance default without first verifying policy coverage will immediately mark ungoverned devices as non-compliant and potentially block user access.

Follow this sequence:

First: Run the PowerShell query above and export the full list of devices with zero compliance policy assignments. Resolve every device on that list before touching the default setting.

Second: Audit your dynamic group queries in Entra ID. For each group used in compliance policy assignment, export the current membership and compare it against your full Intune device inventory. The delta is your exposure.

Third: Review all compliance policies for grace period settings. Any policy with a grace period longer than 24 hours in a production environment requires a documented exception with a defined remediation date.

Fourth: Change the compliance default. In Intune > Devices > Compliance policies > Compliance policy settings, set Mark devices with no compliance policy assigned as to Not Compliant. Do this during a maintenance window with helpdesk coverage.

Fifth: Create a catch-all compliance policy assigned to All Devices with minimal requirements — at minimum, requiring the device to be enrolled and check in within a defined threshold. This ensures no device falls through without evaluation.

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

$settings = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/settings"

if ($settings.secureByDefault -eq $true) {
    Write-Host "PASS: Devices with no compliance policy are marked Non-Compliant" -ForegroundColor Green
} else {
    Write-Host "FAIL: Default compliance behavior is still set to Compliant" -ForegroundColor Red
}

---

Governance Considerations for Ongoing Detection

Fixing the misconfiguration once is not sufficient. The conditions that create it — new enrollments, group query drift, policy layering — are ongoing operational realities.

Build a scheduled query that runs weekly and alerts when any device has been in Intune for more than 48 hours with zero compliance policy assignments. Pipe the output to a Teams channel or a ServiceNow ticket queue. This converts a silent failure mode into an operational signal.

Additionally, treat compliance policy assignments as a change-controlled configuration item. Any modification to a dynamic group query used in compliance assignment should go through the same review process as a firewall rule change. The blast radius of a broken group query is identical: it silently removes enforcement from every device in scope.

Document the secureByDefault setting in your tenant configuration baseline. Include it in your quarterly Intune configuration review alongside Conditional Access policies and Defender for Endpoint onboarding status. This setting is not surfaced in Microsoft Secure Score, which means it will not appear in automated posture assessments unless you explicitly check for it.

---