Microsofts ursprünglich im Jahr 2011 ausgestellte Secure-Boot-Zertifikate laufen seit Juni 2026 schrittweise ab. Betroffen können Windows-Arbeitsplätze, Notebooks, Server und virtuelle Maschinen sein, die noch mit der älteren Secure-Boot-Vertrauenskette arbeiten.

Wichtig ist dabei eine klare Unterscheidung: Secure Boot selbst läuft nicht ab. Es geht um die Zertifikate, mit denen die Firmware vertrauenswürdige Boot-Komponenten wie den Windows Boot Manager überprüft.

Unternehmen sollten deshalb nicht in Panik verfallen, das Thema aber auch nicht ignorieren. Besonders in zentral verwalteten Umgebungen ist eine strukturierte Bestandsaufnahme und kontrollierte Aktualisierung erforderlich.

Was ist Secure Boot?

Secure Boot ist eine Sicherheitsfunktion moderner UEFI-Firmware. Beim Start eines Computers prüft die Firmware, ob die geladenen Boot-Komponenten mit einem vertrauenswürdigen Zertifikat signiert sind.

Dadurch soll verhindert werden, dass sich manipulierte oder unbekannte Software bereits vor dem eigentlichen Start von Windows einnistet. Solche Angriffe werden häufig als Bootkits oder UEFI-Schadsoftware bezeichnet.

Secure Boot schützt damit eine besonders sensible Phase des Systemstarts: den Zeitraum, bevor klassische Virenscanner, Endpoint-Security-Produkte und viele Windows-Schutzmechanismen vollständig aktiv sind.

Welche Zertifikate laufen 2026 ab?

Seit der Einführung von Secure Boot bei Windows-Geräten wurden über viele Jahre dieselben Microsoft-Zertifikate aus dem Jahr 2011 verwendet.

Diese Zertifikate befinden sich unter anderem in den UEFI-Datenbanken DB und KEK:

Die DB enthält Zertifikate und Signaturen, denen die Firmware beim Start vertraut.
Die KEK enthält Schlüssel, mit denen Änderungen an den Secure-Boot-Datenbanken autorisiert werden können.

Microsoft ersetzt die ältere Vertrauenskette durch neue Zertifikate aus dem Jahr 2023. Dazu gehören unter anderem:

Windows UEFI CA 2023
Microsoft UEFI CA 2023
Microsoft Option ROM UEFI CA 2023
Microsoft Corporation KEK 2K CA 2023

Sowohl die Secure-Boot-Datenbank als auch die Key-Exchange-Key-Datenbank müssen auf den erforderlichen neuen Stand gebracht werden.

Startet Windows nach dem Ablauf weiterhin?

Geräte ohne aktualisierte Zertifikate werden nach Angaben von Microsoft nicht automatisch zum Ablaufdatum unbrauchbar. Windows kann zunächst weiterhin starten und reguläre Windows-Updates installieren.

Das eigentliche Risiko entsteht schrittweise: Ein Gerät mit veralteter Vertrauenskette kann möglicherweise zukünftige Sicherheitsupdates für frühe Boot-Komponenten nicht mehr erhalten oder überprüfen.

Betroffen sein können beispielsweise:

der Windows Boot Manager
andere Komponenten vor dem eigentlichen Windows-Start
zukünftige Sperrlisten für unsichere Bootloader
neue Schutzmaßnahmen gegen Bootkits
Secure-Boot-abhängige Firmware oder Software

Das Gerät funktioniert also möglicherweise weiter, verliert aber zunehmend die Fähigkeit, neue Schutzmaßnahmen für den Startvorgang sicher zu übernehmen.

Welche Windows-Versionen müssen betrachtet werden?

Das Thema betrifft nicht nur Windows 11. Microsoft stellt Hinweise für zahlreiche unterstützte Client- und Serverversionen bereit.

In eine Bestandsaufnahme gehören insbesondere:

Windows-10-Arbeitsplätze, einschließlich LTSC-Systemen
Windows-11-Arbeitsplätze und Notebooks
Windows Server 2012 und 2012 R2 mit ESU
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows Server 2025
Hyper-V-Gäste und andere UEFI-basierte virtuelle Maschinen
Windows 365 und Azure Virtual Desktop
Azure-VMs mit Trusted Launch oder vergleichbaren Funktionen

