Zum Hauptinhalt springen
Sicherheit14 min Lesezeit

Secure Boot 2026: Warum vielen Firmen-PCs bald die Boot-Sicherheitsupdates fehlen

Microsofts Secure-Boot-Zertifikate von 2011 laufen 2026 aus. Was das für Ihre Firmen-PCs bedeutet und wie Sie betroffene Geräte rechtzeitig finden.

B
Berkan Demir
|

Es gibt ein Ablaufdatum in Ihrem Gerätepark, das niemand eingetragen hat. Keine Rechnung, keine Lizenzmail, keine Mahnung. Es steht tief in der Firmware Ihrer Windows-PCs, und es fällt mitten in den Sommer 2026. Am 24. Juni 2026 verfällt das erste der Microsoft-Secure-Boot-Zertifikate, die seit 2011 dafür sorgen, dass Ihre Rechner nur vertrauenswürdigen Startcode laden. Das klingt nach einem Detail für Spezialisten. Es ist eines, das genau deshalb gefährlich ist.

Das Tückische an diesem Datum: Am Tag danach fällt nichts sichtbar aus. Kein PC bleibt schwarz, kein Mitarbeiter ruft beim Support an. Genau diese Lautlosigkeit ist das Problem. Wer wartet, bis es kracht, merkt nie etwas. Er merkt nur Monate später nicht, dass eine Schutzschicht still verschwunden ist. Dieser Beitrag ordnet ein, was da abläuft, wen es trifft und welche Reihenfolge der Schritte Sie vor bösen Überraschungen bewahrt.

Die kurze Antwort zuerst

Microsofts Secure-Boot-Zertifikate aus dem Jahr 2011 laufen 2026 aus und werden durch eine neue Generation von 2023 abgelöst. Geräte, die die neuen Zertifikate nicht erhalten, starten zwar weiter, bekommen aber keine künftigen Sicherheitsupdates mehr für den frühen Bootprozess. Microsoft verteilt die Ablösung automatisch auf einem erheblichen Teil der Geräte, aber eben nicht auf allen. Ältere, nicht verwaltete und Windows-10-Geräte fallen oft durch das Raster und brauchen manuelles Eingreifen, bei älterer Firmware sogar zuerst ein BIOS-Update.

Was Secure Boot überhaupt schützt und warum ein Zertifikat ablaufen kann

Secure Boot ist die Türsteherfunktion Ihres Rechners, bevor Windows überhaupt geladen ist. Die Firmware (UEFI, der Nachfolger des alten BIOS) prüft beim Einschalten, ob der Startcode eine gültige digitale Signatur trägt. Nur signierter, vertrauenswürdiger Code darf laden. Das soll genau die Angriffe abwehren, die sich unterhalb von Windows einnisten, sogenannte Bootkits. Diese Schädlinge sind besonders heikel, weil sie aktiv werden, bevor Virenscanner oder Betriebssystem überhaupt wach sind. Wer den Start kontrolliert, kontrolliert alles danach.

Damit dieses Vertrauensmodell funktioniert, braucht es Vertrauensanker: digitale Zertifikate, die festlegen, welche Signaturen gültig sind. Microsoft hat diese Anker 2011 ausgestellt. Und wie jedes Zertifikat haben auch diese ein Verfallsdatum. Das ist kein Versäumnis, sondern Absicht. Zeitlich begrenzte Zertifikate sind ein Sicherheitsmerkmal, kein Fehler. Nur fällt der Zeitpunkt jetzt eben auf 2026, fünfzehn Jahre später, und trifft einen Gerätepark, in dem viele Rechner älter sind, als ihren Besitzern lieb ist.

Die neue Generation ist bereits da. Microsoft hat seit Mai 2026 die 2023er-Zertifikate im Umlauf, darunter das Microsoft Corporation KEK 2K CA 2023, das Windows UEFI CA 2023 und das Microsoft UEFI CA 2023. Sie lösen die 2011er ab. Viele Geräte, die seit 2024 ausgeliefert wurden, tragen die neuen Zertifikate bereits ab Werk. Das Problem liegt nicht bei den neuen Rechnern. Es liegt bei dem Bestand, der schon länger im Betrieb ist.

