Microsoft Fixes Windows Update Caching Issue That Bypassed Driver Auto-Update Controls

Microsoft has resolved a Microsoft 365 service degradation that caused some managed Windows devices to install driver updates even when policies were configured to prevent automatic driver installation.

The incident was tracked as MO1332784 in Microsoft’s service communications and affected Windows devices with policies designed to block or control driver updates. A public Microsoft 365 incident report mirror lists the event as restored and says the issue started on June 2, 2026, at 1:00 PM UTC and ended on June 3, 2026, at 5:30 AM UTC.

The root cause was a Windows Update caching service problem that temporarily dropped device enrollment information. Because affected devices briefly looked like non-enrolled systems, the expected driver approval controls did not apply.

What Happened In MO1332784

Organizations use Windows driver update policies to review, approve, and deploy driver updates in a controlled way. When those controls work correctly, managed devices should follow the approval rules set by administrators.

During this incident, Microsoft said some Windows devices configured to prevent auto updates were installing drivers. The NHSmail service alert says Microsoft validated that the issue was resolved after confirming remediation with a subset of previously affected users.

Microsoft also said the installed drivers were Microsoft approved and signed, and that they did not pose a direct security threat. Even so, unexpected driver changes can create stability, compatibility, and compliance concerns in managed environments.

Key Details At A Glance

Incident ID	MO1332784
Affected service	Microsoft 365 suite, administration
User impact	Some Windows devices with policies configured to prevent auto updates installed drivers
Root cause	Windows Update caching service temporarily dropped device enrollment information
Security status	Drivers were Microsoft approved and signed
Incident start	June 2, 2026, at 1:00 PM UTC
Incident end	June 3, 2026, at 5:30 AM UTC
Final validation	June 4, 2026, according to NHSmail’s posted alert

Why Enrollment Data Was Critical

Managed Windows devices depend on enrollment state so Microsoft cloud services can identify them as corporate devices and apply the correct update rules. If that state disappears from a service cache, update logic may treat the device differently.

The MO1332784 incident details say affected Windows devices were briefly treated as non-enrolled. That prevented the expected driver approval controls from being applied.

That makes the incident more than a simple driver update problem. It shows how cloud-side device state can affect endpoint policy enforcement, especially in environments that depend on Intune, Windows Update, and Windows Autopatch for controlled deployment.

How Driver Update Controls Normally Work

Microsoft’s Intune driver update documentation explains that Windows driver update policies give administrators a dedicated way to review, approve, and deploy driver updates to managed Windows devices.

Those policies support automatic and manual approval workflows. In a manual approval model, administrators review driver updates before deployment, which helps reduce risk for hardware stability and regulated change-control environments.

Microsoft says Intune provides device identity, assignment, and driver approval information, while Windows Autopatch coordinates deployment and Windows Update installs only approved updates during regular scans.

Why The Incident Matters For Enterprises

Microsoft’s finding that the drivers were approved and signed reduces the likelihood of a malware issue. However, enterprises do not only care whether a driver is malicious.

Driver changes can affect boot behavior, peripherals, VPN clients, endpoint security tools, audio devices, network adapters, graphics drivers, and business-critical workflows. A signed driver can still create problems if it installs outside a maintenance window or before compatibility testing.

Microsoft’s driver update policy guidance says organizations can choose between automatic approval of recommended drivers or manual review for every driver update. It also notes that policies with manual approvals require an administrator to approve updates before they deploy.

What Administrators Should Review Now

• Identify devices that received driver updates between June 2 and June 3, 2026.
• Compare installed drivers against approved driver update policy records.
• Check Windows Update and Intune reporting for unexpected driver deployment activity.
• Review help desk tickets for display, network, audio, docking, or peripheral problems after the incident window.
• Confirm that enrolled devices now show the correct management and compliance status.
• Document any unplanned driver changes for audit and change-control records.

Administrators should also check whether any affected machines need rollback, additional testing, or vendor-specific driver review. Microsoft notes that driver update policies do not provide a built-in option to remove or roll back driver updates, so remediation may require device-level action or OEM guidance.

Microsoft Says The Issue Is Resolved

The NHSmail final update says Microsoft validated that the issue was resolved after remediation confirmation from a subset of previously affected users.

Microsoft’s incident messaging said the company updated the affected service cache and enrollment status for affected devices. The company also said it would continue reviewing how the caching service temporarily dropped Windows device enrollment information.

A BleepingComputer report also notes that Microsoft’s Intune Support Team acknowledged the issue publicly while mitigation work was underway.

How To Reduce Risk From Similar Update Issues

Organizations should treat this incident as a reminder to monitor policy outcomes, not just policy configuration. A device can have the correct settings, but a cloud service issue can still affect how those settings apply.

The Microsoft guidance for configuring driver update policies recommends planning how drivers and firmware updates will be evaluated, approved, and deployed. It also recommends periodically reviewing policies for new driver updates.

• Keep driver update policies simple and avoid overlapping assignments where possible.
• Use reporting to confirm which drivers actually installed.
• Set alerts for unexpected driver installation events on managed devices.
• Track driver changes separately for high-risk device groups.
• Validate enrollment state during service incidents that affect update behavior.
• Maintain rollback procedures for critical driver categories.

Driver governance remains important because OEM driver and firmware updates can include reliability, performance, hardware compatibility, and security fixes. The goal is not to block all drivers forever, but to make sure deployment follows a tested and auditable process.

What This Means For Windows Update Trust

The incident does not point to malicious drivers or a supply chain compromise. Microsoft’s service communications said the drivers were Microsoft approved and signed.

Still, the event highlights a real operational risk. When cloud caching, enrollment state, and update orchestration do not line up, enterprise devices may not behave as administrators expect.

For security and IT teams, the next step is practical: review the affected timeframe, confirm device enrollment status, check for unexpected driver installs, and continue monitoring Microsoft service health. The BleepingComputer summary and Microsoft’s mirrored incident details both point to the same root cause: a Windows Update caching problem, not a malicious update campaign.

FAQ