Antimalware-Technologien existieren fast so lange wie Computerviren. Bereits 1972 wurde der Reaper-Wurm im ARPANet freigesetzt, um den Creeper-Wurm von 1971 zu stoppen. Beide Programme enthielten keine destruktiven Payloads, beanspruchten jedoch Systemressourcen. Die heute dominierende x86-/x64-Architektur wurde erstmals 1986 vom BRAIN-Virus befallen. Dessen Analyse beeinflusste die Karriere des IT-Sicherheitsexperten Mikko Hypponen nachhaltig. Bis heute sind über 10.000 Virenstämme mit über 100.000 Varianten bekannt. Besonders Rootkits bereiten IT-Verantwortlichen erhebliche Schwierigkeiten.

Diese Malwaregattung nistet sich in Systemkomponenten ein, die das System vor dem Betriebssystem-Kernel aktiviert, etwa im Bootloader. Dadurch kann ein Rootkit Hardwareaufrufe modifizieren, sodass der Rootkit selbst unentdeckt bleibt. Diese Methode ist weiterhin aktuell: Im Jahr 2021 leitete das Produkt FiveSys HTTP-Aufrufe infizierter Systeme auf fremde Ziele um.

Secure-Boot-Standard als Schutzmaßnahme

Um Rootkits zu bekämpfen, entwickelte das UEFI-Forum unter Federführung von Microsoft nach der Jahrtausendwende den "Secure Boot"-Standard. Er soll das Einschleusen von Malware in Firmware, Bootloader oder Kernel verhindern. Alle Programme im Bootprozess sind dafür digital signiert. Jede Komponente prüft die Signatur der folgenden, bevor sie die Steuerung übergibt. Schlägt die Validierung fehl, bricht der Bootprozess ab. Manche Hardwarehersteller ergänzen ihre UEFI-Implementierungen um einen Selbstheilungsversuch, der die Firmware bei Fehlern auf Werkseinstellungen zurücksetzt. Microsoft führte Secure Boot mit Windows 8.1 als Kompatibilitätsvoraussetzung ein. Zunächst mussten Hersteller die Funktion nur bereitstellen, aber nicht zwingend aktivieren. Seit Windows 11 fordert Microsoft UEFI Secure Boot zwingend für die Installation des Betriebssystems.

Ein Windows-PC mit Secure Boot erfordert die Kooperation mehrerer Akteure. CPU- und Chipsatz-Hersteller liefern den "Hardware Root of Trust" (HWRoT) und sichern den Prozess gegen Umgehung ab. Der Mainboard-Hersteller stellt das UEFI-Subsystem bereit und speichert den "Platform Key" (PK) so, dass der Schlüssel an die Hardware gebunden bleibt. Es obliegt dem Hersteller, PKs für Baureihen oder Einzelgeräte zu generieren. Manche Anbieter verwenden jedoch unsichere Testschlüssel der BIOS-Hersteller. Systeme nehmen den PK in der Regel als gültig an; eine Validierung der Laufzeit oder der Ausstellerinstanz erfolgt meist nicht. Das Zertifikat in der Hardware dient als Container für den Public Key. Das private Gegenstück verbleibt beim Hersteller zum Signieren des UEFI-Firmware-Image.

In der Ladesequenz steuern verschiedene Parteien Code bei. Neben Betriebssystem-Herstellern betrifft dies Anbieter von Peripherie wie Grafikkarten oder Entwickler von Festplattenverschlüsselungen. Deren Boot-ROMs oder EFI-Anwendungen unterliegen ebenfalls der Prüfung durch Secure Boot. Die UEFI-Spezifikation nutzt dafür einen zweistufigen Mechanismus: Die UEFI-Variable "DB" enthält eine Liste erlaubter Zertifikate für Bootloader, Option-ROMs und Betriebssystem-Images. Dies können Endpunkt-Zertifikate oder Zertifizierungsstellen (CA) sein. Auch SHA-256-Hashes von Softwareimages sind möglich. Die mit dem PK signierte Datenbank der "Key Enrollment Keys" (KEK) enthält Zertifikate, die Updates der DB autorisieren. In der KEK befinden sich meist Schlüssel des Hardwareherstellers und die KEK-CA von Microsoft. Drittanbieter müssen ihre Zertifikate von Microsoft oder den Plattformherstellern signieren lassen, um eigene Firmwareupdates durchzuführen.