Es lohnt sich, kurz auseinanderzuhalten, was da eigentlich abgelöst wird, denn nicht jedes der Zertifikate spielt dieselbe Rolle. Vereinfacht gibt es drei Ebenen. Der sogenannte KEK (Key Exchange Key) ist der übergeordnete Schlüssel, der überhaupt erst erlaubt, die darunterliegenden Datenbanken zu aktualisieren. Die DB ist die Liste der erlaubten Signaturen, die DBX die Liste der gesperrten. Wenn der KEK abgelaufen ist, fällt nicht der Start aus, sondern die Fähigkeit, DB und DBX künftig zu pflegen. Das ist der entscheidende Punkt, der in der öffentlichen Diskussion oft untergeht: Das Verfallsdatum trifft nicht die Funktion von heute, sondern die Wartbarkeit von morgen. Ein abgelaufener KEK ist wie ein Schlüssel zum Sicherungskasten, der nicht mehr passt. Das Licht brennt weiter. Aber Sie können keine Sicherung mehr tauschen.

Genau deshalb staffeln sich auch die drei Ablaufdaten so unterschiedlich. Das KEK CA 2011 verfällt zuerst, am 24. Juni 2026, weil ohne erneuerten Schlüssel keine weiteren Datenbank-Updates mehr möglich sind. Das Microsoft UEFI CA 2011, das Signaturen für Drittanbieter-Komponenten abdeckt, folgt am 27. Juni 2026. Und das Microsoft Windows Production PCA 2011, das den Windows-Bootloader selbst signiert, läuft erst am 19. Oktober 2026 aus. Diese gestaffelte Logik ist kein Zufall, sondern soll den Übergang abfedern. Für Sie heißt das praktisch: Es gibt nicht den einen Stichtag, an dem alles kippt, sondern ein Fenster von Juni bis Oktober 2026, in dem die alten Anker nacheinander ihre Gültigkeit verlieren.

Hinweis

Laut Microsoft Support verfällt das Microsoft Corporation KEK CA 2011 am 24. Juni 2026, das Microsoft UEFI CA 2011 am 27. Juni 2026 und das Microsoft Windows Production PCA 2011 am 19. Oktober 2026. Die Ablösung erfolgt durch die 2023er-Generation der Zertifikate.

Was am Tag nach dem Ablauf wirklich passiert und was nicht

Hier liegt das größte Missverständnis, und ich räume es gleich aus. Mit Ablauf der Zertifikate wird kein PC unbrauchbar. Laut Microsoft startet das Gerät weiterhin normal. Auch reguläre Windows-Updates installieren sich weiter. Wer also befürchtet, dass am 25. Juni 2026 die Belegschaft vor schwarzen Bildschirmen sitzt, kann durchatmen. Dieses Szenario tritt nicht ein.

Was ausbleibt, ist subtiler und genau deshalb riskanter. Geräte ohne aktualisierte Zertifikate erhalten keine neuen Schutzmaßnahmen mehr für den frühen Bootprozess. Konkret nennt Microsoft Updates für den Windows Boot Manager, für die Secure-Boot-Datenbanken, für Sperrlisten und für Abwehrmaßnahmen gegen neu entdeckte Boot-Level-Schwachstellen. Im Klartext: Findet jemand morgen eine neue Bootkit-Lücke, können verwundbare Geräte diese Klasse von Angriffen nicht mehr per Update aussperren. Die Tür bleibt offen, und niemand merkt es.

Diese Sperrlisten sind der Kern. Im Fachjargon heißen sie DBX, eine Datenbank widerrufener Signaturen. Wird ein Bootkit oder ein verwundbarer Bootloader bekannt, trägt Microsoft dessen Signatur in die DBX ein, und Secure Boot verweigert künftig den Start. Ohne gültigen Vertrauensanker kann ein Gerät aber keine künftigen DBX-Einträge mehr aufnehmen. Der Sicherheitsforscher von Eclypsium bringt die Konsequenz auf den Punkt: Geräte mit abgelaufenem Schlüssel können keine neuen DBX-Einträge mehr annehmen, womit diese Schwachstellenklasse auf solchen Systemen dauerhaft ausnutzbar bleibt. Dauerhaft ist hier das entscheidende Wort. Es geht nicht um ein Update, das man nachholt. Es geht um eine Tür, die zubleibt.

