The Enforcement Gap Nobody Talks About

Most Intune documentation focuses on policy creation. The enforcement gap—the delta between what the portal reports and what is actually applied on the device—gets far less attention.

Policy assignment and policy enforcement are not the same event. A policy assigned to a dynamic group only applies to devices that are correctly evaluated by that group's membership rule. If the rule references an extension attribute that isn't populated, or a device category that wasn't set at enrollment, the device is excluded silently. No error. No conflict marker. The device simply never receives the policy.

The same failure mode appears with filter logic. Intune filters are evaluated at the time of policy sync, not at assignment. A filter that references deviceManufacturer will silently exclude any device where that property hasn't been reported yet—typically new enrollments that haven't completed their first full inventory cycle.

Remediation starts with accepting that the Intune admin portal's assignment status view is a reporting artifact, not a ground truth. It reflects what the service believes should be applied, not what the device has confirmed as applied.

---

How a Single Policy Failure Cascades

Consider a BitLocker enforcement policy assigned to all corporate Windows devices. The policy requires encryption with TPM+PIN, and it's configured correctly. But the assignment filter was built to exclude personal devices using a managedDeviceOwnerType condition—and someone modified the filter three months ago to add a second condition using AND instead of OR. The logic inversion now excludes a subset of corporate devices instead of personal ones.

The blast radius of that single character change:

• Devices in the affected group never receive the BitLocker policy
• They receive no error—they simply don't enforce encryption
• Compliance policies that depend on BitLocker status mark those devices as compliant because the compliance check evaluates the reported encryption state, not the policy application state
• Conditional Access passes those devices through because compliance is reported as met
• The devices appear healthy in every dashboard

This is not a hypothetical. The combination of filter logic errors, dynamic group evaluation delays, and compliance policy dependency chains creates exactly this failure mode in production environments.

The cascade continues at the audit layer. When a SOC 2 auditor asks for evidence that all corporate endpoints enforce full-disk encryption, the Intune compliance report shows all devices as compliant. The actual enforcement state is unknown. That gap—between reported compliance and actual enforcement—is what regulators are increasingly treating as a control failure, not just a technical gap.

---

Quantifying Blast Radius Before It Becomes a Breach

Blast radius in endpoint policy management is the count of devices that are exposed due to a misconfiguration, multiplied by the severity of the missing control. You cannot manage what you cannot measure, and most Intune environments have no systematic method for quantifying this.

The first tool is Microsoft Graph API combined with PowerShell. The following query retrieves all managed devices and their policy assignment status for a specific configuration profile, allowing you to identify devices that are assigned but not reporting a successful application state.

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

$profileId = "<YOUR_CONFIGURATION_PROFILE_ID>"

$deviceStatuses = Get-MgDeviceManagementDeviceConfigurationDeviceStatus `
    -DeviceConfigurationId $profileId `
    -All

$exposedDevices = $deviceStatuses | Where-Object {
    $_.Status -notin @("compliant", "notApplicable")
}

Write-Host "Total devices evaluated: $($deviceStatuses.Count)"
Write-Host "Devices NOT enforcing policy: $($exposedDevices.Count)"

$exposedDevices | Select-Object DeviceDisplayName, Status, LastReportedDateTime, UserPrincipalName |
    Export-Csv -Path ".\ExposedDevices_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

This gives you a point-in-time snapshot. But point-in-time is insufficient for audit purposes. You need trend data—specifically, whether the exposure count is growing, stable, or shrinking over time.

The second tool is Microsoft Defender for Endpoint's device inventory combined with Kusto Query Language in the Microsoft 365 Defender portal. This query identifies devices that have not received a specific policy category within a defined window, cross-referenced against their last check-in time.

// KQL — Microsoft 365 Defender Advanced Hunting
// Identifies devices with stale Intune policy sync (>72 hours)
// and no recent configuration profile application event

DeviceInfo
| where Timestamp > ago(7d)
| where OnboardingStatus == "Onboarded"
| summarize LastSeen = max(Timestamp), 
            LastIntuneSync = max(iff(isnotempty(MdmStatus), Timestamp, datetime(null)))
    by DeviceId, DeviceName, OSPlatform, MdmStatus
| where LastIntuneSync < ago(72h) or isempty(MdmStatus)
| project DeviceName, OSPlatform, MdmStatus, LastSeen, LastIntuneSync
| order by LastIntuneSync asc

Devices surfaced by this query are candidates for policy enforcement gaps. They haven't synced recently enough to confirm current policy state, which means any change made in the last 72 hours—including a corrective fix—may not have reached them.

---

The Audit Trail Failure That Regulators Are Catching

Under SOC 2 Type II, ISO 27001:2022, and HIPAA Security Rule requirements, organizations must demonstrate not just that controls exist, but that controls were continuously enforced during the audit period. A policy that was correctly configured but silently failed for 90 days represents a continuous control gap—not a point-in-time misconfiguration.