Auch Systeme, die nur selten eingeschaltet werden, sollten berücksichtigt werden. Dazu gehören Ersatznotebooks, Schulungsgeräte, Notfallarbeitsplätze und länger abgeschaltete Server.

Wie lässt sich prüfen, ob Secure Boot aktiviert ist?

Auf einem einzelnen Windows-System kann der Secure-Boot-Status über die Windows-Sicherheitsoberfläche oder PowerShell geprüft werden.

Prüfung über Windows-Sicherheit

Öffnen Sie:

Windows-Sicherheit → Gerätesicherheit → Sicherer Start

Seit 2026 zeigt Windows dort je nach Update- und Gerätestatus zusätzliche Informationen zu den Secure-Boot-Zertifikaten an.

Microsoft verwendet dabei grüne, gelbe und rote Statusanzeigen. Ein grünes Symbol allein bestätigt jedoch nicht zwingend, dass alle Zertifikate aktualisiert wurden. Entscheidend ist die konkrete Meldung, dass Secure Boot aktiviert und alle erforderlichen Zertifikatupdates angewendet wurden.

Prüfung über PowerShell

In einer als Administrator gestarteten PowerShell kann folgender Befehl verwendet werden:

Confirm-SecureBootUEFI

Mögliche Ergebnisse:

True: Secure Boot ist auf diesem System aktiviert.
False: Secure Boot wird unterstützt, ist aber deaktiviert.
Fehlermeldung: Das System arbeitet möglicherweise im Legacy-BIOS-Modus oder unterstützt die Abfrage nicht.

Der Befehl bestätigt zunächst nur, ob Secure Boot aktiv ist. Er allein weist noch nicht nach, dass die neue Zertifikatskette vollständig installiert wurde.

Was gilt, wenn Secure Boot deaktiviert ist?

Ist Secure Boot deaktiviert, sind die eigentlichen Schritte zur Aktualisierung der Secure-Boot-Zertifikate laut Microsoft zunächst nicht anwendbar.

Das bedeutet jedoch nicht, dass kein Handlungsbedarf besteht. Ein Gerät mit deaktiviertem Secure Boot nutzt den entsprechenden Schutz des Startvorgangs grundsätzlich nicht.

Unternehmen sollten daher prüfen, warum Secure Boot ausgeschaltet ist:

Wurde Windows im Legacy-BIOS-Modus installiert?
Gibt es alte Hardware oder Erweiterungskarten ohne UEFI-Unterstützung?
Wurde Secure Boot wegen einer früheren Kompatibilitätsstörung deaktiviert?
Handelt es sich um eine ältere virtuelle Maschine der Generation 1?
Gibt es Abhängigkeiten zu Linux, Spezialsoftware oder älteren Treibern?

Secure Boot sollte nicht ohne technische Prüfung aktiviert werden. Änderungen am Bootmodus können dazu führen, dass Windows nicht mehr startet oder BitLocker den Wiederherstellungsschlüssel verlangt.

Wie wird der Zertifikatsstatus zentral überwacht?

Für einzelne Geräte reicht die grafische Prüfung aus. In Unternehmensumgebungen müssen jedoch möglicherweise Dutzende oder Hunderte Systeme kontrolliert werden.

Microsoft stellt dafür verschiedene Statussignale bereit. Dazu gehören:

Registry-Werte zum Updatezustand
Windows-Ereignisprotokolle
PowerShell-Abfragen
Microsoft Intune Remediations
Configuration Manager
RMM- und Monitoring-Lösungen

Der Registry-Wert UEFICA2023Status sollte nach erfolgreicher Aktualisierung den erwarteten aktualisierten Zustand anzeigen.

Zusätzlich sind insbesondere folgende Ereignisse relevant:

Ereignis-ID 1801: Die erforderlichen neuen Secure-Boot-Zertifikate wurden noch nicht vollständig angewendet.
Ereignis-ID 1808: Die erforderlichen neuen Secure-Boot-Zertifikate wurden erfolgreich in der Firmware angewendet.