Achtung

Das eigentliche Risiko ist nicht der Ausfall, sondern die Stille. Ein Gerät ohne aktualisierte Zertifikate läuft scheinbar unverändert weiter. Erst wenn die nächste Boot-Level-Schwachstelle bekannt wird, zeigt sich, dass die Schutzschicht fehlt. Bis dahin gibt es kein Warnsignal. Glück ist keine dokumentierte Risikomanagementmaßnahme.

Warum Microsofts automatischer Rollout nicht alle Geräte rettet

Die gute Nachricht zuerst: Sie müssen das nicht komplett von Hand erledigen. Microsoft übernimmt den Aktualisierungsprozess für die neuen Zertifikate auf einem erheblichen Teil der Windows-Geräte selbst, in einem verwalteten, gestaffelten Rollout. Die Zertifikate werden über die kumulativen Updates verteilt. Wer einen relativ aktuellen, gut verwalteten Windows-11-Rechner mit moderner Firmware betreibt, wird vermutlich gar nichts davon mitbekommen, und das ist beabsichtigt.

Die schlechte Nachricht ist die Formulierung erheblicher Teil. Das ist nicht alle. Und genau in dieser Lücke leben die Geräte, über die ich mir bei KMU am meisten Gedanken mache. In meinen Bestandsaufnahmen sehe ich bei Betrieben dieser Größe immer wieder dasselbe Muster: Es gibt nicht den einen, sauberen Gerätepark. Es gibt den Empfangsrechner, der seit sieben Jahren läuft. Den Maschinen-PC in der Werkstatt, den niemand anfasst, weil er läuft. Den alten Server im Abstellraum. Diese Geräte haben oft wenig Telemetrie, sind nicht zentral verwaltet und damit genau die, die der automatische Rollout schlechter erreicht.

Dazu kommt ein zweites Nadelöhr, das viele unterschätzen: die Firmware. Bevor Windows die neuen Zertifikate überhaupt schreiben kann, muss bei vielen älteren Modellen zuerst der Gerätehersteller ein Firmware-Update liefern. Microsoft nennt die Firmware-Aktualisierung ausdrücklich als Schritt vor dem Zertifikatsupdate, weil sie die Kompatibilität verbessert und Update-Fehler reduziert. Und hier schließt sich die Falle: Bei PCs, die deutlich älter als fünf bis sechs Jahre sind, hat der Hersteller die Firmware-Pflege häufig längst eingestellt. Wie es ein Bericht von XDA Developers nüchtern formuliert: Bei PCs, die älter als fünf oder sechs Jahre sind, hat der Hersteller die Geräte oft hinter sich gelassen, und es bleibt womöglich kein Weg nach vorn. Ohne passende Firmware kann das Zertifikatsupdate schlicht scheitern.

Hinweis

Eine Zahl, die durch die Presse geht, ist die Schätzung, bis zu jeder dritte Firmen-PC könnte betroffen sein. Diese Größenordnung ist eine grobe Schätzung, keine von Microsoft oder unabhängigen Messungen belegte Quote. Microsoft selbst nennt keine Zahl der nicht erreichten Geräte. Belegt ist die Aussage dahinter: Ältere, wenig verwaltete und Windows-10-Geräte erhalten das Update oft nur manuell. Verlassen Sie sich nicht auf eine Prozentzahl, sondern auf Ihre eigene Inventur.

Der gefährlichste Sonderfall: Windows 10 und die Update-Sackgasse

Es gibt eine Geräteklasse, bei der sich zwei Ablaufdaten unglücklich überlagern. Der Support für Windows 10 endete im Oktober 2025. Ohne erweiterte Sicherheitsupdates (ESU, ein kostenpflichtiges Verlängerungsprogramm) erhalten diese Rechner seither gar keine Updates mehr. Und kein Update bedeutet auch keine neuen Secure-Boot-Zertifikate. Diese Geräte sitzen in einer doppelten Sackgasse: Sie bekommen weder die regulären Sicherheitspatches noch die Zertifikatsablösung.

