Warum dieser Generationstausch mehr als ein Update ist und was Ihre Organisation jetzt tun sollte.

Im Laufe des Jahres 2026 erreicht eine zentrale Sicherheitskomponente nahezu jeder Windows-Umgebung einen geplanten Wendepunkt: Die Microsoft Secure-Boot-Zertifikate der Generation 2011 laufen ab. Im Juni 2026 betrifft das die Microsoft Corporation KEK CA 2011 und die Microsoft Corporation UEFI CA 2011 — beides UEFI CAs, die unterschiedliche Rollen in der Vertrauenskette übernehmen. Im Oktober 2026 folgt die Microsoft Windows Production PCA 2011 — jenes Zertifikat, das seit über einem Jahrzehnt jeden Windows-Bootvorgang absichert.

Auf den ersten Blick klingt das nach einem klassischen Lifecycle-Ereignis. Zertifikate ablaufen lassen, neue einspielen, weiter geht es. Doch diese Einordnung greift zu kurz. Denn Secure Boot ist kein isoliertes Sicherheitselement. Es bildet die Vertrauenskette zwischen Firmware, Bootloader und Betriebssystem — das Fundament, auf dem die gesamte Plattformsicherheit aufbaut. Und wenn sich dieses Fundament verändert, reicht Wartung nicht. Dann steht Architekturarbeit an.

Dieser Artikel ordnet ein, was geschieht, warum es IT-Verantwortliche betrifft und welche Schritte jetzt sinnvoll sind — ohne Alarmismus, aber mit der gebotenen Klarheit.

Was genau passiert 2026 — und warum jetzt?

Die konkreten Ablaufdaten

Microsoft hat die Timeline klar kommuniziert. Drei Zertifikate der Generation 2011 erreichen ihr Ende:

Ablaufdatum	Auslaufendes Zertifikat	Neues Zertifikat	UEFI-Variable
Juni 2026	Microsoft Corporation KEK CA 2011	Microsoft Corporation KEK 2K CA 2023	KEK
Juni 2026	Microsoft Corporation UEFI CA 2011	UEFI CA 2023 / Option ROM UEFI CA 2023	DB
Oktober 2026	Microsoft Windows Production PCA 2011	Windows UEFI CA 2023	DB

An diesen Daten endet nicht der Betrieb der Systeme. Bestehende Geräte booten weiterhin — auch mit abgelaufenen Zertifikaten. Doch ab Juni 2026 können keine neuen Secure-Boot-Sicherheitsupdates mehr verteilt werden. Ab Oktober 2026 sind keine Boot-Manager-Fixes mehr möglich. Systeme fallen in einen degradierten Sicherheitszustand — funktional intakt, aber nicht mehr härtbar.

Der eigentliche Treiber: BlackLotus und die Sicherheitsrealität

Der Secure Boot Zertifikatstausch 2026 kommt nicht allein durch den natürlichen Lifecycle. Er ist auch eine direkte Konsequenz aus CVE-2023-24932 — besser bekannt unter dem Namen BlackLotus. Dieses UEFI-Bootkit war 2023 das erste öffentlich dokumentierte Angriffswerkzeug, das Secure Boot auf vollständig gepatchten Windows-11-Systemen umgehen konnte — und wurde im Darknet für rund 5.000 USD gehandelt (ESET Research, März 2023). Es deaktiviert BitLocker, umgeht Windows Defender und überlebt sogar eine Neuinstallation des Betriebssystems, weil es sich in der EFI-Systempartition einnistet.

Microsoft hat darauf mit dem Sicherheitsupdate KB5025885 reagiert — einem dreiphasigen Prozess, dessen dritte Phase die irreversible Sperrung alter Boot-Manager-Versionen vorsieht. Der Generationstausch ist damit nicht nur ein Ablaufereignis, sondern Teil einer umfassenden Sicherheitsmaßnahme. Die Bedrohungslage macht den Generationstausch nicht nur planbar, sondern dringlich.

Microsofts 5-Step Playbook: Was es leistet — und was nicht

Microsoft hat im November 2025 ein strukturiertes Playbook veröffentlicht, das Organisationen durch die Umstellung führen soll. Die fünf Schritte: Inventarisierung und Vorbereitung, Monitoring des Gerätestatus, OEM-Firmware-Updates, Deployment der neuen Zertifikate und Troubleshooting.

Dieses Playbook ist ein hilfreicher Ausgangspunkt. Es deckt den Windows-seitigen Deployment-Prozess ab und benennt die wichtigsten Registry Keys und Event-IDs. Was es jedoch nicht leistet: eine ganzheitliche Betrachtung der Abhängigkeiten zwischen Firmware, Recovery, Deployment-Infrastruktur und Monitoring. Es beschreibt den Weg für einzelne Geräte — aber nicht das koordinierte Programm, das heterogene Unternehmensumgebungen benötigen.

Warum das kein normaler Zertifikatstausch ist — die sechs Schichten des Generationstausches

Viele Organisationen behandeln den Secure-Boot-Wechsel gedanklich wie einen Zertifikatstausch im klassischen PKI-Sinn: altes Zertifikat raus, neues rein. In der Realität betrifft dieser Generationstausch jedoch mindestens sechs technische Schichten, die alle aufeinander abgestimmt sein müssen.

