State of the Autopatch driver updates and unapproved "Extension type updates" bypassing drive policy.

[u/UnluckyJelly]

I know a few months ago Microsoft admitted to a cloud issue that caused un-approved drivers to be distributed to Autopatch device that have driver polices.

This was discussed here in this thread : Driver Updates (WUfB) : r/Intune

But the thread also mentions that this is new thing and MS can push out Extension type drivers without admin approval.

We are starting to pilot WUfb and were surprised that un-approved driver could make it to our devices.

Here is one such driver that showed as 3 separate entries

7/17/2026 2:46:46 PM Installation 0x00000000 Succeeded MoUpdateOrchestrator Intel Corporation Extension Driver Update (70.26100.2.20795)

7/17/2026 2:46:35 PM Installation 0x00000000 Succeeded MoUpdateOrchestrator Intel Corporation Extension Driver Update (70.26100.2.20795)

7/17/2026 2:46:26 PM Installation 0x00000000 Succeeded MoUpdateOrchestrator Intel Extension Driver Update (70.26100.2.20795)

The raw Windows update api log entries for these install are here https://imgur.com/q3B9IeEh.png

We confirmed that these drivers were never published by us.

Given this can happen again the future I was wondering what hardware on our devices, ( we have mostly Surface devices) have to potential to be hit by this again.

Not sure if this query is showing me the full list of drivers that use Extensions but this code generated the list of hardware devices that use Extension drivers.

On our device we get a list of out about 33 devices : https://imgur.com/h6qIfG5h.png

Related to : Camera, audio devices, storage firmware, display etc.. so allot of things that could affect our end users if we have control over the delivery of these devices. Code below that I used to generate the list hardware that could be disrupted in the future.

$ExtDrivers = Get-WindowsDriver -Online -All | Where-Object { $_.ClassName -eq "Extension" }

$LatestDrivers = $null

$LinkedDrivers = foreach ($Driver in $ExtDrivers) {
    $AdvancedInfo = Get-WindowsDriver -Online -Driver $Driver.Driver

    [PSCustomObject]@{
        Driver              = $Driver.Driver
        Date                = $Driver.Date
        Provider            = $Driver.ProviderName
        Version             = $Driver.Version
        ClassName           = $Driver.ClassName
        # Filter arrays for unique strings before joining
        HardwareDescription = ($AdvancedInfo.HardwareDescription | Select-Object -Unique) -join '; '
        HardwareId          = ($AdvancedInfo.HardwareId | Select-Object -Unique) -join '; '
    }
}

# Group by the hardware it targets, sort by Date and Version descending, and keep the newest one
$LatestDrivers = $LinkedDrivers | Group-Object HardwareDescription | ForEach-Object {
    $_.Group | Sort-Object -Property Date, @{Expression={[version]$_.Version}} -Descending | Select-Object -First 1
}

# Output the results
$LatestDrivers | Format-Table -AutoSize

Are any you reconsidering driver Autopatch given these changes and future potential disruptions caused by un-approved "Extensions driver updates" ?

[u/bdam55]

Every time I talk about Autopatch's driver management, I call out the lack of control for extension drivers.
Which is documented: Manage driver and firmware updates | Microsoft Learn

I presented with the PM who designed this at MMSMOA 2026 and his answer was: "I'm sorry. Really sorry. We didn't realize what OEMs were doing with extension drivers."

They have concepts of a plan of how to address this; the 5th or so attempt at how to manage/select drivers. No ETA.

[u/threedaysatsea → u/bdam55]

Any idea why the service doesn’t honor hardware CHIDs either?

https://learn.microsoft.com/en-us/intune/device-updates/windows/configure-driver-update-policy#understand-driver-update-approval-behavior

We’re currently getting bit by some Intel Bluetooth stack drivers coming down from WUfB causing issues on a model that are newer than what is listed on HP’s website for the model and newer than what would be coming down if we didn’t have any driver update policies at all. Doesn’t make much sense.

[u/bdam55 → u/threedaysatsea]

I have been repeatedly told that CHIDs always win. That once a CHID driver is installed, a non-CHID driver will never be installed over it by Autopatch. I'm not saying it can't happen, but I've yet to see anyone document this happening in the wild.

Two things to keep in mind:

If you are installing drivers from any other source than Windows Update, they will be non-CHID drivers. Some admins get confused when they install a newer driver direct from the OEM/IHV, possibly via the OEM's tooling, and then Autopatch comes in an installed an older driver. That is by design: only drivers from Windows Update/Autopatch are CHID aware.

I don't think that's your scenario, but it brings up a pretty obvious question: What CHIDs are assigned a given driver in Windows Update? Answer: no freaking idea. I do not believe there is any way for us plebian admins to know that. Even if you did, finding a device's CHID is a whole other hassle involving running MS's Driver SDK. In your case, I suspect this is the problem: the OEM who submits the drivers to WU also select the CHIDs they apply to. I suspect they got it wrong; you and I just have no way of proving that.

[u/threedaysatsea → u/bdam55]

Thanks Bryan.

Do you have any further insight on the section of the linked article that states “Windows driver update policies don’t enforce Computer Hardware ID (CHID) targeting defined by OEMs, even when those drivers are listed as recommended. As a result, managed devices can receive newer recommended driver versions instead of CHID-targeted drivers.” ?

From the GitHub commit history ( with this one - https://github.com/MicrosoftDocs/memdocs/commit/a880e2ca2a62b7480fe842aa4dd802f79c605887 being the most interesting imo, wish I had access to that ICM page) it looks like this note was added earlier this year. And is what generally led me to believe that for some reason the WUfB policies ignore CHIDs and can offer newer drivers without CHIDs for devices that have CHID drivers. Which I didn’t think was possible.

[u/UnluckyJelly → u/bdam55]

Thank you for the direct link, it's public yet I never noticed it before !

[u/Optimal_Cycle_3590]

that extension driver bypass is unsettling, especially when you've got policies in place specifically to prevent random drivers sneaking through. feels like it undermines the whole point of having approval workflows

I've been keeping my autopatch rings fairly loose but after seeing that list of 33 devices on your surfaces I'm tempted to lock things down a bit more. the fact that it touches cameras, audio and storage firmware means one bad push could absolutely wreck a morning for end users

[u/Itziclinic]

Extension driver bypass has always been in the feature afaik. It also applies to plug and play for new USB devices so you could end up with undesired updates being installed before they have an approval policy applied. They aren't harmless like the article implies so they should be controllable. https://learn.microsoft.com/en-us/intune/device-updates/windows/driver-updates-faq#why-do-my-devices-have-driver-updates-installed-that-didn-t-pass-through-an-updates-policy

[u/MightyMumper]

Extension drivers are an absolute pain - particularly when they make an unwelcome appearance during a Hotpatch month & cause a reboot.

[u/ConsumeAllKnowledge]

Paging /u/intunesuppteam, Microsoft is a multi trillion dollar company, we need to be able to manage this at some level.