Widerruf und Aktualisierung von Signaturen

Das Verfahren erlaubt den Widerruf kompromittierter Schlüssel über die UEFI-Variable "DBX". Sie enthält gesperrte Zertifikate oder Image-Hashes. Aktualisierungen der DBX erfordern eine Signatur mit einem gültigen KEK-Schlüssel. Zudem führen UEFI-Subsysteme oft eine "Default KEK" und "Default DB", um beschädigte Variablen wiederherzustellen. Microsoft baute 2011 eine PKI-Hierarchie mit drei CAs auf, die 15 Jahre gültig sind:

• Microsoft Corporation KEK CA 2011 (bis 24.06.2026)
• Microsoft Corporation UEFI CA 2011 (bis 27.06.2026)
• Microsoft Windows Production PCA 2011 (bis 19.10.2026)

Diese CAs laufen 2026 ab. Microsoft nutzt den Wechsel für eine stärkere Trennung der Zuständigkeiten. Die bisherige UEFI-CA wird durch zwei spezialisierte Stellen ersetzt: Eine für Bootloader der Systemhersteller und eine für Option-ROMs der Peripherieanbieter. Die neuen CAs wurden im Jahr 2023 signiert. Die Preboot-CAs sind bis 2038 gültig, während die Windows-CA 2035 abläuft.

Was passiert wenn Zertifikate ablaufen

Laut offizieller Microsoft-Kommunikation booten Geräte, die den 2023er CAs noch nicht vertrauen, weiterhin problemlos, sofern die UEFI-Firmware der Spezifikation entspricht. Die Signaturprüfung untersucht die zeitliche Gültigkeit der CA-Zertifikate nicht. Vor dem Bootvorgang steht eine verlässliche Systemzeit nicht zwingend zur Verfügung. Anders verhält es sich beim Signiervorgang selbst: Eine gültige Signatur lässt sich mit einem abgelaufenen Zertifikat nicht mehr erzeugen. Damit können Updates der UEFI-Komponenten und Bootloader nicht mehr mithilfe von Microsoft signierter Pakete durchgeführt werden, da Microsoft diese mit Zertifikaten aus der 2011er PKI nicht mehr signieren kann. Dies setzt das Sicherheitsniveau und die Wartbarkeit herab.

Updatepakete, die vor Ablauf der Zertifikate signiert wurden, lassen sich voraussichtlich auch danach einspielen, sodass IT-Profis versäumte Systeme auch 2027 noch nachpflegen können. Auch hier gilt die Voraussetzung der Kompatibilität der Firmware mit der UEFI-Spezifikation. Der Zertifikatsablauf bleibt nicht ohne Folgen: Sobald Microsoft Sicherheitslücken im Bootloader durch Patches behebt, werden diese mit einem 2023er Schlüssel signiert sein. Systeme ohne diese Zertifikate können den Patch nicht validieren. Das gleiche Problem tritt auf, wenn Peripherie wie Grafikkarten oder RAID-Controller nach November 2026 hergestellt wurden. Deren Boot-ROM ist nur durch 2023er Schlüssel signiert.

Besondere Vorsicht ist geboten, wenn Administratoren nach dem CA-Update die alten Zertifikate über die DBX sperren. Damit wird der Einsatz von Komponenten unmöglich, deren Boot-ROM ausschließlich mit den 2011er Schlüsseln signiert wurde. Dennoch ist das Sperren der alten PKI sinnvoll, da damit in der Vergangenheit zahlreiche Images signiert wurden, von denen einige als Malware identifiziert sind. Die aktuelle Sperrliste von Microsoft umfasst über 400 Image-Hashes.

