Die Uhr tickt für Windows-Systeme, die Secure Boot verwenden. Im Juni 2026 laufen erste Zertifikate aus und Microsoft versucht, seit dem Jahr 2023 die Zertifikate zu aktualisieren. Aber es gibt Probleme, massive Probleme. Nun hat Microsoft Intune ein "Secure Boot-Playbook" mit Hinweisen veröffentlicht. Hier einige Informationen zum Thema.
Auslaufende UEFI Secure Boot-Zertifikate
Kurzer Rückblick, um was es eigentlich geht. Vor 15 Jahren wurden erstmals Secure Boot-Zertifikate (für Windows 8-Maschinen) ausgestellt und im UEFI ausgerollt. Die ersten, seinerzeit ausgestellten und immer noch mit Mainboards ausgelieferten Zertifikate laufen im Juni 2026 ab. Microsoft hat im Techcommunity-Beitrag Act now: Secure Boot certificates expire in June 2026 folgende Tabelle mit der Liste der ablaufenden Zertifikate veröffentlich.
Nach meinem dafürhalten sollten Geräte zwar nach dem Stichtag weiterhin booten. Aber es kann Probleme geben. Microsoft erklärt, dass das Ablaufen der Boot-Zertifikate ab Juni 2026 Einfluss auf die Fähigkeit bestimmter persönlicher und geschäftlicher Geräte, sicher zu starten, haben könne, sofern diese nicht rechtzeitig aktualisiert werden.
Problem ist, dass die Versuche Microsofts, die Secure Boot-Zertifikate per Windows Update zu aktualisieren, in der Vergangenheit "mehr oder weniger gegen die Wand gelaufen sind". Es kann mit der Aktualisierung klappen, muss aber nicht. Letztmalig habe ich im Blog-Beitrag Windows Januar 2026 Update tauscht Secure Boot Zertifikate berichtet. Microsoft versucht nun die Secure Boot-Zertifikate "in Wellen" auf Geräten zu aktualisieren, die das unterstützen. Aber viele Nutzer werden vor Systemen mit nicht aktualisierten Zertifikaten stehen.
Microsoft Playbook zum Zertifikatsaustausch
Die Tage bin ich auf nachfolgenden Post von Microsoft gestoßen, der sich mit dem Thema "Secure Boot" für Windows befasst und auf ein Playbook von Microsoft Intune zum Thema verweist.
Das Playbook mit dem Titel Secure Boot playbook for certificates expiring in 2026 ist zum 2. Februar 2026 in der Techcommunity erschienen. Im Playbook fasst Microsoft nochmals alles Wissenswerte zum Zertifikatsablauf zusammen. Dabei werden auch die Schritte zur Vorbereitung des Zertifikatswechsels skizziert, wie sich die Zertifikate über verschiedene Wege aktualisieren lassen und wie man den Boot-Status der Geräte überwachen und prüfen könne.
Problem ist, dass das etwas eine "Sonnenschein-Beschreibung" ist, die nur auf einzelnen Geräten funktioniert. In Teil 2 skizziere ich zwei Szenarien, die mir die letzten Wochen untergekommen sind. In diesem Szenarien ist es nicht möglich, die UEFI-Zertifikate zum Secure Boot per Microsoft Update zu aktualisieren.
Artikelreihe:
Secure Boot-Zertifikatswechsel: Ein Playbook von Microsoft – Teil 1
Secure Boot-Zertifikatswechsel: Es gibt Hürden beim Austausch – Teil 2
Ähnliche Artikel:
Microsofts UEFI Secure Boot-Zertifikat läuft im Juni 2026 ab
Achtung: Microsofts UEFI Zertifikat läuft am 19. Okt. 2026 aus – Secure Boot betroffen
Windows 10: Chaos beim Austausch neuer Secure Boot-Keys?
Windows Januar 2026 Update tauscht Secure Boot Zertifikate
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status?
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
MVP: 2013 – 2016
Die Frage die sich mir stellt: Warum macht man das nicht über den MB Hersteller durch ein neues BIOS/UEFI Update? Der MB Hersteller kennt seine Bausteine ja wahrscheinlich besser als MS und kann auf seine Besonderheiten eher eingehen.
Diese "Updates" funktionieren auch seit Jahrzehnten problemlos.
Wieso muss MS da drin rumpfuschen?
Das Konzept von Secure Boot ist die Vertrauenskette.
Natürlich gibt es einen Machine (oder Plattform-) Key, den der Hardwarehersteller generiert und zum Signieren an Microsoft gibt. Diese Keys sind meistens 10 oder 20 Jahre gültig und i.d.R. im Moment nicht das Problem.
Problem ist, daß Microsoft seinen Master-Key 2011 (und damit vor der meisten heute noch gebräuchlichen Hardware) generiert hat. Genau der läuft ab.
Sicherlich kann auch der Hardwarehersteller ein Tool bereitstellen, das den Key im UEFI-Speicher tauscht. Streng genommen muß er es sogar, es gibt nämlich neben der verwendeten "current" Liste im UEFI-Speicherbereich noch eine "Default" aus dem BIOS, die zum Einsatz kommt, wenn man die "current" ganz plattgemacht hat bzw. bei der allerersten Einrichtung.
Nur ist halt ein BIOS-Update (das ja auch exakt zur vorhandenen Hardware passen muß) dem unbedarften Endanwender erst recht nicht zuzumuten.
Alle hier vorgestellten Tools ändern nur die "Current" Database, nicht die Default.
Das gilt übrigens auch für Linux (die entsprechenden Bootloader werden seit etwa 5 Jahren ebenfalls von Microsoft signiert, der erste war SuSE) und Hilfstools, die selbständig booten müssen (bei mir der Veeam Recovery Agent).
Ist ja möglich. Bei meinem Firmen-Notebook Lenovo P53, 4-5 Jahre alt, genau so passiert. Allerdings aktualisiert das BIOS-Update erstmal nur die "Default"-Zertifikate, darf nicht die tatsächlich verwendeten "Current" anfassen. Nachdem ich im BIOS die Secure-Boot-Keys erst gelöscht und dann wieder auf Default (somit das neue) gesetzt hatte waren auch die "Current"-Zertifikate aktuell. Ohne daß ich was installieren oder ein Windows-Update da was machen mußte.
Bei einem Mini-PC von Shuttle in meinem Büro ist das letzte BIOS von 2024 und mit den alten Zerts als "Default", denke da kommt wie bei vielen anderen nichts neues mehr nach. Bei dem habe ich halt das "Current"-Set selber aktualisiert.
Tun viele Hersteller ja auch anbieten. Aber ist nun mal auch keine wirkliche Lösung für den 0815 User.
Und schließlich muss die Aktivierung des "neuen" Bootloaders so oder so aus Windows selbst heraus erfolgen.
Wäre die beste Lösung, Problem daran:
– Hersteller stecken nur selten noch Arbeit in bereits verkaufte Hardware
– Wer soll das BIOS updaten? Z.T. werden die Aktualisierungen über Windows-Update angeboten&installiert, aber nur bei einem sehr kleinen Teil.
Da ist es viel einfacher, die Datenbanken+Zertifikate ins NVRAM einzuspielen (so wird es aktuell gehandhabt), diese Möglichkeit ist in den UEFI-Spezifikationen vorgesehen.
Die sind natürlich weg, wenn z.B. die BIOS-Einstellungen mal zurückgesetzt werden.
Nächste Baustelle: Die dbx-Datenbank wird immer größer, was eine Aktualisierung/Austausch bei wenig Speicher erschwert oder sogar die Maschine bricken kann, weil der NVRAM-Bereich überläuft.
Mein Acer Laptop ist 6 Jahre alt und ich nutze Windows 11 25H2, aktuelle Version. Heute hatte ich mit dem Acer Support telefoniert und der Mitarbeiter am Telefon meinte, das es für meinen Laptop kein Bios/UEFI Update geben wird! Er stellte zudem infrage, dass ein Update der Boot Zertifikate über Windows Update funktionieren würde, weil mein Bios/UEFI die Grundvoraussetzungen dafür nicht erfüllen würde. Ich zweifel jetzt auch. Sicherer Start ist bei mir aktiviert. Mein Bios/UEFIUpdate ist von 14.10.2022
Moin, so geht es mir mit meine 13" HP ProBook 430 G5 auch. Da das Erscheinungsjahr der Serie 2017 war, gibt es kein BIOS/UEFI-Update mehr lt. HP-Website, bei der die Secure Boot Zertifikate aktualisiert werden können.
Letztes und installiertes UEFI-Update ist HP Q85 Ver. 01.31.00 vom 15.01.2025.
Sehr schade …
Der Acer Support hat mir heute geschrieben, dass es für einige Geräte noch Bios-Updates geben wird. Zum Zeitpunkt haben sie geschwiegen. Aber angeblich sollen diese über Windows-Updates kommen.
Warum versehe ich denn sowas überhaupt mit einem Ablaufdatum? Oder warum setzte ich es nicht mit Ablaufdatum 200 Jahre oder so. Das ist wieder so ein hausgemachtes Problem.
wenn etwas unendlich unverändert läuft, kann es unendlich angegriffen werden.
was in der IT vor 10, 20, 30 Jahren als sicher und gut galt ist heute der blanke Horror.
was vor 20 Jahren ein Sicherheits Zugeständnis an Hardware und Performance war und trotzdem sicher, hat sich heute als Argument erledigt. im Rückblick kann jeder gut argumentieren, warum etwas "dumm" war, das Wissen (Erfahrung) fehlt aber am Tag der Entscheidung.
Zertifikate müssen ablaufen, da es ab einem bestimmten Zeitpunkt, aufgrund von Technik und besseren Wissens, nicht mehr vertrauenswürdig ist, was der Kern eines Zertifikats ist.
Erst wenn ein Zertifikat nicht mehr den aktuellen Sicherheitsstandards entspricht kann man es auch austauschen und wer es dann trotzdem nicht macht ist selbst schuld wenn etwas passiert.
Technisch ist es oft nicht notwendig aber finanziell schon.
Aus dem gleichen Grund sind, laut Microsoft, zu viele Geräte zu alt für Windows 11. Geld!
Wenn wir kein Ablaufdatum hätten und neue Erkenntnisse nicht einbauen würden, wäre wir immer noch bei der Caesar-Verschlüsselung.
Es ist keine Microsoft Entscheidung, das Zertifikate ablaufen, sondern eine aus gutem (technischen) Grund. Geld ist nur Beifang.
Der Hauptgrund ist Kontrolle über die Hardware.
Warum hat Dein Personalausweis ein Ablaufdatum? Und neuerdings Dein Führerschein?
Ja, es geht auch ums Geldverdienen. Aber eben auch darum, veraltete Informationen nicht ewig in der Welt zu lassen.
In den Anfangszeiten der Kryptographie um die Jahrtausendwende war es tatsächlich normal, Zertifikate mit z.B. 100 Jahren Laufzeit auszustellen.
Nur sind die irgendwann vom Stand der Technik überholt worden (512 oder 1024 Bit Schlüssellänge, MD5 oder SHA1 Signaturen) und heute nicht mehr sicher einsetzbar.
In der Tat geht heute der Trend zu immer kürzeren Laufzeiten, siehe z.B. https://borncity.com/blog/2025/04/16/tls-server-zertifikate-ab-2029-nur-noch-47-tage-gueltig/
Insgesamt alles sehr ärgerlich. Während manche Hersteller noch für ältere Geräte BIOS Updates nachliefern, tun das günstigere Hersteller eher nicht. Und ob dann das Update via Windows funktioniert, ist ja nicht sicher.
Durch Windows 11 hat Microsoft ja schon künstlich viele alte Laptops aussortiert und den Impact von dem Secure Boot Problem verringert.
Aber es wird doch einige treffen, die Secure Boot aktiviert haben und deren Laptop kein BIOS Update bekommt und über die Windows Updates die Zertifikate nicht aktualisiert werden können.
Ein aktuelles Beispiel ist von Dell der T30 PC. Den TPM Chipsatz konnte man von 1.2 auf 2.0 updaten. Dafür gab es ein Update von Dell. So konnte ich noch Windows 11 auf dem alten PC installieren. Jetzt schlägt Secure Boot zu. BIOS Update gibt es keins. Ein manuelles Updaten der Zertifikate schlägt fehl.
Bei Github gibt es eine Scriptsammlung mit der man
a) Prüfen kann, ob die neuen Zertifikate vorhanden sind
b) ob Windows auch wirklich mit den neuen Zertifikaten schon startet oder noch mit den alten
c) Man kann mit dem Script das Update selbst ausführen. Das funktioniert nicht auf allen PC's.
Einfach nach UEFI secure boot-zertifikate script googlen.
PowerShell scripts to check the UEFI KEK, DB and DBX Secure Boot variables as well as scripts for other Secure Boot related items.
Check-UEFISecureBootVariables
Hallo zusammen!
Mal 'ne eventuell ganz dumme Frage: Was mache ich in einer virtualisierten Umgebung?
Also wo und wie tausche ich in dem nicht allzu seltenen Falle eines VMware-Hypervisors, auf dem eine Windows-VM mit aktiviertem Secure Boot läuft, Zertifikate aus?
Für eine Erleuchtung bedanke ich mich im Voraus.
VMware ab der Version 8.2 enthält bereits die neuen Zertifikate.
Für veraltete VMware-Versionen gibt es hier eine Anleitung:
https://knowledge.broadcom.com/external/article/423919/manual-update-of-secure-boot-variables-i.html
Proxmox unterstützt die neuen Zertifikate ab der Version 9.1.4 (genauer gesagt dem Paket pve-edk2-firmware ab Version 4.2025.05-1).
Mit dem Parameter "ms-cert=2023w" werden auch bestehende UEFI-Disks aktualisiert:
https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_bios_and_uefi
In ältere Hyper-V Clients kann derzeit noch nicht der neue Microsoft KEK 2023 hinzugefügt werden. Das ist erst für ca. März von MS angekündigt. Dann wird es aber automatisch ohne eigenes Zutun beim nächsten Starten der VM passieren.
Die neuen 2023 Keys in die DB kommen dann auch ohne eigenes Zutun. Man kann sie aber auch schon jetzt problemlos zusätzlich installieren. Diese Updates wurden ja schon 2023 noch mit dem Microsoft KEK 2011 signiert.
Wer unbedingt meint das schon jetzt brauchen zu müssen kann nur die VM vom Host aus mit dem Powershell script Update-VMVersion oder im Hyper-V-Manager in den Einstellungen auf V13 upgraden.
Aber Obacht: Dann läuft der V13 Client nicht mehr auf Hosts vor Windows 11/Server 2025 und auch die Migration von/zu anderen Host OS wie VMWare, Virtualbox, Promox kann je nach Version nicht mehr möglich sein.
Also besser einfach Abwarten und Tee trinken.
Das war übrigens auch der Grund, warum Windows 11 Home/Pro VMs für das Januar Update hinter einer Firewall, die MS Telemetry blockert, bis zu einer Stunde brauchten. Sie versuchten damals ohne Erfolg den neuen KEK ins UEFI zu bekommen. Könnte daran liegen, dass der verwendete RSA Microsoft PK abweichend von älteren UEFI Standards 4096 und nicht nur 2024 bit lang ist.
Ich habe das UEFI KEK Update deshalb in solchen VMs bis auf Weiteres zwischenzeitlich deaktiviert. Das ist ja seit Oktober problemlos möglich. Selbst in der Home Edition durch entsprechende direkte Registryeinträge.
Fakt ist, der aktive Ausstauch der Zertifikate, sowohl von Seiten von MS wie auch den Herstellern, hätte schon vor mindestens 2-3 Jahren beginnen müssen.
Mir fehlt die Fantasie wie das ganze reibungslos in den nächsten Monaten ablaufen soll.
Zum einen läuft das alles schon seit Ende 2023.
Zum anderen werden auch PCs, wo keine neuen Zertifikate von Microsoft eingespielt werden können noch Jahre weiterhin mit alten Bootloadern auch bei aktiviertem Secureboot starten können.
Und geht selbst das irgendwann nicht mehr bleibt immer noch die Möglichkeit ein eh nicht mehr sicheres und dadurch völlig nutzlose Secureboot notfalls ganz abzuschalten.
Meiner Erfahrung nach alles halb so wild. Einfach folgendes machen:
1. Neuestes Firmwareupdate einspielen, sofern verfügbar (vor allem bei HP, wegen bekannter Probleme)
2. Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944
Das war's eigentlich. Wer den Prozess beschleunigen will, macht dann noch zweimal folgendes mit einem reboot dazwischen: Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Es ist natürlich nicht 100% auszuschließen, dass man damit das Gerät brickt – wie bei jedem Firmwareupdate. Man sollte also jeden Gerätetyp einmal getestet haben, auf den man das loslässt. Ich habe das aber auch schon erfolgreich mit einem P8H77-M LE Mainboard gemacht, dessen neueste Firmware aus dem Jahr 2014 (!) stammt.
Wie ist das eigentlich auf anderen Plattformen und Betriebssystemen? Wenn ich es richtig verstanden habe, gibt es UEFI-Secure-Boot ja auch bspw. für arm/arm64.
Müssen Chromebooks oder MacBooks auch zwingend dieses eine Microsoft Zertifikat aufgeladen bekommen?
Oder ist es nicht eher so, dass wenn man eine reine Linux-Installation hat, auch getrost UEFI-Secure-Boot deaktivieren kann? Und es passiert rein gar nichts nach dem ominösen Juni-Termin 2026?
Zu Chromebooks und Macs kann ich nichts sagen, aber es passiert natürlich nichts, wenn Secure Boot ausgeschaltet ist. Es sei denn, das installierte OS würde nicht ohne starten, dass ist aber bei Linux nicht der Fall. Ein aktuelles Linux kann Secure Boot, es ist aber nicht zwingend. Ist es bei Windows 11 im übrigen zumindest technisch auch nicht, das ist eine künstliche erzeugte Voraussetzung seitens MS.
Es passiert im Juni auch nichts, wenn Secureboot eingeschaltet ist. Das UEFI prüft keine Zertifikate auf ihre zeitliche Gültigkeit.
Natürlich kann man Windows 11 auch mit deaktiviertem Secureboot starten. Auch per BIOS(-Emulation) ist und bleibt problemlos möglich.
Linux bootet erst dann nicht mehr mit Secureboot, wenn ein shim gebootet werden soll, der mit dem neuen 2023 Zertifikat signiert wurde und dieses Zertifikat in der db fehlt. Das dürfte frühestens 2027 der Fall werden.
Du kannst auch auf einer reinen Windows-Installation Secure Boot deaktivieren und es wird nach dem ominösen Juni-Termin 2026 rein gar nichts passieren.
Ob du das für sinnvoll hält, ist deine individuelle Entscheidung. Genauso wie die Frage, ob du deine Wohnungstür abschließt oder nicht.
Muss man irgendwas machen, wenn Secure Boot abgeschaltet ist?
Nein
Nein. Auch wenn es eingeschaltet ist, "musst" du nichts machen.
Aber es wäre natürlich besser a) es einzuschalten und b) das Zertifikatsupdate zu machen. Am allerbesten noch c) die alten Bootloader mit Sicherheitslücken zu sperren.
Warum konkret sollte man es einschalten?
(Sorry, irgendwo falsch getippt; sollte eine Antwort an „Henry Barson" werden.)
Ich persönlich bin der Meinung, dass Secure Boot, weil es von der Ebene darunter, also dem Betriebssystem, manipuliert werden kann (anstatt nur direkt im UEFI bzw. per UEFI-Update), „broken by design" ist und keinen nennenswerten Sicherheitsgewinn bietet, ergo getrost abgeschaltet werden kann.
Meine Meinung; darf natürlich jeder gerne anders sehen.
Lies Dir bitte nochmal genau durch, wie Secure Boot funktioniert, oben sind von Günter genug Artikel verlinkt. Wenn es wirklich so "broken by design" wäre, wäre es seit 2011 bestimmt schon mal jemandem aufgefallen.
Dreh- und Angelpunkt ist das Trusted Platform Module (TPM) welches als Hardware nur wenige (und sehr aufwendige, wie etwa das Abschleifen des IC) Ansätze zur Manipulation bietet.
Dieses führt (wie in anderen Bereichen eine Chipkarte) die eigentlichen kryptographischen Operationen durch und bestimmt, welche zulässig sind.
Insbesondere weiterführende Aktionen wie das Laden des eigentlichen Bootloaders und das Entschlüsseln der (Bitlocker-)verschlüsslten Festplatten sind nur dann möglich, sonst gibt das TPM den Bitlocker-Key nicht heraus.
Für Aktionen wie den aktuellen Schlüsseltausch gibt es den sogenannten KEK (Key Exchange Key). Microsofts 2023-Update ist mit diesem Schlüssel signiert und nur mit einer gültigen Signatur werden Updates am Schlüsselmaterial überhaupt gestattet.
Wenn wir also annehmen, daß der private Teil dieses KEK weiterhin sicher bei Microsoft im Tresor liegt, kann es eigentlich keine Malware geben die eine gültige Signatur aufweist. "Eigentlich" schreibe ich, weil wir seit Edward Snowden wissen, daß die NSA ihre Überwachungskits irgendwie ebenfalls signiert bekommen hat.
Zudem ist es je nach Plattform und Konfiguration möglich, daß von Anwendungsseite überhaupt kein Schlüsseltausch zugelassen wird, dann bleibt nur der Weg, in die UEFI-Shell zu booten und dort den Key auszurollen.
Die Eilbedürftigkeit rührt einfach daher, daß auch dieser KEK Mitte 2026 ausläuft und dann (sofern das TPM über eine gültige Uhrzeit verfügt) gar kein Schlüsseltausch mehr möglich ist.
Noch ein Hinweis am Rande: Es ist eine allgemeine Lebensweisheit, daß sich die größten Gemeinheiten hinter kleinen Sternchen verstecken.
Eine solche ist in obiger Tabelle in der mittleren Zeile, der eigentliche UEFI-Key wird nämlich durch zwei verschiedene Keys ersetzt, "um eine feingranularere Kontrolle zu ermöglichen".
Secure Boot funktioniert unabhängig von TPM und Bitlocker.