osbytes

Search

Find posts, projects, and members.

← back to blog

Windows Update lost enrollment cache and bypassed Intune driver blocks

2026-06-05by@osbytes7 min read
#windows #intune #postmortem #reliability #operations #incident-response #microsoft

TL;DR

  • Incident MO1332784 (acknowledged June 2, resolved June 4): a Windows Update caching service temporarily dropped device enrollment information. Affected PCs were treated as non-enrolled, so driver-approval controls tied to MDM enrollment did not apply (NHSmail relay of Microsoft's root-cause text).
  • What shipped anyway: Microsoft-signed drivers and BIOS updates on machines where admins had blocked automatic driver installs. Microsoft says those packages are not a malware risk; admins still reported audio/video breakage and fleets of tens of thousands of surprise updates (gHacks, June 5).
  • Audit window: check endpoints for unexpected driver/BIOS activity June 1–4. Roll back via Device Manager → Update driver → Browse → Let me pick if hardware regressed.
  • Pattern, not one-off: similar policy bypasses hit Windows Server 2019/2022 → 2025 upgrades in April and Autopatch-managed Windows 11 driver pushes in May (BleepingComputer).

The mechanism that mattered

Enterprise Windows shops do not block updates because they hate patches. They block driver and firmware churn on stable images: pilot rings, change windows, hardware qualification. Intune (and other MDM stacks) lean on enrollment state to decide which Windows Update policies apply. If the client believes the device is not enrolled, the stricter driver-approval path can fall away even when every portal toggle still looks correct.

That is the failure Microsoft named in MO1332784. Per the NHSmail status relay, the root cause was not a rogue package or a bad GPO export. A caching service used by Windows Update lost enrollment metadata. Clients briefly looked unmanaged. Driver installs that should have waited for admin approval went through because the enrollment gate was empty.

Microsoft's mitigation, again per that relay: refresh the service cache and restore enrollment status on affected devices. Policies are supposed to govern drivers again. The interesting engineering question is why a cache inconsistency can flip a managed endpoint into an unmanaged code path without a local error the help desk would notice.

Why this is an ops story, not a CVE story

Microsoft was explicit early: drivers pushed during the window were Microsoft-approved and signed and did not pose a security threat (same NHSmail page). That matters for threat modeling. It does not make the incident harmless.

Unapproved BIOS and GPU/audio driver swaps on imaged fleets still blow up stability, void support assumptions, and burn a change window you did not open. gHacks' June 5 write-up quotes admins juggling tens of thousands of endpoints and broken AV stacks after the surprise installs. Compliance teams care about control effectiveness, not CVSS: a policy that reads "block drivers" but fails silently when enrollment cache hiccups is a governance failure with a receipt in Windows Update telemetry, not a malware alert.

If you only read advisories, you would have missed this. It lived in Microsoft 365 service health and tenant admin comms, then filtered into IT press once fleets started reconciling inventory.

What to do now

Microsoft closed MO1332784 on June 4. The work that remains is fleet hygiene:

  1. Inventory driver and BIOS versions on Intune-managed (or Autopatch-managed) devices for changes between June 1 and June 4. Compare against your last known-good baseline or patch Tuesday expectations.
  2. Prioritize hardware regressions (no audio, black screen, dock failures). gHacks documents the rollback UI path: Device Manager → right-click device → Update driver → Browse my computer → Let me pick from a list, then choose the pre-incident driver if offered.
  3. Add a monitor for enrollment drift, not just patch compliance. If Windows Update can forget enrollment in cache, your dashboards should alarm when a managed device reports non-enrolled while Intune still shows healthy sync, or when driver installs spike on rings that should be frozen.

Microsoft says it is still reviewing how the cache dropped enrollment data. There is no public count of tenants hit. Treat "resolved" as stop the bleeding, not prove your fleet is clean.

The 2026 pattern behind one caching bug

BleepingComputer's June 4 recap ties MO1332784 to two earlier policy bypasses in the same year:

  • April: Windows Server 2019/2022 systems upgraded to Windows Server 2025 without administrator intent.
  • May: Autopatch-managed Windows 11 devices in the EU received driver updates despite policies meant to block them.

Different root causes on paper, same operator feeling: the control plane said no; the client installed anyway. For teams running golden images, that erodes trust faster than a noisy failed patch. Enrollment metadata is part of your trust boundary between portal policy and endpoint behavior. When it goes missing, the endpoint does not fail closed.

Sources