Schicht 1: Firmware (UEFI/BIOS)

Die Firmware bildet die unterste Ebene der Vertrauenskette. Sie enthält den Platform Key (PK) und definiert, welche Zertifikate das System überhaupt akzeptiert. Technisch betrachtet kann die neue Zertifikatsgeneration auch ohne Firmware-Update ausgerollt werden. In der Praxis zeigt sich jedoch: Je älter die Firmwarebasis, desto höher das Risiko für unerwartete Effekte — bei Kompatibilität, Update-Reihenfolgen oder Bootverhalten. Firmware ist damit nicht automatisch ein Blocker, aber ein entscheidender Stabilitätsfaktor.

Besonders kritisch: Laut einer Studie von Eclypsium weisen 77 Prozent der Enterprise-Geräte veraltete Firmware auf — ein Risikofaktor, der durch den Generationstausch akut wird. OEMs liefern für Hardware älter als sieben bis acht Jahre in der Regel keine Firmware-Updates mehr. Der Anteil solcher Geräte in deutschen Mittelstandsunternehmen wird auf 20 bis 35 Prozent geschätzt.

Schicht 2: Zertifikatsstores (DB, DBX, KEK)

Die UEFI-Variablen DB (erlaubte Signaturen), DBX (gesperrte Signaturen) und KEK (Autorisierungsschlüssel für Änderungen) bilden den Kern der Secure-Boot-Konfiguration. Der Generationstausch erfordert, dass alle drei Speicher in der richtigen Reihenfolge aktualisiert werden:

1. Zuerst der KEK — als Voraussetzung für alle weiteren Änderungen.
2. Dann die DB — um die neuen Zertifikate aufzunehmen (die alten bleiben zunächst bestehen).
3. Schließlich die DBX — um kompromittierte Boot-Manager-Versionen zu sperren.

Dieser letzte Schritt ist irreversibel. Wird er ohne vollständige Vorbereitung ausgeführt, können Systeme nicht mehr von älteren, nun gesperrten Bootloadern starten. Die DBX wächst zudem mit jedem Sicherheitsupdate, was bei älteren Systemen mit begrenztem NVRAM-Speicher ein strukturelles Problem erzeugt.

Schicht 3: Bootmanager und Rollback-Schutz

Die neuen Zertifikate erfordern neu signierte Boot-Manager-Versionen. Gleichzeitig führt Microsoft eine Security Version Number (SVN) ein, die ein Zurückrollen auf ältere, potentiell unsichere Bootmanager verhindert. Dieser Rollback-Schutz ist sicherheitstechnisch sinnvoll — erzeugt aber eine harte Abhängigkeit: Systeme müssen vor der Aktivierung vollständig vorbereitet sein, denn ein Zurück gibt es nicht.

Schicht 4: Windows Recovery Environment (WinRE)

Ein häufig unterschätzter Bereich: Die Windows-Wiederherstellungsumgebung verfügt über einen eigenen Bootpfad mit eigenen Abhängigkeiten. Wird WinRE nicht vor den DBX-Änderungen aktualisiert, kann die Wiederherstellungsumgebung nach der Sperrung alter Zertifikate nicht mehr starten. Genau dann, wenn man sie am dringendsten braucht, funktioniert sie nicht. Microsoft adressiert dieses Problem über sogenannte SafeOS Dynamic Updates (z.B. KB5079471 für Windows 11 24H2). Wichtig: Diese Updates können nicht über Windows Update, WUfB oder WSUS installiert werden — die Installation erfolgt manuell per DISM und muss aktiv eingeplant werden.

Schicht 5: Deployment-Infrastruktur

Installationsmedien, PXE-Boot-Umgebungen, Imaging-Prozesse, SCCM-Task-Sequences, WDS-Server — all diese Systeme verteilen und starten Betriebssystem-Installationen. Wenn diese Infrastruktur noch auf alte Boot-Signaturen setzt, während die Zielgeräte bereits die alten Zertifikate sperren, entstehen Inkompatibilitäten. Deployment-Prozesse müssen daher parallel zur Geräteumstellung aktualisiert werden. Aktuelle native Microsoft-Installationsimages (WinPE, Installationsmedien) unterstützen bereits die neuen Signaturen. Nur ältere oder selbst erstellte Image-Versionen erfordern eine manuelle Aktualisierung.

Schicht 6: Monitoring und Validierung

Nach der Umstellung muss der neue Zustand verifiziert werden — nicht nur auf Einzelgeräten, sondern über die gesamte Flotte. Microsoft stellt hierzu Event-IDs bereit (1808 für erfolgreiche Deployments, 1801 für Fehler) sowie den Registry Key UEFICA2023Status. Hinweis: Diese Event-IDs und Registry Keys werden nicht in allen Fällen geschrieben — insbesondere bei Updates, die nicht über den dokumentierten Weg verteilt wurden. Eine direkte Prüfung der veröffentlichten Zertifikate in DB/DBX ist daher immer anzuraten. Ohne systematisches Monitoring bleibt unklar, ob die Umstellung tatsächlich konsistent abgeschlossen ist — oder ob einzelne Systeme in einem Mischzustand verbleiben.

Warum alle sechs Schichten zusammengehören