The Intune audit log captures policy creation, modification, and deletion events. It does not capture enforcement failures at the device level in a format that maps cleanly to a control framework. That gap forces auditors to rely on compliance reports, which—as established above—can show false positives when compliance policies don't accurately reflect enforcement state.

The Intune Audit Log is queryable via Graph API and should be exported to a SIEM on a scheduled basis. The following PowerShell block retrieves audit events for configuration profile changes in the last 30 days and exports them for SIEM ingestion.

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

$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

$auditEvents = Get-MgDeviceManagementAuditEvent -All -Filter `
    "activityDateTime ge $startDate and category eq 'DeviceConfiguration'"

$auditEvents | Select-Object `
    ActivityDateTime,
    ActivityType,
    ActivityResult,
    @{N="Actor";E={$_.Actor.UserPrincipalName}},
    @{N="Resource";E={$_.Resources[0].DisplayName}},
    @{N="ModifiedProperties";E={($_.Resources[0].ModifiedProperties | ConvertTo-Json -Compress)}} |
    Export-Csv -Path ".\IntuneAuditLog_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Write-Host "Exported $($auditEvents.Count) audit events."

The critical gap this exposes: the audit log records who changed the policy, but not which devices stopped receiving it as a result. That correlation requires joining audit events with device status exports—a step that almost no Intune environment performs automatically.

---

Governance Considerations for Policy Enforcement Integrity

The governance failure in most Intune environments is structural, not operational. Policies are treated as configuration artifacts, not as controls with a defined enforcement lifecycle. That framing matters because it determines how changes are reviewed, approved, and validated.

Change management for Intune policies should follow the same rigor applied to firewall rule changes or Active Directory group policy modifications. Every configuration profile change should require:

1. A documented blast radius assessment—which devices and users are affected, and which dependent policies or compliance rules reference this profile
2. A staged rollout using Intune's assignment filter scoping to validate enforcement on a pilot group before full deployment
3. A post-change validation window of at least 72 hours, with automated querying of device status to confirm enforcement rates match expectations
4. An audit log export triggered by the change event, stored in the SIEM with the change ticket reference

The Entra ID group membership audit is equally critical. Dynamic group rules are the most common source of silent policy exclusions, and they are rarely reviewed after initial creation. A quarterly review of all dynamic groups used in policy assignments—specifically validating that membership counts match expected device populations—catches filter drift before it becomes a compliance gap.

Policy conflict detection is another governance gap. When two configuration profiles assign conflicting values for the same setting, Intune marks the setting as "in conflict" and applies neither value. The device is left in an undefined state for that setting. Conflict detection requires systematic review of overlapping profile assignments, which the portal does not surface proactively.

---

Detection Architecture for Misconfiguration at Scale

A detection architecture for Intune policy misconfiguration has three layers: real-time change alerting, periodic enforcement validation, and compliance drift detection.

Real-time change alerting is achievable through Microsoft Sentinel with a connector to the Intune audit log. Any modification to a configuration profile assigned to more than a defined threshold of devices—say, 500 or more—should trigger an alert routed to the endpoint engineering team for immediate blast radius assessment.

Periodic enforcement validation runs on a scheduled basis—daily for critical security controls like BitLocker, Defender settings, and firewall profiles; weekly for lower-severity configurations. The PowerShell and KQL queries above form the foundation of this validation layer. The output feeds a Power BI dashboard or a Sentinel workbook that tracks enforcement rates over time.

Compliance drift detection monitors the delta between Intune-reported compliance and actual policy application state. This requires cross-referencing the compliance policy evaluation results with the configuration profile device status—a join that must be built manually using Graph API exports. When the delta exceeds a defined threshold, it triggers an investigation workflow.

The architecture is not complex. What it requires is deliberate investment in building the data pipeline from Intune's reporting layer into a queryable, time-series format. Most environments skip this step because the Intune portal appears to provide sufficient visibility. It does not.

---

Recommendations for Enterprise Enforcement Integrity

These are the specific actions that close the gap between policy intent and enforcement reality.

Audit your dynamic group rules quarterly. Export all dynamic group membership rules used in policy assignments and validate that device counts match expected populations. Flag any group with a membership count meaningfully below the expected baseline for immediate review.

Build a policy dependency map. Document which compliance policies reference which configuration profiles. When a configuration profile changes, the dependency map tells you immediately which compliance evaluations are affected and which Conditional Access policies may be impacted downstream.

Implement staged rollout as a mandatory process. No configuration profile change should go directly to a full assignment. Use Intune's filter-based scoping to enforce a pilot group of 50–100 devices, validate enforcement status after 48 hours, then expand. This catches filter logic errors before they affect the full estate.

Export audit logs to a SIEM on a daily schedule. The Intune audit log has a 30-day retention window by default. Without SIEM export, audit evidence for a 12-month SOC 2 period is simply unavailable for the first 11 months.

Treat policy conflict reports as P1 incidents. A setting in conflict is a setting not applied. In security-critical profiles—Defender configuration, BitLocker, firewall—an unapplied setting is an open exposure. Conflict reports should be reviewed daily and resolved within a defined SLA.

---