Microsoft May security patch fails for some due to boot partition size glitch

“Something didn’t go as planned. Undoing changes.” That’s all the clue some Windows 11 users will get when Microsoft’s May Security Update fails to install because of insufficient free space on the EFI System Partition (ESP), leaving their systems unprotected by the dozens of patches it contained.

This issue affects devices with limited free space available — typically 10MB or less — on the ESP. “On affected devices, the installation might proceed through the initial phases but fail during the reboot phase at approximately 35-36% completion,” Microsoft said in an advisory. It recommended changing a Windows registry setting to force the update, or to roll back changes and wait for a future update to fix the problem.

Consultants said it was a potentially serious issue given the unexpected exposure and the time the destined-to-fail patch takes to fail to install.

This is the kind of failure that keeps IT leaders up at night, said cybersecurity consultant Brian Levine, who serves as executive director of FormerGov. “When a security update cannot install because the operating system misjudges the state of its own boot partition, the problem isn’t only storage. The real problem is trust in the update process,” he said. “This is a basic hygiene failure dressed up as a technical issue. An update that cannot reliably detect available space on the EFI System Partition is not a small miss. It is a reminder that even mature platforms still struggle with dependency awareness and pre-flight validation.”

Eric Grenier, senior director analyst at Gartner, recommended increasing the size of the disk partition to 1.5GB so that the update can go ahead. “This should not hamper business needs in terms of the size of usable space for an end user”, he said, adding that it will also enable updating of the Windows Recovery Environment. He warned that Microsoft’s own recommendation could lead to trouble. “I would recommend that if an organization wanted to use the modified registry fix that they not only backup the registry beforehand but also test it on some pilot devices before rolling out to the rest of the environment and even then, I would do a slow phased rollout to be sure nothing breaks,” he said. “This type of fix in a production environment should be done with extreme caution because if done incorrectly, fixes will require hands on the keyboard.”

Ishraq Khan, CEO of coding productivity tool vendor Kodezi, says there is a blame on both IT teams and Microsoft.

“Most IT teams reasonably assume that if Windows Update passes its prechecks and starts installation, Microsoft has already validated the system state well enough to avoid a reboot-stage failure. If ESP space is critical to the update succeeding, the updater should have detected and blocked that condition earlier with a clear remediation message,” Khan said. “So while IT environments may contribute to partition pressure over time, Microsoft still owns the orchestration and validation logic that allowed the update to proceed.”

Khan added that this can become a very expensive enterprise IT headache. “That is a design problem for enterprise IT because failure during reboot is much more disruptive than blocking the update before installation begins. From a software maintenance perspective, this is exactly the kind of edge case that becomes expensive at enterprise scale. A small partition constraint on a subset of machines can turn into help desk tickets, rollback cycles, delayed patching, and security exposure.”

David Neuman, COO of consulting firm Acceligence, agreed that this is a substantial IT headache.

“The update appears to pass the early phases but then fails during the reboot phase, which means IT may not find out until the endpoint has already burned through the maintenance window time and rolled back. In an enterprise, it becomes a fleet hygiene problem rather than a one-off help desk problem,” he said. “Affected endpoints may remain unpatched while IT burns time diagnosing a failure that should have been explained earlier. The bigger lesson is that boot, recovery, and firmware-adjacent partitions are now part of patch-management hygiene. Mature IT teams should add ESP size and free-space checks to endpoint health reporting, update gold images so new deployments have adequate ESP capacity and treat boot-partition cleanup or resizing as lifecycle engineering rather than break-fix scripting.”

Microsoft did not respond to a request for comment.

This article first appeared on CSO.Microsoft May security patch fails for some due to boot partition size glitch – ComputerworldRead More