Why "Quality Update" Is Not What You Think

The term Quality Update in Windows Update for Business terminology covers more than cumulative security patches. Microsoft's update classification system bundles several content types under the Quality Update umbrella:

• Security updates: CVE-addressed patches for OS components
• Critical updates: Non-security fixes for significant bugs
• Driver updates: Hardware driver packages sourced from Windows Update
• Firmware updates: UEFI and device firmware delivered through Windows Update for Business
• Optional updates: Feature improvements and non-critical fixes

When you configure a Quality Update policy in Intune without explicitly addressing driver and firmware behavior, Windows Update for Business applies its default logic—which, depending on your tenant configuration and device profile, may install driver and firmware packages in the same deployment wave as your security patches.

This distinction matters enormously for zero-trust architecture and compliance frameworks like SOC2 and FedRAMP, where every change to a managed endpoint must be traceable to an explicit approval decision. A driver that installs because it was bundled with a cumulative update is not an approved change—it's an uncontrolled change that happened to arrive through an approved channel.

---

The Specific Setting and Where It Lives

In Intune, navigate to Devices → Windows → Update rings for Windows 10 and later (or through the newer Windows Update policies blade if your tenant has migrated to the updated experience).

Inside a Quality Update policy, the relevant setting is:

"Allow Windows drivers" — mapped to the CSP path:

./Device/Vendor/MSFT/Policy/Config/Update/ExcludeWUDriversInQualityUpdate

The CSP name is counterintuitive. The policy is named "Exclude WU Drivers in Quality Update," which means:

• Value 0 (default): Drivers ARE included in Quality Update deployment
• Value 1: Drivers are EXCLUDED from Quality Update deployment

When this is set to 0 (or left unconfigured, which resolves to 0), every Quality Update deployment you push through Intune is a potential driver installation event. Your patch approval process approved a security update. Windows Update for Business delivered that update plus whatever driver packages were staged for that device.

In the Intune UI, this surfaces as the "Allow Windows drivers" toggle inside the Update Ring settings. The toggle label is inverted from the CSP—enabled means drivers are allowed, disabled means drivers are excluded. Confirm the CSP value directly if you have any doubt about what the UI is rendering.

---

What Actually Deploys Without This Control

To understand the operational impact, you need to understand how Windows Update for Business sources driver content. Microsoft operates the Windows Update for Business Driver Management service, which ingests driver packages from OEM partners (Dell, HP, Lenovo, Surface, etc.) and makes them available through the standard Windows Update pipeline.

When a device checks in and the driver exclusion policy is not set, the update client evaluates applicable driver packages based on hardware IDs and installs any that are marked as applicable and not deferred. This happens in the same maintenance window as your security patches.

The practical consequences:

Device variance: Two identical hardware models in the same Intune ring may receive different driver versions depending on when they last checked in, what packages were staged at that moment, and whether the OEM had published an update in the interim. Your "standardized" ring is no longer standardized.

Support debt: When a driver update causes a regression—audio stops working, a NIC behaves unexpectedly, a GPU driver introduces a display artifact—the incident investigation starts from a broken baseline. The device's update history shows a cumulative update. The driver update that caused the problem is buried in Windows Update history, not in your Intune deployment logs.

Compliance audit gaps: Your change management record shows a security patch deployment. The device actually received a security patch plus three driver updates. The audit trail does not match the approved change. For SOC2 Type II or FedRAMP Moderate environments, this is a finding.

---

Unsigned and Unvetted Driver Risk

The security dimension of uncontrolled driver installation extends beyond compliance paperwork.

Windows requires kernel-mode drivers to be signed, but signing is not vetting. A driver can be Microsoft-signed through the Windows Hardware Quality Labs (WHQL) process and still contain vulnerabilities. The Bring Your Own Vulnerable Driver (BYOVD) attack class exploits exactly this: legitimate, signed drivers with known vulnerabilities are loaded to escalate privileges or disable security tooling.

When your patch process silently installs driver packages that your security team has not reviewed, you may be expanding the attack surface with each patching cycle. This is not theoretical—Microsoft's own Vulnerable Driver Blocklist (enforced through WDAC and Defender Application Control) exists specifically because signed drivers with exploitable vulnerabilities are a documented threat vector.

Excluding drivers from Quality Update deployment does not mean drivers never update. It means driver updates go through a separate, deliberate approval process—one that your security team can review, test, and approve independently of the monthly patch cycle.

---

Configuring the Exclusion in Intune

The configuration path depends on whether your tenant uses Update Rings or the newer Windows Update policies experience.

For Update Rings (classic experience):

In the Intune portal, open the Update Ring policy, scroll to the User experience settings section, and locate "Allow Windows drivers". Set this to Not allowed (which maps to CSP value 1, excluding drivers).

For Settings Catalog (recommended for new deployments):

Create or edit a Settings Catalog profile and search for:

Update/ExcludeWUDriversInQualityUpdate

Set the value to Enabled (which, per the CSP semantics, means "yes, exclude drivers").

Validate the applied value on a target device using PowerShell:

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$valueName = "ExcludeWUDriversInQualityUpdate"

