Secure-Boot-Zertifikate laufen im Juni 2026 aus: Was IT-Teams bis zum Stichtag für ihre Windows-Flotte aufsetzen müssen

7 Min. Lesezeit

Ab Juni 2026 verlieren die Microsoft-Secure-Boot-Zertifikate aus dem Jahr 2011 ihre Gültigkeit. Windows-Geräte ohne eingespieltes 2023er Zertifikat können danach keine neuen Secure-Boot-Updates mehr installieren und verlieren das Vertrauen in neu signierte Drittanbieter-Software. IT-Teams haben noch rund zwei Monate Zeit für Inventur, Test und Rollout. Wer erst im Juni startet, ist zu spät.

Was im Juni 2026 konkret ausläuft

Secure Boot ist ein UEFI-Mechanismus, der beim Start eines Computers prüft, ob die geladene Firmware, der Bootloader und das Betriebssystem von einer vertrauenswürdigen Quelle stammen. Die Vertrauenskette beruht auf kryptografischen Signaturen, die über sogenannte Certificate Authorities ausgestellt werden. Microsoft hat 2011 drei zentrale CAs etabliert: die Microsoft Corporation KEK CA 2011 für die Key Exchange Key Database, die Microsoft Windows Production PCA 2011 für signierte Windows-Komponenten und die Microsoft Corporation UEFI CA 2011 für Drittanbieter-Software.

Diese drei Zertifikate verlieren ab Juni 2026 ihre Gültigkeit. Die Ablösung ist kein plötzlicher Ausfall, sondern ein gestaffelter Prozess, der sich bis Oktober 2026 hinzieht. Microsoft hat die Nachfolger bereits 2023 aufgesetzt und verteilt sie schrittweise über Windows-Updates auf Bestandsgeräte. Seit Anfang 2024 ausgelieferte PCs enthalten die 2023er CAs direkt ab Werk – ein strategischer Vorteil für Unternehmen mit jungem Gerätepark, aber ein Risiko für alle anderen.

Der Hintergrund ist technisch und regulatorisch motiviert. Die 2011er Zertifikate stammen aus einer Zeit, in der SHA-1 noch verbreitet war und die Secure-Boot-Architektur deutlich weniger Hersteller betraf als heute. Mit dem Übergang auf die 2023er CAs passt Microsoft die Verschlüsselungsverfahren an aktuelle Standards an und verkürzt gleichzeitig die Certificate-Lifetimes auf einen Wert, der für produktive Systeme besser handhabbar ist.

Welche Geräte betroffen sind

Die einfache Regel lautet: Alles was vor 2024 produziert wurde, braucht eine aktive Aktualisierung. Das betrifft in der Praxis die Mehrheit aller Geräte in einem typischen Unternehmen, weil die durchschnittliche Laptop-Lebensdauer zwischen vier und sechs Jahren liegt und Desktops oft noch länger im Einsatz bleiben. Server sind ebenfalls betroffen, wobei Virtualisierungshosts und VMs unterschiedlich behandelt werden.

Physische Windows-Geräte werden über die üblichen Windows-Update-Kanäle mit den 2023er Zertifikaten versorgt. Die Auslieferung ist aber nicht automatisch im Sinne von „jeder Computer bekommt es garantiert“. Microsoft steuert die Verteilung gestaffelt. Einzelne Geräteklassen warten noch auf OEM-Freigaben. Dell, HP, Lenovo und Fujitsu haben unterschiedliche Zeitpläne für Firmware-Updates, die die CA-Änderungen in der Hardware verankern. IT-Teams müssen den Stand pro Gerätemodell prüfen und dürfen nicht davon ausgehen, dass Windows-Update allein das Problem löst.

Virtuelle Maschinen sind ein Sonderfall. Hyper-V, VMware und KVM unterstützen Secure Boot, aber die Certificate-Updates laufen hier über die virtualisierte Firmware, nicht über das Gast-Betriebssystem. Für vSphere-Umgebungen hat VMware Anleitungen zur Umstellung veröffentlicht, Microsoft liefert Hyper-V-Updates über die Host-Patches. Für KVM-Umgebungen auf Linux-Basis ist der Prozess komplexer und erfordert oft manuelle Intervention auf jedem VM-Host.

