The Deferral Window Problem Nobody Audits

Deferral windows are the single most consequential configuration decision in Windows Update for Business, and they are almost never reviewed after initial deployment.

The standard enterprise ring model looks reasonable on paper: a pilot ring with zero deferral, a broad ring at 7 days, and a general population at 14–21 days. The problem is that this model was designed for quality updates in a pre-zero-day-as-commodity threat environment. When Microsoft patches an actively exploited vulnerability—one already appearing in threat actor toolkits—a 21-day deferral is not a cautious deployment strategy. It is a 21-day exposure window with a documented CVE attached to it.

The second problem is that deferral windows compound. A device that misses a Patch Tuesday cycle due to being offline, excluded from a ring, or stuck in a compliance hold doesn't just fall one cycle behind. It falls behind by the deferral window plus the missed cycle. A 14-day deferral on a device that was offline during deployment can result in 45+ days of unpatched exposure before anyone notices.

Intune does not surface this condition natively. You have to query for it.

// KQL — Microsoft Defender for Endpoint: Devices missing patches older than 21 days
DeviceTvmSoftwareVulnerabilities
| where RecommendedSecurityUpdate != ""
| extend DaysSinceUpdate = datetime_diff('day', now(), RecommendedSecurityUpdateDate)
| where DaysSinceUpdate > 21
| summarize VulnCount = count(), OldestUnpatched = min(RecommendedSecurityUpdateDate)
    by DeviceName, OSPlatform, RecommendedSecurityUpdate
| where VulnCount > 0
| order by OldestUnpatched asc

Run this query in Microsoft Defender for Endpoint's Advanced Hunting. Any device appearing here with a DaysSinceUpdate value greater than your longest deferral window is outside your intended policy coverage—not because the policy failed, but because the device was never in scope for it.

---

Ring Sizing and the Exclusion Rule Blind Spot

Most enterprise Intune deployments use Entra ID security groups to define update rings. The logic is clean in theory: devices join groups, groups map to rings, rings control deferral. In practice, the exclusion rules that keep certain devices out of rings are where coverage gaps accumulate silently.

The three most common exclusion patterns that create gaps:

1. VIP device exclusions. Executive devices are frequently excluded from broad rings to avoid disruption. Without a compensating policy that places them in a faster ring, they receive no updates at all until someone manually intervenes. These devices are often the highest-value targets in the environment.

2. Shared device pools. Kiosk devices, shared workstations, and AVD session hosts are routinely excluded from standard update rings because they require coordinated maintenance windows. If the compensating maintenance window policy is misconfigured or the device group membership drifts, these devices fall into a coverage gap indefinitely.

3. Nested group membership failures. Intune evaluates group membership at policy assignment time. Devices in nested Entra ID groups—particularly dynamic groups with complex membership rules—can fail to resolve correctly, leaving them unassigned to any ring. There is no Intune alert for this condition.

Use this PowerShell block to identify devices that are enrolled in Intune but not assigned to any Windows Update ring policy:

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

$allDevices = Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'Windows'" -All
$updateRingPolicies = Get-MgDeviceManagementDeviceConfiguration -All | Where-Object {
    $_.OdataType -eq "#microsoft.graph.windowsUpdateForBusinessConfiguration"
}

$assignedDeviceIds = @()
foreach ($policy in $updateRingPolicies) {
    $assignments = Get-MgDeviceManagementDeviceConfigurationAssignment -DeviceConfigurationId $policy.Id
    foreach ($assignment in $assignments) {
        # Collect group IDs assigned to update ring policies
        $assignedDeviceIds += $assignment.Target.AdditionalProperties["groupId"]
    }
}

$unassignedDevices = $allDevices | Where-Object {
    $_.AzureAdDeviceId -notin $assignedDeviceIds
}

$unassignedDevices | Select-Object DeviceName, OperatingSystem, LastSyncDateTime, ComplianceState |
    Export-Csv -Path ".\UnassignedUpdateRingDevices.csv" -NoTypeInformation

Write-Host "Devices with no update ring assignment: $($unassignedDevices.Count)"

The output of this script is your first audit artifact. Any device in that CSV is outside your patch governance boundary—regardless of what your policy documentation says.

---

The Patch Categories Intune Admins Systematically Under-Deploy

Windows Update for Business in Intune manages quality updates (cumulative monthly patches) and feature updates (Windows version upgrades). What it does not manage by default—and what most Intune admins don't configure explicitly—is the full surface of Microsoft's monthly release.

Three patch categories are routinely missed:

Microsoft Office and M365 Apps updates are not controlled by Windows Update for Business. They require a separate update channel configuration in the Microsoft 365 Apps admin center or via Intune's Office deployment policy. Environments that assume Windows Update for Business covers the full Microsoft patch surface are wrong. CVEs affecting Word, Excel, and Outlook are published monthly and are not in scope for your WUfB rings.