Der gefährlichste Zustand bei diesem Generationstausch ist nicht „gar nicht angefangen“. Es ist „halb fertig“. Wenn einzelne Schichten aktualisiert werden, andere aber nicht, entstehen inkonsistente Zustände: Systeme, die booten, aber nicht wiederhergestellt werden können. Deployment-Prozesse, die neue Geräte mit alten Bootloadern bestücken. Monitoring, das grün zeigt, obwohl die Recovery-Umgebung veraltet ist.

Deshalb ist dieser Generationstausch keine Aufgabe für ein einzelnes Windows-Update, sondern ein koordiniertes Programm über alle sechs Schichten hinweg.

Wer ist betroffen — und wo überall?

Die kurze Antwort: Nahezu jede Organisation mit Windows-Systemen. Die ausführlichere Antwort erfordert einen breiteren Blick, als viele erwarten.

Clients und Arbeitsplatzgeräte

Jedes Windows-10- und Windows-11-System mit UEFI-Firmware — und das sind praktisch alle Geräte seit 2012 — ist vom Generationstausch betroffen. Weltweit sind das laut Microsoft (Januar 2026) rund 1,4 Milliarden aktive Windows-Geräte — davon haben rund 85 Prozent der neuen PCs Secure Boot bereits aktiviert. In Deutschland allein laufen noch rund 32 Millionen Windows-10-Geräte (ComputerBase), deren Zukunft durch das parallele Support-Ende im Oktober 2025 zusätzlich unter Druck steht. Selbst Systeme, auf denen Secure Boot derzeit deaktiviert ist, sind relevant: Künftige Updates oder Compliance-Anforderungen können Secure Boot voraussetzen.

Eine Ausnahme bilden die Copilot+ PCs der 2025er-Generation — diese werden bereits mit den neuen Zertifikaten ausgeliefert.

Server

Windows Server sind ebenso betroffen — weltweit geschätzt 12 bis 15 Millionen Systeme. Microsoft hat im Herbst 2025 ein eigenes Server-Playbook veröffentlicht, das die spezifischen Anforderungen für Server-Umgebungen adressiert. Server erfordern besondere Aufmerksamkeit, weil Firmware-Updates in Produktionsumgebungen sorgfältig geplant werden müssen, Ausfallzeiten oft enger begrenzt sind und die Abhängigkeiten zu Virtualisierung, Storage und Netzwerkdiensten eine zusätzliche Komplexitätsebene erzeugen. Windows Server 2025 wird bereits mit den neuen Zertifikaten als Standard ausgeliefert — ältere Server-Versionen müssen jedoch aktiv umgestellt werden.

Virtuelle Maschinen

Auch virtuelle Maschinen mit UEFI-basiertem Secure Boot sind betroffen. Hyper-V, VMware vSphere und andere Hypervisoren bieten Secure Boot für VMs — und diese VMs beziehen ihre Zertifikate ebenfalls aus den UEFI-Variablen. Die Umstellung muss daher auch in virtualisierten Umgebungen geplant werden.

Deployment- und Recovery-Infrastruktur

Wie in den sechs Schichten beschrieben: WDS-Server, SCCM-Task-Sequences, PXE-Boot-Umgebungen und Installationsmedien müssen aktualisiert werden. Wer hier nicht mitdenkt, verteilt nach der Umstellung weiterhin alte Signaturen auf neue Systeme — und erzeugt systematisch Mischzustände.

Dual-Boot-Systeme

Organisationen, die Linux und Windows parallel auf einem Gerät betreiben, stehen vor einer zusätzlichen Herausforderung. Linux nutzt einen sogenannten „Shim“ als Secure-Boot-Zwischenschicht. Ältere Shim-Versionen sind in der DBX bereits revoziert. Ohne aktualisierte Shim-Versionen von Ubuntu, Fedora, SUSE oder anderen Distributionen bootet das Linux-System nach der DBX-Aktivierung nicht mehr.

Die richtige Frage stellen

Die entscheidende Frage lautet daher weniger: „Sind wir betroffen?“ — denn die Antwort ist mit hoher Wahrscheinlichkeit ja. Die bessere Frage ist: „An welchen Stellen unserer Umgebung wirkt Secure Boot überall mit?“ Diese Perspektive verschiebt den Fokus — weg vom einzelnen Gerät hin zur Betriebsarchitektur.

Was passiert, wenn Organisationen nicht rechtzeitig handeln?

Der Generationstausch erzeugt selten unmittelbare Störungen. Systeme funktionieren weiterhin. Updates laufen. Der Betrieb bleibt stabil. Gerade diese Unsichtbarkeit führt dazu, dass das Thema leicht nach hinten priorisiert wird. Doch die Risiken bei Nicht-Handeln sind konkret und messbar.

Risiko 1: Boot-Fehler nach automatischem Windows Update

Microsoft verteilt aktuell nur DB-Updates (Veröffentlichung neuer Zertifikate) automatisch über Windows Update. Die DBX-Updates (Sperrung alter Zertifikate) werden noch dem Administrator überlassen. Der automatische Rollout der DB-Updates über Confidence Buckets ist dokumentiert und setzt die beschriebenen EventIDs und Registry-Informationen. Darüber hinaus hat Microsoft auf bestimmten Gerätetypen parallel einen nicht dokumentierten Rollout durchgeführt, bei dem diese Informationen nicht gesetzt wurden.

