Es ist Mittwochmorgen, der 8. Mai 2026, kurz nach acht Uhr. Stefan Brenner, IT-Leiter eines mittelstaendischen Maschinenbauers mit 380 Mitarbeitern in Schwaben, steht in seinem Serverraum vor einem ausgedruckten DIN-A3-Plakat. Darauf hat er mit rotem Stift ein einziges Datum gross hinterlegt: 26. Juni 2026. Daneben das Wort "Boot". Eine Woche zuvor hatte er auf einer regionalen IT-Leiter-Konferenz erstmals von einer Frist gehoert, die ihm seitdem nicht mehr aus dem Kopf geht. Es geht nicht um NIS2, nicht um den AI Act, nicht um eine neue Schwachstelle. Es geht um ein Zertifikat, das in seiner UEFI-Firmware sitzt – und das Microsoft Ende Juni nicht mehr verlaengern wird.

Brenner ist nicht allein. Hunderttausende deutsche Mittelstaendler werden in den kommenden Wochen mit derselben Frage konfrontiert sein: Was passiert eigentlich, wenn das Microsoft-Secure-Boot-Zertifikat 2011 ausser Dienst geht? Die Antwort ist, je nach Sichtweise, beunruhigend einfach oder beunruhigend kompliziert. Einfach: Geraete, die bis dahin nicht auf das 2023er-Zertifikat umgestellt sind, werden nach dem Stichtag keine Boot-Manager-Updates mehr erhalten und im Herbst auch keine Sicherheits-Patches mehr fuer den Early-Boot-Prozess. Kompliziert: Der Migrationsweg unterscheidet sich zwischen Client-PCs, Servern, Edge-Geraeten und Branch-Office-Hardware – und genau hier wird der Mittelstand auf dem falschen Fuss erwischt.

Was Secure Boot eigentlich ist – und warum 2011 ploetzlich ein Problem wird

Secure Boot ist eine Funktion der UEFI-Firmware, die seit Windows 8 zum Standard-Sicherheitsmodell von Microsoft gehoert. Vereinfacht gesagt sorgt Secure Boot dafuer, dass nur signierte Boot-Komponenten geladen werden. Die Vertrauenskette beginnt bei einer sogenannten Platform Key (PK) im Firmware-Speicher des Mainboards und reicht ueber die Key Exchange Keys (KEK) bis zu den eigentlichen Signaturzertifikaten in den Datenbanken db (allowed) und dbx (revoked).

Der Knackpunkt: Die meisten heute eingesetzten Windows-PCs, Server, IoT-Geraete und Industrie-PCs vertrauen auf Microsoft-Zertifikate, die 2011 ausgestellt wurden. Konkret sind das die Microsoft Corporation KEK CA 2011, die Microsoft Windows Production PCA 2011 und die Microsoft UEFI CA 2011. Mit einer typischen Lebensdauer von 15 Jahren laufen diese Zertifikate – wie X.509-Zertifikate eben so sind – nach Ablauf der Gueltigkeit aus.

Microsoft hat als Nachfolger drei neue Zertifikate vorbereitet, die seit 2023 verfuegbar sind und die Lebensdauer um weitere 15 bis 18 Jahre verlaengern: die Microsoft Corporation KEK CA 2023, die Windows UEFI CA 2023 und die Microsoft UEFI CA 2023. Das Problem ist nur: Die neuen Zertifikate muessen vor Ablauf der alten in jede einzelne Firmware geschrieben werden. Ohne diesen Eintrag akzeptiert das Geraet nach dem 26. Juni 2026 keine neu signierten Boot-Komponenten mehr.

Was am 26. Juni 2026 wirklich passiert

Microsoft hat den Ablaufplan in mehreren Etappen kommuniziert. Die wichtigsten Daten fuer den Mittelstand:

  • 26. Juni 2026: Das Microsoft Corporation KEK CA 2011-Zertifikat laeuft ab. Geraete ohne 2023er-KEK koennen ab diesem Tag keine neuen db- oder dbx-Updates mehr empfangen.
  • Oktober 2026: Die Microsoft Windows Production PCA 2011 laeuft ab. Geraete ohne den entsprechenden 2023er-Nachfolger erhalten keine signierten Updates fuer den Windows Boot Manager mehr.
  • Herbst 2026: Microsoft stellt die Signatur neuer Boot-Komponenten vollstaendig auf die 2023er-Schluessel um. Drittanbieter-Software, die nicht mit den neuen Schluesseln gegengezeichnet ist, wird auf nicht-aktualisierten Systemen nicht mehr starten.

