Im Juni 2026 laufen UEFI Secure Boot-Zertifikate für Windows ab. Im Oktober 2026 trifft es dann das nächste ablaufende UEFI-Zertifikat für den Secure Boot. Microsoft hat zum 13. Januar 2026 im Rahmen des Patchday erneut den Ansatz unternommen, das Secure Boot-Zertifikat im UEFI auszutauschen. Hier eine kurze Nachlese zum Sachstand.
Auslaufende UEFI Secure Boot-Zertifikate
Vor 15 Jahren wurden erstmals Secure Boot-Zertifikate (für Windows 8-Maschinen) ausgestellt und im UEFI ausgerollt. Erste 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.
Microsoft hat in den Supportdokumenten zu den Windows Sicherheitsupdates für Windows vom 13. Januar 2026, z.B. für KB5074109 für Windows 11 24H2-25H2, erneut an die in diesem Jahr ablaufenden UEFI-Zertifikate erinnert. Hier der betreffende Auszug aus dem Abschnitt "Ankündigungen und Nachrichten":
Ablauf des Windows Secure Boot-Zertifikats
Wichtig: Die von den meisten Windows-Geräten verwendeten Secure Boot-Zertifikate laufen ab Juni 2026 ab. Dies kann sich auf die Fähigkeit bestimmter persönlicher und geschäftlicher Geräte auswirken, sicher zu starten, wenn sie nicht rechtzeitig aktualisiert werden. Um Unterbrechungen zu vermeiden, empfiehlt es sich, den Leitfaden zu lesen und Maßnahmen zu ergreifen, um Zertifikate im Voraus zu aktualisieren. Details und Vorbereitungsschritte finden Sie unter Ablauf des Windows Secure Boot-Zertifikats und CA-Updates (englisch Windows Secure Boot certificate expiration and CA updates).
Von Microsoft heißt es, dass Nutzer möglicherweise Maßnahmen ergreifen müssen, um sicherzustellen, dass Ihr Windows-Gerät auch nach Ablauf der Zertifikate im Jahr 2026 sicher bleibt. Sowohl die UEFI Secure Boot DB als auch die KEK müssen mit den entsprechenden neuen Zertifikatsversionen für 2023 aktualisiert werden.
Zertifikate sollen per Update ausgetauscht werden
Ich hatte bereits 2025 im Beitrag Microsofts UEFI Secure Boot-Zertifikat läuft im Juni 2026 ab auf das Thema hingewiesen. Im letzten Jahr hatte Microsoft auch mehrfach versucht, Zertifikate im UEFI mittels Updates auszutauschen, was aber zu Problemen führte (siehe auch Links zu Artikeln am Beitragsende.
Zertifikate-Update von einigen Geräten im Januar 2026
In den Supportartikeln zu den Sicherheitsupdates vom 13. Januar 2026 für die diversen Windows-Versionen heißt es von Microsoft:
[Secure Boot] Starting with this update, Windows quality updates include a subset of high confidence device targeting data that identifies devices eligible to automatically receive new Secure Boot certificates. Devices will receive the new certificates only after demonstrating sufficient successful update signals, ensuring a safe and phased deployment.
Mit dem Januar 2026-Update rollt Microsoft also neue Secure Boot-Zertifikate aus, allerdings nur an Maschinen, deren Konstellation die automatisch Installation im UEFI ermöglichen. Nur wenn das UEFI bzw. das Windows-System bei der Abfrage signalisiert, dass das UEFI Secure Boot-Zertifikat erfolgreich und sicher aktualisieren kann, wird der Maschine ein aktualisiertes Zertifikat bereitgestellt.
Rollout in Wellen
Bolko weist in diesem Kommentar sogar darauf hin, dass das Rollout in Wellen erfolgt. Erst wenn genügend Geräte erfolgreich aktualisiert wurden, erhalten auch andere Geräte des selben Modells dieses Update in nachfolgenden Wellen.
Was ist mit Maschinen, die patzen?
Die große Frage, die auch Bolko in seinem oben erwähnten Kommentar anspricht, gilt den Maschinen, bei denen der Austausch der Secure Boot-Zertifikate im UEFI scheitert oder abgelehnt wird. Bolko verwies auf meinen Blog-Beitrag Vorsicht: Windows Juni 2025-Updates bricken Fujitsu-Rechner, wo ein spezieller Fall besprochen wurde.
Zudem hatte ich im November 2025 im Artikel Windows 10: Chaos beim Austausch neuer Secure Boot-Keys? noch auf gewisse Ungereimtheiten im Support-Beitrag Registry key updates for Secure Boot: Windows devices with IT-managed updates hingewiesen, die inzwischen aber korrigiert worden sind.
Maschine auf Zertifikatsprobleme testen
Im Support-Beitrag Registry key updates for Secure Boot: Windows devices with IT-managed updates finden sich im Abschnitt "Device testing using registry keys " auch Hinweise für Administratoren, wie man überprüfen kann, ob eine Maschine den Zertifikatstausch zulässt und das Zertifikat bekommen hat.
Dazu sind bestimmte Registry-Keys zu setzen. Die Ergebnisse werden in den im Supportbeitrag beschriebenen Registrierungsschlüsseln UEFICA2023Status und UEFICA2023Error sowie im Ereignisprotokolle (z.B. unter "Sicheres Starten – DB- und DBX-Variablenaktualisierungsereignisse") gemeldet.
Ist Secure Boot aktiv?
Ob Secure Boot auf einem Windows-System überhaupt aktiviert ist, lässt sich leicht prüfen, indem man die Tastenkombination Windows+R drückt und msinfo32 eintippt. Wird der Befehl abgesetzt, erscheint das Fenster mit den Systeminformationen.
In der Systemübersicht sollte im rechten Teilfenster der Zustand unter "Sicherer Startzustand" angezeigt werden. Ich habe Secure Boot bei meiner Windows 10-Maschine (und bei den Linux-Notebooks) deaktiviert.
Alternativ lässt sich der PowerShell-Befehl Confirm-SecureBootUEFI verwenden, der als Ergebnis True oder False anzeigen sollte. Dell hat hier ein Supportdokument bereitgestellt, welches Hinweise gibt, wie man die Zertifikate mittels PowerShell prüfen kann.
Auf GitHub gibt es noch Check-UEFISecureBootVariables, PowerShell-Skripte zum Überprüfen der UEFI-Variablen KEK, DB und DBX Secure Boot sowie Skripte für andere Secure Boot-bezogene Elemente.
Bei Intune gibt es einen Stopp
Interessant ist, dass Microsoft im Support-Beitrag Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates, erschienen am 4. Dezember 2025, in den "Known Issues" zum 16. Dezember 2025 folgendes eingestellt hat:
Microsoft Intune Error Code 65000 on Pro editions of WindowsSymptoms
Secure Boot configuration settings deployed through Microsoft Intune Mobile Device Management (MDM) are currently blocked on Pro editions of Windows 10 and Windows 11.
- Attempts to apply these policies result in Microsoft Intune Error Code 65000.
- Event logs might record POLICYMANAGER_E_AREAPOLICY_NOTAPPLICABLEINEDITION, indicating the feature is unavailable on this edition.
Workaround
The issue is under investigation, and additional information will be shared as soon as it becomes available.
Dieser Klemmer wird also bei Microsoft weiterhin untersucht und ist bisher nicht abgeräumt. Auf reddit.com wird in diesem Thread über die obige Frage diskutiert und in dieser Antwort listet jemand ein Intune Detection Script, was prüft, ob das Windows UEFI CA 2023-Zertifikat gefunden wird.
Frage an die Leserschaft
Das Thema bewegt viele Administratoren – auf reddit.com gibt es diesen aktuellen Thread, auf administrator.de hat jemand diesen Thread zum Thema eröffnet. Diskussionen zu Problemen – auch mit obigem Registry-Key – finden sich in diesem Thread vom 12. Januar 2026.
Wie ist der Update-Status bezüglich UEFI Secure Boot-Zertifikatsaustausch? Ist das Ganze bereits vom Tisch? Gibt es Probleme bei euch? Steht der Zertifikatswechsel noch an?
Ähnliche Artikel:
Microsoft Security Update Summary (13. Januar 2026)
Patchday: Windows 10/11 Updates (13. Januar 2026)
Patchday: Windows Server-Updates (13. Januar 2026)
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
Frage: BlackLotus-Schwachstelle und ablaufendes UEFI-Zertifikat – was droht uns?
Windows 10/11 KB5053484: Neues PS-Script für Zertifikate in Boot-Medien
Windows 10: Chaos beim Austausch neuer Secure Boot-Keys?
FAQ und Script zur Secure Boot-Absicherung gegen CVE-2023-24932 (Black Lotus)
MVP: 2013 – 2016
Also laut dem Script von GitHub (Check-UEFISecureBootVariables) ist bei mir nach sämtlichen Updates nur der 4. Abschnitt,"Current UEFI DBX" aktuell.
"Current UEFI KEK", "Default UEFI KEK", "Current UEFI DB" und "Default UEFI DB" lassen sich nicht aktualisieren.
Kann das mal jemand erklären, was davon gebraucht wird und wie das aktualisiert wird? Secureboot ist aktiv und funktioniert auch (noch).
Du brauchst alles, die DBX ist nur die Sperrliste von den Zertifikaten. Kenne aber auch nicht das github script, da ich mit eigenen arbeite.
Wenn es jetzt nur einen Computer betrifft und du über Powershell nicht fit bist, schau am besten Mal ins UEFI Bios und dort ins Zertifikatsmanagement von SecureBoot. Sind da die 3 CA 2023 Zertifikate in der DB drin, schaut's gut aus. Die DBX brauchst du "nur" für Security, aber der Computer läuft auch ohne den Eintrag in der DBX weiter.
Diese Option hat der PC/BIOS nicht.
Du meinst vermutlich sowas wie Custom-Keymanagement, wo man aus dem BIOS heraus Keys/Datenbanken durch neue von irgendeinem angeschlossenen Laufwerk aus einlesen kann?
Ja, genau, das meinte ich. Wenn dein Computer das nicht unterstützt, du schon das aktuelle BIOS schon eingespielt hast und über Windows du auch keinen Erfolg bei den Updates hast, hast wahrscheinlich leider bald einen Briefbeschwerer außer du kannst SecureBoot deaktivieren.
Für den Fall: Secureboot kann abgeschaltet werden. Der Hersteller liefert keine BIOS-Updates mehr.
Noch zwei Fragen: Beim ausführen des Scriptes "Check UEFI PK, KEK, DB and DBX" werden bei allen Default-Einträgen (das sind wohl die aus dem BIOS) wird angezeigt: "Warnung: Failed to query UEFI variable …..", sind die nicht auslesbar?
Und was ist mit dem Eintrag "Microsoft Option ROM UEFI CA 2023"? Welchen Stellenwert hat die für Secureboot und wie kann oder muss die aktualisiert werden?
Ob sich dbdefault etc. nach Boot des Betriebssystems auslesen lassen hängt vom BIOS-Hersteller ab. Sie müssen es nicht, manche bieten es aber an. Die Inhalte sind auch nur relevant, wenn man das BIOS oder die Secure-Boot-Keys im BIOS "auf Standard zurücksetzt".
Die Option ROM UEFI CA ist relevant für Steckkarten (z.B. Grafikkarte, Netzwerkkarte, RAID-Controller) die eine "BIOS-Erweiterung" (Option ROM) mitbringen, die beim Booten geladen wird. Diese Option ROMs sind momentan von Microsoft mit der 2011-CA signiert. Neue Gerätemodelle die neue Option ROMs bekommen, werden in Zukunft mit der 2023-CA signiert werden. Fehlt die CA im BIOS, wird nach Einbau eines solchen Geräts ein Booten von diesem Gerät bzw, die Nutzung des Geräts vor das Betriebssystem geladen ist (je nach Gerät) bei aktiviertem Secure Boot nicht möglich sein, da das Option ROM nicht geladen wird.
Die Default Zertifikate kommen zum Zug, wenn du das UEFI auf Standardeinstellungen zurücksetzt. In der Regel kann man die nur mit Firmwareupdates aktualisieren. HP und viele weitere PC-Hersteller halten sich noch zurück. Das DBX-Update ist riskant, weil unter Umständen die alten Zertifikate unwiederrufbar gesperrt werden. ISO und Netzwerkinstallation booten danach nicht mehr mit Secure Boot (kann mit Skripten repariert werden). Auch Windows bootet danach eventuell nicht mehr, wenn der Bootloader noch mit den alten Zertifikaten signiert ist.
HP hatte im 09.2025 die HP-Firmware zu Verfügung gestellt. Bei 2 Test Z-Notebooks habe ich die neuen Updates (DBX) installiert. Keine Probleme die Geräte funktionieren tadellos im internen und externen Netzwerk. Acer kommt im ersten Quartal 2026 mit den DBX-Updates. Auch hier werden 2 Test Notebooks dannzumal zu Verfügung stehen, zum testen. Abschliessend werden wir entscheiden wie die nächsten Schritte im Umfeld aussehen werden.
Das zu überprüfen ist alles viel zu kompliziert. MS hat ein Tool zur Verfügung zu stellen was man runter laden und ohne es zu installieren ausführen kann. Dass zeigt dann den Status und Ablaufdaten an und bietet eine Option das Zertifikat zu ersetzen wenn es zu alt ist.
So und nicht anders. Ich habe keine Lust und Zeit auf unzähligen PCs rumzufrickeln nur weil MS mal wieder seine Hausaufgaben nicht macht. Wenn der Rechner wegen abgelaufenen Zertifikat nicht mehr bootet sollte MS haftbar gemacht werden können.
Bitte den Link dazu posten.
Danke.
KEKUpdatePackage_2304.zip von Microsoft
https://aka.ms/KEKUpdatePackage
Leider gibt es dazu 0 Informationen oder Anleitungen, wie man das benutzen soll.
Was muss da ausgeführt werden? Die Powershell? Die .exe? Mit irgendwelchen Parametern?
Vorsicht! Evtl will er Dur was unterschieben.
@Günther Born: unkommentiert hier irgendwelche Direktdownloads Posten ist aber nicht die feine englische Art…
Jan es ist ein MS-Link alles ok!
https://download.microsoft.com/download/3/c/d/3cd0b572-b296-4367-942c-ac1a6fc4fad5/KEKUpdatePackage_2304.zip
Ob die von TBR gepostete Datei ein korrekter Link ist, kann niemand beurteilen. Weder wird die gekürzte URL zu einer langen URL expandiert, noch kann man sonst feststellen, was genau die Quelle ist. In Chrome sehe ich nach dem Download weder in der History, noch im "Downloads" Bereich nähere Informationen zur Quelle.
Daher ist Skepsis wirklich angebracht! Der User Anonym hat das aber scheinbar ohne weiteren Check einfach herunter geladen. Das wäre Sicherheitsnote 6.
Laut einem DIFF Vergleich ist die Datei aber identisch zu der, die man über deinen MS Link herunterladen kann.
Nebenbei: Die Dateien sind von 2023. Daher bleibt die Frage: was genau soll ich mit den enthaltenen Dateien anfangen? Angesichts der geschilderten, potentiellen Probleme mit ISOs, Boot-Laoder etc sollte man nicht einfach mal eben die KEK-Daten aktualisieren.
Die KI sagt:
Es baut ein sicheres, signiertes UEFI‑Paket, das einen neuen KEK‑Eintrag (Microsoft KEK 2023 o. ä.) an die bestehende KEK‑Datenbank eines Geräts anhängen würde – aber nicht direkt ausführt.
Es ist Teil eines Hersteller-/OEM‑Workflows, nicht für Endnutzer gedacht.
Man kann sagen:
„Dieses Skript erzeugt das finale KEK‑Update‑Paket, das Microsoft später als Firmware‑Update an Geräte verteilt, um die neuen Secure‑Boot‑Zertifikate einzuspielen."
Crt's von ms (github) laden und mit in den Ordner packen und falls die fehlen installieren (Explorer-Klick-Rechte-Maustaste auf die Datei (*.crt)) und dann den Task (PI) Secure-Boot-Update mal per Hand starten, falls nötig.
https://ibb.co/XvPBfbV
github link
https://github.com/cjee21/Check-UEFISecureBootVariables/archive/refs/heads/main.zip
vorsicht! das ist nicht universalkompatibel, sonst wärs ja auch zu einfach!
merkt euch besser den vorigen AvailableUpdates regwert und setzt ihn notfalls zurück falls euch anschliessend immer wenige minuten nach dem boot komplett der rechner einfriert.
https://learn.microsoft.com/de-de/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
bitte genauer lesen :) Ich fordere so ein Tool von MS – gibts so nicht.
Ja, habs eben nochmal gelesen das ich das überlesen habe… Man(n) hätte das aber verständlicher definieren können, aber egal…
Man fängt sechs Monate (!!!), nicht Jahre (!!!!eins!!elf), vor Ablauf der Zertifikate an, diese zu tauschen.
Das habe ich mal anders gelernt.
fairerweise, die Zertifikate stehen schon viel länger zur Verfügung als nur 6 Monate.
Ich habe den Eindruck sie versuchen es schon mehrere Jahre, hatten aber gehofft dass sie es gelöst bekommen ohne es an die große Glocke zu hängen.
Ich bin mir mittlerweile auch gar nicht mehr so sicher, dass zwischen dem drohenden Ende der Secure-Boot-Zertifikate und dem angekündigten Supportende für Windows 10 und dazu gehöriger erhöhter Hardwareanforderungen kein ursächlicher Zusammenhang besteht. Mehrere Fliegen, eine Klappe, und so.
Aber dafür habe ich natürlich keine Beweise.
Für Windows 10 mag das stimmen. Aber die Zertifikate laufen auch auf Windows 11 System aus.
also in meinen betreuten Umgebungen sind wir schon Recht weit fortgeschritten, habe einen Teil automatisiert via Powershell Scripte, und Abfragen die dann Werte ins AssetSystem spülen damit kann ich dann tracken welche Geräte patzen bzw. welche in Ordnung sind.
Lessons learned war auf jeden Fall ältere Computer bzw. UEFI haben Probleme, weil denen die Schnittstelle fehlt zum Updaten via Windows OS – es reicht also nicht aus, dass Secure Boot aktiv ist. Dort kann man sich dann manchmal noch behelfen in dem man manuell die Zertifikate via USB Stick ins UEFI einspielt – das funktioniert sehr problemlos, Vorraussetzung sind dafür aber die entsprechenden Menüpunkte exposed im UEFI/BIOS.
Blöd ist dann nur die Kombination, wenn sowohl Cert Management direkt über UEFI und auch über das Windows OS nicht möglich ist. So musste ich mich leider schon von ein paar Acer Notebooks trennen da die dann im Juni in einen "kaputt" Zustand laufen, obwohl sogar als voll Win11 kompatibel im Einsatz waren.
Mir war überhaupt nicht bewusst, dass Windows selbst (zumindest theoretisch) die Zertifikate im UEFI BIOS austauschen/ergänzen kann. Ich dachte immer, dass MUSS vom Hersteller des Devices kommen oder zumindest, dass UEFI BIOS muss eine Option zum manuellen Keymanagement anbieten, so dass man die notwendigen Zertifikate selbst einspielen kann – aber eben erst mal alles außerhalb von Windows.m Betriebssystem
Hast du nähere Informationen dazu, wie dieses Feature/Schnittstelle/Spezifikation im UEFI BIOS heist, dass Windows (oder andere Betriebssysteme) die Secure Boot Zertifikate selbst austauschen/ergänzen können?
Das passiert über UEFI Get-Variable und Set-Variable (genauer dann Authenticated Variable Updates). Über die KEK Signierung findet dann der gültige Austausch statt. Gibt's kein gültiges KEK werden auch zukünftige Änderungen fehlschlagen.
das funktioniert sogar sehr gut, ich verwende den von MS implementierten Weg über den Registry Wert 0x5944 in AvailableUpdates bei HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot und habe das Ganze über eigene Powershell scripte erweitert. Die 0x5944 zählt dann quasi runter und arbeitet einzelne Schritte ab, leider nur halb automatisch es gibt dann noch ein paar Zwischenschritte zB den DBX part den ich dann mit meinem Script erweitert habe und noch eigene Custom "Hilfsflags" zum Auslesen für das AssetManagement.
Da das Ganze über einen längeren Zeitraum etwas zäh abläuft, kann man über den Task /Microsoft/Windows/PI/Secure-Boot-Update die Umsetzung beschleunigen. Mehrere Neustarts sind notwendig. Etwa 1/3 der Computer müssen händisch nachgebessert werden, habe aber auch noch eine Menge an AltComputer und OT in meinen Umgebungen.
Das Tauschen der DB-zertifikate per KEK ist ein Standardfeature, welches in der Speifikation von Secure Boot so drin steht. Dass manche Hersteller das nie getestet haben und es daher heute einige schwarze Schafe gibt wo es nicht funktioniert konnte Microsoft ja im Vornherein nicht ahnen.
Das Tauschen des KEK erfordert eine Signatur des Mainbordherstellers (mit dem Platform Key). Deshalb enthält das genannte Github-Repo ja auch eine Menge Signaturen, die Microsoft bei den Herstellern eingesammelt hat. Ob das signierte Updatepaket dann in Form eines BIOS-Update oder über die normale Updatefunktion vom OS aus ausgerollt wird, ist egal – in beiden Fällen ist der KEK nachher getauscht.
Auch hier gilt, dass diese Funktion von manchen Mainboardherstellern nie getestet wurde und daher nicht wie gewünscht funktionierten.
BIOS-Updates erfüllen nun zwei Zwecke:
– Sie können auch die Zertifikate tauschen, die genutzt werden, wenn man das BIOS oder die Secure-Boot-Konfiguration auf Standard zurücksetzt
– Sie beheben Bugs in der Funktion zum Tauschen von Zertifikaten (Authenticated Variable Updates), die jetzt aufgefallen sind da ein Hersteller (Microsoft) das jetzt mal machen wollte.
Wenn der Tausch der Zertifikate nicht funktioniert und du keine BIOS-Updates bekommst, hast du drei Optionen:
– Secure Boot ausschalten
– Zertifikate im BIOS-Setup tauschen (sofern es die Option gibt)
– Secure Boot auf Custom setzen und selbst einen Platform Key erzeugen, damit die nötigen Dinge signieren und einspielen. Nur was für Bastler (oder "Linux-Frickler").
Ansonsten wird der Start nicht sofort fehlschlagen, aber du bekommst keine Updates für den Windows-Bootloader mehr (sowohl sicherheitsrelevante als auch andere) und bei Einbau von neuen Hardware-Steckkarten (mit Option ROMs) sind diese evtl. vor Start des Betriebssystems nicht nutzbar, was gerade bei Grafikkarten oder RAID-Controllern essentiell ist.
Wo kann man denn die Zertifikate herunterladen, um sie anschließend über das Key Management im UEFI zu installieren?
Habe zwar letztes Jahr erfolgreich mein ASUS Rog Crosshair Hero VI aktualisiert. Trivial war der Vorgang aber nicht.
Ein UEFI Update auf UEFI Version 8902 alleine brachte es nicht. Im Key Management im UEFI wurde nach dem Update noch das alte Zertifikat angezeigt. Erst nach einem kompletten Systemreset, CR2032 ausbauen und Stromlos machen, hat er mir dann die aktualisierten Zertifikate im UEFI angezeigt.
Kann dir leider keinen seriösen Download anbieten, du kannst es aber aus einem funktionierenden Setup im UEFI BIOS exportieren sofern das im Key Management unterstützt wird. Glaube ich habe dafür DELL Optiplex mit Gen14 Intel CPU verwendet.
Werde mal nachschauen, ob man die Zertifikate beim ASUS Rog Crosshair Hero VI exportieren kann.
Habe noch ein Fujitsu Lifebook A1135 , Das protokolliert seit 3 Monaten immer Fehler 1801. Hat das update des Zertifikates noch nicht geschafft. (Habe im UEFI nachgeschaut).
Ein UEFI Update wäre möglich. Allerdings ist das bei Rechnern ohne Flash Back Funktionalität immer ein Risiko. Zumal das System mit UEFI Version 1.09 (mit der wurde es ausgeliefert) problemlos mit deaktivierten modern Standby läuft.
Nach meinem Verständnis, sollte Microsoft einen offiziellen Download für die Zertifikat anbieten. Dann kann es jeder der es sich zutraut von Hand nachladen.
Die Zertifikate liegen alle in einem Github-Repo von Microsoft:
Der KEK:
https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/KEK/Certificates/microsoft%20corporation%20kek%202k%20ca%202023.der
Wenn du Glück hast, reicht es den KEK zu tauschen und der Rest kann dann über den KEK automatisch getauscht werden. Wenn nicht, findest du die anderen Zertifikate daneben auch noch.
Heute wurde das Windows Update "Update des zulässigen Schlüsselaustauschschlüssel (Key Exchange Key, KEK) für sicheren Start" auf meinem System erfolgreich installiert.
Nach dem Reboot erhalten ich trotzdem den Ereignisfehler 1801:
"Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware. Review the published guidance to complete the update and maintain full protection. This device signature information is included here.
DeviceAttributes: BaseBoardManufacturer:Micro-Star International Co., Ltd.;FirmwareManufacturer:American Megatrends International, LLC.;FirmwareVersion:A.70;OEMModelBaseBoard:MAG B660 TOMAHAWK WIFI (MS-7D41);OEMManufacturerName:Micro-Star International Co., Ltd.;OSArchitecture:amd64;
BucketId: bbbbe9dcab8444da8d03c7aa608fa6fdf3f735cef608eb89368052da90513d25
BucketConfidenceLevel: "
Was muss noch tun? Ein Bios-Update bietet mir MSI nicht an (MAG-B660 WIFI MS-7D41).
Muss ich händisch eingreifen oder nur abwarten?
Danke vorab für die Tipps
meine meinung: warte einfach 6 wochen und prüfe dann ob du schon automatisch dran warst.
ich habe bei mir den task trigger von täglich auf 2wöchentlich umgestellt damit mich die eventlog-meldungen nicht so häufig nerven.
In den BIOS-Einstellungen muss das Update evtl. explizit erlaubt werden. Das sollte unter den Sicherheitseinstellungen irgendwo als "Policy" zu finden sein, je nach Board. Ist dort die Einstellung auf "disabled" oder "restricted", dann sind keine Updates möglich oder nur solche, die per Herstellertool selbst kommen.
Hinweis: Solche reinen Signaturupdates kommen selten mit den normalen BIOS-Updates der Hersteller – so zumindest meine Erfahrung.
Wenn alles nichts hilft, kann man auch mal Linux live-booten, denn fwupd bringt dort auch die Secure-Boot-Signaturen auf Stand. Weiterführender Link: https://wiki.archlinux.org/title/Fwupd
Wenn alle Zertifikate installiert sind ist es vermutlich ein PCR7 (Binden nicht möglich) Problem. Administrator->Systeminformation->PCR7 Konfiguration.
Wenn alle Zertifikate installiert sind, ist es vermutlich ein PCR7 (Binden nicht möglich) Problem. Administrator -> Systeminformation -> PCR7 Konfiguration. Vermutlich ist im UEFI der Boot Secure Mode nicht 'Standard'. Achtung, nach Einstellen von Standard sind nur noch die Default Keys vorhanden. Um einen schwarzen Bildschirm zu vermeiden, ist eine UEFI-Grafikkarte Pflicht.
Informative Erläuterungen zu dem Thema gibt es hier: https://www.heise.de/ratgeber/FAQ-Das-Secure-Boot-Desaster-9736679.html
Wer mehr wissen will, sollte sich die Artikel in den c't Heften 07/24 und 12/24 ansehen.
Ich habe zu dem Thema schon so viele Artikel gelesen und Scripts ausgeführt.
Total erfolgreich war ich noch nie.
Ich komme nun langsam zu dem Schluß dass mein HP Notebook mit dem HP eigenen Secure Boot gar nicht betroffen ist.
Wer weis dazu mehr
Bin gespannt wie es dazu weiter geht
Bei meinem 4 Jahre alten Lenovo Thinkpad war das neue Zertifikat nicht drin. Allerdings wohl in den letzten BIOS-Updates mitgeliefert aber nicht automatisch eingetragen. Im BIOS die Secure-Boot-Keys erst gelöscht und dann auf Standard zurückgesetzt und voila, jetzt drin ohne irgendwas installieren oder importieren zu müssen.
Dein Ergebnis ist normal und besagt, dass die neuen Cert's geladen/aktiviert wurden. Alleine das Bios zu aktualisieren reicht nicht aus, die neuen darin befindlichen Cert's müßen auch aktiviert werden. Solange das nicht passiert, sind die inaktiv und es gelten die vorhergehenden alten Cert's.
schon klar.
Wollte nur aufzeigen daß es neben Abwarten ob Windows-Update das macht oder manuellem Einspielen per Kommandos so noch eine zusätzliche Möglichkeit gibt die Zerts zu aktualisieren, aber eben nicht automatisch. Geht so halt recht simpel, sofern der Hersteller BIOS-Updates zur Verfügung stellt welche die neuen Zerts enthalten.
Also beim Lenovo Firmen-Thinkpad klappte das so, bei einem Shuttle-Mini-PC im Büro mit Win11 enthält das "neueste" BIOS von 2024 die neuen Zerts nicht. Bei meinem privaten, vor 2 Monaten angeschafften MSI Z890 Gaming Plus WIFI Board waren von Anfang an die neuen Keys aktiv, da mußte ich gar nichts machen.
Mega! Um die nicht aktive Standard Datenbank zu checken, starten Sie das PowerShell Kommando als Administrator:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023'
Ich hatte auf meinen beiden Rechenrn auch Probleme mit den Zertifikaten. Jetzt habe ich mir bei Github Check-UEFISecureBootVariables https://github.com/cjee21/Check-UEFISecureBootVariables/archive/refs/heads/main.zip heruntergeladen und damit hat das updaten geklappt.
Nach dem entpacken die "Check UEFI PK, KEK, DB and DBX.cmd" mit Admin Rechten starten und sollte bei den current einträgen was mit rotem x sein dann die "Apply 2023 KEK, DB and bootmgfw update.cmd" und auch die "Apply DBX update.cmd" ebenfalls mit Admin Rechte starten und anschließend den Rechner 2x neu starten, danach sollte beim Test mittels "Check UEFI PK, KEK, DB and DBX.cmd" bei current alles mit grünem Haken sein.
Ganz einfach auf meinem PC ist Secure Boot nicht aktiv, also brauche ich weder neue Bootloader noch neue Zertifikate, oder?
An sich schon. Trotzdem wird Microsoft die Neuerungen per Update einspielen. Hintergrund: Microsofts für Secure Boot genutzte Zertifikate haben ein Zusatzproblem, sie laufen 2026 ab. Microsoft kann sie danach nicht mehr zum Signieren neuer Bootloader nutzen. Also spielt der Konzern kurzerhand überall neue Zertifikate ins BIOS und installiert neue Bootloader. Im Idealfall merken Sie auf Ihrem PC davon aber nichts.
Ich finde das Thema sehr diffus.
Es heißt, als Privatanwender müsste man nichts tun … das würde alles mehr oder weniger über das Windows-Update erfolgen und die neuen Zertifikate dann auch (wann auch immer) rechtzeitig im BIOS landen und alles ist gut.
Nun habe ich hier bspw. 2 Laptops mit Win11 Pro. Beide ca. 6 Jahre alt, neueste gar nicht so alte BIOS-Updates der Hersteller. Natürlich auch die neuesten Win11-Updates. Mit W10Privacy ist die Telemetrie abgedreht (möglicherweise unglücklich und für dieses Thema nicht förderlich ?).
Die neuen Zertifikate sind nicht im BIOS, entsprechende Warnmeldungen im Event-Log vorhanden, dass die Zertifikate vorhanden sind aber nicht in der FW. Die wunderbaren Batch-Files/Skripte von "Check-UEFISecureBootVariables" ergeben das gleiche Bild.
Ich werde erst mal abwarten und habe die Telemetrie via Win10Privacy bzw. dem entsprechenden Registry Key mal testweise wieder auf "erforderlich" (1) von vorher "komplett abgedreht" (0) gesetzt. Keine Ahnung, ob das Win11 dazu bewegt, von sich aus aktiv zu werden, ohne manuelle Eingriffe.
Falls sich die nächsten Monate nichts am Zustand der Zertifikate im BIOS ändert, dann werde ich wohl oder übel die Zertifikate und das entsprechende Update des BootManagers via Skript/Powershell aktiv pushen … aber es kann doch nicht sein, dass man das wirklich händisch tun muss ?
Angenommen Secureboot ist nicht verfügbar, z.B. weil es im BIOS ausgeschaltet ist (und man es nicht will oder braucht). Dann bekommt man schon seit einiger Zeit den oben genannten Fehler 1801 im Event Log. Kann man aber ignorieren.
Die spannende Frage ist nun, was passiert nach Juni bzw. Oktober 2026?
Gehen die Updates in Windows 10 LTSC noch?
Gehen die Updates in Windows 11 noch?
Kann ich Windows 10 LTSC oder 11 noch ohne Uhrmanipulation neu installieren?
Gibt es Software (z.B. Microsoft 365 oder Teams), die zickt, oder andere unerwartete Konsequenzen?
Ja, das geht alles noch egal, ob du nun Secure Boot abgeschaltet oder Angeschaltet ist, das bleibt sich ungefähr gleich.
Man muss halt nur auf die Updates achten, die irgendwann von Microsoft eintrudeln werden. Aber im Endeffekt sollte das ohne Probleme über die Bühne gehen.
Ich habe halt Secure Boot auf den beiden Letzt verbliebenen Windows Rechnern Deaktiviert weil die beiden Rechner im Multiboot mit Linux laufen, da gab es zu Anfang immer mal Probleme, mittlerweile sollte das auch der Vergangenheit angehören. Außerdem Laufen dort zwei Analysegeräte dran die keine Zertifizierten Treiber besitzen und ich denke mal da wird es sonst Probleme geben.
Vermutlich ist das Thema vom Tisch. Vielleicht kommt aber trotzdem zur Absicherung eine Aufgabe für das RMM: https://roadmap.synaxon-services.de/p/uefi-secure-boot-readiness.
Man kann ja in einer AD-Umgebung die Logik via GrouPolicy steuern.
https://support.microsoft.com/en-us/topic/group-policy-objects-gpo-method-of-secure-boot-for-windows-devices-with-it-managed-updates-65f716aa-2109-4c78-8b1f-036198dd5ce7
Man kann es auf 3 Arten durchführen:
Enable Secure Boot Certificate Deployment
Automatic Certificate Deployment via Updates
Certificate Deployment via Controlled Feature Rollout
Aber ich finde nirgends etwas, was man am WSUS einstellen muss, damit die Zertifikate auch heruntergeladen und verteilt werden.
Ist es hier irgendwo enthalten?
Sicherheitsupdates (Security Updates)
Kritische Updates (Critical Updates)
Update Rollups (oft enthalten diese kumulativen Updates auch sicherheitsrelevante Komponenten)
Definition Updates (für Antiviren-Software etc.)
Updates (allgemeine Updates)
Oder holt sich der PC die um WSUS herum direkt von Microsoft?
Auf privaten PCs habe ich es bis jetzt immer geschafft, entweder mit oder ohne BIOS-Update vom Hersteller.
Die neuen Zertifikate sind in den monatlichen Kumulativen Updates enthalten. Einspielen tut sich dann der Task "Secure-Boot-Update" in der Aufgabenplanung.
Diese ganze Zertifikatsupdaterei für Secure-Boot ist mal wieder vollkommen unnötig kompliziert und schlecht gemacht. Kein normaler Nutzer wird sich dafür interessieren oder sich das mit dieser Art von "Linux-Fickelei" antun, so, wie es jetzt ist. Alleine die ganzen UEFI-Optionen und Unteroptionen kennt kaum ein Standardnutzer und wird darin auch nicht herumfuhrwerken. Wichtig ist, "geht" oder "geht nicht", und wenn "geht nicht" dann Rücksendung, Wegwerfen/billig bei ebay verticken und Neues kaufen. Alles andere ist eine Illusion von Leuten, die damit beruflich zu tun haben oder sich hobbytechnisch dafür interessieren.
Du bist ein Spaßvogel. Wie man gedanklich darauf kommen kann, ein Microsoft Problem als "Linux-Fickelei" zu bezeichnen, ist schwer nachvollziehbar. Es handelt sich um ein konzeptionelles Microsoft Problem. MS hat sich Secure Boot ausgedacht und sie haben dabei viele Fehler gemacht (z.B. das Anwachsen der Sperrdatei nicht im Blick gehabt). Das hat man davon, wenn eine gewinn-orientierte Organisation alleine einen Standard aus dem Ärmel schüttelt. Sinnvollerweise lässt man so etwas ein technisches Kommitee machen.
Zum deinem Thema "Linux-Fickelei":
Unter Linux erledigt das Firmwar Update Packet die Aktualisierung auf unterstützten Systemen recht elegant. Stand aber auch schon oben. Das das Problem nicht alleine durch Updates auf UEFI-Ebene erledigt werden kann, sondern alle signierten Loader entsprechend aktualisiert werden müssen, macht das Handling prizipiell ähnlich komplex wie unter Windows.
Dafür musst du dich bei Microsoft bedanken.
Bitte genau lesen. Es handelt sich um die Feststellung, dass sich die Herangehensweise des Updates unter Windows als EINE ART "Linux-Frickelei" anfühlt. Mit Linux selbst hat dies nichts zu tun. Dieses Fehlverständnis beim Lesen und die zusätzliche Herumreiterei auf einem Rechtschreibfehler sagen übrigens auch einiges aus.
Ein älterer Lenovo Bildschirm PC IDEACentre AIO 700 mit Windows 10 Pro mit ESU aktiv zeigt trotz normal funktionierenden Updates (Januar 2026 kumulativ ist erfolgreich installiert) bei den Windows Updates Einstellungen in roter Schrift:
Ebenfalls funktioniert das biometrische Gerät für Windows Hello offenbar nicht mehr und führt dazu, dass der Windows-Biometrie Dienst in eine Startversuch Dauerschleife läuft wenn man die Optionen zur Benutzeranmeldung aufrufen will (wo u.a. Windows Hello aufgelistet/angesprochen wird) und im Event Viewer massenweise Einträge hinterlässt.
Deaktiviert man das biometrische Gerät für Windows Hello im Gerätemanager, funktionieren die Anmeldeoptionen wieder und der Windows-Biometrie Dienst läuft auch wieder normal.
Bei der Analyse im Event Viewer stösst man auf Hinweise auf die bald ablaufenden UEFI Zertifikate.
Einträge bzgl. Fehler beim Windows Update selbst gibt es keine. Windows Update Problembehandlung läuft ohne Ergebnis durch. SoftwareDistribution neu anlegen lassen ändert auch nichts.
Ein aktuelles BIOS Update für das Gerät von Lenovo gibt es nicht, weder auf der Lenovo Support Webseite, noch über Lenovo System Update oder die Lenovo Vantage App aus dem Windows Store.
Secure Boot ist nicht aktiv auf dem Gerät.
Fragen:
Kann die o.g. Meldung mit den bald ablaufenden Zertifikaten zu tun haben?
Und ist die Sorge bzgl. der Zertifikate im Grunde egal, da kein Secure Boot verwendet wird?
Weitere Recherchen ergeben, das ist offenbar ein oft vorkommendes Problem ohne derzeitige Lösung, z.B. https://www.deskmodder.de/phpBB3/viewtopic.php?t=33927
Aber da die autom. ESU Updates ja funktionieren, stufen wir es mal als kosmetisches Problem ein.
was ist mit Rechnern welche noch mit Windows 10 und ESU laufen
aber ohne SecureBoot – können die überhaupt technisch per Windows
Update aktualisiert werden und falls ja ist damit zu rechnen das MS
das überhaupt noch macht…
Warum sollte das nicht mehr gehen?
Windows 10 hat z.B. noch ganz offiziell Legacy-Unterstützung (MBR) und ich halte es für sehr unwahrscheinlich, dass Microsoft die Updates kappt, wenn kein Secureboot aktiv ist.
Mein ASROCK Z77 Board lief bisher einwandfrei mit Windows 10 pro und ESU im Secure Boot Modus. Nach dem Update vom Januar 2026 kam öfter BSOD mit " KMODE EXCEPTION NOT HANDLED ". Sfc / scannow und DISM /online /cleanup-image /restorehealth ergaben keine Fehler, ebenso wie der Systemcheck vom RAM und der Treiber. Erst das Deaktivieren von Secure Boot im Bios half und der BSOD ist verschwunden. Jemand hier am Lesen mit ähnlichen Erfahrungen ?
Was ich noch nicht ganz verstanden habe….Wenn ich als Hostsystem Windows mit Hyper-V verwende (ohne Secure Boot) und als Gastsystem Windows mit Secure Boot. Muss ich am Hyper-V Zertifikate erneuern oder reicht dies nur im Gastsystem?
Im Netz finde ich dazu keine passende Antwort. Vielleicht könnt ihr mir hier weiterhelfen?
Wenn ich das System richtig verstehe, dann musst du die Zertifikate im Gastsystem aktualisieren. Was zur Zeit aber nicht funktioniert, da die UEFI-Zertifikate für KEK im virtuellen Rechner schreibgeschützt sind.
Hier gibts etwas Diskussion dazu: https://www.reddit.com/r/sysadmin/comments/1qd3cfg/my_confusion_with_microsofts_secure_boot_changes/
Angeblich arbeitet Microsoft an einem Fix für das Problem.
Auf unserer Testmaschine bleibt das Update der Keys mit dem Fehler 2147942419 = 0x80070013 hängen, was bedeutet, dass "das Medium schreibgeschützt" ist.
Die CA 2023-Zertifikate passen, aber das KEK-Zertifikat wird nicht aktualisiert.
Alles klar, danke für den Link
Hoffen wir MS hat bald eine Lösung
Kann mir wer erklären, warum der mit der Windows UEFI CA 2023 signierte "neue" Bootmanager am 15.05.2026 ausläuft? Ich weiß nicht so recht, wie ich das interpretieren soll.
mountvol S: /s
Get-PfxCertificate -FilePath "S:\EFI\Microsoft\Boot\bootmgfw.efi" | Format-List Issuer, Subject, NotBefore, NotAfter
mountvol S: /d
Issuer : CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
Subject : CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
NotBefore : 15.05.2025 21:23:59
NotAfter : 15.05.2026 21:23:59
https://github.com/cjee21/Check-UEFISecureBootVariables/archive/refs/heads/main.zip
Check-UEFISecureBootVariables-main.zip
Check EFI file info.cmd (as Admin)
Path to EFI file: C:\Windows\Boot\EFI\bootmgfw.efi
ProductVersion : 10.0.26100.30227
NotBefore : 19.06.2025 20:11:43
NotAfter : 17.06.2026 20:11:43
auf einem HP ProDesk 600 G3 DM habe ich das neuste Firmware Update eingespielt
da der Rechner von 2017 ist das BIOS laut HP Seite wohl nicht konform
nach dem Setzen der Certs mit dem Skript bekomme ich Fehlermeldungen:
The Secure Boot Update was blocked due to a knows firmware issue on the device.
Clear + Reset Certs hat nichts geholfen
Nun gibt es noch den manuellen Cert Mode im BIOS. Hier erwartet er aber \EFI\HP\PK.bin KEK.bin DB.bin und DBX.bin. Es reicht wohl nicht die Keys aus dem MS Repo einfach umzubennen da die wohl mit dem HP signert werden müssen?
Finde dazu leider keine Infos.
https://support.hp.com/my-en/document/ish_9642671-9641393-16#GUID-49C8C19D-32CC-4FF9-A635-4A87C0BB0046
hp files in den Ordnern im ersten Link
https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/KEK/HP
http s://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
http s://github.com/microsoft/secureboot_objects
http s://github.com/cjee21/Check-UEFISecureBootVariables
http s://gist.github.com/out0xb2/f8e0bae94214889a89ac67fceb37f8c0
http s://support.microsoft.com/de-de/topic/updateereignisse-f%C3%BCr-sichere-startdatenbanken-und-dbx-variablen-37e47cf8-608b-4a87-8175-bdead630eb69
danke für die Hilfe aber irgendwie übersteigt es meine Fähigkeiten
dann habe ich 5 Files aus dem ersten Link
KEKUpdate_HP_PK1.bin PK2.bin usw.
die nimmt das BIOS aber nicht als Custom Keys an?