Wenn die lokale Konfiguration eines Geräts nicht vorbereitet ist — etwa weil WinRE veraltet ist oder die neuen Zertifikate nicht in der DB liegen — kann das System nach einem DBX-Update nicht mehr starten. In Unternehmensumgebungen bedeutet das: massiver Supportaufwand, physischer Zugriff auf jedes betroffene Gerät, stundenlange Wiederherstellung pro System.

Community-Berichte zeigen, dass besonders ältere HP ProBook/EliteBook- und Dell OptiPlex-Modelle von solchen Problemen betroffen waren.

Risiko 2: Offene Sicherheitslücken

Systeme, die den Generationstausch nicht vollständig durchlaufen, können ab Juni 2026 keine neuen Secure-Boot-Sicherheitsupdates mehr erhalten. Sie bleiben anfällig für BlackLotus und künftige Varianten von UEFI-Bootkits. Bereits heute weisen laut einer Ponemon/Adaptiva-Studie (2023) 48 Prozent aller Endpoints Sicherheitsrisiken auf — eine Zahl, die ohne den Generationstausch weiter steigen wird. Dabei handelt es sich nicht um theoretische Bedrohungen — BlackLotus wurde als funktionsfähiges Angriffswerkzeug dokumentiert und ist in der Lage, BitLocker zu deaktivieren, Sicherheitstools zu umgehen und sich persistent in der EFI-Systempartition einzunisten.

Risiko 3: Mischzustände — der gefährlichste Betriebszustand

Organisationen, die nur Teile der Umstellung durchführen — etwa neue Zertifikate verteilen, aber WinRE nicht aktualisieren — erzeugen inkonsistente Zustände. Diese sind besonders tückisch, weil sie im Normalbetrieb unsichtbar bleiben. Erst im Fehlerfall, wenn die Recovery-Umgebung benötigt wird oder ein neues Deployment ausgerollt werden soll, zeigen sich die Inkompatibilitäten. Zu einem Zeitpunkt also, an dem Zeitdruck herrscht.

Der gefährlichste Secure-Boot-Zustand ist nicht „gar nicht angefangen“ — er ist „halb fertig“.

Risiko 4: Compliance-Verstöße mit konkreten Konsequenzen

Die regulatorische Landschaft hat sich in den letzten Jahren erheblich verschärft:

• Die NIS2-Richtlinie, die seit Oktober 2024 in nationales Recht umgesetzt wird, fordert angemessene Sicherheitsmaßnahmen für Unternehmen in betroffenen Sektoren — mit Bußgeldrisiken von bis zu 10 Millionen Euro. UEFI-Sicherheit wird dabei explizit als Teil der empfohlenen Maßnahmen genannt.
• Der BSI-Grundschutz (Baustein SYS.2.1) schreibt die Secure-Boot-Konfiguration für Clients vor. Neue Bausteine betonen die Firmware-Sicherheit stärker als in früheren Ausgaben.
• Der EU Cyber Resilience Act, der schrittweise bis 2027 in Kraft tritt, erhöht die Anforderungen an die Sicherheit von IT-Equipment zusätzlich.

In der Praxis zeigt sich das bereits: Auditoren beginnen, die UEFI-Sicherheitskonfiguration aktiv zu prüfen. Cyber-Versicherungen fragen zunehmend nach dem Sicherheitsstatus auf Firmware-Ebene. Ein nicht dokumentierter Secure-Boot-Status ist damit nicht nur ein technisches Risiko, sondern ein dokumentiertes Compliance-Defizit — mit potenziellen Folgen bei Audits, Versicherungsansprüchen und Haftungsfragen.

Risiko 5: Hardware am Ende des Lebenszyklus

Geräte, für die der OEM keine Firmware-Updates mehr bereitstellt, können die neuen Zertifikate möglicherweise nicht vollständig aufnehmen. In deutschen KMU betrifft das geschätzt 20 bis 35 Prozent der Systeme. Diese Geräte müssen identifiziert und in die Hardware-Lifecycle-Planung aufgenommen werden — bevor der automatische Rollout beginnt und unkontrollierte Zustände entstehen.

Die Kosten des Nicht-Handelns — in Zahlen

Diese Risiken lassen sich auch ökonomisch beziffern. Laut Gartner (2024) verursachen ungeplante Ausfälle in Enterprise-Umgebungen Kosten von 500.000 bis 1 Million USD pro Stunde. Für KMU in Deutschland liegen die Schätzungen bei 8.000 bis 15.000 EUR pro Stunde Betriebsunterbrechung.

Die gesamtwirtschaftliche Dimension unterstreicht der Bitkom-Wirtschaftsschutzbericht 2025: Der Schaden durch Cyberangriffe belief sich in Deutschland auf 289,2 Milliarden EUR — 87 Prozent der deutschen Unternehmen waren betroffen. Entsprechend hat sich der Anteil von IT-Security am Gesamtbudget von 9 Prozent (2022) auf 17 Prozent (2024) nahezu verdoppelt (Bitkom).

Ein Secure-Boot-Incident — etwa ein flächendeckender Boot-Fehler nach einem ungeplanten DBX-Update oder ein erfolgreicher Bootkit-Angriff — kann diese Kosten innerhalb weniger Stunden realisieren. Die Investition in einen kontrollierten Generationstausch steht in keinem Verhältnis zu den potenziellen Ausfallkosten.

