Mit den Sicherheitsupdates KB5083769 und KB5082052 für Windows 11, die am 14. April 2026 veröffentlicht wurden, gibt es BitLocker-Probleme. Microsoft hat dies inzwischen in Nachträgen in den Supportbeiträgen bestätigt. Die Abfrage des BitLocker Recovery-Keys tritt aber nur in bestimmten, nicht standardmäßig vorhandenen Konstellationen auf.
Windows 11 April 2026-Updates
Zum 14. April 2026 hat Microsoft die kumulativen Sicherheitsupdates KB5083769 (für Windows 11 24H2-25H2) und KB5082052 für Windows 11 23H2 Enterprise und Education veröffentlicht. Beide Updates beinhalten Qualitätsverbesserungen sowie Sicherheitspatches – ich hatte im Blog-Beitrag Patchday: Windows 10/11 Updates (14. April 2026) berichtet. Unter anderem heißt es in den Änderungsmitteilungen:
This update addresses an issue where the device might enter BitLocker Recovery after the Secure Boot updates.
Es gab also Probleme mit dem BitLocker-Recovery-Key, wenn die Secure Boot-Updates ausgerollt wurden. Aber die Problembehebung scheint nicht ganz geklappt zu haben.
Microsoft bestätigt BitLocker-Probleme
Nach Veröffentlichung der Updates hat Microsoft die Support-Beiträge für die kumulativen Updates KB5083769 (Windows 11 24H2-25H2) und KB5082052 (Windows 11 23H2 Enterprise und Education) in den Known Issues-Abschnitten ergänzt.
Dort heißt es inzwischen, dass bei einigen Geräten mit Windows 11, die mit einer nicht empfohlenen BitLocker-Gruppenrichtlinienkonfiguration versehen sind, nach Installation des oben erwähnten Sicherheitsupdates möglicherweise beim ersten Neustart nach der Installation dieses Updates der BitLocker-Wiederherstellungsschlüssel eingegeben werden muss.
Dieses Problem betrifft nur eine begrenzte Anzahl von Systemen mit einer nicht empfohlenen BitLocker-Gruppenrichtlinienkonfiguration. Es müssen folgende Bedingungen erfüllt sein, um in das Problem zu laufen.
- Es muss BitLocker aktiviert und die Gruppenrichtlinie Configure TPM platform validation profile for native UEFI firmware configurations (TPM-Plattformvalidierungsprofil für native UEFI-Firmware-Konfigurationen konfigurieren) eingerichtet sein.
- Weiterhin muss PCR7 im Validierungsprofil enthalten sein (oder der entsprechende Registrierungsschlüssel wurde manuell gesetzt).
Dann melden die Systeminformationen (msinfo32.exe) den Secure-Boot-Status PCR7-Bindung als "Nicht möglich" zurück. Weiterhin ist für obiges Szenario das Windows-UEFI-CA-2023-Zertifikat in der Secure-Boot-Signaturdatenbank (DB) des Geräts vorhanden. Dadurch ist das Gerät für den mit 2023 signierten Windows-Boot-Manager als Standard zwar geeignet. Auf dem Gerät wird der mit dem Windows-UEFI-CA-2023-Zertifikat signierte Windows-Boot-Manager jedoch noch nicht ausgeführt.
Das sind schon einige exotische Bedingungen, unter denen dann beim ersten Start eine BitLocker Recovery-Key vom Nutzer angefordert wird. Bei nachfolgenden Neustarts wird kein BitLocker-Wiederherstellungsbildschirm angezeigt, solange die Gruppenrichtlinienkonfiguration unverändert bleibt.
Der Supportbeitrag Find your BitLocker recovery key liefert Hilfestellung zum Auffinden des BitLocker Recovery Keys.
Wer allerdings in einer Flotte mit mehreren Hundert oder Tausend Geräten in diese Problematik läuft, hat etwas Arbeit vor sich. Unternehmen wird von Microsoft empfohlen, ihre BitLocker-Gruppenrichtlinien auf die explizite Einbindung von PCR7 zu überprüfen. Weiterhin sollten Administratoren mittels msinfo32.exe den PCR7-Bindungsstatus überprüfen, bevor sie die oben genannten Update installieren.
Wer von dem Problem betroffen ist, dem schlägt Microsoft zwei Workarounds zur Lösung des Problems vor:
- Die PCR7-Gruppenrichtlinienkonfiguration zu entfernen, bevor das Update installiert wird (empfohlen).
- Vor der Installation des Updates das "Known Issue Rollback" (KIR) anzuwenden, falls die PCR7-Gruppenrichtlinie nicht entfernt werden kann.
Das KIR verhindert die automatische Umstellung auf den Boot-Manager 2023 und beugt so der Auslösung der BitLocker-Wiederherstellung vor. Microsoft arbeitet an einer Korrektur des Problems. Details zu den Workarounds sind den Supportbeiträgen von KB5083769 (für Windows 11 24H2-25H2) und KB5082052 für Windows 11 23H2 Enterprise und Education zu entnehmen. Ist jemand von diesem Szenario betroffen?
Ergänzung: Über die patchmanagement.org-Mailing-Liste ist mir ein Auszug aus einer Microsoft-Zusammenfassung untergekommen, nachdem folgende Windows Client-Versionen und -Updates betroffen sind.
| Windows 11, version 25H2 | WI1280135 | KB5083769 | – |
| Windows 11, version 24H2 | WI1280137 | KB5083769 | – |
| Windows 11, version 23H2 | WI1280140 | KB5082052 | – |
| Windows 10, version 22H2 | WI1280142 | KB5082200 | – |
| Windows 10, version 21H2 | WI1280143 | KB5082200 | – |
Zudem sind folgende Server-Versionen und -Updates betroffen.
| Server Versions | Message ID | Originating KB | Resolved KB |
|---|---|---|---|
| Windows Server 2025 | WI1280139 | KB5082063 | – |
| Windows Server 2022 | WI1280141 | KB5082142 | – |
Ähnliche Artikel:
Microsoft Security Update Summary (14. April 2026)
Patchday: Windows 10/11 Updates (14. April 2026)
Patchday: Windows Server-Updates (14. April 2026)
Patchday: Microsoft Office Updates (14. April 2026)
Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Windows 11 April 2026-Updates (KB5083769, KB5082052) triggern BitLocker Recovery
Windows Server 2025: Update KB5082063 liefert Error 0x800F0983, 0x80073712
Windows Server 2025: Fehler 0x80073712 bei KB5082063 durch Media Player-Sprachpakete
Windows Server 2016-2025: Reboot von Domain Controllern durch April 2026-Update (KB5082063 etc.)
Windows April 2026-Updates verursachen Anmelde-Probleme
MVP: 2013 – 2016
Der letzte Patch scheint auch zu Problemen mit DCs führen.
Bin gerade sehr beschäftigt. Laut MS ist es kein generelles Problem mit allen Installationen, – aber es gibt Probleme nach der Installation des Patches auf DCs.
Deaktivieren von Bitlocker hat nicht geholfen!
Ein system konnten wir retten durch deinstallation des patches:
Dism /image:c:\ /remove-package /packagename:xxxxx
Zu welchen Problemen kommt es denn?
Ich würde auch gerne wissen, ob ich bei uns etwas übersehen habe.
Die RC4-Problematik haben wir bei uns schon im Vorfeld entschärft, und Server wie Clients installieren wir standardmäßig mit englischer ISO. Nur die Clients bekommen über unser WinPE-Deployskript am Ende das deutsche Sprachpaket aktiviert.
Daher hatten wir vermutlich auch keine Probleme mit den 2025er-Servern, wie sie hier an anderer Stelle berichtet wurden. Über ein Dutzend sind klaglos durchgelaufen.
Wir verwenden für Clients selbst erstellte Images, die aus einer englischen ISO stammen und per Skript neben den ganzen Patches (nach Microsoft Imaging Best Practices) auch gleich das deutsche Sprachpaket integriert bekommen.
Scheinbar Probleme mit ntdsai.dll und samsrv.dll
Server bootet, gibt Problem mit NTDS aus und macht reset.
Englische installationen, 2019-2022, Server Core und mit GUI… mixed bag scheinbar.
Nicht alle DCs betroffen.
Bitlocker ist nicht das Problem, haben wir getestet.
Neue Azure VM (mit dem Apr. Patch) hat das gleiche Problem nach der promo
Zumindest in unserer Umgebung sehe ich das so nicht. Zwei DCs Server 2019 GUI in Deutsch ließen sich problemlos updaten und machen auch keinerlei Probleme. Ist also kein grundsätzliches Problem, da muss noch irgendwas anderes mitverantwortlich sein.
Das ist korrekt. Habe ich so auch geschrieben. Nicht alle DCs sind betroffen, nicht einmal bei unserer Domäne.
Aber:
Es sind nicht nur wir betroffen, kein Einzelfall. Es würde mich nicht wundern wenn der Patch nochmal ein Upgrade bekommt.
Das Risiko ist nicht extrem, aber es ist schon vorhanden.
Und hier ist der MS-Artikel der das Problem bestätigt:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025#4833msgdesc
Bitte beachten:
Der Artikel spricht von Nicht-GCs die betroffen wären. Das kann ich so nicht bestätigen.
Es gibt inzwischen die offizielle Bestätigung von MS.
Es wird vermutet dass es mit aktiviertem Feature "Privileged Access Management" zu tun hat.
Es wird an einem Fix gearbeitet
Die haben nicht nur einen anderen Boot Manger drauf ohne es vorher zu komunizieren, sondern auch sonst kräftig verändert.
Einen Zusammenhang so wie er hier beschrieben ist kann man eigentlich ausschließen:
Der Wert in PCR 7 verändert sich bei einem UEFI nach Standard nur und genau dann, wenn man den Secure Boot Mode ein oder ausschaltet. Das macht beim Booten aber fast niemand.
Die Einstellung in der GPO hat auch nur eine Auswirkung auf ein gerade neu mit Bitlocker verschlüsseltes System Volume.
Verhält sich das UEFI bei PCR 7 (durch ein Firmwareupdate) nicht (mehr) standardkonform kann man es per GPO oder Registry nur deaktivieren – statt wie hier im Text steht aktivieren -, muss danach aber die Systempartition ent- und neuverschüsseln damit es wirksam wird.
Das dürfte hier aber nicht das eigentliche Problem sein. Schneller und mit weniger Nebenwirkungen kann man auch den Protektor zur Verschlüsselung des Systemlaufwerkes für ein ausreichende Anzahl von Neustarts kurzzeitig deaktivieren.
Aber Vorsicht: Der neue Boot Manager auf der ESP unterscheidet sich derzeit bei Windows 10 und auch Server 2025 von denen in WinPE/RE und erst recht von denen auf ISOs und Recoverymedien ohne dass es von MSFT kommuniziert wird.
Unabhängig davon ob er mit dem 2011 oder 2023 Schlüssel signiert ist.
Die Probleme sind also auf 2019 und 2022 DC zu finden? Sonst irgendwelche Unterschiede? Mit/ohne EDR/XDR? Andere Richtlinien für EDR/XDR? Hat jemand die lokalen Gruppenrichtlinien modifiziert? Irgendwelche Sync Produkte installiert wie Sophos AD Sync oder AADConnect?
Wir hatten mal ein Problem beim Inplaceupgrade/Promotion der DCs auf 2019 oder höher. 3 Minuten nach Promotion einer frischen VM waren die Kisten tot. Das lag aber daran, das vor Uhrzeiten mal jemand wild die Default Domain Controllers Policy editiert hat. Replace a process level token, Bypass traverse checking oder irgendwelche anderen Richtlinien hatten eine deutlich kürzere Accountliste. Die Default Domain Controllers Policy würde aber alle DCs betreffen.
Die getestete frische Azure VM spricht aber dagegen.
Habt ihr neben den üblichen GPO oder als Ersatz dafür vielleicht Richtlinien über DSC oder Intune?
Das kam heute morgen bei mir als E-Mail rein:
Domain controllers may restart repeatedly after installing April security update
Status
Confirmed
Affected platforms
Server Versions Message ID Originating KB Resolved KB
Windows Server 2025 WI1282748
KB5082063
–
Windows Server 2022 WI1282749
KB5082142
–
Windows Server 2019 WI1282750
KB5082123
–
Windows Server 2016 WI1282751
KB5082198
–
After installing the April 2026 Windows security update (the Originating KBs listed above) and rebooting, non Global Catalog (non GC) domain controllers (DCs) in environments that use Privileged Access Management (PAM), might experience LSASS crashes during startup. As a result, affected DCs may restart repeatedly, preventing authentication and directory services from functioning, and potentially rendering the domain unavailable.
In some environments, this issue can also occur when setting up a new domain controller, or on existing DCs if authentication requests are processed very early during startup.
Note: This issue affects Windows Server only. It does not impact consumer PCs or personal devices. The scenario is unlikely to be observed on individual-use devices that are not managed by an IT department.
Workaround: IT administrators can reach out to Microsoft Support for business to access a mitigation. This mitigation can be applied to devices that already have installed the April 2026 update or prior to installing it.
Resolution: Microsoft is working to address this issue and will release a resolution in the next coming days.
Affected versions:
• Client: None
• Server: Windows Server 2025; Windows Server 2022; Windows Server, version 23H2; Windows Server 2019; Windows Server 2016
Hilfe, Hilfe, Hilfe!
Das Update KB5079473 vom 11.03.26 hatte bei mir zu Anmeldeproblemen AM LAPTOP insgesamt, also nicht bei irgendwelchen Anwendungen, geführt. Nach Eingabe des Kennwortes schaltete sich der Laptop ab. Zack. Zunächst ging erneutes Einschalten und Anmelden, bis auch das nach ein paar Tagen zäh wurde. Als ich nur noch mit Mühe das Einschalten (Knopf lange gedrückt halten, wurde nötig,) und die Anmeldung ohne Abschaltung schaffte, habe ich die Ursache begriffen und das Update deinstalliert und musste schließlich noch eine Reparaturversion von Windows 11 installieren.
Gestern dann KB5083769 und – zack- der Laptop schaltet sich heute wieder beim Anmelden ab!!! Kam mit erneutem Einschalten (das dauerte) und Anmelden endlich rein und habe sofort das update deinstalliert (danach ausgeschaltet, eingeschaltet, angemeldet – ging). Nicht dass das System mir das bei den windows updates als deinstalliert anzeigen würde. Genau wie der Schrott vom März! Ich traue mich gar nicht, den Laptop heute wieder auszuschalten. Jedenfalls nicht vor einer vollständigen Sicherung. Was mach ich jetzt mit den Updates? Wieder aussetzen? Und wieso finde ich nirgendwo den Hinweis auf diese Art der Anmeldeprobleme durch diese Updates? Ich werde doch nicht die einzige Betroffene sein. Oder läuft bei mir am Gerät zusätzlich etwas falsch? Ich hoffe, jemand versteht das hier, denn ich bin einfach nur genervter Laie, was die Technik angeht. Was nutzen mir Sicherheitsupdates, wenn diese mir die Technik zerstören oder behindern? (Ich bin es echt leid, ich war auch ein Opfer von diesem unsäglichen Avira-Update vor einiger Zeit – gab einen neuen Computer – und vor einigen Jahren von dem Windows Dauer-Blue-Screen – gab einen anderen Computer.)
Ist definitiv kein generelles Problem mit dem Update, da wir das bei uns auf ca. 100 Geräten (sowohl Desktops als auch Notebooks verschiedener Hersteller) installiert haben und da hat keiner solche Probleme. Da muss noch was anderes verantwortlich sein, Treiber oder installierte Software zum Beispiel. Du schreibts da was von Avira, der könnte da auch reingrätschen. Ich bin persönlich kein Freund von deren Software bzw. insgesamt von Antivirensoftware von Drittherstellern, der eingebaute Windows Defender reicht normalerweise völlig.
Avira ist hier nicht mehr und kommt mir auch nicht mehr ins Haus, aber das war auch ein anderes Gerät. Der Laptop hier ist nur durch den windows defender geschützt, nachdem mir einige Fachleute versichert hatten, dass das reicht.
Wie lang wartest du ungefähr vom Beginn des Bootvorgangs bis du dich anmeldest? Der geplante Task "\Microsoft\Windows\PI\Secure-Boot-Update", der Secure Boot Zertifikate tauscht, startet 5 Minuten nach Systemstart und es gibt Berichte von unterschiedlichen Maschinen, die sich beim Versuch die Zertifikate zu tauschen hart aufhängen bis man sie stromlos macht. Grundsätzlich sollte Microsoft auf diesen Maschinen das Update nicht automatisch installieren (dafür haben sie ihre riesige Kompatibilitätsdatenbank und die Telemetriedaten), aber im März hatten sie es bei einigen Modellen doch geschafft. Wenn verfügbar, können BIOS-/Firmware-Updates das Problem beheben.
Wenn das die Ursache ist: Gibt mehrere Workarounds, jeder davon sollte den Freeze vermeiden:
– Den genannten Task auf Deaktiviert setzen in der Aufgabenplanung
– Registry Key "HighConfidenceOptOut=1" verhindert Secure-Boot-Updates selbst wenn Microsoft hohes Vertrauen hat dass es klappt. Suchmaschine deines geringsten Misstrauens weiß mehr
– Man kann auch Secure Boot komplett ausschalten (hat dann kein Secure Boot mehr, aber Windows versucht nicht mehr die Zertifikate zu aktualisieren). Wenn Bitlocker/Geräteverschlüsselung genutzt wird, diese vorher pausieren oder zumindest den Recovery Key griffbereit haben.
So oder so, wenn man das macht, werden die Secure Boot Zertifikate nicht mehr aktualisiert. Microsoft hat in einem Diskussionsthread in solchen Fällen empfohlen, mit der Angabe des Inhalts von BucketHash unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing (der gibt an unter welcher Kennung die Mainboardrevision + Firmwareversion in Microsofts Telemetrie geführt wird) ein Feedback im Feedback Hub zu eröffnen. Dann kann Microsoft das Modell entweder auf die Blacklist setzen oder schauen ob sie dazu mehr Telemetrie finden um die Ursache zu beheben.
Muss ehrlicherweise zugeben, dass ich nicht alles verstanden habe von deiner ausführlichen Antwort, muss alles wohl noch mal lesen unter Hilfestellung einer Suchmaschine. Aber zur ersten Frage: Also, der Zeitraum zwischen Bootbeginn und Anmelden ist deutlich kürzer als 5 min. Gleichwohl habe ich mit auswärtiger Hilfe den Task in der Aufgabenplanung für die secure-boot-updates deaktiviert. Bin mal gespannt, was am 12. Mai passiert. Aber was ich ja gar nicht nachvollziehen kann, ist, wieso windows 11 behauptet, es sei auf dem neuesten Stand, obwohl ich das Update deinstalliert habe. Das update kann sich doch wohl nicht deinstalliert und dann sofort wieder installiert haben, oder doch? Oder das Deinstallieren abgebrochen haben? (Ich fand es aber auch wirklich schräg und bedenklich, als am Vortag das Update losging, obwohl ich beim Laptop-Ausschalten ganz bewusst nicht "Update und Herunterfahren", sondern "Herunterfahren" ausgewählt habe.) Und wenn doch, warum quasi fehlgeschlagenes Deinstallieren den Fehler beim Anmelden beseitigt hat.
Ich bin nur froh, dass Patchday nur einmal im Monat ist.
bei mir ein ähnliches verhalten, 04/2026 update -> zack bitlocker recov key und dann schaltet sich der laptop einfach so beim anmelden ab und das schon zweimal.
das blöde daran, der laptop befindet sich leider jetzt an einem remote standort und niemand ist vor ort ^^
Eine Datensicherung ist vor Rettungsversuchen natürlich sehr empfehlenswert. Angeblich hängen manche der Probleme seit März mit der BIOS Version zusammen. Ein Update vom BIOS/UEFI und aller Treiber schadet vielleicht nicht aber so richtig gute Ideen habe ich grad nicht.
Steht etwas hilfreiches in der Ereignisanzeige? Ansonsten Update deinstallieren und bis nächsten Monat aussetzen. Überprüfung von Storage und RAM dürfte eher nichts anzeigen, wenn es ohne das Update ohne Probleme läuft.
Das update ist von mir deinstalliert worden, gleichwohl behauptet windows, es sei erfolgreich installiert. Seit dem Deinstallieren (Deinstallationsversuch?) klappt das mit dem Anmelden wieder. Bin jetzt sehr gespannt auf den Mai und halte das BIOS im Hinterkopf.
Nach Installation der Microsoft Security Updates vom April 2026 kommt es einem meiner Kunden zu einem kritischen Boot‑Problem auf mehreren Windows Server 2022 Systemen, die virtuell auf VMware vSphere (ESXi 8.0) betrieben werden. (als Citrix Multisession OS Server)
Fehlerbild
Nach erfolgreicher Installation der Updates starten die betroffenen virtuellen Maschinen nicht mehr.
Die VMs bleiben im UEFI‑Bootmenü stehen
Eine Auswahl im Bootmenü führt zu keiner Reaktion, der Bootvorgang setzt nicht fort
Secure Boot ist standardmäßig aktiviert
Die vSphere‑Umgebung läuft bereits auf ESXi Version 8.0, ein veralteter Hypervisor kann somit ausgeschlossen werden.
Das Verhalten ist reproduzierbar und betrifft ausschließlich Systeme, auf denen die April‑2026‑Updates installiert wurden. Setzt man den via Citrix MCS ausgerollten Snapshot zurück auf den Patchstand von März booten die Maschinen wieder korrekt.
Ich kann nur vermuten, dass es am Security Update von April liegt, andere Änderungen gab es am Master Image nicht.
Hat jemand zusätzliche Ideen?
"Es muss BitLocker aktiviert und die Gruppenrichtlinie Configure TPM platform validation profile for native UEFI firmware configurations (TPM-Plattformvalidierungsprofil für native UEFI-Firmware-Konfigurationen konfigurieren) eingerichtet sein.
Weiterhin muss PCR7 im Validierungsprofil enthalten sein (oder der entsprechende Registrierungsschlüssel wurde manuell gesetzt)."
Ich habe nicht den Hauch einer Ahnung, was das bedeutet oder wie das auf meine Systeme geraten sein sollte, aber das heutige Update hat mir bisher 2 Rechner abgeschossen.
Ganz normales, privates Windows 11 Pro 25H2
Update: 2 weitere BitLocker-geschützte W11Pro-Maschinen anderen Fabrikats haben nicht gezickt.