Microsoft tauscht ja die Secure Boot-Zertifikate im BIOS aus, da die alten Zertifikate im Oktober 2026 auslaufen. Bei den betreffenden Updates scheint es aber Probleme zu geben, weil Microsoft bestimmte Anweisungen zum Zertifikatswechsel möglicherweise fehlerhaft vorgegeben hat. Ein Blog-Leser hat mich auf das Problem hingewiesen.
UEFI Secure Boot-Zertifikat läuft 2026 ab
Im Jahr 2026 laufen verschiedene Microsoft Secure Boot-Zertifikate im UEFI ab. Das betrifft im Juni 2026 das UEFI Secure Boot-Zertifikate. Im Oktober 2026 trifft es dann das nächste ablaufende UEFI-Zertifikat für den Secure Boot. Ich hatte im Blog-Beitrag Microsofts UEFI Secure Boot-Zertifikat läuft im Juni 2026 ab auf diesen Sachverhalt hingewiesen.
Microsoft hat zum 26. Juni 2025 den Techcommunity-Beitrag Act now: Secure Boot certificates expire in June 2026 zu diesem Thema veröffentlicht und obige Tabelle gepostet. Der Hintergrund ist, dass diese UEFI-Zertifikate vor 15 Jahren (für Windows 8-Maschinen) erstmals ausgestellt wurden. Neben obigem Artikel gibt es von Microsoft noch das Dokument Secure Boot Certificate updates: Guidance for IT professionals and organizations (Deutsch: Zertifikatupdates für den sicheren Start: Leitfaden für IT-Experten und Organisationen) mit vielen Details und technische Erläuterungen.
Ein Leserhinweis auf ein Problem
Ein Blog-Leser hat sich bei mir zum 11. November 2025 per E-Mail gemeldet, weil er bei der Aktualisierung der neuen Secure Boot Keys auf einem Windows 10 IoT 21H2 Enterprise LTSC in Probleme gelaufen es. Laut Leser stellte sich heraus, dass die Vorgaben:
2. 0x0800 – This bit tells the scheduled task to apply the Microsoft UEFI CA 2023 to the DB
mit
3. 0x1000 – This bit tells the scheduled task to apply the Microsoft Option ROM CA 2023 to the DB
vertauscht wurden. Die Bits zur Steuerung der Zertifikatsinstallation sind in folgender Tabelle aus Secure Boot Certificate updates: Guidance for IT professionals and organizations dokumentiert.
Wenn die Bits vertauscht werden, installiert der eingeplante Task das falsche Zertifikat oder installiert überhaupt nichts. Der Leser schrieb dazu: "Neben einem gescheiterten und ungewolltem Zertifikat, spielt die falsche Reihenfolge möglicherweise auch eine Rolle. Mit 'Microsoft Option ROM CA 2023' ist das eigentliche 'Microsoft Option ROM UEFI CA 2023' gemeint."
Korrektur des Microsoft-Artikels
In einer Nachtrags-Mail teilte der Leser dann noch mit, dass Microsoft den Artikel Secure Boot Certificate updates: Guidance for IT professionals and organizations vom 26. Juni 2025 folgendermaßen korrigiert habe:
2. 0x0800 – This bit tells the scheduled task to apply the Microsoft Option ROM UEFI CA 2023 to the DB.
If 0x4000 is also set, then the scheduled task will check the DB and will only apply Microsoft UEFI CA 2023 if it finds Microsoft Corporation UEFI CA 2011 already in the DB.
3. 0x1000 – This bit tells the scheduled task to apply the Microsoft UEFI CA 2023 to the DB.
If 0x4000 is also set, then the scheduled task will check the DB and will only apply Microsoft Option ROM UEFI CA 2023 if it finds Microsoft Corporation UEFI CA 2011 already in the DB.
Die darunter liegende Beschreibung zu "If 0x4000 is also set, …." enthält noch das vertauschte Zertifikat. Die nun geänderte Reihenfolge "2. Microsoft Option ROM UEFI CA 2023", "3. Microsoft UEFI CA 2023" mag Microsoft nicht stören, wäre auch mehr Arbeit gewesen, schrieb der Leser noch.
Obiger Screenshot zeigt übrigens die Änderungsmitteilung "MC1185931: Secure Boot playbook for certificates expiring in 2026", die im Microsoft 365 Admin Center oder hier abgerufen werden kann.
MVP: 2013 – 2016
Der letzte Link ist wohl eine geschlossene Gruppe denn "Sie sind nicht berechtigt, auf diese Inhalte zuzugreifen".
Es wird auch für alle Rechner lustig die noch mit legacy BIOS unterwegs sind, denn die fallen, sofern sie nicht umgestellt werden aus der MS Automatik irgendwann heraus.
Da darf man dann so einiges per Hand machen :).
Secure Boot mit Legacy BIOS? Geht das überhaupt, ich dachte das wäre erst zusammen mit UEFI eingeführt worden?
Natürlich nicht. Es gibt aber unmengen an Rechnern, die nie umgestellt wurden und um genau diese geht es!
Bei Lenovo laufen z.b. etliche Rechner im "Setup Mode". Da ist in wahrheit auch nichts mit "secure boot"!
Das Thema wird noch sehr viel Spaß bereiten!
im legacy mode sollten die Keys doch eh keine Rolle spielen
Sorry, das verstehe ich nichts so ganz. Rechner die nicht umgestellt wurden haben aber auch kein Windows 11, wo (zumindest offiziell) Secure Boot Pflicht ist. Bei den alten Kisten passiert einfach gar nichts, die werden weiterlaufen.
Problematisch sind ja nur Systeme, die auch Secure Boot verwenden. Und das geht nur mit UEFI.
Er meint wohl, dass der PC, der im Legacy Mode läuft, auch die Zertifikate nicht ins EFI geimpft bekommt, solange das aktuell noch möglich ist.
Dieser Client wird nach Ablauf der Zertifikate, die das EFI kennt aber nicht mehr in der Lage sein, via EFI zu booten. Oder nur mit Aufwand/Umwegen. Der Automatismus, dass das einfach via Windows Update da rein geimpft wird, dürfte aber fehlschlagen, sofern das System nicht via EFI bootet.
Wenn man also nicht bis zum Ablauf der Gültigkeit dort Hand anlegt und das System auf EFI Boot umstellt, dann wird das für alle diese Systeme zum Problem, sofern man irgendwann mal meint, auf EFI gehen zu wollen – was auch immer der Grund dafür sein kann.
Im Legacy Mode wird das natürlich weiter funktionieren.
Man kann auch EFI booten, ohne die Secure-Boot-Funktion aktiviert zu haben.
Dann sind die Zertifikate egal.
Das entspricht nicht den Windows 11 Systemanforderungen, aber es geht.
Der Austausch erfolgt doch automatisch über Windows Update. Falls man patcht, braucht man also keine weiteren Schritte durchführen, oder?
Was ist mit Systemen, auf denen ein Windows 10 läuft, das keine Updates von Microsoft mehr bekommt?
Ergänzung: Andere Frage: Was ist mit anderen bootfähigen Medien (USB-Sticks, DVDs)? Müssen die nun schon wieder neu erstellt werden? Nach dem Motto „man hat ja sonst nichts zu tun"?
Windows 10 kann das genauso wie Windows 11.
Siehe die Liste unterhalb von "Applies to":
support. microsoft. com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f
Windows 10 kann das seit 9.Mai 2023.
siehe
support. microsoft. com/de-de/topic/verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-%C3%A4nderungen-des-sicheren-starts-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Bei bootfähigen USB-Sticks und DVDs musst du kontrollieren, ob der Bootmanager \EFI\Microsoft\Boot\bootmgfw.efi das neue Zertifikat integriert hat und ob die "Secure Version Number" (SVN) im Bootmanager bootmgfw.efi mindestens genauso groß ist wie die SVN im UEFI.
Falls das Zertifikat passt, aber die SVN kleiner ist, dann bootet er nicht.
siehe Punkte 2 und 4 im zweiten Link oben.
Diese SVN-Nummer ist aber schlecht dokumentiert.
Mir ist keine Tabelle bekannt, welches Update oder welches Datum welche SVN eingeführt bzw erhöht hat.
Wie man die SVN abfragt ist ebenfalls unbekannt.
Man kann die neue aktuelle SVN eintragen, indem man die Bitmaske 0x200 einstellt (Punkt 4).
Einfach das gelumpe abschalten, für private ist das ohnehin uninteresant.
Gegenbeispiel:
Das Spiel Battlefield 6 braucht Secure Boot.
Im Prinzip stimme ich dir aber zu.
Tja und wenn Spiele das vollkommen unnötig vorraussetzen boykottiert man die!
Außer man gehört halt zu den Zwangsgestörten für die Verzicht nicht mehr möglich ist.
Was ist das mal wieder für ein Tonfall, Günther Born?
Ob interessant oder nicht, definiert doch aber der Anwender nicht irgendwer im Internet!?
Es gibt schon Beispiele, wo das durchaus sinnvoll ist, das zu nutzen. Auch privat.
Das Ding dabei ist halt nur, dass man die komplette Kette der Maßnahmen eben sauber implementieren muss – nicht nur sich ein Feature rauspicken sollte. EFI Secure Boot allein bringt gar nix. Das stimmt wohl und für sich allein gennommen braucht man das auch nicht.
Aber wenn man das in Summe betrachtet – inkl. aller Maßnahmen. Secure Boot, EFI Password zum Schutz vor Änderung der Bootreihenfolge. Festgepinntes Boot Gerät, Zugriff auf das Bootmenü untersagt, Verschlüsslung via Software oder wenn TPM genutzt, dann abgesichert mit PBA um den TPM Store zu verschlüsseln. Kein Standby der das System aufwecken kann ohne PBA zu erzwingen. Kein WinRE oder alternative ohne PBA usw. usf.
Zugedreht ist die Kiste nicht mit aktuell verfügbaren Mitteln knackbar. Es sei denn Jemand fingert die Encryption Keys während der Fahrt im laufenden System ab – aber das ist technisch eine ganz andere Baustelle. Das Notebook oder den PC einfach entwendet funktioniert damit nicht (mehr).
Aber ja, der default Zustand bei Windows 11, vor allem Home ist in der Form nicht sonderlich sicher. TPM only ohne PBA und ohne EFI Password mit offener Bootreihenfolge usw. kann man technisch auch gleich sein lassen. Der Vorteil davon ist bestenfalls noch, wenn die Disk mal stirbt und man Garantieansprüche vom Hersteller nutzt, die Daten nicht im Klartext da drauf stehen.
Tja wenn die Boardhersteller und MS das sauber implementiert haben, aber es war doch so das das Ganze erst Lücken aufgerissen hat weil sie geschlampt haben…
*******************************
Zugedreht ist die Kiste nicht mit aktuell verfügbaren Mitteln knackbar.
*******************************
Oder die Implementierung ist so schlampig das sie erst recht Lücken öffnet, was bereits so geschehen ist! Und das patchen wieder anderswo Löcher riß.
TPM war aber sowieso nie für die Sicherheit des Users bestimmt!
Genau, einfach Linux nehmen und fertig.
Aber nur, wenn man Secure Boot abstellt, oder? Schließlich wird auch der Linux Bootloader-Loader von Microsoft signiert, wenn ich da nicht etwas völlig missverstanden habe.
Abgesehen davon bin ich ja schon immer der Ansicht gewesen, dass Secure Boot aufgrund der Möglichkeit, von der Betriebssystem-Ebene aus manipuliert zu werden, „insecure by design" und damit sinnlos ist. Habe es bisher aber nach dem Motto „vielleicht braucht man's doch mal" auf meinem PC noch am Leben gehalten. So langsam nervt's aber.
Zugehörige Meldungen gibts auch bei Windows Server 2019 auf MBR/Legacy, sowohl in simplen VMs als auch auf Hardware, in beiden Varianten Lichtjahre von dem Thema entfernt.
LevelDisplayName : Error
Id : 1801
ProviderName : Microsoft-Windows-TPM-WMI
LogName : System
Message : Secure Boot CA/keys need to be updated. This device signature information is included here.
[…]
UpdateType: 0
HResult: Incorrect function.
Habe ich hier auf einem Server 2016 (Hardware) ebenfalls, auf einigen 2016 als VM dagegen nicht.
Zum Thema Secure Boot-Zertifikate habe ich jetzt schon mehrfach folgendes gelesen:
PowerShell als Admin öffnen und folgende Abfrage eingeben:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
True
Und wenn wie in meinem Fall die Antwort "True" lautet, dann ist alles ok. Da ich mich mit der Thematik selber nicht gut genug auskenne frage ich jetzt einfach mal nach, ob diese Abfrage ausreicht um abschließende Klarheit zu haben? Sollte vielleicht noch kurz erwähnen, dass ich mit 22H2 Pro unterwegs bin.
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match "Windows UEFI CA 2023"
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match "Microsoft Corporation KEK 2K CA 2023"
Sollten beide true ergeben.
Selbst bei unseren neusten Computern, letztes Jahr gekauft, mit neustem BIOS (die erhalten ja noch, Lenovo M70t 5 Gen), steht UEFI CA 2023 auf True, KEK 2K CA 2023 jedoch noch auf False…da ist noch der KEK 2011 aktiv.
Hab auch noch nicht rausfinden können, ob und wie man das sonst pushen könnte…
Zumindest konnte ich mittlerweile alle Geräte dazu bringen, das CA 2023 wenigstens mal vorhanden zu haben. Also bei uns alle:
UEFI CA 2011 True
UEFI KEK 2011 False
UEFI CA 2023 True
UEFI KEK 2023 False
OMG ich muss mich korrigieren…
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match "Microsoft Corporation KEK 2K CA 2023" ergibt bei uns auch True. Meine Abfrage enthielt einen Schreibfehler!!!
Ist aber auch verwirrend…Microsoft/Windows, mit und ohne 2K ;)
Der Wald und die Bäume ;)
Mal schauen wie Oma und Opa ihre Computer ab Sommer 2026 am Laufen halten. Ohne Profis wird das nicht gehen und viele Privatpersonen werden gar nicht mitbekommen, dass es auch bei Hardware welche erst 5-7 Jahre alt ist ein Update der Zertifikate braucht.
Beispiel hier mit einem HP-Notebook Baujahr Ende 2019:
UEFI-Zertifikatsupdate mit dieser Anleitung gestartet (setzen des Registry-Wertes), der Link ist dem oben erwähnten Secure Boot playbook entnommen:
https://support.microsoft.com/de-de/topic/registrierungsschl%C3%BCsselupdates-f%C3%BCr-den-sicheren-start-windows-ger%C3%A4te-mit-it-verwalteten-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d
Der Prozess endet mit dem Wert UEFICA2023Error = „0x80004005" im Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Es braucht nun vermutlich erst mal ein BIOS/Firmware-Update. Gibt es für dieses Gerät, was wenn nicht? Fortsetzung folgt…
Das setzen des Registry-Wertes alleine reicht nicht aus, man muss auch den "Secure-Boot-Update"-Task starten. Der Registry-Wert dient nur dazu, um dem Task zu sagen, was er genau updaten soll.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Neustart und dann überprüfen mit (in Powershell):
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
siehe Punkt "1. Installieren Sie die aktualisierten Zertifikatdefinitionen in der Datenbank.":
support. microsoft. com/de-de/topic/verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-%C3%A4nderungen-des-sicheren-starts-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Danke, ja so geht es schneller. Ich hatte den Wert für AvailableUpdates gesetzt, dann einen Reboot gemacht und danach gewartet bis in UEFICA2023Status = "InProgress" stand (der Task gelaufen ist).
Klappt aber immer noch nicht, in der Ereignisanzeige gibt es folgende Meldungen:
TPM-WMI 1801 Secure Boot CA/keys need to be updated…
TPM-WMI 1795 The system firmware returned an error Unbekannter Fehler when attempting to update a Secure Boot variable 64. This device signature information is included here. [Firmwareangaben …]
Sieht danach aus, als ob das OS nicht ins TPM schreiben kann. Nächster Schritt BIOS-Update.
Das BIOS ist jetzt auf die neueste Version vom März 2025 aktualisiert. Das „Windows UEFI CA 2023" Zertifikat wird immer noch nicht aktualisiert. Gleicher Fehler wie vorher: TPM-WMI 1795 The system firmware returned an error Unbekannter Fehler when attempting to update a Secure Boot variable 64. This device signature information is included here. [Firmwareangaben …]
Leser @Jürgen hat vor ein paar Tagen in einem Kommentar 1) geschrieben: „…HP ist gerade im Roll-Out: https://support.hp.com/de-de/document/ish_13070353-13070429-16
Allerdings nur 2018 und jünger."
Dort steht dann die Timeline wie HP die aktualisierten BIOS zur Verfügung stellt:
HP PC ab Einführungsjahr 2024 haben die aktuellen Zertifikate bereits installiert.
Für HP PC mit Einführungsjahr 2022-2024 sollte es seit 30.9.2025 aktuelle BIOS geben.
Für HP PC mit Einführungsjahr 2018-2021 sollten bis zum 31.12.2025 BIOS Update verfügbar gemacht werden. Alles was älter ist bekommt kein BIOS-Update weil HP diese Plattformen nicht mehr unterstützt.
Erkenntnis des Tages: die Secure Boot Zertifikate können nur aktualisiert werden wenn das BIOS mitspielt. Im Falle meines Testgerätes somit warten bis Ende 2025.
1) https://www.borncity.com/blog/2025/11/12/windows-10-22h2-out-of-band-update-kb5071959-11-oktober-2025/#comment-236485
Möchte vielleicht jemand einmal einen stichwortartigen (und leicht verständlichen) Ablauf für diejenigen, die proaktiv handeln und die Sache sicherstellen wollen, verfassen und hier posten (ggf. auch ein Script)? Ich bin mir sicher, dass sich viele darüber freuen würden. Bolko, hast du etwas?
Anleitung:
support. microsoft. com/de-de/topic/verwalten-der-windows-start-manager-sperrungen-f%C3%BCr-%C3%A4nderungen-des-sicheren-starts-im-zusammenhang-mit-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Runterscrollen bis "1. Installieren Sie die aktualisierten Zertifikatdefinitionen in der Datenbank."
In der Anleitung fehlt allerdings das Update des KEK-Zertifikats.
Man muss diese Änderung also durchführen, bevor KEK abgelaufen ist.
KEK-Update:
learn. microsoft. com/de-de/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx
In der Hinweis-Box gibt es folgenden Link zum Update-Paket:
aka. ms/KEKUpdatePackage
Hallo Bolko,
vielen herzlichen Dank für Deine Informationen.
Zu Deiner Antwort:
"KEK-Update:
learn. microsoft. com/de-de/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx
In der Hinweis-Box gibt es folgenden Link zum Update-Paket:
aka. ms/KEKUpdatePackage"
Ich habe nun auf UEFI CA 2023 aktualisiert.
Unten stehender Befehl liefert noch false:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match "Microsoft Corporation KEK 2K CA 2023"
Muss das Script aus dem Package jetzt zusätzlich manuell ausgeführt werden?
Ohne das neue KEK 2023 Zertifikat wird man ab der zweiten Jahreshälfte 2026 keine neuen Updates für DB und DBX installieren können, weil das alte KEK im UEFI deren Installation ablehnt.
In der DB stehen die erlaubten Signaturen, in der DBX stehen die gesperrten Signaturen.
Im Normalfall sollte man das neue KEK 2023 Zertifikat installieren.
Secure Boot wird aber dank des UEFI CA 2023 Zertifikats auch ohne KEK-Update die aktuellen Bootloader starten können.
>> „Secure Boot wird aber dank des UEFI CA 2023 Zertifikats auch ohne KEK-Update die aktuellen Bootloader starten können."<<
In den HP-BIOS gibt es in den Secure Boot Einstellungen einen Schalter „Enable MS UEFI CA Key". Nach meinem Verständnis muss dieser aktiv sein damit KEK aussen vor bleibt. Auf dem Testrechner hier ist der Schalter ab Werk aktiv.
support.hp.com/de-de/document/ish_13070353-13070429-16 unter Punkt "Informationen zu neuen Secure Boot-Zertifikaten"
Ergänzende Infos zu den Secure Boot registry keys:
support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d
Regkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Name:
AvailableUpdates
Ich habe jetzt manuell den Value auf 0x5944 (HEX) gesetzt
Anschließend mit PS (Admin) gestartet:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Jetzt ist der Value auf 0x4000 (Mit Windows UEFI CA 2023 signierter Boot-Manager aktiviert)
Der Key: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
UEFICA2023Status: Updated
WindowsUEFICA2023Capable: 0x2
und nach einem Reboot wird mir auch für
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match "Microsoft Corporation KEK 2K CA 2023"
ein True geliefert :-)
Es gibt 3 neue Gruppenrichtlinien für die Zertifikatupdates:
1. Enable Secure Boot Certificate Deployment
2. Certificate Deployment via Controlled Feature Rollout (CFR)
3. Automatic Certificate Deployment via Updates
windowspro. de/wolfgang-sommergut/update-uefi-zertifikate-fuer-secure-boot-3-neue-gruppenrichtlinien
Danke. Das sind alles gute Quellen. Die Kollegen haben das auch schon etliche Male gelesen. Ich denke die Leserschaft interessiert vor allem auch Best Practice Empfehlungen. Also was wird wann in der Praxis tatsächlich gemacht. In meinem Fall warte ich nicht das Microsoft Enforcement ab, sondern triggere die Maschinen vorab und schaue, ob es funktioniert hat. Was macht ihr?