Die Ergebnisse sollten gemeinsam mit Hersteller, Modell, BIOS-Version, Firmwaredatum und Betriebssystem-Build dokumentiert werden.

Warum muss zuerst die Firmware geprüft werden?

Die Aktualisierung betrifft nicht nur Windows, sondern auch die UEFI-Firmware des Geräts. Ältere oder fehlerhafte Firmware kann die Übernahme der neuen Zertifikate verhindern.

Microsoft empfiehlt deshalb, vor einer breiten Verteilung verfügbare BIOS- und UEFI-Updates der Gerätehersteller zu prüfen.

Besondere Aufmerksamkeit benötigen:

ältere PC- und Notebookmodelle
Geräte mit lange nicht aktualisiertem BIOS
Systeme mit individuellen UEFI-Schlüsseln
Server mit älterer Firmware
virtuelle Maschinen mit veralteter Plattformkonfiguration
Spezialsysteme und Industrie-PCs

Der Firmwarestand sollte vor der Zertifikatsbereitstellung dokumentiert und auf einer repräsentativen Auswahl von Geräten getestet werden.

Warum ist eine Pilotgruppe notwendig?

Eine unkontrollierte Verteilung auf alle Systeme gleichzeitig ist nicht empfehlenswert. Firmware, Hardwaremodelle und Bootkonfigurationen können sich auch innerhalb eines Unternehmens deutlich unterscheiden.

Eine Pilotgruppe sollte möglichst folgende Varianten enthalten:

verschiedene Hersteller
unterschiedliche Gerätemodelle
unterschiedliche BIOS- und Firmwarestände
Windows 10 und Windows 11
Notebooks mit BitLocker
Desktop-PCs
physische Windows-Server
virtuelle Windows-Server

Erst nach erfolgreicher Prüfung sollte die Verteilung schrittweise auf weitere Gerätegruppen ausgeweitet werden.

Welche Probleme können auftreten?

Die Aktualisierung verläuft auf kompatiblen und aktuellen Systemen in der Regel kontrolliert. Bei veralteter Firmware oder fehlerhaften Bootkonfigurationen können jedoch Probleme auftreten.

Mögliche Fehlerbilder sind:

Secure-Boot-Validierungsfehler
BitLocker-Wiederherstellungsabfragen
wiederholte BitLocker-Wiederherstellungsschleifen
Verzögerungen oder Hänger beim Start
fehlgeschlagene Zertifikatsaktualisierungen
Geräte, die nicht mehr ordnungsgemäß starten

Vor Änderungen sollten deshalb BitLocker-Wiederherstellungsschlüssel zentral gesichert und die Wiederherstellungsverfahren getestet werden.

Was Unternehmen jetzt konkret tun sollten

Gerätebestand erfassen: Arbeitsplätze, Notebooks, Server und virtuelle Maschinen vollständig inventarisieren.
Secure-Boot-Status prüfen: Ermitteln, auf welchen Geräten Secure Boot aktiv, deaktiviert oder nicht verfügbar ist.
Zertifikatsstatus kontrollieren: Windows-Sicherheitsanzeige, Registry-Signale und Ereignis-IDs auswerten.
Firmware inventarisieren: Hersteller, Modell, BIOS-Version und Firmwaredatum dokumentieren.
Herstellerupdates installieren: Erforderliche BIOS- und UEFI-Aktualisierungen vor der Zertifikatsumstellung einspielen.
BitLocker-Schlüssel prüfen: Sicherstellen, dass die Wiederherstellungsschlüssel zentral verfügbar und aktuell sind.
Pilotgruppe bilden: Unterschiedliche Geräte- und Betriebssystemtypen kontrolliert testen.
Zertifikate gestaffelt verteilen: Updates nicht sofort unkontrolliert auf dem gesamten Gerätebestand aktivieren.
Neustarts einplanen: Bestimmte Schritte, insbesondere die Aktualisierung des Boot Managers, werden erst nach einem Neustart abgeschlossen.
Erfolg überwachen: Ereignisprotokolle und Registry-Werte nach jeder Bereitstellungswelle kontrollieren.
Problemgeräte separat behandeln: Geräte mit Hardware- oder Firmwareeinschränkungen nicht erzwingen, sondern mit dem Hersteller abstimmen.