Besonders heikel sind ältere Geräte, die aus OEM-Sicht das End-of-Service erreicht haben. Für diese Hardware gibt es möglicherweise keine passende Firmware mehr, die die 2023er CAs verankert. Microsoft und die Hersteller werden vermutlich nicht alle Alt-Geräte supporten. Die XDA-Developers-Redaktion hat in einer Analyse Ende März 2026 darauf hingewiesen, dass ein Teil der Pre-2020-Windows-PCs den Fix nie bekommen dürfte. Für IT-Teams bedeutet das: Diese Geräte sollten inventarisiert, priorisiert und entweder früh ausgetauscht oder in isolierten Netzsegmenten mit reduzierten Rechten betrieben werden.

Der Inventar-Check: PowerShell und Registry

Die gute Nachricht für IT-Teams: Der Status eines Geräts lässt sich mit minimalem Aufwand prüfen. Microsoft stellt zwei Verfahren zur Verfügung. Das erste ist ein Registry-Eintrag im Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status. Der Wert dieses Eintrags soll letztendlich auf „updated“ stehen. Andere Werte wie „NotStarted“ oder „InProgress“ zeigen an, dass die Verteilung noch nicht abgeschlossen ist.

Das zweite Verfahren ist eine PowerShell-Abfrage, die Microsoft in seinem Tech-Community-Blog publiziert hat. Sie listet die aktuell installierten Secure-Boot-Datenbank-Einträge und erlaubt einen maschinellen Abgleich mit dem Soll-Zustand. Für Flotten-weite Inventur empfiehlt sich die Kombination mit Microsoft Intune, Configuration Manager oder einem vergleichbaren Endpoint-Management-Tool, das den Registry-Wert systemweit abfragen kann. Eine manuelle Prüfung auf Hunderten Geräten ist nicht praktikabel.

Wichtig ist die Unterscheidung zwischen „Zertifikat installiert“ und „Zertifikat aktiv“. Ein Gerät kann das 2023er Zertifikat in der UEFI-Datenbank stehen haben, ohne dass es produktiv genutzt wird. Erst wenn der Status auf „updated“ steht und die Firmware die 2023er CAs für die Bootloader-Prüfung heranzieht, ist das Gerät vorbereitet. Die vollständige Transition braucht mehrere Neustarts und in manchen Fällen manuelle UEFI-Einstellungen. IT-Teams sollten den Prozess deshalb auf einer Handvoll Pilot-Geräte pro Modell durchspielen, bevor der Flotten-Rollout startet.

Der Update-Prozess in vier Schritten

Microsoft empfiehlt einen strukturierten Ansatz, den IT-Teams über die nächsten sechs bis acht Wochen umsetzen können. Der Prozess gliedert sich in vier Schritte, die logisch aufeinander aufbauen und sich nicht parallelisieren lassen:

Was passiert, wenn das Update nicht rechtzeitig läuft

Die Folgen einer verpassten Aktualisierung sind nicht dramatisch im Sinne eines kompletten Systemausfalls, aber sie sind technisch unangenehm und organisatorisch belastend. Windows-Geräte ohne 2023er CAs bleiben funktional. Sie starten weiterhin, lassen sich bedienen und verarbeiten Anwendungen. Zwei Dinge ändern sich aber substanziell.

Erstens: Neue Secure-Boot-Revisionen, die Microsoft nach dem Stichtag veröffentlicht, werden nicht mehr vertrauenswürdig installiert. Das betrifft vor allem Updates gegen neue Boot-Level-Malware-Klassen wie BlackLotus oder CoSign-basierte Angriffe. Geräte ohne Update verlieren also schrittweise den Schutz vor Angriffen, die auf die Secure-Boot-Kette zielen. Das ist keine akute Bedrohung, aber ein langsam wachsendes Risiko.

Zweitens: Drittanbieter-Software, die nach dem Stichtag mit den neuen 2023er CAs signiert wurde, wird von alten Geräten nicht mehr als vertrauenswürdig erkannt. Das betrifft beispielsweise Linux-Bootloader wie Shim und GRUB, die häufig neu signiert werden. Dazu kommen spezielle Security-Tools mit eigenen Kernel-Komponenten. IT-Teams mit gemischten Umgebungen oder spezialisierten Anwendungen werden hier sehr schnell Probleme sehen.

Für Compliance-Perspektiven ist das relevant, weil NIS2 und ISO 27001 Anforderungen an aktuelle Sicherheitspatches und Vulnerability-Management stellen. Ein Auditor wird die Frage nach dem Secure-Boot-Certificate-Status nicht übersehen, wenn er sich mit der Endpoint-Security-Architektur befasst. Wer hier keinen dokumentierten Status vorweisen kann, handelt sich nicht nur technische Probleme ein, sondern auch regulatorische.