Das ist genau die Sorte Gerät, die in einer Bestandsaufnahme gern übersehen wird, weil sie funktioniert und niemandem auffällt. In meinen Audits ist der Windows-10-Rechner, der noch eine Spezialsoftware oder eine alte Maschine bedient, fast schon ein Klassiker. Er läuft. Er stört nicht. Und er ist 2026 gleich an mehreren Fronten ungeschützt. Wer seinen Gerätepark erfasst, sollte diese Maschinen zuerst markieren, nicht zuletzt.

Was das auf Geschäftsführer-Ebene bedeutet, jenseits der Technik

Bis hierher klingt das nach einer Aufgabe für die IT. Ist es auch. Aber die Frage, die ein Geschäftsführer beantworten können muss, ist eine andere: Was kostet mich das, wenn ich es ignoriere, und was, wenn ich es übertreibe? Beide Fehler sind real. Wer in Panik den gesamten Gerätepark austauscht, verbrennt Geld für Hardware, die noch jahrelang taugt. Wer gar nichts tut, trägt ein Risiko, das er im Ernstfall nicht erklären kann. Der richtige Weg liegt dazwischen, und er heißt nicht Aktionismus, sondern Inventur.

Der Kern für die Geschäftsleitung ist die Frage der Nachweisbarkeit. Ein Gerät, das gegen neue Boot-Level-Schwachstellen ungeschützt bleibt, ist nicht nur technisch verwundbar. Es ist im Schadensfall ein Punkt, an dem die unangenehme Frage auftaucht: Wussten Sie davon, und was haben Sie getan? In meinen Bestandsaufnahmen ist genau das der Unterschied zwischen einem beherrschbaren Vorfall und einem haftungsrelevanten. Nicht ob etwas passiert ist, sondern ob das Unternehmen nachweisen kann, dass es den bekannten Stand der Technik kannte und bewusst gehandelt hat. Eine dokumentierte Liste betroffener Geräte mit einer Entscheidung pro Gerät ist genau dieser Nachweis. Eine vergessene Maschine im Werkstattregal ist das Gegenteil.

Übersetzt in die Sprache, in der ein Inhaber denkt: Es geht hier nicht um Secure Boot, es geht um planbare Kosten statt unplanbarer Ausfälle, um einen Haftungsnachweis statt eines blinden Flecks und um Ruhe statt der diffusen Ahnung, dass irgendwo etwas im Argen liegt. Die Technik ist nur der Weg dorthin. Der eigentliche Wert ist, dass Sie am Ende eine Liste haben, auf die Sie zeigen können, statt einer Vermutung, die Sie nachts beschäftigt.

Hinweis

Manche werden sagen, das regelt Microsoft doch automatisch, also kein Thema. Das ist zu viel versprochen. Der automatische Rollout schließt die wichtigste Lücke, aber nicht jede. Er erreicht den gepflegten Bestand zuverlässig und genau die alten, unverwalteten Geräte schlechter, bei denen das Risiko am größten ist. Die Automatik ersetzt nicht die Inventur. Sie macht sie nur kürzer.

Die Stolperfallen beim Umstieg und warum die Reihenfolge über Ausfall entscheidet

Das Zertifikatsupdate ist kein Knopf, den man einfach drückt. Wer es falsch oder zur falschen Zeit einspielt, handelt sich genau die Ausfälle ein, die er vermeiden wollte. Microsoft Learn nennt konkrete Störungsbilder bei älterer Firmware oder fehlerhaft angewendeten Updates: Secure-Boot-Validierungsfehler, BitLocker-Wiederherstellungsabfragen, teils in einer Schleife, hängende Starts und Geräte, die gar nicht mehr booten. Das ist die Liste, die man nicht im Tagesgeschäft erleben will.

Besonders der Punkt BitLocker verdient Aufmerksamkeit. BitLocker ist die Festplattenverschlüsselung von Windows. Ändert sich die Boot-Konfiguration, kann BitLocker einmalig nach dem Wiederherstellungsschlüssel fragen. Haben Sie diesen Schlüssel nicht griffbereit, bleibt das Gerät gesperrt, und zwar genau das Gerät, auf dem die Daten liegen, die Sie brauchen. Das ist kein theoretisches Risiko. Es ist die häufigste Art, wie ein gut gemeintes Update zum halben Tagesausfall wird.

