Walk into most MSP-managed Windows fleets and the update story stops at quality and feature rings.
Drivers? “Windows Update grabs those.” Firmware? “The OEM utility does that.”
That’s not a strategy. That’s three different cooks in the same kitchen, and you’re praying none of them serves up a bad BIOS on a Friday afternoon.
Here’s the real win. Intune has had a dedicated approval surface for driver and firmware updates for a while now. And almost nobody’s switched it on.
What is a driver update policy, really?
It’s a separate Intune profile that sits alongside your existing update rings. It shows you every driver and firmware update Windows Update has queued for your managed devices, and lets you decide — one at a time — whether to ship it.
Approve, pause, defer, hold back the one dodgy NIC driver while the rest go through. All in the portal.
Critically, it’s the same pipeline Windows Autopatch uses for drivers. Five-laptop accounting firm on Business Premium or 500-seat shop on M365 E3 — same surface. You need Intune Plan 1 and a Windows licence that includes the Autopatch entitlement (Business Premium and M365 E3/E5 both have it), devices must be Entra joined or Entra hybrid joined, and telemetry must be set to Required or higher. That’s the lot.
Step-by-Step: switching it on
Check your existing rings aren’t blocking drivers
This is the bit that catches people. If your existing Update Ring or Settings Catalog policy blocks drivers, the whole feature does nothing. In your update ring, set Windows driver to Allow. In the Settings Catalog, set Exclude WU Drivers in Quality Update to Allow Windows Update drivers.
Both default to Allow, but I’ve found plenty of older tenants where someone clicked Block years ago and forgot.
Open the right blade
Sign in to the Microsoft Intune admin centre → Devices → By platform → Windows → Manage updates → Windows 10 and later updates → Driver updates tab → Create profile.
Pick an approval mode
You get two:
- Automatically approve all recommended driver updates — anything the OEM tags “recommended” gets approved on its own, with a deferral you set between 0 and 30 days.
- Manually approve and deploy driver updates — every driver lands as Needs review and waits for you.
Approval method: Automatically approve all recommended driver updates
Make updates 7
available after:Notice what’s missing? There’s no per-vendor split and no per-device override. One policy, one device — stack two driver policies on the same machine and you’ll fight yourself.
Assign and stage
Pilot group of around 10% — your own laptops, IT, one tolerant power user. Watch it for a fortnight. Then 25%. Then the rest. The per-driver pause button is your friend the first time something breaks.
Why this actually changes behaviour
Most clients have never had a driver controlled by anyone other than Windows Update itself. The first time a Lenovo BIOS update bricks a laptop at 4pm on a Friday, that’s the conversation you do not want to be having with the owner.
With a policy on, you see the update before it hits anyone. You pause it. The rest of the fleet still ships. The client doesn’t even know it happened — and that’s the point.
“But surely Windows Update already knows what’s safe?”
Windows Update knows what applies. It doesn’t know your fleet. You do.
One last wrinkle. The policy doesn’t honour the OEM’s Computer Hardware ID targeting — so managed devices can pick up a newer “recommended” driver even when the OEM reserved a CHID-matched build for that exact model. My recommendation? Use manual approval on hardware you don’t have a spare of in a drawer to test against.
Driver update policies aren’t there to give you more buttons to click. They’re there to take the OEM utility, the random Windows Update behaviour, and the 4pm Friday surprise off the table completely.
If you’re not running one on every managed tenant, you’re outsourcing your hardware change control to luck.
CIAOPS 