Admins Blocked the Updates. The Platform Installed Them Anyway.

For roughly two days at the start of June, a fleet-management assumption that thousands of admins rely on quietly stopped being true. Microsoft's service incident MO1332784 describes a misconfiguration in the Windows Update caching service that temporarily dropped device enrollment information. Managed Windows devices were treated as non-enrolled, and the driver-approval policies configured for them simply stopped being applied. Nobody turned the gates off. The platform just stopped seeing them.

"We've received a report of an issue where users' Windows devices that have configured policies to prevent auto updates are installing drivers." - Microsoft, incident MO1332784

What two days without gates looks like

Admins reported tens of thousands of unexpected BIOS and driver installations on devices where those exact updates were explicitly blocked. The breakage was immediate and physical: audio and video devices stopped working, printers broke, VPN clients failed after network driver updates, and some machines blue-screened. The affected window was roughly June 2-3, and Microsoft closed the incident with "We've validated that this issue is resolved following impact remediation."

Note what did not fail here. The policies were correct. The admins had done everything right. What failed was the invisible link between the policy and its enforcement - and there was no independent check downstream to notice that changes were landing on the fleet without ever passing the approval they were supposed to pass. The first signal was broken hardware.

The same engine, as an attack path

An MDM or UEM platform is a mass-change engine: whatever it pushes - or fails to gate - lands on every device at once. That is exactly why attackers target it. In May 2025, two Ivanti EPMM vulnerabilities (CVE-2025-4427, an authentication bypass, and CVE-2025-4428, remote code execution) chained into unauthenticated RCE on the EPMM server itself. Exploitation in the wild began within about 48 hours of a public proof of concept; CISA added both CVEs to its Known Exploited Vulnerabilities catalog on May 19. The campaign, attributed to the China-nexus actor UNC5221, hit roughly 20 internet-facing EPMM deployments - among the victims, the largest German telecom provider, UK healthcare organizations, and a transportation organization managing Houston airport systems. Attackers used hard-coded MySQL credentials to exfiltrate the mifs database: managed devices, LDAP users, Office 365 tokens.

None of this is new. In 2023, twelve Norwegian government ministries were breached through an Ivanti EPMM zero-day (CVE-2023-35078) that had been exploited since at least April of that year. CISA's advisory on that incident said the quiet part plainly: MDM systems "are attractive targets for threat actors because they provide elevated access to thousands of mobile devices." And in September 2025, CISA's malware analysis report AR25-261A documented loaders and malicious listeners planted on compromised MDM servers, urging organizations to treat MDM systems as high-value assets. In June the mass-change engine silently dropped its gates; in 2023 and 2025 the engine itself was the way in. Both roads end at the same place: unapproved change, delivered at fleet scale.

The fleet behind those gates

Jamf's Security 360 report, published in May, is a useful reminder of what those approval gates are actually protecting - and how much unvalidated risk already sits on the average fleet:

Had devices on critically out-of-date operating systems

53%

Had a user fall victim to a phishing link

25%

Contained at least one medium-severity vulnerability

95%

Requested dangerous permissions

62%

Different population than the chart above: these are shares of applications assessed, not shares of organizations.

That is the environment your device-management platform pushes changes into, at scale, every day. It is precisely because MDM is so powerful - and so essential - that its changes deserve a second, independent look.

Microsoft fixed the caching issue in two days, and credit where due - it published the cause. But the incident leaves every fleet owner with a question worth answering honestly: if your management platform stopped honoring your approval gates tomorrow, would you find out from your own controls, or from ten thousand broken printers?