Ablauf der Secure-Boot-Zertifikate im Juni 2026 – was Sie jetzt wissen müssen

Nach über 15 Jahren läuft im Juni 2026 erstmals eine ganze Generation von Secure-Boot-Zertifikaten ab. Was wie ein technisches Randthema klingt, betrifft praktisch jedes Windows-Gerät, das seit 2012 ausgeliefert wurde – und kann bei mangelnder Vorbereitung dazu führen, dass Systeme zwar weiter starten, aber dauerhaft im Sicherheitsstand von 2011 eingefroren bleiben.

Worum geht es?

Secure Boot stellt sicher, dass beim Start eines Rechners ausschließlich vertrauenswürdige, digital signierte Software ausgeführt wird. Die Vertrauenskette basiert auf Zertifikaten, die im UEFI-Firmware-Speicher hinterlegt sind. Drei dieser Zertifikate stammen aus dem Jahr 2011 und laufen jetzt gestaffelt aus:

• Microsoft Corporation KEK CA 2011 (24. Juni 2026)
• Microsoft Corporation UEFI CA 2011 (27. Juni 2026)
• Microsoft Windows Production PCA 2011 (19. Oktober 2026)

Als Nachfolger stehen die 2023er-Zertifikate bereit, die Microsoft bereits seit 2024 schrittweise über Windows-Updates verteilt. Geräte, die seit 2024 produziert wurden, bringen sie oft bereits ab Werk mit.

Was passiert, wenn ein Gerät die neuen Zertifikate nicht erhält?

Hier herrscht oft Verwirrung – deshalb die wichtigste Klarstellung vorweg: Der reine Ablauf eines Zertifikats führt nicht zu einem Boot-Fehler. UEFI Secure Boot prüft beim Start lediglich, ob eine Signatur in der erlaubten Datenbank (DB) steht und nicht in der Sperrliste (DBX). Ablaufdaten spielen dabei keine Rolle.

Solange das Microsoft UEFI CA 2011 also in der DB steht und nicht in die DBX aufgenommen wurde, bootet Windows auch nach Juni 2026 weiterhin normal.

Das eigentliche Problem liegt woanders. Microsoft formuliert es so:

Devices that haven’t received the newer 2023 certificates will continue to start and operate normally, but will no longer be able to receive new security protections for the early boot process.

Konkret bedeutet das für nicht aktualisierte Geräte:

• Keine neuen DBX-Updates mehr – die Sperrliste gegen bekannte Bootkits wie BlackLotus (CVE-2023-24932) bleibt eingefroren.
• Keine neuen Boot-Manager-Signaturen – Sicherheitslücken im Bootloader können nicht mehr geschlossen werden.
• Kein Vertrauen in neu signierte Drittanbieter-Software, sofern diese mit den 2023er-Zertifikaten signiert wurde.

Microsoft spricht hier vom „degraded security state“ – das System läuft, ist aber dauerhaft sicherheitsveraltet und in regulierten Umgebungen nicht mehr compliance-fähig.

Und die DBX-Sperre der alten Zertifikate?

Eine berechtigte Sorge: Wird Microsoft die alten 2011er-Zertifikate irgendwann aktiv per DBX sperren – und damit Boot-Bricks auslösen? Antwort: Ja, aber bewusst verzögert. Microsoft trennt strikt zwei Schritte:

1. Erst Rollout der 2023er-Zertifikate
2. Erst danach (und nur wenn die Telemetrie ausreichende Abdeckung zeigt) die DBX-Sperrung der 2011er

Ein fixes Zwangsdatum für den DBX-Widerruf gibt es derzeit nicht. Für unvorbereitete Geräte ist dieser Zeitpunkt aber kritisch: Sobald die 2011er-CA in die DBX aufgenommen wird und gleichzeitig keine 2023er-CA im UEFI hinterlegt ist, startet das System nicht mehr.

 

Für alle erfahrenen Leser – unsere Schritt-für-Schritt-Anleitung zeigt genau, was Sie jetzt tun sollten

 

Microsoft hat ein eigenes Secure Boot Playbook für die 2026er-Zertifikatserneuerung veröffentlicht. Die wichtigsten Schritte im Überblick:

1. Inventarisieren

Bevor der Zertifikatsstatus einzelner Geräte geprüft werden kann, muss eine grundlegendere Frage beantwortet sein: Welche Geräte gibt es im Unternehmen überhaupt? In der Praxis fehlt vielen Organisationen ein vollständiger Überblick über ihren Bestand – Altgeräte, Homeoffice-Notebooks, Maschinen in der Produktion oder vergessene Systeme in Außenstellen tauchen in keinem Inventar sauber auf. Genau diese blinden Flecken sind kritisch: Ein Gerät, von dem die IT nichts weiß, kann weder auf seinen Secure-Boot-Status geprüft noch mit den neuen 2023-Zertifikaten versorgt werden.

Der erste Schritt ist deshalb ein verlässliches Discovery – das automatisierte Aufspüren aller Geräte im Netzwerk. Eine vollständige Hardware-Inventarisierung ist damit nicht „nice to have“, sondern die zwingende Voraussetzung für einen flächendeckenden Rollout. Wer hier Lücken hat, riskiert, dass Geräte beim späteren DBX-Widerruf unbemerkt zurückbleiben und anschließend nicht mehr startfähig sind.

Prüfen Sie dann unternehmensweit:

• Ist Secure Boot überhaupt aktiviert?
• Welchen Wert hat der Registry-Schlüssel UEFICA2023Status? Zielwert ist Updated.
• Existiert ein UEFICA2023Error-Schlüssel? Falls ja, liegt ein Fehler an.

Wie Sie diese und weitere relevante Werte mit Hilfe von Ivanti Neurons und Ivanti Endpoint Manager gezielt einsammeln, aufbereiten und auswerten, zeigen wir Ihnen im nächsten Teil dieser Blogserie.

2. OEM-Firmware-Updates zuerst

Das ist der oft übersehene Punkt: Die Windows-seitige Auslieferung der Zertifikate kann nur funktionieren, wenn das UEFI bereit ist, sie aufzunehmen. OEM-BIOS-/Firmware-Updates haben Vorrang vor den Windows-Zertifikatsupdates. HP, Lenovo, Dell und andere stellen entsprechende Updates bereit.

3. Pilot-Rollout

Wählen Sie eine kleine, repräsentative Gerätegruppe – besonders ungewöhnliche Hardware – und testen Sie das Update-Verfahren, bevor Sie es flottenweit ausrollen.

4. Verifikation

Erfolg lässt sich an zwei Stellen ablesen:

• Event ID 1808 im System-Event-Log – Update erfolgreich angewendet
• Event ID 1801 – Fehler beim Anwenden
• UEFICA2023Status = Updated

Wichtig: Secure Boot muss aktiv sein

Ein Detail, das gerne übersehen wird: Windows kann DB/DBX-Updates nur dann in die Firmware schreiben, wenn Secure Boot aktiv ist. Bei Geräten, bei denen Secure Boot von Anfang an deaktiviert war und auch deaktiviert bleibt, findet dieses Zertifikatsupdate schlicht nie statt. Das ist im Normalbetrieb zunächst unkritisch: Bei ausgeschaltetem Secure Boot prüft die Firmware beim Start weder DB noch DBX, sodass das System unabhängig vom Zertifikatsstatus bootet.

Das eigentliche Problem entsteht erst, wenn man Secure Boot zu einem späteren Zeitpunkt aktivieren möchte, etwa weil es für Windows 11, BitLocker, bestimmte Compliance-Vorgaben oder Sicherheitsfeatures vorausgesetzt werden. Genau hier entsteht eine Henne-Ei-Situation.

Der Bootloader auf der Platte ist noch mit dem alten Microsoft UEFI CA 2011-Zertifikat signiert, weil das Update nie eingespielt wurde. Wurde das 2011-Zertifikat zu diesem Zeitpunkt bereits in die DBX (Sperrliste) aufgenommen, lehnt die Firmware diese Signatur beim Aktivieren von Secure Boot ab. Das Gerät bootet dann nicht mehr und landet im schlimmsten Fall direkt in einem Secure-Boot-Violation-Fehler oder in der Recovery.

Der Ausweg ist nicht, Secure Boot einfach wieder zu deaktivieren und es dabei zu belassen, sondern die Trust Chain nachträglich zu aktualisieren, bevor die DBX-Sperre greift. Konkret sollte man bei solchen Geräten Secure Boot rechtzeitig aktivieren, solange das 2011-Zertifikat noch nicht gesperrt ist, damit Windows im laufenden Betrieb die 2023-Zertifikate und einen aktuell signierten Boot Manager nachziehen kann. Erst danach ist das Gerät gegen den späteren DBX-Widerruf abgesichert.

Die Kernaussage für diese Gerätegruppe lautet also: Wer Secure Boot dauerhaft deaktiviert lässt, verschiebt das Problem nur – und riskiert, dass eine spätere Aktivierung nach dem DBX-Widerruf zu einem nicht mehr startfähigen System führt, weil die Firmware den alten, gesperrten Bootloader dann konsequent ablehnt.

Fazit

Die Zertifikatserneuerung 2026 ist die erste globale „Chain of Trust“-Erneuerung seit Einführung von Secure Boot – und sie verläuft in einem bewusst sanften, telemetriegesteuerten Tempo. Bei gut gepflegten Windows-11-Clients läuft der Großteil dieses Prozesses automatisch im Hintergrund ab. Kritisch wird es bei:

• Windows Server (kein automatischer Rollout – manuelle Aktion zwingend)
• Geräten mit veralteter OEM-Firmware
• Offline-/Air-Gapped-Systemen
• Systemen, bei denen Secure Boot deaktiviert ist

Genau hier entsteht die eigentliche Herausforderung: Sie müssen wissen, welche Geräte in Ihrer Umgebung bereits die 2023-Zertifikate erhalten haben, bei welchen der Boot Manager noch auf dem alten Stand ist und wo Secure Boot überhaupt aktiv ist. Ohne belastbares Reporting tappt man hier im Dunkeln – und entdeckt nicht startfähige Systeme erst dann, wenn der DBX-Widerruf bereits zugeschlagen hat.

Im nächsten Teil dieser Serie zeigen wir Ihnen, wie Sie mit unseren Ivanti-Tools genau diese Transparenz schaffen: vom flächendeckenden Reporting des Zertifikats- und Secure-Boot-Status bis zum gesteuerten, sicheren Rollout der neuen Zertifikate – damit kein Gerät unbemerkt zurückbleibt.

Sind noch Fragen offen? Melden Sie sich einfach – wir kümmern uns darum.