Szenario: Montagmorgen bei der Kellerhoff Präzisionstechnik GmbH

Es ist ein ganz normaler Montagmorgen Ende Juni 2026. Andreas Kellner, IT-Leiter bei der Kellerhoff Präzisionstechnik GmbH – einem mittelständischen Maschinenbauer mit 340 Mitarbeitern und 28 Windows-Servern – beginnt seinen Tag wie immer mit dem Blick aufs Monitoring-Dashboard. Was er sieht, bereitet ihm sofort Bauchschmerzen: Fünf Server zeigen nach dem Wochenend-Patch-Cycle keine Verbindung mehr, drei Workstations in der Fertigung starten nicht durch und in der Produktion flackert eine Fehlermeldung, die er noch nie gesehen hat – etwas über „Secure Boot" und „ungültiges Zertifikat".

Kellner ruft seinen Kollegen Stefan Weis an, den zuständigen Systemadministrator. Der erklärt nach kurzem Nachschlagen: Die Microsoft Secure Boot-Zertifikate aus dem Jahr 2011 sind am 26. Juni 2026 abgelaufen – und die betroffenen Geräte haben das Update auf die 2023er-Zertifikate nie erhalten, weil die Firmware-Voraussetzungen nicht rechtzeitig geschaffen wurden. Ein stiller, unspektakulärer Countdown lief bereits seit Jahren – und niemand hatte ihn auf dem Radar.

Dieses Szenario ist fiktiv, aber technisch absolut realistisch. Es beschreibt genau das, was tausenden deutschen Unternehmen in den kommenden Wochen passieren kann, wenn sie nicht handeln. Dieser Artikel erklärt, warum Secure Boot-Zertifikate ablaufen, was das konkret bedeutet – und vor allem, was IT-Abteilungen jetzt tun müssen, um das Kellner-Szenario zu vermeiden.

Was ist Secure Boot – und warum sind Zertifikate so wichtig?

Secure Boot ist ein Sicherheitsstandard der UEFI-Spezifikation (Unified Extensible Firmware Interface), der sicherstellt, dass beim Start eines Computers ausschließlich Software ausgeführt wird, die von einer vertrauenswürdigen Instanz digital signiert wurde. Die Idee dahinter ist simpel und wirkungsvoll: Ein Angreifer, der versucht, schadhaften Code bereits vor dem Betriebssystem zu starten – etwa über einen Bootkit oder einen Rootkit in der UEFI-Firmware –, wird durch Secure Boot effektiv blockiert, weil seine unsignierte oder mit einem nicht vertrauenswürdigen Zertifikat signierte Software schlicht nicht ausgeführt wird.

Im Secure Boot-Ökosystem gibt es eine Hierarchie von Zertifikaten, ähnlich einer Public-Key-Infrastruktur (PKI): An der Spitze steht der Platform Key (PK), der vom Gerätehersteller (OEM) gesetzt wird. Darunter liegen die Key Enrollment Keys (KEK) und die sogenannten Signature Databases (db/dbx), in denen vertrauenswürdige und explizit ausgeschlossene Zertifikate gelistet sind. Microsoft betreibt zwei eigene Certificate Authorities (CAs) im Secure Boot-Ökosystem: die „Microsoft Windows Production PCA 2011" für Windows-Systemkomponenten und die „Microsoft Corporation UEFI CA 2011" für Drittanbieter-Software wie UEFI-Treiber und Bootloader.

Diese 2011er-Zertifikate bilden seit über einem Jahrzehnt das Fundament des Vertrauens für Milliarden von Windows-Geräten weltweit. Sie signieren Bootloader, Treiber, Wiederherstellungsumgebungen und auch viele Linux-Distributionen, die über den Microsoft-Pfad auf Windows-Geräten starten können (Shim-Mechanismus). Und jetzt laufen sie ab.

Die Ausgangslage: 2011er-Zertifikate laufen ab

Die originalen Microsoft Secure Boot-Zertifikate aus dem Jahr 2011 haben eine Gültigkeitsdauer von 15 Jahren. Das bedeutet: Ab Juni 2026 beginnen sie zu verfallen, der vollständige Ablauf erstreckt sich bis Oktober 2026. Das ist keine technische Panne oder ein Versehen – es ist das vorgesehene Ende des Zertifikatslebenszyklus. Problematisch ist, dass viele IT-Abteilungen diesen Termin entweder nicht auf dem Schirm hatten oder unterschätzt haben.

