Five checks for Intune driver update policy coverage

Windows Autopatch stages your OS updates across deployment rings. It does not touch your drivers. Driver update policies are a separate, opt-in Intune feature, they were not available when Autopatch launched, and Autopatch creates none of them automatically when you build a group. So the common state is a fleet with clean ring staging on quality updates and nothing at all on drivers. Those drivers keep updating anyway, on whatever Windows Update offers by default: no deferral, no ring, no approval queue, no admin visibility.

That gap sits at Ring 0. Kernel drivers run below every security product on the box, which is exactly why BYOVD ransomware operators load a signed, vulnerable driver to reach kernel memory and kill EDR. Qilin and Warlock operators were documented in April 2026 doing this to disable over 300 EDR tools. Here are five checks to find out whether your tenant is managing the driver channel or ignoring it.

1. Does a driver update policy exist in the tenant?

Start at the tenant plane. A tenant with zero driver update policies has no review surface at all.

Bad: No profile exists. The Graph call below returns an empty value[] array, or every profile reports deviceReporting = 0.

Good: At least one profile with deviceReporting > 0 and inventorySyncStatus.driverInventorySyncState = "success".

Fix: UI path is Intune admin center, Devices, Windows updates, Driver updates tab, Create profile. To confirm from the API:

GET https://graph.microsoft.com/beta/deviceManagement/windowsDriverUpdateProfiles

Requires the DeviceManagementConfiguration.Read.All scope. Known gap while you audit: LTSC devices cannot be enrolled in driver update policies. If part of your fleet runs LTSC, that segment stays uncovered by design, so track it separately rather than assuming one policy blankets everything.

2. Is a given device enrolled under that policy?

A policy existing does not mean a specific device receives it. Autopatch enrollment and driver-policy enrollment are different states.

Bad: enrollmentState reads notEnrolled, or it reads enrolled (under Autopatch, but no driver policy assigned). Either way the device will not receive approved drivers.

Good: enrollmentState reads enrolledWithPolicy.

Fix: Query the updatable-asset record for the device by its Entra device ID:

GET https://graph.microsoft.com/beta/admin/windows/updates/updatableAssets/{entraDeviceId}

Inspect enrollment.driver.enrollmentState. If it is enrolled rather than enrolledWithPolicy, the device is in Autopatch but no driver policy targets it. Assign the policy to a group that includes the device.

3. Are driver updates being approved and delivered?

The policy sorts updates into two buckets. Recommended drivers auto-approve in Automatic mode after a configurable 0 to 30 day deferral. Everything else, firmware and optional and superseded drivers, lands as “Needs review” and deploys only after you approve it. Firmware always requires manual approval, whatever mode the policy is in.

Bad: newUpdates > 0 on a manual-approval policy with no recent admin activity. Approvals are piling up unreviewed and nothing is shipping.

Good: newUpdates = 0 on an automatic policy, or a documented, regular review cadence on a manual one.

Fix: UI path is Reports, Windows Updates, Summary tab, Windows Driver updates section. From the API:

GET https://graph.microsoft.com/beta/deviceManagement/windowsDriverUpdateProfiles/{profileId}

Check newUpdates for the pending-review count and approvalType for the mode. One design detail that catches shops off guard: the quality-update deferral you set inside a Windows Update ring policy does not apply to drivers. A tenant with tuned ring staging still has no ring-enforced staging on drivers unless a driver policy sets its own deferral.

Also confirm no ring policy is suppressing the channel outright. A ring with “Exclude WU Drivers in Quality Update” set to Enabled, or a Settings Catalog policy blocking the Windows driver channel, overrides your driver policies and installs nothing. Both default to Allow, but a policy tightened for unrelated reasons can silently close the channel.

4. Are on-device prerequisites met?

Two device-side settings gate the whole pipeline. Without telemetry, Intune gets no driver inventory to report on. Without the sign-in service, Windows Update never offers drivers in the first place.

Bad: AllowTelemetry = 0 (Security level) blocks reporting. wlidsvc set to Disabled stops Windows Update from offering drivers.

Good: AllowTelemetry >= 1 and wlidsvc Status is Running.

Fix: Run both checks on the endpoint:

# Telemetry level: must be >= 1 for Intune driver reporting
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection" -Name AllowTelemetry

# Microsoft Account Sign-In Assistant service: must be Running
Get-Service -Name wlidsvc | Select-Object Name, Status, StartType

If AllowTelemetry returns 0, raise it to at least Basic through the same policy channel that set it. If wlidsvc is Disabled, set its startup type to Manual (it is trigger-started) and confirm it can run.

5. What driver versions are installed on the endpoint?

The last check is ground truth. Everything above tells you whether the machinery is wired up. This tells you whether the driver on the box is the one you approved.

Bad: DriverDate predates a known vendor security advisory, or the version string does not match the currently approved entry in the policy.

Good: The installed version matches or exceeds the latest approved entry, with a DriverDate inside the expected release window.

Fix: List signed drivers with version and date, oldest first:

# All signed drivers with version and install date
Get-WmiObject Win32_PnPSignedDriver |
  Select-Object DeviceName, DriverVersion, DriverDate |
  Sort-Object DriverDate |
  Format-Table -AutoSize

# Alternatively via DISM (includes INF filename)
Get-WindowsDriver -Online -All |
  Select-Object Driver, Version, Date, ProviderName

Compare each DriverVersion against the approved version in the Intune policy driver list. A machine running an older version than the policy approved means delivery is broken somewhere in checks 2 through 4, and this is where you catch it.

Kernel drivers are the layer attackers reach for precisely because most fleets leave them unmanaged. CVE-2024-35250 in the Kernel Streaming Service went from patch to CISA KEV inside six months. The Paragon Partition Manager set, CVE-2025-0285 through -0289, exploits biontdrv.sys even on machines where Paragon was never installed, because the attacker supplies the driver. An OS ring that stages quality updates flawlessly does nothing for any of that. The driver channel is a policy you have to build, and if these five checks come back empty, nobody built it.

Sources

• Manage Windows Driver Updates — Microsoft Intune
• Configure Windows Driver Update Policies — Microsoft Intune
• Frequently Asked Questions — Windows Driver Update Policies
• Manage driver and firmware updates — Windows Autopatch
• Windows Autopatch FAQ — Microsoft Learn
• Reports for Windows Driver Update Policies — Microsoft Intune
• Deploy a driver update using Windows Autopatch — Microsoft Graph
• List windowsDriverUpdateProfiles — Microsoft Graph beta
• Qilin and Warlock Ransomware Use Vulnerable Drivers to Disable 300+ EDR Tools
• Windows Kernel Bug Now Exploited in Attacks to Gain SYSTEM Privileges (CVE-2024-35250)
• Playing around with Driver Updates in Intune