Nicht einfach Registry-Werte auf allen Geräten setzen

Microsoft stellt verschiedene technische Möglichkeiten bereit, um verwaltete Geräte für die Zertifikatsaktualisierung vorzubereiten. Dazu gehören Registry-Einstellungen, PowerShell, Intune, Configuration Manager und Windows Configuration System.

Solche Einstellungen sollten jedoch nicht ohne vorherige Bestandsaufnahme und Pilotierung unternehmensweit verteilt werden.

Das bloße Setzen eines Registry-Werts löst keine Firmwareprobleme und ersetzt keine Kompatibilitätsprüfung. Bei ungeeigneten Systemen kann ein erzwungenes Vorgehen zu Startproblemen oder BitLocker-Abfragen führen.

Fazit

Die Secure-Boot-Zertifikate aus dem Jahr 2011 laufen 2026 schrittweise ab. Das bedeutet nicht, dass alle Windows-Geräte plötzlich ausfallen oder Secure Boot vollständig seine Funktion einstellt.

Systeme mit veralteter Vertrauenskette können jedoch zukünftig wichtige Schutzupdates für den frühen Startvorgang verpassen. Dadurch steigt langfristig das Risiko durch Bootkits, unsichere Bootloader und inkompatible Startkomponenten.

Unternehmen sollten daher jetzt ihren Gerätebestand inventarisieren, Firmwarestände prüfen, Pilotgruppen bilden und die neuen Secure-Boot-Zertifikate von 2023 kontrolliert verteilen.

Systemhaus Schulz unterstützt Unternehmen bei der Inventarisierung ihrer Windows-Geräte, der Prüfung von Secure Boot und BitLocker, der Aktualisierung von BIOS und Firmware sowie bei der kontrollierten Bereitstellung und Überwachung der neuen Secure-Boot-Zertifikate.

PowerShell-Prüfskript auf GitHub

Für die technische Überprüfung von Windows-Arbeitsplätzen und Windows-Servern stellt Systemhaus Schulz ein PowerShell-Skript in einem öffentlichen GitHub-Repository bereit.

Das Skript arbeitet in der Standardausführung ausschließlich lesend. Es erfasst unter anderem den UEFI- und Secure-Boot-Status, die installierte BIOS-Version, den Status der neuen Secure-Boot-Zertifikate, relevante Ereignisprotokolle sowie den BitLocker- und Neustartstatus.

Die Ergebnisse werden zusätzlich als JSON- und CSV-Bericht gespeichert. Dadurch eignet sich das Skript auch für die Auswertung über RMM-Systeme, zentrale Softwareverteilung oder andere Verwaltungswerkzeuge.

Secure-Boot-2023-Certificate-Checker auf GitHub öffnen

Repository herunterladen

Das vollständige Repository kann über Git heruntergeladen werden:

git clone https://github.com/Systemhaus-Schulz/Secure-Boot-2023-Certificate-Checker.git

Prüfung ohne Systemänderungen

PowerShell als Administrator öffnen, in das heruntergeladene Verzeichnis wechseln und das Skript starten:

Set-ExecutionPolicy -Scope Process Bypass

.\Systemhaus-Schulz-SecureBoot-2023-Check.ps1

In diesem Modus nimmt das Skript keine Veränderungen am System vor. Es erstellt lediglich einen Prüfbericht und bewertet den aktuellen Secure-Boot-Status.

Optionale Bereitstellung starten

Nach erfolgreicher Firmwareprüfung und Sicherung des BitLocker-Wiederherstellungsschlüssels kann der von Microsoft vorgesehene Aktualisierungsprozess optional angestoßen werden:

.\Systemhaus-Schulz-SecureBoot-2023-Check.ps1 `
    -StartDeployment `
    -ConfirmRecoveryKeyBackedUp

Die Bereitstellung sollte zuerst auf einer repräsentativen Pilotgruppe getestet werden. Das Skript löst keinen automatischen Neustart aus und ersetzt keine Prüfung der BIOS- beziehungsweise UEFI-Firmware durch den Gerätehersteller.

Secure-Boot-Zertifikate laufen 2026 ab: Was Unternehmen jetzt prüfen müssen