Microsoft hat reagiert: Bereits 2023 wurden neue CAs eingeführt – die „Windows UEFI CA 2023" und die „Microsoft UEFI CA 2023". Diese neuen Zertifikate sind der Nachfolger der 2011er-Zertifikate und müssen auf allen Geräten eingespielt werden, bevor die alten CAs verfallen. Das klingt nach einem einfachen Update – ist es aber nicht, denn die Situation hat mehrere Komplikationsebenen.

Das Drei-Schichten-Problem

Das Secure Boot-Update auf die 2023er-Zertifikate erfordert eine Zusammenarbeit auf drei Ebenen, die alle gleichzeitig stimmen müssen:

  • OEM-Firmware: Der Gerätehersteller muss ein UEFI-Firmware-Update bereitstellen, das die neuen 2023er-CA-Zertifikate in die Key Enrollment Key Database (KEK db) einspielt. Ohne dieses OEM-Firmware-Update kann Windows das Certificate-Update nicht erfolgreich abschließen.
  • Windows-Update: Microsoft verteilt die neuen Zertifikate über Windows Update und ab Mai 2026 (Patch Tuesday 13. Mai für Windows 10/Server 2019/2022, 16. Mai für Windows 11/Server 2025) als Teil der regulären kumulativen Updates.
  • Kompatibilitätsprüfung: Das Update prüft vor der Installation, ob die notwendigen Firmware-Voraussetzungen erfüllt sind. Fehlen sie, wird das Certificate-Update zurückgehalten – mit der Konsequenz, dass das Gerät nach Ablauf der 2011er-Zertifikate in einem potenziell unsicheren Zustand bleibt.

Das heißt: IT-Abteilungen, die nur auf Windows Update vertrauen und keine OEM-Firmware-Pflege betreiben, laufen Gefahr, dass ein Teil ihrer Geräteflotte das Update nie erhält.

Was passiert, wenn ein Gerät das Update nicht erhält?

Microsoft hat klargestellt, dass Geräte, die die neuen 2023er-Zertifikate nicht erhalten haben, nach dem Ablauf der 2011er-Zertifikate weiterhin starten und normal betrieben werden können – Windows-Updates werden weiterhin installiert, der reguläre Betrieb ist nicht unterbrochen. Das klingt zunächst beruhigend, trügt aber über die eigentlichen Konsequenzen hinweg:

  • Keine künftigen Secure Boot-Security-Updates: Sicherheitsupdates, die über den Secure Boot-Kanal verteilt werden – insbesondere Updates der Signature Database (db) und der Revocation List (dbx) –, können nach dem Ablauf der alten CAs nicht mehr installiert werden. Das bedeutet, dass neue Sicherheitslücken in Boot-Komponenten auf diesen Geräten dauerhaft offen bleiben.
  • Kein Vertrauen in neue Drittanbieter-Zertifikate: Software und UEFI-Treiber, die mit den neuen 2023er-Zertifikaten signiert sind, werden von nicht aktualisierten Geräten als nicht vertrauenswürdig eingestuft. Das kann bei künftigen Hardware-Treibern, Recovery-Werkzeugen oder sogar bei Linux-Dual-Boot-Szenarien zu erheblichen Problemen führen.
  • Compliance-Risiken: Für Unternehmen, die unter NIS2, ISO 27001, BSI Grundschutz oder anderen Frameworks operieren, entsteht durch veraltete Secure Boot-Zertifikate ein dokumentierbares Compliance-Defizit. Auditoren werden gezielt nach diesem Thema fragen.

Kurz gefasst: Die Geräte laufen zwar weiter – aber die Sicherheitsfundamente erodieren still und leise. Für sicherheitsbewusste IT-Abteilungen ist das keine akzeptable Situation.

User Story: Wie IT-Leiter Kellner das Problem gelöst hätte

Kehren wir zu Andreas Kellner zurück – aber diesmal mit einem anderen Ausgang. Angenommen, er hätte im März 2026 diesen Artikel gelesen. Wie wäre sein Vorgehen gewesen?

„Ich hab mir zunächst ein Bild vom Umfang gemacht", erzählt der fiktive Kellner. „Wir haben 28 Server und rund 210 Workstations im Unternehmen. Das erste, was ich getan habe, war Inventar machen: Welche OEMs haben wir, welche Modelle, und haben die bereits UEFI-Firmware-Updates für das Secure Boot-Zertifikat veröffentlicht?"