Deployment-Wege — manuell und automatisch

Der Rollout der neuen Secure-Boot-Zertifikate kann über verschiedene Wege erfolgen. Wichtig: Keiner dieser Wege beinhaltet das Sperren der alten Zertifikate (DBX-Update) oder Infrastruktur-Arbeiten wie WinRE-Aktualisierung oder Deployment-Anpassungen. Diese Schritte müssen separat geplant werden.

Manuelle Deployment-Wege

Microsoft bietet vier manuelle Deployment-Optionen für die Veröffentlichung neuer Zertifikate in der DB:

• Registry Key: Setzen des DWORD-Werts `AvailableUpdates` auf `0x5944` unter `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot`.
• Group Policy: Über Computer Configuration > Administrative Templates > Windows Components > Secure Boot. Hinweis: Hierüber ist kein Sperren alter Zertifikate möglich.
• Windows Configuration System (WinCS): Für domain-joined Windows 11 (ab 23H2). Hinweis: Kein Boot-Manager-Update möglich.
• Microsoft Intune: Über den inzwischen verfügbaren Configuration Service Provider (CSP) mit drei Settings-Catalog-Policies für Intune-verwaltete Geräte.

Automatische Deployment-Wege

Zusätzlich zu den manuellen Optionen gibt es automatische Verteilungswege:

• Kumulative Updates mit Confidence Bucket: Microsoft verteilt DB-Updates gestaffelt über Confidence Buckets. Dieser Weg ist dokumentiert und setzt die beschriebenen EventIDs und Registry-Keys.
• Controlled Feature Rollout (CFR): Microsoft kann Features über CFR gezielt aktivieren.
• Undokumentierter Weg: Microsoft hat auf bestimmten Gerätetypen Zertifikate in der DB durch kumulative Updates auch ohne Confidence Bucket verteilt — ohne die üblichen EventIDs und Registry-Informationen zu setzen.
• OEM-Firmware-Updates: Einige OEMs nehmen die neuen Zertifikate in ihre UEFI/BIOS-Updates auf. Dieser Weg ist noch nicht umfassend geprüft.

Wichtige Grundsätze

Deployment-Methoden sollten nicht auf demselben Gerät gemischt werden. Alle genannten Optionen verteilen Zertifikate — aber keine von ihnen prüft die Konsistenz über alle sechs Schichten. Die Zertifikatsverteilung ist ein notwendiger Schritt, aber kein ausreichender. Firmware-Status, WinRE, Deployment-Infrastruktur und Monitoring müssen parallel adressiert werden.

Die einzelnen Update-Schritte (DB-Update, DBX-Update) erfordern jeweils nur wenige Momente und einen Neustart. Der zeitaufwändigste Schritt ist typischerweise das Firmware-Update. Die Schritte müssen nicht unmittelbar nacheinander ausgeführt werden.

Das Sperren der UEFI CA 2011 ist alternativ über das OEM-UEFI-Setup (BIOS-Konfiguration) möglich.

Was IT-Verantwortliche jetzt tun sollten — Handlungsempfehlungen für eine kontrollierte Umstellung

Der Generationstausch ist planbar. Wer frühzeitig beginnt, schafft sich Handlungsspielraum und vermeidet den gefährlichen Zustand des Reagierens unter Zeitdruck. Die folgenden Schritte bilden einen pragmatischen, strukturierten Einstieg.

1. Transparenz schaffen: Statusbild erheben

Bevor Maßnahmen ergriffen werden, braucht es ein belastbares Bild des Ist-Zustands. Das bedeutet:

• Welche Secure-Boot-Zertifikate sind auf welchen Geräten aktiv?
• Welche Firmware-Versionen sind im Einsatz — und welche erhalten noch OEM-Support?
• Wie ist der Status von DB, DBX und KEK auf den einzelnen Systemen?
• Ist WinRE aktuell? Funktioniert die Recovery-Umgebung mit den neuen Zertifikaten?
• Welche Deployment-Prozesse berühren die Startkette?

Microsoft stellt hierzu den Registry Key `UEFICA2023Status` sowie die Event-IDs 1808 und 1801 bereit. Für eine systematische Erhebung über alle sechs Schichten reicht das jedoch selten — insbesondere in heterogenen Umgebungen mit unterschiedlichen Hardware-Generationen und Deployment-Pfaden.

2. Firmware-Basis bewerten

Eine Übersicht über die Firmware-Versionen aller Geräte ist ein früh notwendiger Schritt. Systeme, für die der OEM keine Updates mehr bereitstellt, sollten identifiziert und gesondert eingeplant werden. Dies betrifft häufig Geräte älter als sieben bis acht Jahre — ein relevanter Anteil in vielen Mittelstandsumgebungen.

Wichtig: Microsofts eigenes Playbook empfiehlt, OEM-Firmware-Updates vor den Windows-Zertifikats-Deployments einzuspielen. Die Reihenfolge ist entscheidend.

3. Pilotgruppe definieren und testen

Eine kontrollierte Umstellung beginnt mit einer Pilotgruppe. Ausgewählte Geräte — repräsentativ für die verschiedenen Hardware-Generationen und Konfigurationen der Organisation — werden zuerst umgestellt. Dabei werden alle sechs Schichten einbezogen: Firmware, Zertifikatsstores, Bootmanager, WinRE, Deployment und Monitoring.

