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?
Ä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)
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.
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.
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.