Aus der Liste der Fallstricke ergibt sich eine klare Reihenfolge. Erst messen, dann Firmware, dann erst die Zertifikate, und niemals flächendeckend ohne Pilotgruppe:

  1. Firmware vor Zertifikat: Spielen Sie das OEM-Firmware-Update zuerst ein, weil veraltete Firmware die häufigste Ursache für Validierungsfehler und hängende Starts ist.
  2. Pilotgruppe vor Flächen-Rollout: Testen Sie zuerst an mehreren Gerätemodellen und Firmware-Ständen, weil unterschiedliche Hersteller verschieden reagieren und ein Testlauf den Betriebsausfall verhindert.
  3. BitLocker-Schlüssel bereit vor dem Update: Halten Sie die Wiederherstellungsschlüssel griffbereit, weil das Update eine einmalige BitLocker-Abfrage auslösen kann und ein gesperrtes Gerät sonst stillsteht.
  4. Windows-10-Geräte zuerst markieren: Erfassen Sie diese Maschinen vorrangig, weil sie ohne ESU weder Updates noch die neuen Zertifikate erhalten und damit den größten blinden Fleck bilden.

Tipp

Für die Schnellprüfung an einem einzelnen PC öffnen Sie die Windows-Security-App und gehen auf Gerätesicherheit und dann Sicherer Start. Steht dort, dass Secure Boot aktiv ist und alle erforderlichen Zertifikatsupdates angewendet wurden, ist das Gerät fertig. Meldungen über eine ältere Boot-Vertrauenskonfiguration oder einen nicht unterstützten automatischen Update-Pfad zeigen Handlungsbedarf an.

Wie Sie technisch sauber prüfen, statt zu raten

Für einen einzelnen Rechner reicht der Blick in die Windows-Security-App. Für einen ganzen Gerätepark brauchen Sie etwas Belastbareres. Microsoft beschreibt eine Prüfung per PowerShell-Skript: Man exportiert den Inhalt der Secure-Boot-Datenbank als Datei und prüft, ob das Windows UEFI CA 2023 enthalten ist. Ergänzend lassen sich die Ereignis-IDs 1801 und 1795 sowie der Registrywert mit dem Namen UEFICA2023Status auswerten, dessen Sollwert auf aktualisiert steht. Das ist die Art von Prüfung, die sich auf viele Geräte ausrollen lässt, statt jeden Rechner einzeln zu öffnen.

Den Rollout selbst steuert man in verwalteten Umgebungen über einen Registrywert namens AvailableUpdates im Secureboot-Schlüssel. Microsoft empfiehlt für den vollständigen Rollout den Kombiwert 0x5944, der alle 2023er-Zertifikate in die Datenbank schreibt, das Schlüsselzertifikat aktualisiert und einen neu signierten Boot-Manager einspielt. Ein geplanter Windows-Task mit dem Namen Secure-Boot-Update verarbeitet die Änderung anschließend, er läuft alle zwölf Stunden und lässt sich auch manuell anstoßen. Wer eine Verwaltungslösung wie Microsoft Intune oder Gruppenrichtlinien einsetzt, kann den Wert auch darüber verteilen. Nach dem Neustart prüfen Sie erneut den Status, über die Security-App oder den Datenbank-Export, und behalten bei BitLocker-Geräten den Wiederherstellungsschlüssel in Reichweite.

Diese technische Tiefe ist kein Selbstzweck. Sie ist der Unterschied zwischen einer dokumentierten Aussage und einem Bauchgefühl. Wenn in einem halben Jahr jemand fragt, ob Ihr Gerätepark gegen Boot-Level-Angriffe geschützt ist, wollen Sie eine Liste zeigen können, keine Vermutung äußern.

Die Abwägung: Wann sich der Aufwand lohnt und wann der Austausch

Nicht jedes Gerät verdient denselben Aufwand, und so ehrlich sollte man die Sache angehen. Bei Geräten mit aktueller Firmware und zentraler Verwaltung ist die Antwort einfach: Hier erledigt der automatische Rollout das Meiste, Ihre Aufgabe beschränkt sich auf das Verifizieren. Der Aufwand ist gering, der Nutzen hoch, die Entscheidung trivial. Diese Klasse können Sie schnell abhaken.