Das Erneuern der Zertifikate im Überblick

Der Aufbau der Chain of Trust im Secure Boot ermöglicht es Hardwareanbietern, den Zertifikatsupdate-Prozess über ein Firmwareupdate durchzuführen. Windows kann anschließend den Bootloader austauschen. Einige Notebookhersteller liefern seit Ende 2023 Firmware aus, die die neuen und alten Microsoft-CAs parallel enthält. Für andere Systeme hat Microsoft das Update der UEFI-Zertifikatsspeicher in Windows integriert. Der geplante Task "Secure-Boot-Update" im Ordner "\Microsoft\Windows\PI" übernimmt die Durchführung. Dieser Task existiert auf allen Secure-Boot-fähigen Windows-Versionen und läuft ab Systemstart alle 12 Stunden. Dabei gelten zwei Einschränkungen:

1. Der schreibende Zugriff von Windows auf UEFI-Variablen erfordert, dass Secure Boot im nativen UEFI-Modus aktiv ist. Admins können dies in der PowerShell mit Confirm-SecureBootUefi prüfen. "True" bestätigt den Start durch Secure Boot, "False" signalisiert ein aktives UEFI bei deaktiviertem Secure Boot. Im BIOS-Modus liefert das Cmdlet eine Fehlermeldung.
2. Der Firmwarehersteller muss ein Updatepaket bereitstellen, dass den 2023er Microsoft-KEK-Key mit dem gültigen Platform Key signiert. Microsoft hat die OEMs dazu aufgefordert.

Damit der Task aktiv wird, müssen Sie im Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecureBoot" den DWORD-Wert "AvailableUpdates" setzen. Ein komplettes Update der Zertifikate erreichen Sie mit dem Wert "0x5944". Danach können Sie den Task manuell starten oder den nächsten Durchlauf abwarten. Der Wert "0x5944" setzt sich bitweise zusammen:

• 0x4000: Die beiden 2023er UEFI-CAs nur anwenden, wenn die 2011er UEFI-CA vorhanden ist
• 0x1000: UEFI 2023 CA anwenden
• 0x0800: Option ROM UEFI 2023 CA anwenden
• 0x0100: Den durch Windows UEFI 2023 CA signierten Boot-Manager anwenden
• 0x0040: Windows UEFI 2023 CA anwenden
• 0x0004: Microsoft KEK 2K 2023 CA anwenden

Aufgrund der KEK- und DB-Hierarchie muss der Vorgang zweimal wiederholt und das System dazwischen neu gestartet werden. Nach erfolgreichem Einspielen wird das jeweilige Bit auf 0 gesetzt. Ergebnisse werden im System-Ereignisprotokoll unter der Quelle "TPM-WMI" mit den Event-IDs 1801 (Fehler) oder 1808 (Erfolg) protokolliert. Die Zertifikate sind in aktuellen Windows-Patchständen bereits enthalten.

Client-Zertifikate automatisch erneuen

Bei Geräten mit Windows 10 oder 11 mit Berechtigung für Extended Security Updates (ESU) führt Microsoft den Prozess automatisch durch, sofern Telemetriedaten geliefert werden. Administratoren können den Prozess über ADMX-Vorlagen unter "Administrative Vorlagen \ Windows-Komponenten  \Sicherer Start" steuern:
-    Enable Secure Boot certificate deployment
-    Automatic certificate deployment via Updates (Aktiviert bedeutet hier: nicht automatisch aktualisieren)
-    Certificate deployment via Controlled Feature Rollout

Da es sich um Legacy-Richtlinien handelt, werden diese nicht automatisch auf Standardwerte zurückgesetzt. Es empfiehlt sich, jedes Modell einzeln zu testen und die Richtlinie per WMI-Filter, Group Policy Preferences oder Intune-Policies auszurollen.