Im Klartext bedeutet das: Wer am 27. Juni 2026 mit einem nicht-aktualisierten Geraet arbeitet, hat ein System, das in der Sache funktioniert – das aber bei der naechsten neuen Boot-Schwachstelle keinen Patch mehr akzeptiert. Microsoft hat in den vergangenen drei Jahren mehrere Boot-Manager-Schwachstellen gepatcht, darunter BlackLotus (CVE-2023-24932), BootHole (CVE-2020-10713) und HVCI Bypass-Klassen, die ueber Secure-Boot-Signaturen umgangen werden konnten. Der Trend zeigt klar nach oben: Bootkit-Angriffe sind 2025 und 2026 der bevorzugte Zugriffsvektor staatlich gesponserter Akteure auf Endpoints geworden, weil sie persistent unterhalb des Betriebssystems wirken.

Warum der Mai-Patch-Tuesday die letzte komfortable Welle ist

Der 12. Mai 2026 ist nicht nur ein normaler Patch-Tuesday. Er ist der letzte planmaessige Update-Termin vor dem Zertifikatsablauf, der in einem fuer den Mittelstand komfortablen Zeitfenster liegt. Microsoft hat in den vergangenen Monaten die 2023er-Zertifikate ueber sogenannte Controlled Feature Rollout (CFR) auf Client-PCs ausgespielt – allerdings nur auf aktiv genutzten Geraeten und mit aktivierter Telemetrie.

In der Praxis bedeutet das: Ein Buero-PC, der jeden Tag bootet und an Windows Update angeschlossen ist, hat die neuen Zertifikate hoechstwahrscheinlich bereits installiert. Ein Reserve-Notebook im Schrank, ein Servicegeraet eines Aussendienstmitarbeiters auf Elternzeit oder eine Industrie-Workstation in einer Schweiss-Strasse, die monatlich nur einmal hochgefahren wird – die haben sie nicht. Und dann sind da noch die Server.

Genau hier wird die Geschichte unangenehm. Auf Windows Server rollt Microsoft die 2023er-Zertifikate nicht automatisch ueber CFR aus. IT-Administratoren muessen die neuen Schluessel manuell aktivieren – ueber Registry-Eintraege oder ueber das von Microsoft bereitgestellte Servicing Stack Update (SSU). Der Grund ist nachvollziehbar: Im Server-Umfeld kann ein falsch ausgerolltes Zertifikat eine ganze Produktionsumgebung zum Stillstand bringen, deshalb will Microsoft hier kein automatisches Eingreifen riskieren. Fuer den Mittelstand bedeutet das aber zusaetzlichen Aufwand – und einen weiteren Punkt auf einer ohnehin ueberlasteten To-do-Liste.

User Story: Stefan Brenner und der Sommer-Sprint

Zurueck zu Stefan Brenner, dem IT-Leiter aus Schwaben. Sein Unternehmen, ein Hersteller von Sondermaschinen, betreibt eine bunt gemischte IT-Landschaft: 220 Windows-11-Clients, 24 Windows-Server (16 Hyper-V-Hosts und 8 Linux-Gaeste, plus mehrere Standalone-File- und Domain-Controller), zwei Domain Controller, ein Exchange-Server-on-Prem, der mittelfristig in die Cloud migrieren soll, und – das oft vergessene Stiefkind – rund 60 Industrie-PCs in der Fertigung, viele davon Windows 10 IoT, einige davon noch Windows 7 Embedded auf abgekuendigten Steuerungen. Dazu kommen Notebooks von 38 Aussendienstmitarbeitern, von denen drei in Elternzeit sind und ihr Geraet seit Monaten nicht eingeschaltet haben.