Kellner hätte Folgendes getan: Über Microsoft Intune – Kellerhoff verwendet eine hybride Active Directory / Intune-Umgebung – startete er eine Geräteinventur und exportierte alle Gerätemodelle mit ihren aktuellen BIOS/UEFI-Versionen in ein Excel-Sheet. Dann besuchte er die Support-Seiten der drei in seinem Unternehmen eingesetzten OEMs: HP, Lenovo und Fujitsu. Jeder dieser Hersteller hatte bereits dedizierte Firmware-Update-Pakete für das Secure Boot-Zertifikat veröffentlicht.

„Das schwierige waren die 14 älteren Workstations, die schon über 7 Jahre alt waren. Für die gab es keine Firmware-Updates mehr. Ich habe das dem Geschäftsführer eskaliert und empfohlen, diese Geräte im Rahmen des ohnehin geplanten Hardware-Refresh vorzuziehen – was er genehmigt hat."

Für die restlichen Geräte rollte Kellner zunächst die OEM-Firmware-Updates aus – in einer Testgruppe von 10 Geräten über drei Wochen, dann in Wellen von jeweils 30-50 Geräten. Erst als alle Geräte die aktuelle Firmware hatten, wartete er auf den Mai-Patch-Tuesday, der die neuen 2023er-Zertifikate automatisch über Windows Update ausrollte. Der Ende-Juni-Stichtag verlief problemlos. Kein einziges Gerät zeigte eine Fehlermeldung.

Schritt-für-Schritt: Der Enterprise-Aktionsplan

Hier ist ein konkreter Aktionsplan, der sich direkt an IT-Abteilungen im deutschen Mittelstand richtet und auf den offiziellen Microsoft-Empfehlungen basiert:

Phase 1: Bestandsaufnahme (bis Ende April 2026)

Der erste Schritt ist Transparenz über die eigene Gerätelandschaft. Erstellen Sie ein vollständiges Inventar aller Windows-Systeme mit folgenden Informationen: Gerätehersteller (OEM), Modellbezeichnung, aktuelle UEFI/BIOS-Version, Windows-Version und aktuelle Secure Boot-Konfiguration. In einer gut verwalteten Intune- oder SCCM-Umgebung sind diese Daten weitgehend verfügbar. Für nicht verwaltete Geräte hilft ein PowerShell-Skript:

Get-WmiObject -Class Win32_BIOS | Select-Object Manufacturer, Name, Version, BIOSVersion
Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name KEK | Select-Object -ExpandProperty Certificates | ForEach-Object { $_.ToBeSigned.Subject }

Das zweite Element der Bestandsaufnahme: Prüfen Sie für jeden OEM, ob bereits ein UEFI-Firmware-Update für das Secure Boot-Zertifikat verfügbar ist. Die großen Hersteller (HP, Dell, Lenovo, Fujitsu, ASUS, Acer) haben bereits entsprechende Updates veröffentlicht oder angekündigt. Für Geräte, für die kein Firmware-Update verfügbar ist (typischerweise Geräte älter als 5-7 Jahre), müssen Sie eine separate Strategie entwickeln.

Phase 2: OEM-Firmware-Updates ausrollen (April bis Anfang Mai 2026)

Firmware-Updates sind kritisch und erfordern besondere Sorgfalt. Im Gegensatz zu normalen Software-Updates kann ein fehlgeschlagenes Firmware-Update im schlimmsten Fall ein Gerät unbootbar machen. Empfohlenes Vorgehen:

  • Testen Sie Firmware-Updates zunächst in einer kontrollierten Gruppe von 5-10 Repräsentativgeräten
  • Dokumentieren Sie die Ausgangskonfiguration vor dem Update (UEFI-Screenshot, Firmware-Version)
  • Führen Sie Firmware-Updates niemals remote auf kritischen Produktionssystemen durch – planen Sie Wartungsfenster
  • Nutzen Sie herstellereigene Tools: HP Sure Admin / HPIA, Lenovo System Update, Dell Command | Update, Fujitsu DeskUpdate
  • In Intune-verwalteten Umgebungen: Nutzen Sie Windows Autopatch oder SCEP/WSUS-Erweiterungen für OEM-Software-Updates, sofern verfügbar

Microsoft empfiehlt ausdrücklich: Firmware-Updates müssen vor den Windows-Zertifikats-Updates eingespielt sein. Die Reihenfolge ist entscheidend.

