Microsoft’s May 26, 2026 Windows 11 preview update KB5089573, for versions 25H2 and 24H2, advances builds 26200.8524 and 26100.8524 while documenting a May security-update installation failure tied to cramped EFI System Partitions. The headline is not that a preview update contains another known issue note; it is that Windows servicing is again colliding with the messy physical reality of PC boot partitions. For enthusiasts, this is a reminder that the most fragile part of a modern Windows update may be a tiny partition most users never see. For IT teams, it is another case where Microsoft’s cloud-era rollback machinery helps, but does not erase the need to understand what is happening on disk.
KB5089573 is, on paper, exactly the sort of late-month Windows 11 preview update Microsoft has trained administrators to expect. It is a non-security cumulative preview for Windows 11 version 25H2 and Windows 11 version 24H2, carrying the familiar mix of reliability fixes, gradual-rollout features, servicing-stack changes, and platform housekeeping. The builds move to 26200.8524 for 25H2 and 26100.8524 for 24H2.
That would usually make this update optional reading for most home users and scheduled reading for administrators who track what will likely be folded into the next Patch Tuesday payload. Preview updates are where Microsoft lets production-quality but non-security changes breathe before the broader mandatory release cadence picks them up. They matter because they show the next month’s direction, not because every device must install them immediately.
But the KB page’s known-issue section is where this release becomes more interesting. Microsoft says some devices may fail to complete installation of the May 2026 security update, KB5089549, with error 0x800f0922 when the EFI System Partition has very little free space, especially 10 MB or less. The affected installation pattern is painfully familiar: Windows appears to install the update, reboots, stalls around 35 to 36 percent, rolls back, and tells the user that something did not go as planned.
That is the Windows Update version of a check-engine light. The visible error is terse, the rollback is noisy, and the true cause is buried in servicing logs. The important detail is not only the 0x800f0922 code, but Microsoft’s explicit identification of the EFI System Partition, or ESP, as the pressure point.
Real PCs are not ideal. OEM images vary, dual-boot setups add clutter, firmware tools drop files, and security software or recovery environments may leave their own traces. Microsoft’s own diagnostic text points to third-party or OEM files outside Microsoft boot directories as a contributor in at least some cases. That is a polite way of saying that Windows servicing sometimes arrives at a partition that has been treated as shared storage by every actor in the boot chain.
The threshold Microsoft highlights — 10 MB or less available — is tiny by modern storage standards and enormous by boot-partition standards. A Windows user with terabytes free on C: can still fail an update because the small system partition at the front of the disk is nearly full. That mismatch is why this class of failure feels so irrational to normal users.
The failure point also matters. Microsoft says the update can succeed in its initial phases and then fail during restart at roughly 35 to 36 percent. That suggests a machine that is not obviously broken before the reboot and may not be obviously diagnosable afterward unless someone knows to inspect the CBS log. The log strings Microsoft calls out — including “SpaceCheck: Insufficient free space” and “ServicingBootFiles failed. Error = 0x70” — are the real breadcrumb trail.
For administrators, this is the part worth operationalizing. If help desks see 0x800f0922 after the May security update, the next move should not be a generic Windows Update reset script. It should be an ESP free-space check and a look at CBS.log for boot-file servicing failures.
That is useful, but it is not a casual tweak. The corrected shape of the command is the familiar administrative-registry pattern: add the
The bigger point is that this workaround does not magically create space. It changes the rule Windows applies while trying to use the available space. That may be perfectly reasonable for affected systems, but it should not be mistaken for long-term partition hygiene.
For enthusiasts, the temptation will be to treat this as a one-line fix and move on. For fleet administrators, the more durable question is whether their deployed images have ESPs that are too small or polluted by vendor files. If a fleet repeatedly depends on reducing padding to install boot-related updates, the registry change is masking an architectural problem.
There is also a subtle risk in how this workaround will circulate. Forum posts, social media replies, and help-desk snippets tend to strip away context. A registry command that is appropriate for a very specific ESP-space failure can quickly become a universal incantation for 0x800f0922, even though that error code has appeared in other Windows Update contexts over the years.
KIR is one of the more underappreciated parts of Windows Update. It gives Microsoft a way to retreat from a bad change while keeping the rest of an update in place. In a world of cumulative updates, where one package contains many fixes, that matters.
But KIR also exposes the split between unmanaged and managed Windows. Consumer devices can often receive the mitigation automatically, while enterprise-managed machines may need administrators to download and configure a special Group Policy matching Windows 11 version 25H2 or 24H2. Microsoft says affected enterprise devices must install and configure the policy, then restart, to temporarily disable the change that causes the issue.
That split is not a flaw so much as a consequence of enterprise control. Managed environments often deliberately limit what Microsoft can change remotely. The price of that control is that administrators own the last mile when a rollback policy is needed.
This is where the KB’s language deserves close reading. Microsoft says a resolution is in progress and will be included in a future Windows update. In other words, the current state is mitigation, not final repair. KIR can stop the bleeding, but the underlying servicing behavior still needs a proper update-side fix.
The preview update itself includes Secure Boot-related servicing changes, including broader targeting data for devices eligible to receive new Secure Boot certificates and a policy to limit some Secure Boot service data sent to Microsoft. That is classic Microsoft balancing: increase coverage for a security-critical transition while offering managed environments more knobs over telemetry and policy behavior.
This matters because the ESP is where many of these boot-chain concerns become physical. Secure Boot certificate transitions, boot manager updates, recovery components, OEM additions, and servicing metadata all intersect with the same small region of disk. A free-space failure there is not merely a storage bug; it is a symptom of Windows’ boot security and servicing models becoming more active over the life of the machine.
Admins have spent years learning to watch disk encryption status, TPM readiness, firmware mode, and Secure Boot state. ESP capacity deserves to join that checklist. A device can be compliant on paper and still fail a boot-servicing update because the partition created years ago no longer fits the job being asked of it.
This is especially true for older upgraded machines. A PC that began life under one Windows generation, passed through multiple feature updates, collected OEM utilities, and then moved into Windows 11 24H2 or 25H2 may not look like a clean 2026 reference device. Its boot partition carries history, and Windows Update is now grading that history during servicing.
Task Manager gains better visibility into NPU usage on PCs with neural processing units, including optional NPU and NPU engine columns. Neural engines that are part of GPUs also appear on the Performance page, giving users and developers a clearer view of AI-related activity. That is not a cosmetic detail; it is Microsoft turning AI hardware from marketing copy into something observable.
Shared Audio is another consumer-facing addition, using Bluetooth LE Audio broadcast technology so two people can listen from one Windows 11 PC at the same time on supported devices. This is the kind of feature that will be invisible until it is suddenly useful on a flight, in a dorm room, or at a desk where two people are reviewing the same media. It also depends on the messy hardware reality of Bluetooth support, device compatibility, and driver maturity.
Accessibility improvements continue as well. Magnifier gains clearer screen-reader announcements and support for magnifying permitted protected content, while touch keyboard reliability and sign-in behavior receive attention. These are not the changes that dominate keynote slides, but they are the changes that decide whether Windows feels polished to users who rely on those paths daily.
The update also promises faster app launch and core shell experiences, better Windows Search behavior for very short file queries, improved USB reliability with docks and hubs, and power-related fixes in sensor and HID paths. That collection reads like a Windows 11 maturity pass: less about one flagship feature, more about shaving latency, preventing battery drain, and reducing the number of small failures that make modern PCs feel unreliable.
That sequence burns trust because it consumes time without giving the user a useful next action. The phrase “Something didn’t go as planned” is deliberately plain, but it is also operationally empty. It does not say that the boot partition is short on space. It does not say to check CBS.log. It does not say that the system drive’s visible free space may be irrelevant.
Microsoft has improved Windows Update recovery considerably over the last decade, and rollback is better than a bricked boot path. But successful rollback is still a failed maintenance event. In business environments, it means lost time, repeated reboots, possible compliance drift, and support tickets that start with a screenshot rather than a root cause.
This is where Windows’ consumer simplicity and enterprise complexity collide. The consumer message must be understandable. The enterprise diagnostics must be precise. Too often, the user sees the simple message, and the administrator has to reconstruct the precise one after the fact.
A better Windows Update experience would surface boot-partition space as a first-class preflight failure, at least in logs and management reporting. If Windows can determine during servicing that the ESP is too tight, administrators should be able to know that before rebooting hundreds or thousands of devices into a predictable rollback.
OEMs have historically shipped systems with partitions sized for the assumptions of their moment. Those assumptions age. What looked adequate for one Windows release can become marginal after years of boot-chain updates and security transitions.
Enterprise image builders can make the same mistake. A reference image that optimizes partition layout too aggressively may pass deployment tests and then become fragile during later servicing. The cost is not paid at imaging time; it is paid two years later when an update fails on restart and the only visible clue is 0x800f0922.
The practical lesson is not that every administrator should start resizing ESPs tomorrow. Resizing boot partitions at scale is not a casual maintenance task, and doing it badly can create the outage this workaround is meant to avoid. The lesson is that ESP sizing and contents should be measured, reported, and treated as part of lifecycle management.
This is also an area where Microsoft could push the ecosystem harder. If Secure Boot certificate renewal and boot servicing are going to become more active over time, Windows hardware guidance should leave less room for marginal boot partitions. The operating system cannot keep treating the ESP as both invisible and critical.
KB5089573 illustrates that tension neatly. The package’s feature and quality changes are broad: AI component updates, Task Manager visibility, shell performance, USB reliability, storage UI improvements, font rendering fixes, and Secure Boot servicing refinements. Yet the operational story becomes the May security update’s failure mode on devices with cramped ESPs.
This is the bargain Windows administrators live with. Cumulative updates are easier to reason about in inventory systems, but harder to partially accept when something goes wrong. Known Issue Rollback softens that problem for certain classes of changes, but it does not make the update model modular in the way old-school patch selection once was.
The security angle makes this even harder. Microsoft warns against uninstalling security updates for good reason. If a security update fails to install, administrators cannot simply shrug and wait indefinitely. They need either a safe mitigation, a corrected update, or a device-level repair path that brings the machine back into compliance.
That is why the ESP issue deserves more attention than a normal preview-update bug. It touches the boot chain, it affects installation of a security update, and it arrives just before a Secure Boot certificate deadline that already demands administrator attention.
But affected machines should be handled deliberately. If a device fails KB5089549 with 0x800f0922 and rolls back around 35 to 36 percent, the ESP should become the prime suspect. CBS.log entries about insufficient free space or
For unmanaged systems, restarting may help Microsoft’s Known Issue Rollback mitigation apply. For enterprise-managed devices, administrators should use the version-matched KIR Group Policy provided for Windows 11 25H2 and 24H2, then restart affected machines. Where the registry workaround is used, it should be documented, controlled, and ideally followed by a review of ESP health rather than forgotten.
The most disciplined shops will turn this into a detection exercise. They will inventory ESP free space, correlate failures by device model and image lineage, and identify whether particular OEM builds or older deployment templates are overrepresented. That is slower than telling users to run a command, but it produces a fleet-level answer instead of a ticket-level patch.
The concrete readout is straightforward:
Microsoft Ships a Routine Preview With a Very Non-Routine Footnote
KB5089573 is, on paper, exactly the sort of late-month Windows 11 preview update Microsoft has trained administrators to expect. It is a non-security cumulative preview for Windows 11 version 25H2 and Windows 11 version 24H2, carrying the familiar mix of reliability fixes, gradual-rollout features, servicing-stack changes, and platform housekeeping. The builds move to 26200.8524 for 25H2 and 26100.8524 for 24H2.That would usually make this update optional reading for most home users and scheduled reading for administrators who track what will likely be folded into the next Patch Tuesday payload. Preview updates are where Microsoft lets production-quality but non-security changes breathe before the broader mandatory release cadence picks them up. They matter because they show the next month’s direction, not because every device must install them immediately.
But the KB page’s known-issue section is where this release becomes more interesting. Microsoft says some devices may fail to complete installation of the May 2026 security update, KB5089549, with error 0x800f0922 when the EFI System Partition has very little free space, especially 10 MB or less. The affected installation pattern is painfully familiar: Windows appears to install the update, reboots, stalls around 35 to 36 percent, rolls back, and tells the user that something did not go as planned.
That is the Windows Update version of a check-engine light. The visible error is terse, the rollback is noisy, and the true cause is buried in servicing logs. The important detail is not only the 0x800f0922 code, but Microsoft’s explicit identification of the EFI System Partition, or ESP, as the pressure point.
The EFI Partition Has Become Windows’ Hidden Chokepoint
The ESP is not where users store documents, games, Teams recordings, or browser caches. It is a small FAT-formatted boot partition used by UEFI firmware and operating systems to store boot loaders and related files. In an ideal world, it is quiet infrastructure: created during setup, rarely touched by humans, and large enough to survive years of servicing.Real PCs are not ideal. OEM images vary, dual-boot setups add clutter, firmware tools drop files, and security software or recovery environments may leave their own traces. Microsoft’s own diagnostic text points to third-party or OEM files outside Microsoft boot directories as a contributor in at least some cases. That is a polite way of saying that Windows servicing sometimes arrives at a partition that has been treated as shared storage by every actor in the boot chain.
The threshold Microsoft highlights — 10 MB or less available — is tiny by modern storage standards and enormous by boot-partition standards. A Windows user with terabytes free on C: can still fail an update because the small system partition at the front of the disk is nearly full. That mismatch is why this class of failure feels so irrational to normal users.
The failure point also matters. Microsoft says the update can succeed in its initial phases and then fail during restart at roughly 35 to 36 percent. That suggests a machine that is not obviously broken before the reboot and may not be obviously diagnosable afterward unless someone knows to inspect the CBS log. The log strings Microsoft calls out — including “SpaceCheck: Insufficient free space” and “ServicingBootFiles failed. Error = 0x70” — are the real breadcrumb trail.
For administrators, this is the part worth operationalizing. If help desks see 0x800f0922 after the May security update, the next move should not be a generic Windows Update reset script. It should be an ESP free-space check and a look at CBS.log for boot-file servicing failures.
The Registry Workaround Is a Scalpel, Not a Hammer
Microsoft’s first workaround is to modify an ESP-related registry setting by adding anEspPaddingPercent DWORD under the Bfsvc control key and setting it to zero. In plain English, Microsoft is telling affected systems to relax the padding requirement used while servicing boot files so the update can proceed on devices with very limited ESP headroom.That is useful, but it is not a casual tweak. The corrected shape of the command is the familiar administrative-registry pattern: add the
Bfsvc key path, set the EspPaddingPercent value, restart, and try the update again. The command should be run from an elevated Command Prompt, and the machine should be backed up before registry changes are made.The bigger point is that this workaround does not magically create space. It changes the rule Windows applies while trying to use the available space. That may be perfectly reasonable for affected systems, but it should not be mistaken for long-term partition hygiene.
For enthusiasts, the temptation will be to treat this as a one-line fix and move on. For fleet administrators, the more durable question is whether their deployed images have ESPs that are too small or polluted by vendor files. If a fleet repeatedly depends on reducing padding to install boot-related updates, the registry change is masking an architectural problem.
There is also a subtle risk in how this workaround will circulate. Forum posts, social media replies, and help-desk snippets tend to strip away context. A registry command that is appropriate for a very specific ESP-space failure can quickly become a universal incantation for 0x800f0922, even though that error code has appeared in other Windows Update contexts over the years.
Known Issue Rollback Shows Its Strength and Its Boundary
Microsoft’s second mitigation is Known Issue Rollback, or KIR. For consumer devices and non-managed business devices, Microsoft says the rollback has already propagated automatically, and a restart may help the mitigation apply faster. That is the modern Windows servicing safety net doing what it was designed to do: disable a problematic non-security change without forcing every user through a full uninstall.KIR is one of the more underappreciated parts of Windows Update. It gives Microsoft a way to retreat from a bad change while keeping the rest of an update in place. In a world of cumulative updates, where one package contains many fixes, that matters.
But KIR also exposes the split between unmanaged and managed Windows. Consumer devices can often receive the mitigation automatically, while enterprise-managed machines may need administrators to download and configure a special Group Policy matching Windows 11 version 25H2 or 24H2. Microsoft says affected enterprise devices must install and configure the policy, then restart, to temporarily disable the change that causes the issue.
That split is not a flaw so much as a consequence of enterprise control. Managed environments often deliberately limit what Microsoft can change remotely. The price of that control is that administrators own the last mile when a rollback policy is needed.
This is where the KB’s language deserves close reading. Microsoft says a resolution is in progress and will be included in a future Windows update. In other words, the current state is mitigation, not final repair. KIR can stop the bleeding, but the underlying servicing behavior still needs a proper update-side fix.
Secure Boot Timing Makes the ESP Problem Harder to Ignore
KB5089573 also lands against a larger Secure Boot backdrop. Microsoft’s note warns that Secure Boot certificates used by most Windows devices are set to expire starting in June 2026 and that devices may need updated certificates to avoid disruption. That makes boot infrastructure a live operational subject, not an obscure footnote.The preview update itself includes Secure Boot-related servicing changes, including broader targeting data for devices eligible to receive new Secure Boot certificates and a policy to limit some Secure Boot service data sent to Microsoft. That is classic Microsoft balancing: increase coverage for a security-critical transition while offering managed environments more knobs over telemetry and policy behavior.
This matters because the ESP is where many of these boot-chain concerns become physical. Secure Boot certificate transitions, boot manager updates, recovery components, OEM additions, and servicing metadata all intersect with the same small region of disk. A free-space failure there is not merely a storage bug; it is a symptom of Windows’ boot security and servicing models becoming more active over the life of the machine.
Admins have spent years learning to watch disk encryption status, TPM readiness, firmware mode, and Secure Boot state. ESP capacity deserves to join that checklist. A device can be compliant on paper and still fail a boot-servicing update because the partition created years ago no longer fits the job being asked of it.
This is especially true for older upgraded machines. A PC that began life under one Windows generation, passed through multiple feature updates, collected OEM utilities, and then moved into Windows 11 24H2 or 25H2 may not look like a clean 2026 reference device. Its boot partition carries history, and Windows Update is now grading that history during servicing.
The Preview Payload Still Signals Where Windows 11 Is Going
The known issue will understandably dominate admin attention, but KB5089573 is not just a failure advisory. The preview includes a set of Windows 11 changes that show Microsoft continuing to tune the operating system around AI hardware, accessibility, low-power behavior, and everyday shell performance.Task Manager gains better visibility into NPU usage on PCs with neural processing units, including optional NPU and NPU engine columns. Neural engines that are part of GPUs also appear on the Performance page, giving users and developers a clearer view of AI-related activity. That is not a cosmetic detail; it is Microsoft turning AI hardware from marketing copy into something observable.
Shared Audio is another consumer-facing addition, using Bluetooth LE Audio broadcast technology so two people can listen from one Windows 11 PC at the same time on supported devices. This is the kind of feature that will be invisible until it is suddenly useful on a flight, in a dorm room, or at a desk where two people are reviewing the same media. It also depends on the messy hardware reality of Bluetooth support, device compatibility, and driver maturity.
Accessibility improvements continue as well. Magnifier gains clearer screen-reader announcements and support for magnifying permitted protected content, while touch keyboard reliability and sign-in behavior receive attention. These are not the changes that dominate keynote slides, but they are the changes that decide whether Windows feels polished to users who rely on those paths daily.
The update also promises faster app launch and core shell experiences, better Windows Search behavior for very short file queries, improved USB reliability with docks and hubs, and power-related fixes in sensor and HID paths. That collection reads like a Windows 11 maturity pass: less about one flagship feature, more about shaving latency, preventing battery drain, and reducing the number of small failures that make modern PCs feel unreliable.
The 35 Percent Rollback Is a Trust Problem
For a user, the most damaging part of this bug is not the technical cause. It is the experience. Windows says it is installing, reboots into an update phase, reaches the mid-30s, fails, rolls back, and returns with a vague apology.That sequence burns trust because it consumes time without giving the user a useful next action. The phrase “Something didn’t go as planned” is deliberately plain, but it is also operationally empty. It does not say that the boot partition is short on space. It does not say to check CBS.log. It does not say that the system drive’s visible free space may be irrelevant.
Microsoft has improved Windows Update recovery considerably over the last decade, and rollback is better than a bricked boot path. But successful rollback is still a failed maintenance event. In business environments, it means lost time, repeated reboots, possible compliance drift, and support tickets that start with a screenshot rather than a root cause.
This is where Windows’ consumer simplicity and enterprise complexity collide. The consumer message must be understandable. The enterprise diagnostics must be precise. Too often, the user sees the simple message, and the administrator has to reconstruct the precise one after the fact.
A better Windows Update experience would surface boot-partition space as a first-class preflight failure, at least in logs and management reporting. If Windows can determine during servicing that the ESP is too tight, administrators should be able to know that before rebooting hundreds or thousands of devices into a predictable rollback.
OEMs and Image Builders Own Part of This Mess
It is tempting to blame Microsoft for every Windows Update failure because Microsoft owns the servicing pipeline. That is only partly fair here. The ESP is a shared dependency shaped by Windows setup, OEM factory imaging, firmware tooling, recovery products, encryption workflows, and years of updates.OEMs have historically shipped systems with partitions sized for the assumptions of their moment. Those assumptions age. What looked adequate for one Windows release can become marginal after years of boot-chain updates and security transitions.
Enterprise image builders can make the same mistake. A reference image that optimizes partition layout too aggressively may pass deployment tests and then become fragile during later servicing. The cost is not paid at imaging time; it is paid two years later when an update fails on restart and the only visible clue is 0x800f0922.
The practical lesson is not that every administrator should start resizing ESPs tomorrow. Resizing boot partitions at scale is not a casual maintenance task, and doing it badly can create the outage this workaround is meant to avoid. The lesson is that ESP sizing and contents should be measured, reported, and treated as part of lifecycle management.
This is also an area where Microsoft could push the ecosystem harder. If Secure Boot certificate renewal and boot servicing are going to become more active over time, Windows hardware guidance should leave less room for marginal boot partitions. The operating system cannot keep treating the ESP as both invisible and critical.
Microsoft’s Cumulative Model Keeps Raising the Stakes
The cumulative update model has obvious benefits. It reduces patch fragmentation, simplifies compliance logic, and ensures that systems converge on a known baseline. But it also means an update that contains dozens of improvements can be blocked by one low-level servicing problem.KB5089573 illustrates that tension neatly. The package’s feature and quality changes are broad: AI component updates, Task Manager visibility, shell performance, USB reliability, storage UI improvements, font rendering fixes, and Secure Boot servicing refinements. Yet the operational story becomes the May security update’s failure mode on devices with cramped ESPs.
This is the bargain Windows administrators live with. Cumulative updates are easier to reason about in inventory systems, but harder to partially accept when something goes wrong. Known Issue Rollback softens that problem for certain classes of changes, but it does not make the update model modular in the way old-school patch selection once was.
The security angle makes this even harder. Microsoft warns against uninstalling security updates for good reason. If a security update fails to install, administrators cannot simply shrug and wait indefinitely. They need either a safe mitigation, a corrected update, or a device-level repair path that brings the machine back into compliance.
That is why the ESP issue deserves more attention than a normal preview-update bug. It touches the boot chain, it affects installation of a security update, and it arrives just before a Secure Boot certificate deadline that already demands administrator attention.
The Fix Is Operational Discipline, Not Panic
The right response is measured. There is no evidence in Microsoft’s note that every Windows 11 24H2 or 25H2 device is affected, and the specific risk condition is limited free space on the EFI System Partition, especially 10 MB or less. Many systems will never encounter the failure.But affected machines should be handled deliberately. If a device fails KB5089549 with 0x800f0922 and rolls back around 35 to 36 percent, the ESP should become the prime suspect. CBS.log entries about insufficient free space or
ServicingBootFiles failing with error 0x70 are strong confirmation.For unmanaged systems, restarting may help Microsoft’s Known Issue Rollback mitigation apply. For enterprise-managed devices, administrators should use the version-matched KIR Group Policy provided for Windows 11 25H2 and 24H2, then restart affected machines. Where the registry workaround is used, it should be documented, controlled, and ideally followed by a review of ESP health rather than forgotten.
The most disciplined shops will turn this into a detection exercise. They will inventory ESP free space, correlate failures by device model and image lineage, and identify whether particular OEM builds or older deployment templates are overrepresented. That is slower than telling users to run a command, but it produces a fleet-level answer instead of a ticket-level patch.
The May Preview’s Real Message Is Written in the Boot Partition
KB5089573 is not a reason to avoid all preview updates, nor is it proof that Windows 11 24H2 or 25H2 is uniquely unstable. It is a reminder that servicing reliability depends on old assumptions that may no longer hold, especially on machines that have accumulated years of firmware, OEM, and operating-system history.The concrete readout is straightforward:
- KB5089573 is a May 26, 2026 preview cumulative update for Windows 11 versions 25H2 and 24H2, moving systems to builds 26200.8524 and 26100.8524.
- Microsoft documents a related May 2026 security-update failure in KB5089549 where affected devices may fail with 0x800f0922 during restart at roughly 35 to 36 percent.
- The failure is tied to limited free space on the EFI System Partition, especially when 10 MB or less is available.
- Microsoft offers a registry-based workaround for affected devices and a Known Issue Rollback mitigation, with enterprise-managed systems requiring a matching Group Policy and restart.
- The update also advances Windows 11 features and fixes around Shared Audio, Task Manager NPU visibility, Magnifier, USB reliability, Windows Search, storage settings, and Secure Boot servicing.
- Administrators should treat ESP capacity as a real servicing prerequisite, not an obscure partitioning detail.
References
- Primary source: Microsoft Support
Published: Tue, 26 May 2026 21:02:23 Z
May 26, 2026—KB5089573 (OS Builds 26200.8524 and 26100.8524) Preview - Microsoft Support
support.microsoft.com