Brenners erste Aktion am Morgen des 8. Mai: Er oeffnet PowerShell ISE auf seinem Admin-Notebook und fuehrt das Skript aus, das Microsoft fuer die Zertifikats-Inventur empfiehlt:

[ExperimentalFeatures]::SetSecureBootCertStatus()
Get-WinEvent -LogName Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin |
  Where-Object { $_.Id -in 1037, 1795, 1796 } |
  Format-Table TimeCreated, Id, Message -Wrap

Auf seinem Notebook sieht er, dass das 2023er-Zertifikat seit Februar installiert ist. Er atmet kurz auf – und schickt das Skript danach via Microsoft Endpoint Configuration Manager als Inventory-Job an alle 220 Clients. Das Ergebnis 90 Minuten spaeter: 188 Geraete sind aktualisiert. 32 nicht. Die meisten davon sind Reserve-Hardware oder Notebooks von Mitarbeitern, die Home Office machen und Updates haeufig pausieren. Brenner trifft Entscheidung Nummer eins des Tages: Alle 32 Geraete werden bis zum 1. Juni in der zentralen Werkstatt physisch eingesammelt, manuell aktualisiert und neu ausgegeben.

Schwieriger wird es bei den Servern. Auf den 24 Hosts und VMs ist – wie erwartet – noch kein 2023er-Zertifikat installiert. Brenner muss hier eine Reihenfolge planen: zuerst die Domain Controller (paarweise, einer nach dem anderen), dann die Hyper-V-Hosts, am Ende die File- und Print-Server. Fuer jeden einzelnen Server gilt: Zertifikat manuell ueber die Microsoft-Anleitung einspielen, danach Test-Reboot in einem Wartungsfenster, danach Verifikation, dass der Bootloader funktioniert. Auf den Hyper-V-Hosts will er die Updates an einem Wochenende ausrollen, an dem er die VMs auf den jeweils anderen Host live-migrieren kann. Insgesamt rechnet er mit drei Wartungsfenstern bis Mitte Juni.

Die Industrie-PCs sind das eigentliche Sorgenkind. Brenner ruft seinen Maschinenlieferanten an und stellt fest: Die Steuerungssoftware fuer die aelteren Sondermaschinen ist nur fuer das 2011er-Zertifikat zertifiziert. Ein Update auf das 2023er-Zertifikat kann theoretisch funktionieren, ist vom Hersteller aber nicht freigegeben. Konsequenz: Brenner und sein Maschinenpartner einigen sich darauf, dass die Industrie-PCs in der Fertigung von der Aussenwelt netzwerkseitig isoliert werden. Sie erhalten kein Microsoft-Update mehr, dafuer auch keinen Internet-Zugriff – und werden bei der naechsten Generation der Maschinen komplett ausgetauscht. Das ist eine pragmatische Entscheidung, die in vielen mittelstaendischen Fertigungsbetrieben so oder aehnlich getroffen werden wird.

Bleiben die drei Notebooks der Mitarbeitenden in Elternzeit. Brenner laesst sich von der Personalabteilung die Adressen geben, fragt schriftlich, ob er die Geraete fuer eine Aktualisierung kurzzeitig einsammeln darf, und vereinbart bei zwei der drei Mitarbeiter Abholtermine. Das dritte Geraet bleibt unsynchronisiert – der Mitarbeiter kommt erst im August aus der Elternzeit zurueck, dann wird das Notebook neu aufgesetzt.

Am Ende seines Mai-Sprints hat Brenner einen klaren Plan: 1. Inventur abgeschlossen, 2. Client-Update bis 1. Juni, 3. Server-Update in drei Wartungsfenstern bis 15. Juni, 4. Industrie-PCs isoliert, 5. drei Sonderfaelle dokumentiert. Was er ausserdem in seine Mai-Status-Mail an die Geschaeftsfuehrung schreibt: "Wir werden den 26. Juni 2026 ohne Boot-Stillstand ueberstehen. Aber wir hatten Glueck, dass wir die Frist nicht erst Mitte Juni entdeckt haben."

Wo der Mittelstand typischerweise stolpert