Ergebnisse aus der Pilotgruppe liefern die Grundlage für die breite Ausrollung und decken frühzeitig Inkompatibilitäten oder Sonderfälle auf.

4. Deployment- und Recovery-Infrastruktur aktualisieren

Parallel zur Geräteumstellung müssen ältere oder selbst erstellte Installationsmedien, PXE-Boot-Umgebungen und Imaging-Prozesse auf die neuen Signaturen umgestellt werden (aktuelle native Microsoft-Images unterstützen die neuen Signaturen bereits). Ebenso ist sicherzustellen, dass WinRE auf allen Systemen den aktuellen Stand hat — über SafeOS Dynamic Updates per DISM. Dieser Schritt wird häufig übersehen — und rächt sich spätestens bei der nächsten Neuinstallation oder Wiederherstellung.

5. Monitoring etablieren und Abschluss dokumentieren

Nach der Umstellung muss der erreichte Zustand validiert und dokumentiert werden. Die Event-IDs 1808/1801 sowie der `UEFICA2023Status`-Registry-Key bieten Ansatzpunkte für ein systematisches Monitoring. Da diese Indikatoren jedoch nicht in allen Fällen gesetzt werden, sollte ergänzend immer eine direkte Prüfung der in DB/DBX veröffentlichten Zertifikate erfolgen. Für Organisationen mit NIS2- oder BSI-Grundschutz-Anforderungen ist die Dokumentation des Prozesses und des erreichten Zustands zudem ein Compliance-Nachweis.

6. Zeitfaktor realistisch einplanen

Die einzelnen Update-Schritte (DB-Update, DBX-Update) erfordern jeweils nur wenige Momente und einen Neustart. Der zeitaufwändigste Schritt ist typischerweise das Firmware-Update. Die Schritte müssen nicht unmittelbar nacheinander ausgeführt werden. Bei einer Gerätebasis von mehreren hundert oder tausend Systemen addiert sich der Gesamtaufwand — besonders wenn OEM-Firmware-Updates, WinRE-Aktualisierungen per DISM und Deployment-Anpassungen hinzukommen. Für Unternehmen mit 250 bis 2.500 Geräten sollte ein bis vier Personenmonate Projektaufwand eingeplant werden — zuzüglich Projektmanagement und Koordination.

Wer erst unter Zeitdruck reagiert, riskiert genau die Mischzustände, die es zu vermeiden gilt. Ein strukturierter Ansatz mit ausreichend Vorlauf ist der wirksamste Schutz vor operativen Überraschungen.

Warum frühzeitiges Handeln den Unterschied macht

Der Generationstausch bei Secure Boot ist kein Ereignis, das an einem Stichtag eintritt und dann vorbei ist. Es ist ein Prozess, der sich über mehrere Monate erstreckt und dessen Komplexität mit jedem ungeplanten automatischen Update zunimmt. Microsoft verteilt DB-Updates (neue Zertifikate) bereits über den dokumentierten Confidence-Bucket-Mechanismus automatisch. Darüber hinaus hat Microsoft auf bestimmten Gerätetypen einen nicht dokumentierten parallelen Rollout durchgeführt. Die Forcierung der DBX-Updates (Sperrung alter Zertifikate) steht aktuell noch aus — doch die Richtung ist klar.

Organisationen, die frühzeitig handeln, haben drei entscheidende Vorteile:

1. Kontrolle: Sie bestimmen die Reihenfolge, das Tempo und den Umfang der Umstellung — statt auf automatische Updates zu reagieren.
2. Konsistenz: Sie können alle sechs Schichten koordiniert umstellen und vermeiden Mischzustände, die im Nachhinein aufwendig zu diagnostizieren und zu beheben sind.
3. Planbarkeit: Sie können Hardware-Ersatzbedarf früh erkennen, Budgets rechtzeitig einplanen und den Prozess für Auditoren dokumentieren.

Wer dagegen abwartet, riskiert, dass automatische Updates den Prozess überholen — mit potenziell inkonsistenten Ergebnissen und hohem reaktivem Aufwand.

Häufig gestellte Fragen zum Secure Boot Zertifikatstausch 2026

Booten meine Systeme nach dem Zertifikatsablauf noch?

Ja. Bestehende Systeme starten weiterhin, auch wenn die alten Zertifikate abgelaufen sind. Allerdings können ab Juni 2026 keine neuen Secure-Boot-Sicherheitsupdates mehr verteilt werden. Die Systeme funktionieren, verlieren aber die Fähigkeit zur Härtung — ein degradierter Sicherheitszustand, der mit der Zeit zunehmend riskant wird.

Reicht ein Windows Update, um die Umstellung abzuschließen?

Windows Update kann die neuen Zertifikate in die UEFI-Variablen einspielen. Es prüft jedoch nicht die Konsistenz über alle sechs Schichten hinweg. Firmware-Status, WinRE, Deployment-Infrastruktur und Monitoring-Abdeckung müssen separat sichergestellt werden. Wer sich ausschließlich auf Windows Update verlässt, riskiert Mischzustände.

Was ist, wenn wir Secure Boot deaktiviert haben?