Die Vorabprüfung ist bei aktivem BitLocker besonders wichtig. Veränderungen an der UEFI-Firmware lösen den Recovery-Modus aus, was die Eingabe des 48-stelligen Wiederherstellungsschlüssels erfordert. Falls das Firmware-Werkzeug des Herstellers die BitLocker-Verwaltung nicht automatisiert, müssen Sie den Festplattenschutz vor dem Update aufheben:

manage-bde -protectors -disable C: -RebootCount 0

Zertifikate auf Servern manuell installieren

Für Server hat Microsoft kein automatisches Updateverfahren vorgesehen. Die manuelle Aktualisierung führen Sie jedoch genauso durch wie oben beschrieben:

• Aktualisieren Sie die Firmware – der Stand muss neuer als März 2023 sein.
• Stellen Sie sicher, dass Sie Secure Boot tatsächlich einsetzen.
• Setzen Sie den Registrierungswert für "AvailableUpdates" auf 0x5944.
• Triggern Sie den geplanten Task oder warten Sie den nächsten Lauf ab.
• Kontrollieren Sie das Ergebnis.
• Starten Sie das System neu und wiederholen Sie den Vorgang.

Bei Servern müssen Sie genau abwägen, ob Sie die 2011er PKI nach erfolgreichen Updates durch einen Eintrag in der DBX sperren. Einerseits haben Zertifikaten aus dieser PKI sehr viele Images und Treiber signiert, was den Sicherheitsstandard absenkt, solange Sie dieser PKI noch vertrauen. Andererseits verbauen Sie sich durch das Sperren der alten Zertifikate den Einbau von Karten mit Boot-ROM, die noch keine 2023er Signatur tragen. Je nachdem, wie Sie den Lifecycle der Serverhardware in Ihrer Organisation handhaben, kann die Entscheidung hier unterschiedlich ausfallen.

Bei Systemen, auf denen kein Windows-Betriebssystem installiert ist, variiert das Handling von UEFI-Updates zwischen den Linux-Distributionen erheblich. Hier sind Administratoren meist auf Updates der Anbieter angewiesen. Linux-Server unter Secure Boot bringen in der Regel keinen eigenen signierten Bootloader oder KEK mit. Fast alle Distributionen nutzen den von Microsoft signierten First-Stage-Bootloader "Shim". Dieser prüft die Integrität des eigentlichen Linux-Bootloaders. Die standardkonforme Vertrauenskette endet somit faktisch beim Shim.

Zur Statusermittlung unter Linux dient der mokutil-Befehl. Auf einigen Plattformen lassen sich Aktualisierungen mit "fwupdmgr" vornehmen. Für den ESXi-Hypervisor steht eine finale Vorgehensweise noch aus; Broadcom empfiehlt derzeit, Anweisungen der Hardwareproduzenten abzuwarten.

Erfolgreiches Update der Zertifikate prüfen

Trotz automatisierter Rollouts ist eine Überwachung der Ergebnisse wichtig, um vor Ablauf der 2011er PKI manuell eingreifen zu können. Wenn ein Endpoint-Managementsystem Registrierungswerte erfasst, sind folgende Pfade unter "HKLM \ SYSTEM \ CurrentControlSet \ Control \ SecureBoot \" relevant:

• State\UEFISecureBootEnabled (0 oder 1)
• Servicing\WindowsUEFICA2023Capable (0, 1 oder 2)
• Servicing\UEFICA2023Status ("NotStarted", "InProgress" oder "Updated")
• Servicing\UEFICA2023Error (nur bei Fehlern vorhanden)

Zur Untersuchung einzelner Geräte dient das Get-SecureBootUEFI-Cmdlet. Da es Variablen in Rohform ausgibt, sind Skripte zur Dekodierung der Byte-Arrays in Image-Hashes oder X509-Zertifikate notwendig. Eine Sammlung von Skripten des Nutzers "cjee21" fasst diese Ergebnisse lesbar zusammen. Diese Werkzeuge können nach Prüfung als Basis für eigene Automatisierungen dienen.