Brenners Fall ist das Bilderbuch-Szenario. In der Praxis sehen wir bei pleXtec-Kunden mehrere wiederkehrende Stolperstellen, die bei der Migration regelmaessig zu Problemen fuehren:

  • BIOS/UEFI ohne genug Speicherplatz fuer neue Zertifikate. Vor allem aeltere Industrie-Mainboards der Jahre 2014 bis 2018 haben in der Firmware nur Platz fuer wenige Zertifikate. Der Versuch, ein 2023er-Zertifikat einzuspielen, scheitert mit Fehlermeldungen wie EFI_OUT_OF_RESOURCES. Loesung: Ein Firmware-Update vom Mainboard-Hersteller einspielen – das raeumt die NV-RAM-Bereiche typischerweise auf.
  • Custom-Secure-Boot-Konfigurationen. Wer aus Compliance-Gruenden eigene Zertifikate in die db eingespielt hat (zum Beispiel fuer interne Boot-Tools), muss diese Konfiguration nach der Microsoft-Aktualisierung erneut anpassen, ohne die Microsoft-Zertifikate zu ueberschreiben.
  • Linux-Dual-Boot-Systeme. Linux-Distributionen, die ueber Microsoft-Drittanbieter-Zertifikate (Shim) booten, brauchen ebenfalls aktualisierte Shim-Versionen, die mit dem neuen Microsoft UEFI CA 2023 signiert sind. Aelter signierte Bootloader sind nach dem Stichtag nicht mehr lauffaehig, sobald Microsoft die alten db-Eintraege im Rahmen einer regulaeren Revocation-Welle herausnimmt.
  • Hardware-Geraete ohne UEFI-Update-Pfad. Manche Industrie-PCs, NAS-Geraete und Edge-Boxen haben keinen Update-Pfad fuer ihre UEFI-Firmware – haeufig, weil der Hersteller das Geraet abgekuendigt hat. Diese Geraete sind nach dem Sommer 2026 effektiv "frozen": funktional weiter nutzbar, aber ohne Aussicht auf Boot-Sicherheits-Updates.
  • Cloud-VMs in Hybrid-Setups. Wer Azure-VMs oder hybride Setups mit Trusted Launch betreibt, muss die Trusted Launch-Konfiguration ebenfalls auf die neuen Zertifikate aktualisieren. Das wird haeufig vergessen, weil "Cloud" in der Wahrnehmung vieler IT-Teams als "Microsoft macht das schon".

Sechs-Punkte-Plan fuer die naechsten 48 Tage

Wenn Sie heute, am 9. Mai 2026, mit der Migration starten, haben Sie genau 48 Tage bis zum Ablauf der ersten Zertifikate. Das ist machbar – aber nicht mit der Methode "irgendwann mache ich das mal". Hier ein Sechs-Punkte-Plan, den wir bei pleXtec mit unseren Kunden in den vergangenen Wochen erprobt haben:

  1. Inventur (Tag 1 bis 5): Erfassen Sie alle Geraete mit UEFI-Boot in einer Liste – Clients, Server, Industrie-PCs, Notebooks, Edge-Hardware. Notieren Sie pro Geraet: Hersteller, Modell, OS, BIOS-Version, letztes Patch-Datum. Nutzen Sie dafuer Inventory-Tools wie Microsoft Endpoint Configuration Manager, Lansweeper oder PRTG.
  2. Risiko-Klassifizierung (Tag 6 bis 10): Klassifizieren Sie jedes Geraet in eine von drei Kategorien: aktualisierbar via Windows Update, aktualisierbar mit manuellem Eingriff, nicht aktualisierbar. Letztere brauchen einen Compensation-Plan – Netzwerk-Isolation, Endgeraete-Tausch oder Risiko-Akzeptanz mit dokumentierter Geschaeftsfuehrungs-Freigabe.
  3. Server-Sprint (Tag 11 bis 30): Aktualisieren Sie alle Windows-Server in geplanten Wartungsfenstern. Beginnen Sie mit weniger kritischen Systemen (Test-, Build-, Print-Server), arbeiten Sie sich an die Kern-Infrastruktur (DCs, Hypervisoren, File-Server) hoch. Fuehren Sie nach jedem Update einen Test-Reboot durch und dokumentieren Sie das Ergebnis.
  4. Client-Welle (Tag 11 bis 35, parallel): Fuer Clients reicht in der Regel die automatische CFR-Verteilung, falls Telemetrie und Update-Strom aktiv sind. Pruefen Sie via Endpoint-Inventur taeglich, welche Clients noch fehlen, und greifen Sie bei Geraeten in Reserve oder bei Mitarbeitenden in Abwesenheit aktiv ein.
  5. Sonderfaelle (Tag 20 bis 45): Industrie-PCs, IoT-Hardware, Edge-Boxen. Fuer jedes nicht aktualisierbare Geraet brauchen Sie eine schriftliche Begruendung, eine Kompensationsmassnahme und ein Eskalationsdatum, bis zu dem das Geraet entweder ersetzt oder formal abgekuendigt sein muss.
  6. Verifikation und Dokumentation (Tag 40 bis 48): Vor dem 26. Juni laesst sich der Status des Secure-Boot-Zertifikats unter Windows einfach pruefen: Im Windows-Sicherheitscenter unter "Geraetesicherheit" zeigt Microsoft seit dem April-Update den Status an. Dokumentieren Sie pro Geraet einen Screenshot oder einen Eintrag in Ihrem CMDB.

