Zwei völlig unterschiedliche Technologien, eine sehr ähnliche Problematik - DNS und Secure Boot sind beides Technologien die (idealerweise) problemfrei im Hintergrund laufen .. bis sie dann plötzlich zum Thema werden. Genau das könnte im Laufe dieses Jahres bei Secure Boot der Fall sein - die kryptographischen Vertrauensanker, auf denen UEFI Secure Boot beruht, stammen größtenteils aus dem Jahr 2011. Und das Ende fünfzehnjährigen Laufzeit nähert sich mit großen Schritten.

Um den "fachlichen" Teil dieses Beitrages mit einer positiven Nachricht zu beginnen: Es werden nicht plötzlich hunderttausende Computer zu Elektroschrott werden. Ein abgelaufenes Zertifikat "brickt" nicht automatisch ein betroffenes Gerät, ein bereits "vertrauenswürdiger" Bootloader bleibt dies auch weiterhin. Das eigentliche Problem ist subtiler, die Sicherheitslage im Boot-Layer friert ein. Ohne aktives Eingreifen verlieren betroffene Systeme die Fähigkeit, neue Boot-Komponenten zu verifizieren und / oder künftige Sperrlisten gegen Bootkits einzuspielen.

Im Kern geht es um drei Microsoft-Zertifikate die in den kommenden Wochen und Monaten auslaufen:

• Microsoft Corporation KEK CA 2011 - läuft am 24.06.2026 ab; sie signiert Updates an die Signaturdatenbank und die Sperrliste; sie wird ersetzt durch die Microsoft Corporation KEK 2K CA 2023;
• Microsoft UEFI CA 2011 (auch als "Third-Party UEFI CA" bekannt) - läuft am 27.06.2026 ab; sie signiert Drittanbieter-Bootloader und Option ROMs, darunter den Linux-Shim; bei der Erneuerung wird sie bewusst in zwei Zertifikate aufgespalten - die Microsoft UEFI CA 2023 für Bootloader und die Option ROM UEFI CA 2023 für Option ROMs;
• Microsoft Windows Production PCA 2011; läuft am 19.10.2026 ab; sie signiert den Windows-Boot-Manager; sie wird ersetzt durch die Windows UEFI CA 2023

Anmerkung: Bei der Recherche für diesen Post fand ich teilweise abweichende Daten in der Berichterstattung. Die in der Auflistung angeführten Datumsangaben stammen direkt von Microsoft.

Wie Eingangs schon erwähnt, der bloße Ablauf der Zertifikate macht kein Gerät unbrauchbar. Systeme starten unverändert weiter. Der eigentliche schaden ist ein schleichender Verlust von Funktionalität am Boot-Layer. Läuft die KEK CA 2011 ab und wird nicht durch ihren Nachfolger ersetzt, kann Microsoft einem Gerät keine signierten Aktualisierungen der Signatur- und Sperrdatenbank mehr zustellen. Damit erreichen künftige Widerrufe - etwa gegen neue Bootkits - das Gerät nicht mehr. Mit dem Ablauf der signierenden CA lassen sich außerdem keine neuen Bootloader und Boot-Komponenten mehr verifizieren, die nur noch 2023-signiert ausgeliefert werden.

Kurzum: Die Sicherheitslage friert auf dem letzten Stand ein anstatt "auszufallen". Betroffene Geräte booten weiter, sind aber gegen neu entdeckte Pre-Boot-Angriffe zunehmend ungeschützt und verlieren ebenso die Fähigkeit, sich dagegen nachzurüsten.

Konkret spürbar wird das vor allem dort, wo neue, ausschließlich 2023-signierte Artefakte auf alte Vertrauensanker treffen. Eine frische Windows- oder Linux-Installation von einem aktuellen Medium, ein nach Juni 2026 nur noch 2023-signiertes Linux-Shim-Sicherheitsupdate oder ein neuer Boot-Manager scheitern an der Verifikation, wenn die Firmware die 2023-Zertifikate nicht kennt. Linux ist hier über die Third-Party UEFI CA explizit mitbetroffen, nicht nur Windows.

Zwo, eins - Risiko?

Das Einbringen neuer Schlüssel greift tief in die Boot-Kette ein und bringt eigene Risiken mit sich. Das praktisch relevanteste betrifft BitLocker, denn jede Veränderung der Secure-Boot-Variablen verändert die PCR7-Messungen, was eine Abfrage des Recovery-Keys auslösen kann. Microsoft empfiehlt deshalb, BitLocker während des Updates temporär auszusetzen und vor jedem Schritt die Recovery-Keys in AD (oder Entra ID) zu sichern.

Schwerer einzuschätzen ist das Risiko fehlerhafter Firmware. Ein KEK-Update hat es in der Form nie zuvor gegeben, weshalb sich nicht ausschließen lässt, dass einzelne BIOS-Implementierungen ihn fehlerhaft umsetzen. Und selbst wenn die Updatemechanismen in der Theorie funktionieren sollten, hat laut eines Diskussionsbeitrages auf der Mailingliste des LVFS-Projektes zumindest ein Hardwarehersteller Zugriff auf einen wichtigen privaten Schlüssel verloren:

That means the platform keys in the hardware need to be changed, which is uncharted water and ""a terrible idea from an attestation point of view"".

Hinzu kommt eine eigene Klasse von problematischen Auswirkungen die per se kein Bug oder Fehler sind, sondern eine logische Schlussfolgerung der Gegenmaßnahmen - sobald die PCA 2011 über die DBX widerrufen wird, werden ältere Boot-, Recovery- und Installationsmedien (inklusive WinPE, OEM-Recovery-Partitionen und Backups) unbrauchbar. Und dieser Schritt ist bei aktivem Secure Boot nicht umkehrbar.

Was nun?

Wer Windows aktuell hält bzw. unter Linux die dual-signierten Shims und fwupd-Updates einspielt und vorab die OEM-Firmware aktualisiert, vollzieht den Wechsel meist transparent. Dies gilt insbesondere für Privatpersonen.

Auch für Verantwortliche in Unternehmen und Organisationen ist die zentrale Auswirkung damit weniger ein akuter Ausfall als ein Handlungsdruck mit "Verfallsdatum". Systemadministrator:innen sollten schnellstmöglich den Secure Boot- und Zertifikatsstatus der eigenen Systeme erheben (via PowerShell-Skript, Windows Update for Business, ..) und, sofern notwendig, einen entsprechenden schrittweisen Rollout der benötigten Änderungen planen, testen und durchführen.