Auch Systeme mit deaktiviertem Secure Boot sind relevant. Künftige Windows-Updates, Compliance-Anforderungen oder Sicherheitsrichtlinien können Secure Boot voraussetzen. Die UEFI-Variablen (DB, DBX, KEK) existieren auf dem System unabhängig davon, ob Secure Boot aktiv ist.

Wie lange dauert die Umstellung pro Gerät?

Die einzelnen Update-Schritte (DB-Update, DBX-Update) erfordern jeweils nur wenige Momente und einen Neustart. Der zeitaufwändigste Schritt ist typischerweise das Firmware-Update. Die Schritte müssen nicht unmittelbar nacheinander ausgeführt werden. Hinzu kommen die Firmware-Bewertung, WinRE-Aktualisierung per DISM und Validierung. Für eine Unternehmensumgebung mit 250 bis 2.500 Geräten sollte man ein bis vier Personenmonate Projektaufwand einplanen — plus Projektmanagement und Koordination.

Ist die DBX-Revokation wirklich irreversibel?

Ja. Sobald alte Boot-Manager-Versionen in der DBX gesperrt sind, kann dieser Schritt nicht rückgängig gemacht werden. Systeme, die danach noch auf alte Bootloader angewiesen sind, starten nicht mehr über Secure Boot. Deshalb ist die vollständige Vorbereitung aller Schichten vor der DBX-Aktivierung so entscheidend.

Muss ich die abgelaufenen Zertifikate sperren?

Ja — die Sperrung der alten Zertifikate über die DBX ist ein notwendiger Schritt, um bekannte Schwachstellen (wie BlackLotus/CVE-2023-24932) zu schließen. Ohne DBX-Update bleiben kompromittierte Bootloader weiterhin startfähig. Hinweis: Das Sperren der UEFI CA 2011 ist alternativ auch über das OEM-UEFI-Setup (BIOS-Konfiguration) möglich.

Warum finde ich in meiner Signatur-Datenbank nicht alle Zertifikate?

Einige Zertifikate sind an Abhängigkeiten gekoppelt. Die Microsoft UEFI CA 2023 wird in der Signatur-Datenbank (DB) erst angezeigt, wenn im UEFI-Setup die Einstellung zum Erlauben von Microsoft 3rd-Party UEFI CAs aktiviert ist. Dies kann zu Verwirrung führen, wenn nach der Umstellung scheinbar Zertifikate fehlen.

NIS2 und Compliance: Warum der Generationstausch keine Option ist

Die regulatorischen Rahmenbedingungen haben sich seit Ende 2025 grundlegend verändert. Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Deutschland in Kraft. Über 30.000 Unternehmen sind betroffen — und die Frist zur BSI-Registrierungspflicht läuft am 6. März 2026 ab.

Bußgelder und Haftung

Die Sanktionsrahmen sind erheblich:

Kategorie	Bußgeldrahmen
Essential Entities (wesentliche Einrichtungen)	bis 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes
Important Entities (wichtige Einrichtungen)	bis 7 Mio. EUR oder 1,4 % des weltweiten Jahresumsatzes

Hinzu kommt die persönliche Haftung der Geschäftsleitung für die Umsetzung angemessener Sicherheitsmaßnahmen.

Firmware-Integrität als explizite NIS2-Anforderung

NIS2 fordert in Artikel 21 unter anderem Maßnahmen zur Sicherheit der Lieferkette und zur Sicherung der Netz- und Informationssysteme einschließlich Hardware und Firmware. Secure Boot ist damit kein optionales Sicherheitsfeature, sondern ein dokumentationspflichtiger Bestandteil der Compliance.

Das BSI hat diese Einordnung durch eigene Analysen untermauert: Im Rahmen des SiSyPHuS-Projekts (Studie zu Systemintegrität und Plattformhärtung unter Sicherheitsaspekten) hat das BSI detaillierte UEFI-Secure-Boot-Analysen veröffentlicht, die als Referenz für die Bewertung der eigenen Secure-Boot-Konfiguration dienen.

Ergänzend haben NSA und CISA im Dezember 2025 gemeinsame Enterprise-Guidance zu UEFI Secure Boot herausgegeben — ein weiteres Signal, dass Firmware-Sicherheit inzwischen als nationale Sicherheitsfrage eingestuft wird.

Was das für den Generationstausch bedeutet

Organisationen, die den Secure-Boot-Generationstausch nicht dokumentiert und kontrolliert durchführen, riskieren nicht nur technische Schwachstellen, sondern ein nachweisbares Compliance-Defizit. Bei einer NIS2-Prüfung oder einem Audit nach BSI-Grundschutz wird der Secure-Boot-Status abgefragt werden. Wer hier keinen konsistenten, dokumentierten Zielzustand nachweisen kann, hat ein Problem — unabhängig davon, ob ein tatsächlicher Sicherheitsvorfall eingetreten ist.

Häufige Fragen aus der Community

Neben den grundlegenden FAQ weiter oben erreichen uns aus Foren, Admin-Communitys und Kundengesprächen regelmäßig drei Fragen, die wir hier aufgreifen:

„Werden Windows Server automatisch auf die neuen Zertifikate aktualisiert?“