Zertifikate in der Virtualisierung

Die Virtualisierung verlagert die Zertifikatsaktualisierung von der Hardware in die Software, erfordert jedoch oft Downtime. Damit das Update gelingt, muss die virtuelle Infrastruktur aktuell sein. Dies umfasst den Hypervisor und die Version der virtuellen Hardware jeder VM. Bei Hyper-V-Hosts unter Windows Server 2025 funktioniert das Update in Windows-VMs meist automatisch. Bei VMs mit anderen Gastbetriebssystemen aktualisieren sich die Zertifikate in der VM-Firmware nicht selbstständig. Hier müssen Sie die VM herunterfahren und in den Einstellungen die ausgewählte CA für Secure Boot ändern, speichern und anschließend wieder zurücksetzen. Dieser Vorgang wirkt auf das Gastsystem wie ein Firmwareupdate. Bei älteren Host-Versionen wird das Einspielen des 2023er KEK derzeit oft mit der Fehlermeldung "Zugriff verweigert" (Event-ID 1795) abgelehnt. Microsoft hat für März 2026 Abhilfe angekündigt.

Bei VMware enthalten neu angelegte VMs ab Hardwareversion 13 die 2023er Zertifikate, sofern die ESXi-Hosts mindestens Stand 8.0.2 aufweisen. Ältere VMs behalten die bisherige Konfiguration. Ein manuelles Löschen der nvram-Datei ist riskant, da dabei alle UEFI-Variablen verloren gehen. Da der Platform Key der UEFI-Firmware in vielen VMware-Konstellationen ungültig ist, schlägt die Aktualisierung des KEK oft fehl, was wiederum Updates der DB und DBX verhindert. Die Anleitung von Broadcom für unterstützte ESXi-Versionen erfordert Downtime und mehrere Neustarts.

Fazit – Secure-Boot-Zertifikate rechtzeitig aktualisieren

Die ursprüngliche Microsoft-PKI für Secure Boot läuft nach 15 Jahren aus. Wenn für Anfang 2027 ohnehin ein Hardware-Refresh geplant ist, können Sie das Thema vernachlässigen, da Neugeräte die 2023er Zertifikate bereits mitbringen. Für den sicheren Weiterbetrieb bestehender Systeme sollten IT-Teams Firmwareupdates unter Beachtung von BitLocker durchführen und die Windows-eigenen Updatefunktionen nutzen. Bei virtuellen Maschinen müssen Hypervisor und Hardwareversion auf den aktuellen Stand gebracht werden. Eine Sperrung der 2011er Zertifikate sollte erst erfolgen, wenn sichergestellt ist, dass alle Preboot-Komponenten bereits über neue Signaturen verfügen. (jp)

Über den Autor: Evgenij Smirnov ist Senior Solutions Architect bei Semperis und Microsoft-MVP für Cloud & Datacenter Management sowie VMware Certified Implementation Expert für Datacenter-Virtualisierung.

Viele weitere Themen rund um IT-Sicherheit finden Sie in Ausgabe 04/2026

IT-Administrator April 2026
Netzwerksicherheit

Remote Work, künstliche Intelligenz und vernetzte Industriesysteme verändern die Anforderungen an die IT-Security spürbar. Die April-Ausgabe des IT-Administrator bringt Sie beim Thema Netzwerksicherheit auf den neuesten Stand. Sie erfahren unter anderem, wie Cyberkriminelle KI für Angriffe nutzen, werfen einen Blick auf Open-Source-Intrusion-Detection und lesen, wie Sie sichere Netzwerke in Azure aufbauen.

Bestellen Sie hier das Einzelheft – gedruckt oder digital.
Für Abonnenten steht der Artikel außerdem im Heftarchiv bereit.