Compliance-Implikationen: NIS2, ISO 27001 und die Audit-Realitaet

Was viele IT-Verantwortliche unterschaetzen: Der Secure-Boot-Zertifikatsablauf hat direkte Implikationen fuer aktuelle Compliance-Frameworks. Im Rahmen von NIS2 sind betroffene Unternehmen verpflichtet, ihre Patch-Faehigkeit ueber den gesamten Geraete-Lebenszyklus aufrechtzuerhalten. Ein Geraet, das nach dem 26. Juni 2026 keine Boot-Manager-Updates mehr akzeptiert, faellt aus dieser Faehigkeit heraus – und das ist auditrelevant.

Auch ISO 27001 in der 2022er-Fassung adressiert das Thema in den Kontrollen A.8.7 (Schutz vor Schadsoftware) und A.8.9 (Konfigurationsmanagement). Wer ein Audit nach Sommer 2026 erfolgreich bestehen will, muss zeigen koennen, dass seine UEFI-Konfiguration aktuell und mit gueltigen Zertifikaten versehen ist. Auditoren werden mit hoher Wahrscheinlichkeit explizit nach dem Status der 2023er-Microsoft-Zertifikate fragen – und Antworten in der Form "wir wussten nichts davon" werden nicht akzeptiert werden.

Fuer Unternehmen, die in regulierten Sektoren arbeiten (Finanzdienstleister unter DORA, KRITIS-Betreiber unter BSIG, pharmazeutische Hersteller unter GxP), kommt eine zusaetzliche Schicht hinzu: Aenderungen an Boot-Konfigurationen sind in vielen Faellen genehmigungspflichtige Change-Requests, die Validierungsdokumentation erfordern. Wer hier am 24. Juni in Panik ueber das Zertifikat aktualisieren will, scheitert an den eigenen QM-Prozessen.

Ein Blick nach vorn: Quantum-Resistant Bootloader

Der Zertifikatswechsel 2026 ist mehr als eine technische Routine – er ist die Vorstufe fuer eine groessere Migration, die Microsoft schon jetzt vorbereitet: Die Post-Quantum-Cryptography-Migration im Boot-Pfad. Die 2023er-Zertifikate nutzen weiterhin RSA-4096 und ECDSA-P384, also klassische asymmetrische Verfahren. Microsoft hat in mehreren Forschungspublikationen angedeutet, dass die naechste Generation der Boot-Zertifikate – die voraussichtlich ab 2030 verfuegbar sein werden – auf Hybrid-Verfahren mit ML-DSA (frueher: Dilithium) und SLH-DSA (frueher: SPHINCS+) setzen wird.