Nein. Im Gegensatz zu Windows-Client-Systemen erfolgt auf Windows Servern kein automatisches Deployment der neuen Secure-Boot-Zertifikate über Confidence Buckets. Microsoft hat im Herbst 2025 ein separates Server-Playbook veröffentlicht, das manuelle Schritte erfordert. Wer darauf wartet, dass Server sich selbst aktualisieren, wartet vergeblich — und riskiert, dass Server-Systeme in einem degradierten Sicherheitszustand verbleiben.

„Was passiert, wenn wir nur teilweise umstellen — etwa nur Clients, aber nicht Server oder Recovery?“

Mischzustände sind gefährlicher als der Ausgangszustand. Wenn Clients die neuen Zertifikate tragen, die Deployment-Infrastruktur aber noch alte Signaturen verteilt, erzeugt jede Neuinstallation einen inkonsistenten Zustand. Wenn WinRE nicht aktualisiert wurde, funktioniert die Wiederherstellung genau dann nicht, wenn sie gebraucht wird. Die Umstellung muss alle sechs Schichten umfassen — oder sie erzeugt mehr Risiko, als sie beseitigt.

„Betrifft der Generationstausch auch virtuelle Maschinen?“

Ja. Hyper-V-VMs mit vTPM und aktiviertem Secure Boot sind genauso betroffen wie physische Systeme. Die UEFI-Variablen in der VM müssen ebenfalls aktualisiert werden. Gleiches gilt für VMware vSphere und andere Hypervisoren, die UEFI Secure Boot für VMs unterstützen. Wer seine VM-Landschaft nicht in die Umstellungsplanung einbezieht, übersieht einen erheblichen Teil der betroffenen Systeme.

Secure Boot Check: Klarheit schaffen, bevor der Zeitdruck kommt

Viele IT-Verantwortliche stehen vor der gleichen Ausgangslage: Das Thema ist erkannt, aber der tatsächliche Status der eigenen Umgebung ist unklar. Welche Geräte tragen bereits die neuen Zertifikate? Welche Firmware-Versionen sind im Einsatz? Wo lauern Abhängigkeiten, die im Normalbetrieb unsichtbar bleiben?

Genau hier setzt der Secure-Boot-Check von Trans4mation an.

In einem strukturierten Assessment prüfen wir alle relevanten Schichten Ihrer Windows-Umgebung: von Firmware und Zertifikatsspeichern über Bootmanager und WinRE bis hin zu Deployment-Prozessen und Monitoring. Das Ergebnis ist ein belastbares Statusbild — keine Präsentation, sondern eine dokumentierte Grundlage für fundierte Entscheidungen.

Darauf aufbauend begleiten wir Sie bei der kontrollierten Umsetzung — von der Pilotgruppe über die breite Ausrollung bis zur Validierung des konsistenten Zielzustands. Dabei geht es nicht nur um die erfolgreiche Umstellung, sondern darum, eine überprüfbare Sicherheitsbasis zu etablieren, die auch vor Auditoren Bestand hat.

Ergänzend bringen wir unsere Erfahrung aus vergleichbaren Infrastrukturprojekten ein, um Abhängigkeiten früh zu erkennen, Risiken realistisch einzuordnen und tragfähige Vorgehensweisen zu entwickeln.

Kennen Sie Ihren Secure Boot Status?

Buchen Sie ein unverbindliches Gespräch mit unseren Secure-Boot-Experten und erfahren Sie, wo Ihre Organisation steht — bevor Windows Update es erzwingt.

Jetzt Secure Boot Check terminieren

Quellen

• Microsoft TechCommunity: Secure Boot Playbook — Certificates Expiring 2026
• Microsoft TechCommunity: Windows Server Secure Boot Playbook
• BSI: Lagebericht zur IT-Sicherheit in Deutschland 2024
• BSI: SiSyPHuS — UEFI Secure Boot Analyse
• Bitkom: Wirtschaftsschutzstudie 2025 — Cyberangriffe auf die deutsche Wirtschaft
• ESET Research: BlackLotus UEFI Bootkit Analysis (März 2023)
• Eclypsium: Enterprise Firmware Security Report
• Gartner / ITIC: Hourly Cost of Downtime Reports 2024
• Ponemon Institute / Adaptiva: Managing Risks and Costs at the Edge (2023)
• NSA / CISA: UEFI Secure Boot Customization Enterprise Guidance (Dezember 2025)
• Microsoft: Offizielle Secure-Boot-Update-Seite

Über Trans4mation IT GmbH

Wir begleiten mittelständische Unternehmen bei der sicheren Gestaltung und dem Betrieb ihrer IT-Infrastruktur. Mit Erfahrung aus zahlreichen Infrastrukturprojekten verbinden wir technische Tiefe mit pragmatischer Umsetzung — vom Statuscheck bis zum dokumentierten Abschluss. Im Bereich Secure Boot 2026 unterstützen wir Organisationen dabei, den Generationstausch kontrolliert, konsistent und compliant umzusetzen.

Redaktionelle Anmerkung: Dieser Artikel wurde im März 2026 veröffentlicht. Die dargestellten Informationen basieren auf der zum Zeitpunkt der Veröffentlichung aktuellen Microsoft-Dokumentation. Da sich die Rollout-Timeline weiterentwickelt, empfehlen wir, aktuelle Änderungen unter aka.ms/GetSecureBoot zu verfolgen.

Weiterführende Ressourcen:

• Microsoft Secure Boot Playbook
• Microsoft Windows Server Secure Boot Playbook

Views: 45