Schwieriger wird es in der Mitte: Geräte, die fünf bis sieben Jahre alt sind, aber noch eine gültige Aufgabe haben. Hier stehen sich zwei Wege gegenüber. Der eine ist, das Firmware-Update zu suchen, einzuspielen und die Zertifikate manuell nachzuziehen. Der andere ist der Austausch. Die ehrliche Abwägung lautet: Solange der Hersteller noch Firmware liefert, ist die manuelle Aktualisierung fast immer günstiger als neue Hardware. Findet sich keine aktuelle Firmware mehr, kippt die Rechnung. Dann zahlen Sie Arbeitszeit für einen Versuch, der scheitern kann, und stehen am Ende doch vor dem Austausch. In meinen Audits ist die verlorene Stunde für ein aussichtsloses Firmware-Update teurer als die ehrliche Entscheidung, das Gerät zu ersetzen.

Am klarsten ist die dritte Gruppe, auch wenn sie am unbequemsten ist: Geräte ohne Update-Pfad. Das sind die Maschinen, für die der Hersteller keine Firmware mehr liefert, und die Windows-10-Rechner ohne erweiterte Sicherheitsupdates. Für sie gibt es keine technische Lösung, nur eine geschäftliche Entscheidung. Austauschen, isolieren oder das erhöhte Restrisiko bewusst dokumentieren. Diese drei Optionen sind nicht gleichwertig, aber sie sind alle besser als die vierte, die in der Praxis am häufigsten gewählt wird: nichts entscheiden und hoffen, dass es schon gutgeht. Hoffen ist hier keine Strategie, sondern ein aufgeschobenes Problem mit Zinsen.

Mein Fazit

Dieses Ablaufdatum ist kein Notfall, und genau das macht es so leicht zu verschlafen. Nichts blinkt, nichts fällt aus, kein Anwender beschwert sich. Wer abwartet, wird nicht bestraft, jedenfalls nicht sofort. Die Rechnung kommt erst, wenn die nächste Boot-Level-Schwachstelle bekannt wird und ein Teil Ihrer Geräte sie nicht mehr aussperren kann. Bis dahin sieht alles gut aus. Das ist die unangenehmste Form von Risiko: die, die man nicht sieht.

Die gute Nachricht ist, dass die Arbeit überschaubar und planbar ist, solange Sie sie vor dem Sommer 2026 angehen. Auf vielen Geräten erledigt Microsoft die Ablösung selbst. Ihre eigentliche Aufgabe ist nicht, alles von Hand umzustellen, sondern zu wissen, welche Geräte der Automatik durch die Maschen gehen, und für die einen Plan zu haben. Inventur, Firmware zuerst, Pilotgruppe, BitLocker-Schlüssel bereit. In dieser Reihenfolge wird aus einem stillen Risiko eine abgehakte Routineaufgabe.

Und für die Geräte, die keinen Weg nach vorn haben, weil der Hersteller die Firmware aufgegeben hat: Auch das ist eine Entscheidung, die Sie bewusst treffen sollten. Austauschen, isolieren oder das Restrisiko dokumentieren. Was Sie nicht tun sollten, ist, die Frage offenzulassen, bis sie sich von selbst beantwortet.

Geräteliste erstellt: alle Windows-PCs und -Server mit Secure-Boot-Status erfasst, Geräte älter als fünf Jahre und Windows-10-Geräte markiert.
Pro Stichprobe in der Windows-Security-App unter Sicherer Start geprüft, ob alle Zertifikatsupdates angewendet sind.
OEM-Firmware-Stand pro Modell geprüft und fällige BIOS-Updates eingeplant, bevor das Zertifikatsupdate folgt.
BitLocker-Wiederherstellungsschlüssel aller verschlüsselten Geräte an einem sicheren, erreichbaren Ort hinterlegt.
Pilotgruppe aus mehreren Herstellern und Firmware-Ständen definiert und das Zertifikatsupdate dort zuerst getestet.
Verwalteten Rollout vorbereitet, etwa über Registrywert 0x5944, Intune oder Gruppenrichtlinie.