Was bedeutet das fuer den Mittelstand? Im Rahmen der jetzigen Aktualisierung sollten Sie pruefen, ob Ihre UEFI-Firmware grundsaetzlich Crypto-Agilitaet unterstuetzt – also die Faehigkeit, ohne komplettes Firmware-Update neue kryptographische Algorithmen zu akzeptieren. Geraete mit dieser Faehigkeit werden den naechsten Zertifikatswechsel deutlich entspannter durchstehen. Geraete ohne diese Faehigkeit muessen 2030 ein zweites Mal getauscht werden – ein Argument, das in jeder Hardware-Beschaffung der naechsten zwei Jahre eine Rolle spielen sollte.

Praxistipp: Drei Befehle, die Sie heute laufen lassen sollten

Wenn Sie diese Zeilen lesen und sich fragen, wo Sie ueberhaupt anfangen sollen, hier sind drei PowerShell-Schnipsel, mit denen Sie in den naechsten 30 Minuten einen ersten Eindruck von Ihrer Lage bekommen:

1. Pruefen, ob auf einem Windows-Client das 2023er-KEK-Zertifikat installiert ist:

$kek = Get-SecureBootUEFI -Name KEK
$kek.Bytes | ForEach-Object { [BitConverter]::ToString($_) -replace "-", "" } |
  Select-String "MicrosoftCorporationKEKCA2023"

2. Aktivieren des automatischen Rollouts auf Windows Server (registry-basiert; vorher Backup einer beliebigen RegSicherung anlegen):

New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Servicing\OneSettings" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Servicing\OneSettings" `
  -Name "Microsoft-Windows-SecureBoot-OptIn" -Value 1

3. Inventarisieren ueber alle Geraete einer Domain mit Hilfe von WinRM und einer einfachen Liste:

$computers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
foreach ($c in $computers) {
  Invoke-Command -ComputerName $c -ScriptBlock {
    $kek = (Get-SecureBootUEFI -Name KEK).Bytes
    [PSCustomObject]@{
      Computer = $env:COMPUTERNAME
      KEK2023  = ([System.Text.Encoding]::ASCII.GetString($kek) -match "2023")
    }
  } -ErrorAction SilentlyContinue
} | Export-Csv .\secureboot-inventur.csv -NoTypeInformation

Die exportierte CSV-Datei ist Ihr Ausgangspunkt fuer alle weiteren Massnahmen. Wer diese Datei am 9. Mai erstellt, hat eine fundierte Diskussionsgrundlage. Wer sie am 24. Juni erstellt, hat ein Problem.

Schluss: Die unscheinbare Frist mit der grossen Wirkung

Es gibt im Jahr 2026 eine ganze Reihe von Compliance- und Sicherheitsfristen, die deutlich lauter sind als der Secure-Boot-Zertifikatsablauf. Der EU AI Act tritt am 2. August in den Hochrisiko-Vollzug, der Cyber Resilience Act schaltet im September scharf, und NIS2-Audits werden in vielen Bundeslaendern in den naechsten Monaten erstmals operativ durchgefuehrt. Inmitten dieses Compliance-Marathons droht der 26. Juni vergessen zu werden – obwohl er in seiner technischen Konsequenz fuer Hunderttausende von Geraeten eine harte Kante setzt.

Stefan Brenner aus Schwaben hatte Glueck. Er hat Anfang Mai von der Frist erfahren und nutzt den Mai-Patch-Tuesday als Hebel, um seine Flotte rechtzeitig zu aktualisieren. Andere Mittelstaendler werden im Juli oder August feststellen, dass ihre Geraete keine Boot-Updates mehr empfangen – und werden dann unter Zeitdruck Hardware tauschen oder Zertifikate manuell einspielen muessen, was deutlich teurer wird als ein geplanter Sprint.

Wenn Sie unsicher sind, wie Ihr Unternehmen aufgestellt ist, sprechen Sie uns an. Das pleXtec-Team unterstuetzt mittelstaendische Unternehmen bei Migrations-Projektmanagement, bei der Inventarisierung, bei der Erstellung von Compliance-Dokumentationen und bei der konkreten Umsetzung. Mehr ueber unsere Leistungen finden Sie unter /leistungen, und unter /informationssicherheit haben wir die wichtigsten Themen rund um Patch-, Boot- und Endpoint-Sicherheit fuer 2026 zusammengefasst. Im Zweifel gilt: Ein vorausgeplanter Mai ist immer besser als ein hektischer Juli.