Mit dem Patch Tuesday vom 12. Mai 2026 hat Microsoft die kumulative Aktualisierung KB5089549 für Windows 11 24H2 (Build 26100.8457) und Windows 11 25H2 (Build 26200.8457) ausgeliefert. Drei Tage später, am 15. Mai 2026, dokumentierte das Unternehmen im Windows Release Health Dashboard einen reproduzierbaren Installationsfehler: Auf Geräten mit knappem freien Platz auf der EFI System Partition (ESP) bricht das Update mit Fehlercode 0x800f0922 ab, rollt sich automatisch zurück und hinterlässt die kryptische Meldung „Something didn't go as planned. Undoing changes." Für betroffene Administratoren bedeutet das nicht nur eine ausgefallene Installation, sondern auch ein ungepatchtes System mit den über 120 in diesem Update adressierten Schwachstellen.
Wer den Fehler im Tagesgeschäft nur als Einzelfall abhakt, übersieht das eigentliche Problem: Die ESP wurde bei vielen OEM-Auslieferungen und bei In-Place-Upgrades von Windows 10 zu klein dimensioniert. Mit jeder Erweiterung der Bootkette — neue Microsoft-Zertifikate aus der UEFI CA 2023-Migration, zusätzliche OEM-Tools, BitLocker-Erweiterungen, neue Bootmanager-Binärdateien — wird der freie Platz weiter knapp. KB5089549 macht in größerem Umfang öffentlich sichtbar, was bei Bestandsanalysen schon länger auffällt: Eine zu klein dimensionierte ESP ist kein hypothetisches Problem — sie kann reale Patch-Vorgänge zum Scheitern bringen und damit die Wirksamkeit des Patch-Managements einschränken.
Was genau passiert beim Installationsabbruch
Das Update durchläuft die initialen Phasen scheinbar normal — Vorbereitung, Download, erste Bereitstellung im laufenden System-Image. Erst nach dem geplanten Neustart, in dem die Bootmanager-Dateien auf der ESP aktualisiert werden müssen, bricht der Vorgang bei rund 35 bis 36 % Fortschritt ab. Windows rollt das Update vollständig zurück, der Anwender landet wieder im vorherigen Build, und die Update-Komponente protokolliert den Abbruch.
Wer die Logdatei C:\Windows\Logs\CBS\CBS.log öffnet, findet drei charakteristische Einträge: SpaceCheck: Insufficient free space, ServicingBootFiles failed. Error = 0x70 und einen ergänzenden Hinweis SpaceCheck: <value> used by third-party/OEM files outside of Microsoft boot directories. Der dritte Eintrag ist diagnostisch besonders wertvoll: Er weist explizit darauf hin, dass nicht etwa Microsoft-eigene Dateien den verfügbaren Speicher belegen, sondern Hersteller-spezifische Inhalte — etwa Bootmenü-Erweiterungen, OEM-Recovery-Loader oder Drittanbieter-Bootloader. Microsoft selbst nennt 10 MB freien ESP-Speicher als kritische Grenze, unterhalb derer das Update zuverlässig fehlschlägt.
Die EFI System Partition als unterschätzter Engpass
Die ESP ist eine kleine, in der Regel mit FAT32 formatierte Partition, die UEFI-Firmware beim Start auswertet, um den Bootloader des Betriebssystems zu laden. Ihre Standardgröße bei einer Windows-11-Neuinstallation beträgt 100 MB. Geräte, die ursprünglich mit Windows 7 oder 8 ausgeliefert und mehrfach upgegradet wurden, haben oft ESPs von 100 MB oder weniger — eine Größe, die in der UEFI-Spezifikation zwar zulässig ist, aber für moderne Anforderungen knapp dimensioniert.
Was liegt auf der ESP? In typischen Konfigurationen finden sich dort der Windows Boot Manager (bootmgfw.efi), das Microsoft-Bootloader-Verzeichnis (\EFI\Microsoft\Boot), bei Multi-Boot-Systemen zusätzliche Loader (etwa für Linux über Shim), OEM-spezifische Werkzeuge wie Dell BIOS-Update-Loader oder Lenovo Diagnostics und — bei aktivierter Festplattenverschlüsselung — Komponenten für die BitLocker-Wiederherstellung. Mit jedem Funktionsupdate kommen neue oder größere Binärdateien hinzu. Die Secure Boot-Zertifikatsrotation auf die 2023er Microsoft CA hat den Druck zusätzlich erhöht, weil aktualisierte Bootmanager mit neuen Signaturen ausgeliefert werden.
| Komponente auf der ESP | Typische Größe | Bemerkung |
|---|---|---|
Windows Boot Manager (bootmgfw.efi) |
ca. 1,5 MB | Wird bei jedem Funktionsupdate ersetzt |
\EFI\Microsoft\Boot (mit Sprachressourcen) |
30–60 MB | Wächst mit installierten Sprachpaketen |
| Boot Configuration Data (BCD) | wenige KB | Konfigurationsdatenbank |
| Linux/Shim-Loader (bei Dual-Boot) | 1–5 MB | Pro installiertes OS |
| OEM-Tools (Dell, Lenovo, HP) | 5–40 MB | Hersteller- und Modellabhängig |
| Recovery- und Diagnose-Loader | 5–20 MB | Teilweise mehrfach vorhanden |
Wenn auf einer 100-MB-Partition bereits 90 MB belegt sind, fehlt der Pufferspeicher, den das Servicing-Subsystem benötigt, um die neuen Bootmanager-Dateien atomar zu schreiben, bevor die alten entfernt werden. Genau dieser Vorgang scheitert bei KB5089549.
Microsofts Empfehlung Nr. 1: Registry-Workaround EspPaddingPercent
Für betroffene Geräte schlägt Microsoft als ersten Workaround eine Anpassung des bfsvc-Verhaltens vor (Boot File Servicing — die Komponente, die Bootdateien auf der ESP verwaltet). Standardmäßig reserviert das Servicing-Subsystem einen prozentualen Pufferspeicher, um zukünftige Aktualisierungen abzufedern. Mit dem Registry-Wert EspPaddingPercent auf 0 wird dieser Puffer für die laufende Installation deaktiviert, sodass das Update auch mit minimal freiem Platz durchlaufen kann.
Die einzige Aktion in einer administrativen Eingabeaufforderung:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Bfsvc" /v EspPaddingPercent /t REG_DWORD /d 0 /f
Anschließend muss das Gerät neu gestartet und die Installation erneut angestoßen werden. Wichtig: Dieser Wert ist ausdrücklich als temporäre Notlösung gedacht. Wer ihn dauerhaft setzt, verliert den Sicherheitsspielraum für kommende Updates. Wir empfehlen, den Schlüssel nach erfolgreicher Installation wieder zu entfernen oder besser noch: die ESP strukturell zu vergrößern. Letzteres ist mit Werkzeugen wie gptgen, kommerziellen Partitionierungsprogrammen oder einer Neuinstallation möglich — keine dieser Optionen ist trivial im Bestand, weshalb der Eingriff in einem Wartungsfenster mit vollständiger Datensicherung erfolgen sollte.
Microsofts Empfehlung Nr. 2: Known Issue Rollback per Gruppenrichtlinie
Microsoft hat parallel einen Known Issue Rollback (KIR) ausgerollt. KIR ist ein Mechanismus, mit dem Microsoft eine problematische, nicht sicherheitsrelevante Änderung in einem ansonsten ausgelieferten Update wieder deaktivieren kann, ohne dass ein vollständiges Ersatz-Update nötig wird. Auf Privatgeräten und nicht zentral verwalteten Geschäftssystemen wurde der Rollback automatisch propagiert; ein Neustart beschleunigt die Wirkung.
Für verwaltete Umgebungen — also Geräte, die über Microsoft Intune, Gruppenrichtlinien oder einen WSUS-/SCCM-Server verwaltet werden — liefert Microsoft eine spezielle MSI-Gruppenrichtlinie mit dem Namen KB5089549 260514_06221 Known Issue Rollback. Sie wird unter Computer Configuration → Administrative Templates importiert und konfiguriert. Nach Aktivierung und einem Neustart der Endgeräte wird die problematische Änderung an bfsvc temporär deaktiviert, und das Update kann installiert werden. Microsoft kündigt eine dauerhafte Korrektur in einem kommenden Windows-Update an — das KIR ist explizit als Übergangslösung gedacht.
| Workaround | Geeignet für | Aufwand | Risiko |
|---|---|---|---|
Registry-Wert EspPaddingPercent=0 |
Einzelne betroffene Geräte | Niedrig (ein Befehl pro Gerät) | Spielraum für künftige Updates entfällt — manuell zurücksetzen |
| KIR-Gruppenrichtlinie | Verwaltete Flotten | Mittel (Policy importieren, ausrollen) | Nur temporär — Microsoft entfernt KIR mit zukünftigem Update |
| ESP vergrößern (gptgen o. ä.) | Strukturelle Sanierung | Hoch (Backup, offline-Aktion) | Eingriff in Partitionierung; bei Fehlern unbootbares System |
| Neuinstallation mit 300 MB ESP | Geräte am Lebensende | Sehr hoch | Vollständige Neuaufsetzung erforderlich |
Warum dieser Vorfall mehr ist als ein Microsoft-Fehler
Der eigentlich problematische Befund ist nicht der Update-Code, sondern der Zustand vieler Endgeräte. Eine ESP, die nach Jahren kaum noch freien Platz aufweist, war schon vor KB5089549 ein Risiko. In der Praxis sind Geräte mit hoher ESP-Belegung keine Seltenheit — typischerweise Maschinen, die mehrfach upgegradet wurden, bei denen OEM-Tools mit jeder Generation kumuliert haben oder bei denen ältere Recovery-Loader nicht entfernt wurden. Bisher hat das nur selten Probleme verursacht; das Mai-Update macht den Engpass nun für eine breitere Geräteklasse spürbar.
Hinzu kommt: KB5089549 ist Teil der Microsoft-Strategie, die Bootkette über die UEFI CA 2023 abzusichern und das Vertrauen in die alte 2011er-CA bis Juni 2026 auslaufen zu lassen. Wer das Update nicht installiert, bleibt nicht nur ungepatcht gegen über 120 dokumentierte Schwachstellen, sondern auch zurück bei der Zertifikatsmigration. Beides ist mit Blick auf Defense-in-Depth unhaltbar — eine Bootkette mit veralteten Zertifikaten ist genau das Einfallstor, das BlackLotus und vergleichbare Bootkits ausnutzen.
Was IT-Teams jetzt operativ tun sollten
Kurzfristig sind die beiden von Microsoft beschriebenen Workarounds die richtige Antwort: Auf verwalteten Geräten die KIR-Gruppenrichtlinie ausrollen, auf Einzelgeräten den Registry-Wert setzen. Mindestens genauso wichtig ist aber die Bestandsaufnahme: Wie viele Geräte in der eigenen Flotte sind betroffen? Welche haben weniger als 20 MB freien ESP-Speicher und sind damit auch für künftige Updates gefährdet?
Eine einfache Diagnose über PowerShell liefert den freien Speicher der ESP:
mountvol B: /s
Get-PSDrive B | Select-Object Used, Free
mountvol B: /dSkaliert man diese Abfrage über ein Endpoint-Management-Werkzeug wie Microsoft Intune, SCCM, ManageEngine oder Tanium, lässt sich die ESP-Belegung systematisch erheben. Geräte mit weniger als 30 MB freiem Platz gehören auf eine Sanierungsliste — entweder über strukturelle Maßnahmen (Vergrößerung, Tausch) oder im nächsten Hardware-Erneuerungszyklus.
Mittelfristig sollte die ESP-Größe Teil der Imaging-Standards werden. Microsoft empfiehlt mindestens 100 MB; für moderne Umgebungen mit Multi-Boot, eigener Zertifikat-Einrollung oder umfangreichen OEM-Werkzeugen sind 300 MB praxistauglich. Bei der Bereitstellung neuer Geräte lohnt sich der Blick in die OEM-Vorgaben — einige Hersteller liefern bewusst kleinere ESPs aus, um Platz für Recovery-Partitionen zu reservieren. Was in der Theorie funktioniert, kollidiert in der Praxis mit der Realität von Servicing-Anforderungen.
Patch-Management muss die Bootkette mitdenken
Klassisches Patch-Management orientiert sich an Anwendungen, Treibern und Betriebssystemkomponenten — die Bootkette wird selten als eigene Domäne betrachtet. KB5089549 zeigt, dass das ein Fehler ist. UEFI-Firmware, die ESP, Bootmanager und Zertifikate auf der Firmware-Ebene sind eigenständige Patch-Objekte mit eigenen Anforderungen an Speicherplatz, Test und Rollback. Wer sie unterschätzt, scheitert nicht an exotischen Sonderfällen, sondern an ganz alltäglichen kumulativen Updates.
Für mittelständische IT-Teams bedeutet das konkret: Die ESP gehört in das Inventar. Die Belegung muss überwacht werden — idealerweise als Compliance-Kennzahl mit definiertem Schwellwert (etwa „mindestens 40 MB frei"). Ein dokumentierter Sanierungsweg für Altgeräte mit knapper ESP gehört in den Patch-Management-Prozess. Und: Pilotgruppen sollten bewusst Geräte mit knapper ESP enthalten, damit Probleme wie der jetzige Fehler in der Pilotphase auffallen, bevor sie die gesamte Flotte treffen. Die BSI IT-Grundschutz-Bausteine zum Patchmanagement und zur Härtung von Clients formulieren entsprechende Anforderungen — KB5089549 ist ein konkretes Beispiel, warum diese Anforderungen mehr sind als formale Checklistenpunkte.
Zusammenhang mit der UEFI-CA-2023-Migration
KB5089549 enthält neben dem ESP-Problem weitere für Sicherheitsteams relevante Komponenten: Es treibt die Secure-Boot-Zertifikatsmigration auf die 2023er Microsoft CA voran, behebt einen kritischen BitLocker-Wiederherstellungsfehler aus früheren Versionen und enthält die regulären Sicherheitspatches des Patch Tuesday. Wer das Update wegen des ESP-Problems aussetzt, schiebt damit gleichzeitig die Vorbereitung auf das Auslaufen der alten Microsoft-CA im Juni 2026 auf. In Konsequenz droht doppelter Aufwand, wenn beide Themen — ESP-Sanierung und Zertifikatsmigration — gleichzeitig nachgeholt werden müssen.
Pragmatisch heißt das: Den Workaround anwenden, das Update installieren, parallel die ESP-Belegung als strukturelles Thema aufnehmen. So bleibt die Bootkette aktuell, ohne den Engpass dauerhaft zu verschleppen.
Fazit
Der Installationsfehler 0x800f0922 bei KB5089549 ist kein klassischer Microsoft-Fehler im Update-Code, sondern eine sichtbare Folge dessen, dass die EFI System Partition über Jahre als unsichtbarer Speicher behandelt wurde. Die kurzfristigen Workarounds — Registry-Wert oder KIR-Gruppenrichtlinie — lösen den unmittelbaren Schmerzpunkt. Die strukturelle Antwort lautet jedoch: ESP-Belegung systematisch erfassen, Schwellwerte definieren, Imaging-Standards anpassen und die Bootkette als eigenständige Patch-Domäne behandeln. Wer das jetzt anpackt, gewinnt nicht nur Ruhe vor diesem konkreten Update, sondern Verlässlichkeit für die kommenden Funktionsupdates und die UEFI-CA-Migration im Juni.
Engpässe in der Bootkette finden, bevor sie das nächste Patch-Tuesday-Update ausbremsen. In unserer Systemhärtung prüfen wir ESP-Belegung, Secure-Boot-Konfiguration und Bootmanager-Status flottenweit, dokumentieren betroffene Geräte mit Sanierungspfaden und integrieren die Ergebnisse in Ihr bestehendes Patch- und Compliance-Berichtswesen. Termin für eine Härtungsanalyse vereinbaren.