Phase 3: Windows-Zertifikats-Update überwachen (Mai / Juni 2026)

Nachdem die OEM-Firmware-Updates auf der gesamten Flotte eingespielt sind, können Sie dem Windows-Update-Prozess vertrauen, um die neuen 2023er-Zertifikate automatisch zu verteilen. Microsoft plant die Verteilung im kumulativen Patch Tuesday:

  • Windows 10, Server 2019, Server 2022: Patch Tuesday 13. Mai 2026
  • Windows 11, Server 2025: Patch Tuesday 16. Mai 2026

Ab Windows Update Build Mai 2026 zeigt die Windows-Sicherheits-App einen neuen Status-Indikator für den Secure Boot-Zertifikat-Update-Status. Nutzen Sie diesen als schnellen Überblick. Für die systematische Überwachung auf Flottenebene stellt Microsoft eine PowerShell-basierte Abfrage zur Verfügung, die den Update-Status aller Geräte in Ihrer Intune- oder Configuration Manager-Umgebung abfragt.

Auf der Landing Page https://aka.ms/GetSecureBoot hält Microsoft alle offiziellen Ressourcen aktuell – inkl. des offiziellen Secure Boot Playbooks für Enterprises.

Phase 4: Sonderfälle und Problemgeräte

Nicht alle Szenarien passen in den Standard-Update-Ablauf. Häufige Sonderfälle, denen IT-Abteilungen begegnen werden:

Ältere Geräte ohne Firmware-Update: Für Geräte, deren OEM keine weiteren Firmware-Updates anbietet (End-of-Support), gibt es keine einfache Lösung. Optionen: Hardware-Refresh beschleunigen, die Geräte in isolierte Netzwerksegmente verschieben (falls weiterhin betrieben) oder Secure Boot deaktivieren (was seinerseits neue Risiken schafft und dokumentiert werden muss).

Linux-Systeme und Dual-Boot: Linux-Distributionen, die über den Microsoft-Shim-Mechanismus auf Windows-Geräten starten (alle major Distros: Ubuntu, Debian, RHEL, SUSE etc.), sind ebenfalls betroffen. Red Hat hat eigene Guidance veröffentlicht; Distribution-spezifische Shim-Updates sind für RHEL 7/8/9 bereits verfügbar. In Dual-Boot-Umgebungen müssen beide Betriebssysteme berücksichtigt werden.

Virtuelle Maschinen und Hypervisoren: VMs mit aktiviertem vTPM und Secure Boot unter Hyper-V oder VMware ESXi erben die Zertifikatslage ihres Host-Systems. Prüfen Sie, ob Ihre Hypervisor-Infrastruktur Firmware-Updates erhält und ob virtuelle UEFI-Konfigurationen separat behandelt werden müssen.

Air-Gapped / isolierte Systeme: Systeme ohne Internetzugang erhalten Windows-Updates nicht automatisch. Für WSUS-verwaltete oder komplett isolierte Umgebungen müssen Updates manuell heruntergeladen und importiert werden. Erstellen Sie jetzt die notwendigen Prozesse und Genehmigungsworkflows.

Die Compliance-Dimension: Was NIS2 und ISO 27001 sagen

Für Unternehmen, die unter NIS2-Regulierung fallen oder eine ISO-27001-Zertifizierung anstreben oder aufrechterhalten, hat das Thema Secure Boot eine direkte Compliance-Relevanz. Beide Frameworks verlangen ein systematisches Patch- und Schwachstellenmanagement, das auch Firmware und Boot-Infrastruktur umfasst. Ein abgelaufenes Secure Boot-Zertifikat, das dazu führt, dass keine weiteren Sicherheitsupdates für den Boot-Kanal mehr eingespielt werden können, ist ein dokumentierbares Kontrollversagen.

Im Rahmen eines BSI-Grundschutz-Audits oder einer NIS2-Meldepflicht-Prüfung wird dieser Aspekt zunehmend abgefragt. IT-Abteilungen sollten die Secure Boot-Zertifikat-Migration als eigenes Change-Management-Projekt dokumentieren – mit Scope, Timeline, Risikoabschätzung und Nachweis der erfolgreichen Umsetzung. Das schafft einerseits Rechtssicherheit, andererseits demonstriert es gegenüber Geschäftsleitung und Auditoren eine proaktive Sicherheitskultur.

