Intune driver updates not working is almost never a driver problem. The policy is usually correct, the devices are usually healthy, and the drivers are usually published. What blocks them is a setting in a different blade, a scan cycle that has not finished, or an assignment method the feature does not support. There are five causes worth checking and they resolve in a fixed order. Here is that order, with the documented behaviour behind each one and the exact console wording to look for.
The first place to look is not the driver policy at all. It is the update ring reaching the same device. A ring with the Windows drivers setting left on Block stops the device scanning for drivers at all, and no amount of approval in the driver blade will override it. That is the same class of problem covered in Intune update rings, where the setting doing the damage is rarely the setting you were editing.
One disclosure before the detail. My tenant is a lab with no enrolled devices, so I have not watched a driver approval land on a production fleet or timed how long the inventory took to fill in across a real estate. Everything below is documented behaviour, verified against Microsoft Learn on 6 September 2026, plus the places where I would expect it to bite.
What a driver update policy actually does
A driver update policy is an approval surface, not a delivery mechanism. Windows Update still delivers the driver. The policy decides which drivers a targeted device is allowed to be offered, and whether that decision is yours or Microsoft’s. It sits in the Microsoft Intune admin center under Devices > Windows updates, on the Driver updates tab.
Two requirements catch people before anything else. Microsoft documents the licence requirement as Microsoft Intune Plan 1 plus a Windows licence that carries the Windows Autopatch entitlement, which in practice means Windows 10/11 Enterprise E3 or E5, Windows 10/11 Education A3 or A5, or Microsoft 365 Business Premium. Intune Plan 1 on its own is not enough, and that surprises tenants who bought Intune standalone. The client side is stricter than most policies too. Microsoft’s driver update requirements state that the device must be Microsoft Entra joined or hybrid joined, diagnostic data must be at least the Required level, and the Microsoft Account Sign-In Assistant service, wlidsvc, must be enabled and running. Windows Enterprise LTSC is not supported at all.
Intune also does not inventory the drivers already installed on your devices. The list you are looking at is a list of available upgrades, not a picture of the fleet. That single fact explains a lot of confused reporting.
Intune driver updates not working: the five causes, in check order
Work down this table before opening a support case. Each row is a documented behaviour, not a guess, and the order matters because the cheap checks sit at the top.
| Check | Symptom it produces | Resolution |
|---|---|---|
| Update ring Windows drivers set to Block | Policy assigned, devices healthy, driver list stays empty forever | Set it to Allow. Microsoft’s own configuration guidance names this as the policy to review first. |
| Settings catalog Exclude WU Drivers in Quality Update | Same as above, but invisible because you are looking in the wrong blade | Set it to Allow Windows Update drivers. A hardening baseline often sets this without anyone noticing. |
| Less than 24 hours since assignment | Driver list empty, no error anywhere | Wait. Nothing is wrong yet. See the next section. |
| Automatic approval policy | Drivers to review column sits at 0 and looks broken | Expected. Recommended drivers are approved without review, so the review count is meant to be zero. |
| Assignment filter on the policy | Policy appears assigned, no device ever picks it up | Remove it. Driver update policies do not support assignment filters. |
The filter row is the one that costs the most time, because filters work almost everywhere else in Intune and there is no warning in the assignment blade. Microsoft’s driver update policy FAQ states plainly that driver updates are not currently supported with assignment filters. If you have built a filter driven assignment model, and many tenants have, this is a hole in it.
The 24 hour rule
A device has to complete its daily Windows Update scan before Intune can process what that device is eligible for. Microsoft documents the resulting delay as up to 24 hours for all healthy devices to check in, and the sync with the Windows Autopatch service happens once a day. So a policy created at four in the afternoon has an empty driver list at half past four, and that is correct behaviour.
This is worth stating clearly because it is the single most common reason someone reports Intune driver updates not working when nothing is wrong. A Microsoft Q and A thread on exactly this symptom resolved with the same answer: create the policy, let devices scan for about a day, and the Drivers to review count fills in. The engineer had not misconfigured anything.
If a day passes and the list is still empty, the device is not scanning rather than the policy being wrong. That is a sync problem, and it diagnoses the same way as any other, which I have written up separately in forcing an Intune sync. Check the device is actually checking in before you touch the driver policy again.
The failure modes
These are the behaviours that do not look like failures until they have already cost you something.
You cannot change the approval type after creation. Microsoft documents that once a driver update policy is created, the approval method is fixed, and only the deferral value can be edited on an automatic policy. On the Windows Autopatch side the equivalent operation is worse: switching between automatic and manual generates new policies that replace the old ones, and every approval, pause and decline you had recorded goes with them. Decide the approval model before you create anything, not after the first review cycle.
Pause is best effort, not a stop button. A paused driver is not recalled. Devices do not recognise the pause until their next update scan, and if an installation is already under way it may complete regardless. If a driver is actively breaking machines, pausing it does not undo the ones already in flight.
There is no rollback. Driver update policies have no remove or roll back option. Microsoft’s stated approach is to use deployment rings to test on small groups, and to handle any actual rollback outside the policy entirely. This is the strongest argument for manual approval on hardware you have not seen before, and it is why I would not run automatic approval across an entire estate on day one.
Approved cannot go back to Declined. The status flow is one way in places. A driver in Needs review can go to Approved or Declined. An approved driver can only be paused. If you approve something by accident, pausing it is the whole of your recourse.
Drivers vanish from the list, and that is by design. When an OEM publishes a newer version, the older driver moves to the Other drivers tab, or is removed entirely if no targeted device could install it. The list is scoped to what your assigned devices can actually take, so a driver disappearing usually means the fleet moved past it.
Autopilot does not use these policies. Driver update policies are not applied during Windows Autopilot, although Windows still applies critical driver updates of its own during provisioning. If your build quality depends on a specific driver level, provisioning is not where it gets set. That is a constraint worth reading alongside the rest of the provisioning behaviour in Autopilot reset.
Two policies on one device is supported and still a bad idea. Microsoft supports it and recommends against it. Where a driver is approved in one policy and paused in another, approved wins. That is the opposite of what most admins assume, and it is a quieter version of the ordinary Intune policy conflict problem, because nothing in the console flags the overlap.
What I would do differently
Most reports of Intune driver updates not working come back to policy shape rather than policy settings, so that is where I would spend the effort. I would treat driver policy as a hardware model boundary, not an organisational one. Groups built around departments produce driver lists that are a union of every model those people happen to hold, which makes manual review meaningless. One policy per model family, assigned to a device group that is provably exclusive, is the only shape where the Recommended drivers tab tells you anything useful. Since filters are unavailable, that group membership has to be real rather than dynamic sleight of hand.
I would also start every new hardware family on manual approval and move to automatic only after a cycle has passed without incident, precisely because there is no rollback. Automatic approval with a deferral of 0 days is the configuration most likely to be regretted, and the deferral field only applies to automatically approved drivers, so a manual policy gains nothing from it.
Finally, I would resist the urge to bulk approve. The Bulk actions control accepts up to 100 drivers at a time and will not mix operations, which reads like a convenience and functions as a way to approve a firmware update you never looked at. The full driver update policy configuration reference is worth reading before the first policy rather than after the first incident.
Last verified: 6 September 2026.