Sonderfall Linux Dual-Boot und RHEL-Umgebungen

Unternehmen mit Linux-Umgebungen oder Dual-Boot-Geräten müssen einen zusätzlichen Schritt mitdenken. Red Hat hat bereits Anfang 2026 eine offizielle Guidance für RHEL-Umgebungen publiziert, die die Transition auf die 2023er CAs beschreibt. Der Kernpunkt: Der Red Hat Shim-Bootloader ist von Microsoft mit der UEFI CA 2011 signiert. Sobald diese CA ausläuft, können RHEL- und Fedora-Systeme auf nicht-aktualisierten Geräten nicht mehr sicher booten. Red Hat liefert neue Shim-Versionen, die mit der UEFI CA 2023 signiert sind, aber diese setzen die entsprechende CA auf dem Zielgerät voraus.

Für Dual-Boot-Geräte mit Windows und Linux ergibt sich daraus eine klare Reihenfolge. Zuerst muss Windows die 2023er CAs über das Update-Verfahren installieren, dann muss die UEFI-Firmware die neuen CAs in der Vertrauenskette verankern, erst danach kann ein RHEL- oder Fedora-Shim mit 2023er Signatur erfolgreich booten. Die umgekehrte Reihenfolge funktioniert nicht – ein fehlgeschlagenes Update kann zu einem nicht mehr bootenden Linux-Partition führen. Betroffene Teams sollten die RHEL-Updates bis zur abgeschlossenen Windows-Transition zurückhalten.

Sechs-Punkte-Checkliste für IT-Teams

Für die verbleibenden Wochen bis Juni 2026 lassen sich sechs konkrete Handlungsschritte priorisieren:

1. Inventur starten. Alle Windows-Geräte per zentralem Endpoint-Management auf den UEFICA2023Status abfragen. Ergebnis als Excel-Liste oder Dashboard dokumentieren, gegliedert nach Geräteklasse und Standort.
2. Firmware-Updates prüfen. Pro Geräteklasse beim Hersteller nachfragen, ob aktuelle BIOS-Versionen die 2023er CAs unterstützen. Dell, HP, Lenovo und Fujitsu haben Support-Artikel mit kompatiblen Firmware-Versionen publiziert.
3. Pilot aufsetzen. Fünf bis zehn Geräte pro Modell in einer Pilot-Gruppe aktualisieren, Status verifizieren, Probleme dokumentieren. Zeitfenster bis Ende April reservieren.
4. Rollout-Plan erstellen. Flotten-Rollout in zwei bis drei Wellen aufteilen, mit Betrieb und Fachbereichen abstimmen. Wochen-Ziele statt Tages-Ziele definieren, Reserven für unerwartete Probleme einplanen.
5. Linux- und Virtualisierungs-Umgebungen koordinieren. Mit Linux-Admins und Virtualisierungs-Teams abklären, ob abhängige Systeme betroffen sind. Update-Reihenfolge festlegen, rückwärts-kompatible Snapshots anlegen.
6. Risiko-Liste für Alt-Geräte. Alle Geräte ohne verfügbaren Fix separat dokumentieren. Optionen sind Austausch, Netz-Isolation oder Reduktion der Angriffsfläche durch restriktive Software-Whitelists. Entscheidung auf CISO-Ebene absichern.

Fazit

Die Secure-Boot-Transition ist kein Regulatorik-Thema mit vager Deadline, sondern eine harte technische Abschaltung mit festem Datum. Unternehmen, die die Aktualisierung bis Juni 2026 abschließen, haben keinen akuten Bruch zu erwarten. Wer die Deadline verpasst, sitzt danach auf Geräten, die schrittweise neue Secure-Boot-Updates und neu signierte Software nicht mehr vertrauen – und das in einer Phase, in der Boot-Level-Angriffe durch Gruppen wie BlackLotus zugenommen haben.

Die Arbeit ist machbar, aber sie erfordert Priorität. Die Inventur ist der wichtigste erste Schritt, weil sie die Basis für jede weitere Entscheidung liefert. Danach folgt ein strukturierter Rollout, der Pilot, Tests und Produktions-Phasen sauber trennt. Für IT-Teams heißt das konkret: Diese Woche die Inventur starten, nächste Woche Pilot-Geräte ausrollen, bis Ende April alle Standardgeräte aktualisiert, im Mai die Problemfälle abarbeiten. Wer sich daran hält, hat einen ruhigen Juni.

