Skip to content
May 26, 2026 Mid-Level (3-5 years) Error Reference

Troubleshooting Windows 11 May 2026 Security Update Failure (Error 0x800f0922)

The May 2026 Windows security update KB5089549 fails on devices with low EFI System Partition space. Here is how to identify affected devices, fix the ESP, and deploy the update with Intune.

Troubleshooting Windows 11 May 2026 Security Update Failure (Error 0x800f0922)

If you manage Windows 11 devices with Intune, you may have seen the May 2026 security update (KB5089549) fail on some machines with error 0x800f0922. The installation proceeds through the initial phases, reboots, and then rolls back at approximately 35-36% completion. After the rollback, the device is left on the previous update, exposed to the vulnerabilities the May update was supposed to fix.

Microsoft has confirmed this issue affects devices where the EFI System Partition (ESP) has 10 MB or less of free space. This is not a rare edge case. Many enterprise devices that were provisioned with the default 100 MB ESP and have accumulated multiple firmware updates, bootloaders, or recovery tools over several Windows feature updates are now hitting this limit.

This guide covers how to identify affected devices, what the ESP size constraint looks like, three methods to resolve it, and how to deploy the fix at scale with Intune and PowerShell.

Identifying Affected Devices

Before you push any remediation, you need to find the machines that are likely to hit this error. The failure itself is self-evident — the update fails with 0x800f0922 during the reboot phase — but proactive detection saves you a round of failed deployments.

Run this PowerShell command on any Windows 11 device to check the ESP free space:

Get-Partition | Where-Object { $_.Type -eq 'System' -and $_.GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' } | Get-PartitionSupportedSize | Select-Object SizeMin, SizeMax

To check the current vs. supported size:

$esp = Get-Partition | Where-Object { $_.Type -eq 'System' -and $_.GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' }
$size = Get-PartitionSupportedSize -Partition $esp
[PSCustomObject]@{
    CurrentSizeMB = [math]::Round($esp.Size / 1MB, 1)
    MinSizeMB     = [math]::Round($size.SizeMin / 1MB, 1)
    MaxSizeMB     = [math]::Round($size.SizeMax / 1MB, 1)
    FreeSpaceMB   = [math]::Round((Get-Volume -Partition $esp).SizeRemaining / 1MB, 1)
}

If FreeSpaceMB shows 10 MB or less, the device is at risk. If the current size is already at or near MaxSizeMB, the ESP cannot be extended and you need a different approach.

For Intune-managed fleets, deploy this as a proactive remediation script. Run it on all Windows 11 devices and collect the output to identify your risk pool. Expect 5-15% of devices provisioned before 2025 to be affected, depending on your hardware refresh cycle and firmware update frequency.

The Root Cause: EFI System Partition Constraints

The EFI System Partition is a small FAT32 partition required for UEFI boot. On most Windows devices, the ESP is 100 MB by default. Microsoft’s own documentation recommends 100 MB minimum, with 260 MB recommended for newer systems.

Over the lifecycle of a device, the ESP accumulates:

  • Boot manager files from each Windows feature upgrade
  • Firmware update payloads from manufacturer drivers
  • Recovery tools and boot configuration data
  • Diagnostic and telemetry boot components

Each Windows 11 feature update (23H2, 24H2, 25H2, 26H1) adds approximately 5-15 MB of boot assets to the ESP. After three or four feature updates, a 100 MB ESP that started with 30 MB free is now at single-digit MB or completely full. When the May 2026 security update tries to write additional boot configuration files during the reboot phase, the install fails and rolls back.

This is not a corruption issue or a driver conflict. It is a capacity problem. And the fix is straightforward once you understand the constraint.

Method 1: Extend the ESP with DiskPart

This is the cleanest fix for devices where the ESP has room to grow (current size < MaxSize). You need to shrink the adjacent Windows partition first, then extend the ESP into the freed space.

Run these commands from an elevated command prompt or PowerShell session:

REM Shrink the Windows partition by 100 MB
diskpart /s shrink.txt

Create shrink.txt with:

select volume C
shrink desired=100 minimum=100
select partition 1
extend size=100
exit

This takes the ESP from 100 MB to 200 MB, which provides sufficient room for several more feature update cycles. After the ESP is extended, reboot and retry the May 2026 security update.

Important: The partition numbers may vary. Run diskpart interactively and use list volume and list partition to confirm the correct indices before scripting. The ESP is typically Partition 1 on GPT disks, but verify this on your hardware.

Method 2: Clean Up the ESP Without Resizing

If the ESP cannot be extended (maxed out at 100 MB on some firmware configurations), you can reclaim space by removing unnecessary files. Use DiskPart to assign a drive letter to the ESP, then inspect and clean it.

REM Assign drive letter S to the ESP
diskpart
select partition 1
assign letter=S
exit

REM Navigate to ESP and inspect
S:
dir /s /a

Look for:

  • Old Windows Boot Manager directories from previous feature versions (e.g., EFI\Microsoft\Boot\* with backup folders)
  • Firmware update files that have been superseded
  • Recovery tool binaries that are no longer needed

Remove outdated boot assets with caution:

REM Example: remove old boot backup folders (verify contents first!)
rmdir /s /q S:\EFI\Microsoft\Boot\Backup

After cleanup, remove the drive letter:

diskpart
select partition 1
remove
exit

Reboot and attempt the update again. This method is riskier than extending the partition because it is firmware-specific and requires understanding which files are safe to remove. Test on a non-production device first.

Method 3: Deploy the ESP Extension at Scale with Intune

For enterprise fleets, you need an automated remediation that runs on all at-risk devices. Create an Intune proactive remediation script pair:

Detection script checks if the ESP has less than 20 MB free:

$esp = Get-Partition | Where-Object { $_.Type -eq 'System' -and $_.GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' }
$free = (Get-Volume -Partition $esp).SizeRemaining
exit ([math]::Round($free / 1MB) -lt 20 ? 1 : 0)

Remediation script extends the ESP by shrinking C and growing the ESP:

$esp = Get-Partition | Where-Object { $_.Type -eq 'System' -and $_.GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' }
$currentSize = [math]::Round($esp.Size / 1MB)
$maxSize = [math]::Round((Get-PartitionSupportedSize -Partition $esp).SizeMax / 1MB)

# Only remediate if there's room to grow
if ($maxSize -gt $currentSize) {
    $growBy = [math]::Min(100, $maxSize - $currentSize)
    $target = Get-Partition -DriveLetter C
    Resize-Partition -DriveLetter C -Size ($target.Size - ($growBy * 1MB))
    Resize-Partition -Partition $esp -Size ($esp.Size + ($growBy * 1MB))
    Write-Output "ESP extended from ${currentSize}MB to $(($currentSize + $growBy))MB"
} else {
    Write-Output "ESP already at max size ($currentSize MB) - manual cleanup required"
    exit 1
}

Deploy this to a pilot group first, then roll to your full Windows 11 device fleet after validation.

Limitations and Caveats

BitLocker must be suspended. Any operation that modifies partition structure triggers a BitLocker recovery event. Suspend BitLocker before running the remediation: Suspend-BitLocker -MountPoint "C:" -RebootCount 1. The remediation must account for this or you will trigger thousands of recovery key requests.

Not all firmware allows ESP resizing. Some UEFI implementations lock the ESP size. On these devices, Method 2 (cleanup) or a reimage with a larger ESP are the only options. Test the remediation script on a representative hardware sample before broad deployment.

Virtual machines and Citrix PVS devices handle the ESP differently. VM ESPs are often dynamically sized and may not need this fix. Check before including VDI endpoints in your remediation scope.

The May 2026 update still needs to be re-attempted. Extending the ESP fixes the installation failure, but it does not retroactively install KB5089549. After remediation, target the affected devices with an Intune update policy to retry the May update.

Conclusion

The KB5089549 0x800f0922 failure is a capacity problem, not a corruption or compatibility issue. Devices with less than 10 MB free on the EFI System Partition cannot complete the security update installation. The fix is to extend the ESP to 200 MB or clean up unnecessary boot files.

For desktop engineers managing Windows 11 fleets at scale, an Intune proactive remediation script that extends the ESP on at-risk devices is the most efficient approach. Deploy to a pilot, validate against your hardware catalog, then roll to production. Once the ESP has room, the May 2026 security update installs normally and your devices remain protected.

Was this helpful?

Comments

Comments are coming soon. Have feedback? Reach out via the About page.