One Misconfigured Intune Policy, Thousands of Exposed Endpoints
One Misconfigured Intune Policy, Thousands of Exposed Endpoints
The assumption that a policy assigned in Intune is a policy enforced on the endpoint is one of the most operationally dangerous beliefs in enterprise endpoint management. It is not always true, and the gap between those two states—assigned versus enforced—is where ransomware propagates, credentials get harvested, and lateral movement goes undetected for weeks.
The Compliance Theater Problem
Intune's compliance reporting answers a narrow question: does a policy exist, and is it assigned to a target group? That is not the same as asking whether the policy is enforcing the intended control on every device in scope.
A configuration profile can be assigned, show as "Succeeded" in the Intune portal, and still fail to enforce the intended security control. This happens for several well-documented reasons: the policy applies at the user scope but the device is shared, the CSP node the policy targets is not supported on the OS build running on a subset of devices, a conflicting policy from a different profile wins the precedence battle silently, or the setting was deprecated in a Windows update and the CSP now accepts the value without applying it.
None of these failure modes surface as a compliance failure in the standard Intune compliance policy report. The device checks in, the policy is marked "Succeeded," and the endpoint is treated as compliant. Auditors reviewing the Intune assignment report see green. Security teams see no alert. The control is not operating.
The structural insight: Intune's "Succeeded" status confirms policy delivery, not policy effect. These are architecturally distinct events, and conflating them is the root cause of the governance blind spot this article addresses.
---
How Misconfiguration Persists at Enterprise Scale
At small scale, a misconfigured policy gets caught because an admin notices unexpected behavior on a device they manage directly. At enterprise scale—thousands of devices across multiple Entra ID groups, multiple OS versions, multiple device cohorts—the signal disappears into noise.
Three mechanisms allow misconfiguration to persist undetected:
Policy sprawl without ownership. In mature Intune tenants, configuration profiles accumulate over years. Profiles created for a pilot, a specific hardware model, or a deprecated compliance requirement remain assigned because no one has a clear mandate to review and retire them. When a new security policy conflicts with an older one, the conflict resolution is silent. The winning policy is not always the intended one.
Group membership drift. Entra ID dynamic groups are evaluated continuously, but group membership changes are not surfaced in Intune's policy assignment reports in a way that makes it obvious when a device has moved out of scope for a critical security profile. A device that was in the "Managed Workstations - Tier 0" group last quarter may have moved to a different group due to an attribute change, silently losing the policy assignment that enforced credential guard or attack surface reduction rules.
OS version heterogeneity. A policy that enforces a specific CSP node may behave differently—or not at all—on Windows 10 22H2 versus Windows 11 23H2. When your device fleet spans multiple OS versions, a policy that works correctly across most devices may silently fail on the remaining cohort. Without OS-version-stratified reporting, that failure is invisible.
---
The Defender and Entra Disconnect
The operational problem compounds because the three platforms that together constitute your endpoint security posture—Intune, Microsoft Defender for Endpoint, and Entra ID—do not share a unified policy enforcement validation layer.
Intune owns policy delivery. Defender owns threat signal and behavioral telemetry. Entra owns identity and conditional access. A misconfigured Attack Surface Reduction (ASR) rule in Intune does not generate a Defender alert that says "this ASR rule is not enforcing as expected." Defender will report on threats it detects, but it has no mechanism to tell you that a specific Intune-delivered policy is failing to prevent the attack vector it was designed to close.
This means your detection workflow for policy misconfiguration has to be constructed deliberately, using Defender Advanced Hunting and Intune's Graph API, because no native dashboard surfaces the gap.
The following KQL query runs in Microsoft Defender XDR Advanced Hunting and identifies devices where ASR rules are in audit mode rather than block mode—a common misconfiguration that passes Intune compliance checks while leaving the control operationally ineffective:
// Identify devices where ASR rules are operating in Audit mode
// Run in: Microsoft Defender XDR > Advanced Hunting
DeviceEvents
| where ActionType == "AsrAuditEvent"
| summarize
AuditEventCount = count(),
DistinctRules = dcount(AdditionalFields),
LastSeen = max(Timestamp)
by DeviceName, DeviceId
| where AuditEventCount > 0
| join kind=leftouter (
DeviceInfo
| summarize arg_max(Timestamp, OSVersion, JoinType) by DeviceId
) on DeviceId
| project DeviceName, DeviceId, OSVersion, JoinType, AuditEventCount, DistinctRules, LastSeen
| sort by AuditEventCount descThis query surfaces devices generating ASR audit events—events that indicate the rule matched a behavior but did not block it because the rule is in audit mode. If your Intune policy is supposed to set ASR rules to block mode, these devices represent a direct policy enforcement failure that Intune's compliance report will not show you.
---
Constructing an Enforcement Validation Workflow
The remediation for the governance blind spot is not a single tool or dashboard. It is a deliberate workflow that crosses Intune, Defender, and the Graph API, executed on a cadence that matches your organization's risk tolerance.
The first layer is Graph API enumeration of policy conflicts. Intune exposes device configuration state through the Graph API, including conflict detection that the portal UI does not always surface clearly. The following PowerShell script queries the Graph API for devices with configuration profile conflicts and exports them for review:
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
$conflictedDevices = @()
$devices = Get-MgDeviceManagementManagedDevice -All -Property "id,deviceName,operatingSystem,osVersion,complianceState"
foreach ($device in $devices) {
# Get configuration state for each device
$configStates = Get-MgDeviceManagementManagedDeviceDeviceConfigurationState `
-ManagedDeviceId $device.Id -All
$conflicts = $configStates | Where-Object { $_.State -eq "conflict" }
if ($conflicts.Count -gt 0) {
foreach ($conflict in $conflicts) {
$conflictedDevices += [PSCustomObject]@{
DeviceName = $device.DeviceName
DeviceId = $device.Id
OSVersion = $device.OsVersion
ProfileName = $conflict.DisplayName
ProfileId = $conflict.Id
ConflictState = $conflict.State
LastReportTime = $conflict.LastReportedDateTime
}
}
}
}
$conflictedDevices | Export-Csv -Path ".\IntuneConflictReport_$(Get-Date -Format 'yyyyMMdd').csv" `
-NoTypeInformation -Encoding UTF8
Write-Host "Conflict report exported. Total conflicted device-profile pairs: $($conflictedDevices.Count)"Run this script weekly and pipe the output into your ITSM or security operations workflow. A device appearing in this report is a device where Intune has detected a policy conflict—meaning the intended control may not be the one that won.
---
Group Membership Drift as a Security Control Failure
The Entra ID dynamic group problem deserves its own operational response. When a device moves out of a group that scopes a critical security profile, the profile is removed from the device. Intune does not generate a security alert for this. It is treated as a normal policy lifecycle event.
For Tier 0 and Tier 1 devices—endpoints with access to privileged credentials, domain controllers, or sensitive data—group membership changes should be treated as security events, not administrative events.
The following KQL query runs against Entra ID audit logs in Microsoft Sentinel or Log Analytics and surfaces device group membership changes that affect groups used for security policy scoping:
// Detect device removals from security-scoped Entra ID groups
// Requires: Entra ID audit logs ingested into Log Analytics / Sentinel
AuditLogs
| where OperationName == "Remove member from group"
| where TargetResources[0].type == "Device"
| extend
DeviceName = tostring(TargetResources[0].displayName),
DeviceId = tostring(TargetResources[0].id),
GroupName = tostring(TargetResources[1].displayName),
InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
ChangeTime = TimeGenerated
// Filter to groups that scope security policies — adjust prefix to match your naming convention
| where GroupName has_any ("Tier0", "Tier1", "SecureWorkstation", "PrivilegedAccess", "MDE-Onboarded")
| project ChangeTime, DeviceName, DeviceId, GroupName, InitiatedBy
| sort by ChangeTime descWire this query to a Sentinel analytics rule with a medium-to-high severity alert. Every time a device drops out of a security-scoped group, your SOC should know within minutes—not discover it during the next quarterly audit.
---
Governance Validation Beyond the Assignment Report
The governance failure mode is specific: policies that exist and are assigned satisfy most audit frameworks' control evidence requirements. ISO 27001, SOC 2, and CIS Controls audits typically accept screenshots of policy assignment as evidence of control implementation. They do not require proof of enforcement effect.
This creates a structural incentive to treat policy assignment as the end state rather than the beginning of a validation chain. Security teams that want to close this gap need to define a second tier of control evidence: enforcement validation artifacts that demonstrate the policy is producing the intended security state on the endpoint.
For BitLocker enforcement, the enforcement validation artifact is not the Intune encryption report—it is a confirmed query of the device's actual encryption status via Graph API, correlated against the expected policy scope. For Credential Guard, it is a confirmed registry or WMI query result from the endpoint, not the Intune profile assignment status. For ASR rules in block mode, it is the absence of audit-mode events in Defender telemetry for devices in scope, as shown in the first KQL query above.
Building an enforcement validation library—a set of queries and scripts that produce second-tier evidence for each critical control—is the operational work that separates organizations that can prove their controls are working from those that can only prove their controls are assigned.
---
Recommendations for Production Environments
These are the specific actions that close the gap described in this article, ordered by operational impact:
Separate policy delivery monitoring from policy enforcement validation. Intune's built-in reports cover delivery. Build a separate validation layer using Graph API queries and Defender Advanced Hunting that runs on a weekly cadence and produces an enforcement confidence score per device cohort.
Implement a policy conflict review process. Run the Graph API conflict enumeration script above on a weekly schedule. Any device with a configuration conflict on a security-critical profile—BitLocker, ASR, Firewall, Credential Guard—should generate a ticket in your ITSM system within 24 hours.
Treat Entra ID group membership changes for security-scoped groups as security events. Deploy the Sentinel analytics rule above. Do not rely on quarterly access reviews to catch device group drift that removes security policy scope.
Stratify your enforcement validation by OS version. Run your validation queries with OS version as a dimension. A policy that shows full enforcement across most of your fleet may be hiding complete enforcement failure on a specific OS build that represents a significant portion of your Tier 0 devices.
Define enforcement validation artifacts for each critical control in your audit evidence package. Work with your compliance team to replace or supplement policy assignment screenshots with second-tier enforcement evidence. This is the only way to close the governance blind spot at the audit level.
Assign explicit ownership to every configuration profile in Intune. Use profile descriptions and naming conventions to record the owning team, the business justification, and the last review date. Profiles without an owner are the ones that create silent conflicts when new policies are deployed.
---
Final Thoughts
The misconfigured Intune policy problem is not primarily a configuration problem. It is an operational architecture problem. The tooling to detect and remediate it exists—Graph API, Defender Advanced Hunting, Sentinel analytics rules—but it has to be assembled deliberately, because no native Microsoft dashboard surfaces the full picture.
The organizations most exposed to this failure mode are not the ones with the worst security policies. They are the ones with mature, well-intentioned policy libraries that have grown complex enough that conflict detection, group membership drift, and OS version heterogeneity have created invisible gaps between what is assigned and what is enforced.
Closing that gap requires treating policy enforcement validation as a continuous operational discipline, not a one-time configuration task. The queries and scripts in this article are starting points. The real work is building the workflow, the ownership model, and the governance evidence chain that makes enforcement validation a repeatable, auditable process—one that produces answers before an incident forces the question.
---