Häufige Fragen

Können wir das Update zentral über Intune oder Configuration Manager ausrollen?

Ja, beide Werkzeuge unterstützen den Rollout. Microsoft stellt spezifische Deployment-Ringe bereit, die über Windows Update for Business oder WSUS verteilt werden. Intune bietet zudem Compliance-Policies, die den UEFICA2023Status überwachen und bei Abweichung Alarme auslösen. Für Configuration Manager empfiehlt Microsoft eine Kombination aus Inventur-Task-Sequence und automatisierten Rollouts pro Gerätegruppe. Manuelle Eingriffe sind nur bei Geräten mit UEFI-Custom-Settings oder gesperrter Firmware notwendig.

Was passiert bei Geräten, die bereits Secure Boot deaktiviert haben?

Für Geräte, bei denen Secure Boot aus Kompatibilitätsgründen deaktiviert wurde, ändert sich kurzfristig nichts. Die auslaufenden Zertifikate betreffen nur aktive Secure-Boot-Funktionalität. Allerdings sollten IT-Teams diese Geräte nicht als erledigt abhaken. Das Deaktivieren von Secure Boot ist ein Sicherheitsrisiko, das 2026 nicht mehr akzeptabel sein sollte. Die Certificate-Transition ist deshalb ein guter Zeitpunkt, die Secure-Boot-Deaktivierungen zu auditieren und wo möglich umzukehren.

Wie erkenne ich, ob mein Hardware-Hersteller das Update noch liefert?

Die einfachste Quelle ist die Support-Seite des jeweiligen Herstellers. Dell, HP, Lenovo und Fujitsu haben Listen ihrer unterstützten Geräte veröffentlicht. Für Geräte, die dort nicht auftauchen, sollte eine direkte Anfrage beim Hersteller-Support erfolgen. Wenn auch diese Anfrage keine positive Antwort liefert, ist das Gerät aus OEM-Sicht End-of-Service und erhält den Fix nicht mehr. Microsoft selbst betreibt unter aka.ms/GetSecureBoot eine Landing-Page mit einer Tool-Sammlung und Hersteller-Verweisen.

Was bedeutet das für unsere Virtualisierungs-Umgebung?

Hyper-V-VMs auf Windows Server bekommen die Aktualisierung über Host-Patches mit. VMware vSphere braucht die ESXi-Firmware-Updates, die VMware selbst bereitstellt. KVM-basierte Umgebungen auf Linux-Hosts sind komplexer, weil die OVMF-Firmware separat aktualisiert werden muss. Für produktive Virtualisierungs-Plattformen empfiehlt sich eine Rollout-Welle vor dem Stichtag, getrennt vom Client-Update. Wer Test-VMs als Pilot nutzt, kann Edge-Cases früh identifizieren.

Gibt es eine Möglichkeit, die Aktualisierung zu erzwingen, wenn Windows Update sie nicht anbietet?

Microsoft verteilt die 2023er CAs gestaffelt, um Produktionssysteme nicht zu überlasten. Ein manueller Override ist über den Registry-Eintrag MicrosoftUpdateManagedOptIn möglich, der den Rollout für das spezifische Gerät beschleunigt. Der Wert sollte für einzelne Pilot-Geräte auf 0x5944 gesetzt werden. Diese Methode ist vor allem für dedizierte Test-Geräte und Compliance-Audits sinnvoll, nicht für flächendeckenden Rollout.

Wird es eine Verlängerung der Deadline geben?

Microsoft hat bislang keine Verlängerung angekündigt und signalisiert im Gegenteil mit der Playbook-Publikation, dass die Deadline ernst gemeint ist. Die Planung sollte deshalb konsequent auf den Juni-Stichtag ausgelegt werden. Selbst wenn Microsoft im letzten Moment eine Kulanzregelung einführen sollte, ist der Vorteil eines rechtzeitig durchgezogenen Rollouts groß genug, um sich nicht auf Gnadenfristen zu verlassen. IT-Teams sollten die Deadline als fix behandeln.

Quelle Titelbild: Pexels / panumas nikhomkhai

Hier schreibt Tobias Massow für Sie

Mehr Artikel vom Autor Tobias Massow