if (Test-Path $registryPath) {
    $value = Get-ItemProperty -Path $registryPath -Name $valueName -ErrorAction SilentlyContinue
    if ($null -ne $value) {
        Write-Output "ExcludeWUDriversInQualityUpdate = $($value.$valueName)"
        if ($value.$valueName -eq 1) {
            Write-Output "STATUS: Drivers are EXCLUDED from Quality Update deployment. Policy is correctly applied."
        } else {
            Write-Output "STATUS: Drivers are INCLUDED in Quality Update deployment. Policy may not be applied or is set to default."
        }
    } else {
        Write-Output "Value not found. Policy may not be applied to this device."
    }
} else {
    Write-Output "WindowsUpdate policy registry path not found. No WUfB policy applied."
}

Run this as a Proactive Remediation detection script across your estate to identify devices where the policy has not yet applied or has been overridden.

---

Separating Driver Deployment Into a Controlled Channel

Excluding drivers from Quality Updates does not eliminate driver management—it moves it into a channel you control. Microsoft provides Windows Update for Business Driver Management (also called Intune Driver Updates in the Intune portal) as a separate policy type specifically for this purpose.

Under Devices → Windows → Driver updates for Windows 10 and later, you can:

• Review applicable driver packages for your device population
• Approve specific driver versions for specific hardware models
• Set independent deferral periods for driver deployment
• Pause driver deployments independently of security patch deployments

This is the architecture that gives your security team a review gate. A driver package surfaces in the Driver Updates blade, your team reviews it (or your OEM validation process reviews it), you approve it, and it deploys on a schedule you control. The security patch cycle is no longer contaminated by unreviewed driver content.

---

Querying Deployment State at Scale with KQL

For environments using Microsoft Defender for Endpoint or Azure Monitor with Windows Update compliance data, you can query driver installation events across the estate to establish a baseline before and after applying the exclusion policy.

Use this KQL query in Microsoft Defender XDR Advanced Hunting to identify driver installation events correlated with Windows Update activity:

// Identify driver installations correlated with Windows Update activity
// Run in Microsoft Defender XDR Advanced Hunting
DeviceEvents
| where ActionType == "DriverLoad"
| where Timestamp > ago(30d)
| join kind=leftouter (
    DeviceEvents
    | where ActionType == "WindowsUpdateInstalled"
    | project DeviceId, UpdateTimestamp = Timestamp, UpdateName = AdditionalFields
) on DeviceId
| where abs(datetime_diff('minute', Timestamp, UpdateTimestamp)) < 60
| project Timestamp, DeviceName, DeviceId, FileName, FolderPath, UpdateTimestamp
| order by Timestamp desc

This surfaces driver loads that occurred within 60 minutes of a Windows Update installation event—a strong signal that the driver arrived as part of a patch deployment rather than through a separate, controlled channel.

For Intune compliance reporting, use the following KQL against your Log Analytics workspace if you have Intune diagnostic data flowing through Azure Monitor:

// Check Windows Update policy CSP values reported through Intune diagnostics
IntuneDevices
| where TimeGenerated > ago(7d)
| extend PolicyCSP = tostring(parse_json(Properties).ExcludeWUDriversInQualityUpdate)
| where isnotempty(PolicyCSP)
| summarize DeviceCount = count(), LastSeen = max(TimeGenerated) by PolicyCSP
| project PolicyCSP, DeviceCount, LastSeen
| order by DeviceCount desc

Adapt the field names to match your specific Log Analytics schema—Intune diagnostic field names vary depending on your connector version and workspace configuration.

---

Governance Considerations for Regulated Environments

For environments subject to SOC2 Type II, FedRAMP Moderate, or internal zero-trust mandates, the driver exclusion setting is not optional hygiene—it is a control boundary.

The relevant control principle is change authorization: every change to a managed endpoint must be traceable to an explicit approval decision by an authorized party. When drivers install as passengers on security patch deployments, the change authorization chain breaks. The approver approved a security update. The system installed additional software. The audit log does not reflect the full scope of what changed.

Document the following in your change management system:

1. The policy setting that excludes drivers from Quality Updates (CSP path, value, assignment scope)
2. The separate Driver Updates policy that governs driver deployment (approval workflow, deferral period, responsible reviewer)
3. The validation query used to confirm policy application across the estate
4. The exception process for emergency driver deployments outside the standard cycle

This documentation structure maps directly to the change management and configuration management control families in SOC2 and FedRAMP. It gives your auditor a clear chain from policy intent to technical implementation to operational validation.

---

Recommendations

Audit your current state first. Before changing anything, run the PowerShell validation script above as a Proactive Remediation across your device population. Understand how many devices currently have drivers included in Quality Update deployment. This is your baseline.

Apply the exclusion to new rings before existing rings. If you have a pilot ring with low business impact, apply the driver exclusion there first. Confirm that security patches continue to deploy correctly and that no unexpected behavior surfaces before rolling to production rings.

Activate the Driver Updates blade immediately after applying the exclusion. Excluding drivers from Quality Updates without activating a separate driver management policy means drivers stop updating entirely. That is not the goal. The goal is controlled driver deployment, not no driver deployment.

Set a review cadence for the Driver Updates blade. Microsoft and OEMs publish driver packages continuously. Without a review cadence, the Driver Updates blade accumulates unreviewed packages. Assign ownership—typically the endpoint engineering team—and set a monthly review cycle aligned with Patch Tuesday.

Include driver deployment state in your compliance reporting. Add the KQL queries above to your security operations dashboard. Driver installation events correlated with patch deployments should be a tracked metric, not a blind spot.

---