Mehr zum Thema systematische Compliance-Dokumentation und NIS2-Anforderungen erfahren Sie in unserem Leistungsbereich Compliance-Software.

Technischer Hintergrund: Warum sind Zertifikate in der UEFI-Welt so komplex?

Für technisch Interessierte: Die Komplexität des Secure Boot-Zertifikatsökosystems liegt in seiner Dezentralität. Jeder PC-Hersteller (OEM) kontrolliert den Platform Key (PK) in der UEFI-Firmware seines Geräts. Dieser PK kann nicht über ein Software-Update geändert werden – er sitzt tief in der Firmware. Deshalb braucht jedes Firmware-Update die Mitwirkung des OEM.

Wenn Microsoft neue CA-Zertifikate einführt, müssen diese in die Key Enrollment Key Database (KEK db) des Geräts aufgenommen werden. Dieser Schritt erfordert eine kryptografische Signatur durch den OEM – deshalb muss das OEM ein dediziertes Firmware-Update bereitstellen, das die neuen Microsoft-CAs in die KEK db schreibt. Erst dann kann Windows (mit Administratorrechten und signiertem Update) seinerseits die Signature Database (db) aktualisieren, in der die vertrauenswürdigen Endentitätszertifikate gespeichert sind.

Diese Architektur ist absichtlich so designed: Sie verhindert, dass ein Angreifer, der Administratorrechte auf einem Windows-System erlangt hat, einfach beliebige Zertifikate in die Secure Boot-Trusted-List einschleusen kann. Der Hardware-Root-of-Trust bleibt beim OEM. Das macht das System sicher – und Zertifikatsmigrationen gleichzeitig komplex.

Handlungsempfehlungen für IT-Verantwortliche im Mittelstand

Zusammenfassend empfiehlt pleXtec folgende Maßnahmen für IT-Abteilungen im deutschen Mittelstand:

  • Sofort: Vollständiges Geräte-Inventar erstellen – OEM, Modell, UEFI-Version, Alter
  • Bis Ende April: OEM-Firmware-Update-Verfügbarkeit für alle Gerätemodelle prüfen; Plan für Geräte ohne verfügbares Update erstellen
  • Vor dem 13. Mai: OEM-Firmware-Updates in Testumgebung validieren, dann in Wellen ausrollen
  • Mai/Juni: Patch Tuesday-Updates überwachen, Zertifikats-Update-Status in Windows Security App prüfen
  • Laufend: Geräte ohne Update in separater Liste verwalten, Risikobewertung und ggf. Ersatzbeschaffung initiieren
  • Dokumentation: Das gesamte Projekt als Change-Management-Vorgang dokumentieren für Compliance-Nachweis

Der Handlungsbedarf ist real und zeitkritisch – aber er ist auch bewältigbar. Es ist kein technisch revolutionäres Projekt; es ist solides, systematisches IT-Asset-Management. Wer jetzt strukturiert vorgeht, meidet das Kellner-Szenario vom Montagmorgen.

Ausblick: Was nach dem Secure Boot-Update kommt

Die Migration auf die 2023er-Zertifikate ist nur der erste Schritt einer langfristigen Modernisierung der UEFI-Sicherheitsinfrastruktur. Microsoft hat angekündigt, künftig kürzere Zertifikatslebenszyklen einzuplanen – 10 statt 15 Jahre – und die Update-Mechanismen zu vereinfachen. Gleichzeitig arbeitet die Industrie an UEFI-Spezifikationen, die OEM-unabhängige Zertifikatsaktualisierungen ermöglichen.

Für IT-Abteilungen bedeutet das: Firmware-Management und Secure Boot-Pflege werden zu regulären Bestandteilen des Patch-Management-Prozesses. Wer jetzt die Strukturen und Prozesse aufbaut, ist auch für künftige Zertifikatsmigrationen gewappnet – ohne Krisenmanagement am Montagmorgen.

Wenn Sie Unterstützung bei der Planung und Umsetzung der Secure Boot-Migration oder bei der Etablierung eines strukturierten Firmware-Management-Prozesses benötigen, sprechen Sie uns an. Unser Team unterstützt Sie bei Informationssicherheit und IT-Infrastruktur. Nehmen Sie Kontakt auf – wir analysieren gemeinsam mit Ihnen den Status Ihrer Geräteflotte und erstellen einen praxistauglichen Migrationsplan.