Driver and firmware updates are disabled by default in most enterprise Intune configurations because they carry a higher risk of hardware compatibility issues. The problem is that driver-level CVEs—particularly those affecting network adapters, storage controllers, and UEFI firmware—are increasingly weaponized. Leaving driver updates on manual or disabled is a documented compliance gap in FedRAMP High environments.

Microsoft Defender definition updates operate on a separate cadence entirely. While definition updates typically deploy automatically, the platform and engine updates for Defender are quality updates that follow your WUfB deferral schedule. A 14-day deferral on quality updates means your Defender engine may be 14 days behind—a meaningful gap when Microsoft releases engine updates in response to active campaigns.

Use this KQL query in Defender for Endpoint to identify devices where the Defender engine version lags behind the current release by more than one version:

// KQL — Identify devices with outdated Defender engine versions
DeviceInfo
| where Timestamp > ago(24h)
| where OnboardingStatus == "Onboarded"
| extend EngineVersion = todynamic(MachineGroup)
| summarize arg_max(Timestamp, *) by DeviceId, DeviceName
| project DeviceName, OSPlatform, DefenderAvStatus, 
          SensorHealthState, OnboardingStatus,
          MachineGroup, Timestamp
| where DefenderAvStatus != "Updated"
| order by Timestamp asc

Adjust the DefenderAvStatus filter based on your environment's baseline. Any device returning a non-"Updated" status is a candidate for investigation against your WUfB deferral configuration.

---

Compliance Holds That Freeze Patch Deployment

Compliance policies in Intune can block a device from receiving updates when they interact with Conditional Access. This is an intended behavior—but it creates a paradox that most governance documentation ignores.

A device that falls out of compliance (expired certificate, BitLocker key escrow failure, stale check-in) may be blocked from accessing corporate resources via Conditional Access. That same device, now isolated from normal network paths, may also fail to reach Windows Update endpoints. The result: the device is both non-compliant and unable to receive the patches that would return it to compliance.

This condition is not theoretical. It appears regularly in environments with aggressive Conditional Access policies and no remediation path for offline or semi-connected devices. The device sits in a compliance hold, accumulates patch debt, and appears in audit reports as a persistent finding.

The governance fix requires two things: a documented remediation workflow for compliance-hold devices that includes a patch catch-up path, and a monitoring query that identifies devices in this state before they age into audit findings.

The operational reality is that your patch coverage percentage means nothing if a portion of your fleet is in a compliance hold that prevents update delivery. Audit frameworks like SOC 2 Type II and ISO 27001 evaluate actual patch state, not policy intent.

---

Mapping Coverage Gaps to Audit Frameworks

SOC 2 Type II, ISO 27001, and FedRAMP each have specific patch management requirements that map directly to Intune configuration decisions.

SOC 2 Type II (CC7.1) requires evidence that vulnerabilities are identified and remediated within defined timeframes. Your deferral window configuration is the primary evidence artifact. If your policy says 14-day deferral but your Advanced Hunting data shows devices at 30+ days, you have a control failure—not a documentation gap.

ISO 27001:2022 (A.8.8) requires that technical vulnerabilities be managed in a timely manner. The standard does not define "timely," which means your auditor will use your own documented SLA against you. If your patch SLA document says 30 days for critical CVEs and your data shows 45-day exposure on a subset of devices, that subset is your finding.

FedRAMP High requires patch deployment within 30 days for critical vulnerabilities and 15 days for actively exploited vulnerabilities (per NIST SP 800-40 Rev. 4 guidance). Driver and firmware update deferrals that exceed these windows are a documented gap in FedRAMP High environments.

The documentation requirement for zero-day scenarios is specific: you need evidence that your monitoring detected the zero-day, that affected devices were identified, and that remediation occurred within your defined window. Intune's built-in reporting does not produce this evidence automatically. You need the Advanced Hunting queries and the PowerShell exports running on a scheduled basis, with outputs stored in a location your auditors can access.

---

Operational Recommendations for Closing the Gap

Four changes that address the specific gaps described in this article—not generic patch hygiene advice:

Implement a zero-day response ring. Create a dedicated Intune update ring with zero deferral and zero deadline grace period. Assign it to no devices by default. When Microsoft publishes a zero-day CVE with active exploitation confirmed, move affected device groups into this ring immediately. Document the ring in your incident response runbook, not just your patch management policy.

Audit ring membership monthly, not quarterly. Device group membership drifts. Dynamic group rules break. Run the PowerShell script above on a monthly schedule and review the output before it becomes an audit finding. Store the CSV outputs with timestamps as compliance evidence.

Separate your M365 Apps update channel from your WUfB configuration. Explicitly configure the Microsoft 365 Apps update channel in Intune (Monthly Enterprise Channel for most environments, Current Channel for security-sensitive roles). Do not assume Windows Update for Business covers this surface.

Enable driver updates for a monitored subset. Rather than leaving driver updates disabled globally, enable them for a canary group of 50–100 devices and monitor for stability issues over 30 days. If stable, expand to the broader fleet. The risk of leaving driver-level CVEs unpatched in a FedRAMP or SOC 2 environment outweighs the compatibility risk for most hardware generations.

---