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
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.
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?
(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.