Secure-Boot-Zertifikate laufen ab: Was Admins jetzt prüfen müssen

Am 19. Oktober 2026 läuft das Zertifikat ab, mit dem Microsoft seit 2011 den Windows-Boot-Manager signiert. Zwei andere Secure-Boot-Zertifikate von 2011 sind im Juni bereits abgelaufen, und ob deine Geräte die neuen Nachfolger schon haben, weißt du nur, wenn du nachgesehen hast. Dieser Artikel ist ein Arbeitsplan für Admins und IT-Leiter im Mittelstand: Was passiert wirklich, welche Geräte musst du anfassen, wie rollst du aus, und was legst du im ISMS ab?

Was läuft wann ab, und was passiert wirklich?

Secure Boot ist die UEFI-Funktion, die beim Start nur Software mit gültiger Signatur ausführt. Die Firmware prüft diese Signaturen gegen Zertifikate, die in ihr gespeichert sind: Der Key Exchange Key (KEK) autorisiert Änderungen an den Datenbanken, die Datenbank für erlaubte Signaturen (DB) enthält die vertrauenswürdigen Zertifikate, und die Sperrliste (DBX) enthält verbotene. Seit Windows 8 tragen praktisch alle Windows-Geräte denselben Satz an Microsoft-Zertifikaten von 2011 in KEK und DB.

Microsoft erneuert diesen Satz. Die Daten stammen aus der Microsoft-Support-Seite zum Ablauf der Secure-Boot-Zertifikate (Stand der Seite: Mai 2026):

Die UEFI CA 2011 wird bei der Erneuerung in zwei Zertifikate aufgeteilt. Eines signiert Bootloader von Drittanbietern, das andere deren Option-ROMs, also Firmware-Treiber etwa von Grafik- oder Netzwerkkarten. Der 19. Oktober fällt übrigens auf einen Montag. Wenn du Neustarts einplanst, liegt das Wochenende davor in deinem Zeitfenster.

Was passiert nach dem 19. Oktober?

Weniger, als manche Warnmeldung vermuten lässt, aber mehr, als du ignorieren solltest. Microsoft beschreibt die Folgen so: Geräte, die die 2023er Zertifikate nicht erhalten haben, starten und laufen weiter normal, und die üblichen Windows-Updates werden weiter installiert. Sie können aber keine neuen Sicherheitsmechanismen für den frühen Startprozess mehr bekommen. Dazu zählen Updates für den Windows-Boot-Manager, für die Secure-Boot-Datenbanken, Sperrlisten und Korrekturen für neu entdeckte Schwachstellen auf Boot-Ebene. Als Beispiel nennt Microsoft Fixes gegen BitLocker-Umgehungen.

Der Grund: Ein abgelaufenes Zertifikat darf nichts Neues mehr signieren. Der Schutz veraltet deshalb schleichend, mit jeder neu entdeckten Boot-Lücke ein Stück mehr. Das ist die Art von Risiko, die im Schwachstellenmanagement gern durchrutscht: kein Ausfall, keine Fehlermeldung, nur eine wachsende Lücke.

Zwei Dinge solltest du außerdem wissen:

• Der 19. Oktober ist kein harter Stichtag für die Technik. Laut Microsoft-FAQ lassen sich die neuen Zertifikate auch nach dem Ablauf noch einspielen, solange das Gerät bootet und Updates installieren kann. Der Termin ist trotzdem ein guter Anker, weil du bis dahin Pilot, Rollout und Nachweis geschafft haben willst.
• Secure Boot abzuschalten ist keine Lösung. Microsoft rät ausdrücklich davon ab. Ein Gerät ohne Secure Boot bekommt die neuen Zertifikate nicht und ist gegen Bootkits schutzlos.

Wer ist betroffen? Windows, Server, VMs und Linux im Dualboot

Als durchgehendes Beispiel nehmen wir eine Firma mit etwa 110 Mitarbeitenden: 95 Notebooks und Desktops mit Windows 11, 12 Geräte mit Windows 10 und ESU, sechs Windows-Server auf Hyper-V und zwei Entwickler-Notebooks mit Ubuntu im Dualboot. Die Clients verwaltet die IT mit Intune, die Server per Gruppenrichtlinie. Das ist ein typisches Bild im Mittelstand.

Windows 11 und Windows 10

Betroffen ist jedes Gerät mit aktivem Secure Boot, und das sind die meisten Geräte, die seit 2012 gekauft wurden. Bei Windows 11 spielt Microsoft die Zertifikate über Windows Update aus. Es gibt zwei Hilfen, die Microsoft "Assists" nennt. Die erste liefert die neuen Zertifikate über die monatlichen Updates an Gerätegruppen, bei denen Microsoft genug erfolgreiche Updates beobachtet hat (High-Confidence-Buckets). Sie ist standardmäßig aktiv. Die zweite, der Controlled Feature Rollout, erledigt den Wechsel für Geräte, die dafür angemeldet sind und Diagnosedaten senden. Beide sind laut Microsoft-FAQ eine Hilfe, keine Garantie: Verantwortlich für die Zertifikate bleibt der Kunde.

Windows 10 bekommt die Zertifikate nur, solange es unterstützt wird. Der Support endete am 14. Oktober 2025, seitdem gibt es Updates nur mit Extended Security Updates (ESU) oder bei einer LTSC-Version. Nach der Lifecycle-FAQ von Microsoft endet das erste ESU-Jahr für Windows 10 am 13. Oktober 2026. Wenn du Windows 10 weiter betreibst, brauchst du also eine Verlängerung für das zweite Jahr, sonst bleiben diese Geräte nicht nur beim Boot-Schutz, sondern bei allen Updates stehen. In unserem Beispiel sind das die 12 Altgeräte: Prüf zuerst den ESU-Status, bevor du über Zertifikate nachdenkst.

Windows Server und virtuelle Maschinen

Die Microsoft-Dokumentation nennt Windows Server 2012 und 2012 R2 (jeweils mit ESU), 2016, 2019, 2022 und 2025. Bei Servern gibt es zwei Besonderheiten. Erstens zeigt die Windows-Sicherheit auf Servern die neuen Statusanzeigen standardmäßig nicht an, du brauchst also eine zentrale Überwachung. Zweitens laufen viele Server virtualisiert.

Bei virtuellen Maschinen hängt es an der virtuellen Firmware. Microsoft nennt zwei Wege: Der Hersteller der Virtualisierung (Hyper-V, VMware, Azure, AWS und andere) liefert neue virtuelle Firmware mit den 2023er Zertifikaten, das gilt für neu erstellte VMs. Bei langlebigen VMs spielt Windows die Zertifikate wie auf einem physischen Gerät ein, sofern die virtuelle Firmware Secure-Boot-Updates unterstützt. Zwei bekannte Probleme aus der Microsoft-Dokumentation sind für Hyper-V relevant:

• Auf einigen Hyper-V-VMs scheitert das KEK-Update mit Ereignis 1795 und der Meldung "The media is write protected". Die Korrektur steckt in den Updates ab dem 10. März 2026, bei Windows Server 2025 ab dem 14. April 2026. Du musst sie auf Host und Gast einspielen. Aus dem Gast heraus zeigt dir das Ereignis, wo es fehlt: Laut Microsoft meldet 1795, dass der Host das Update noch braucht, 1803, dass der Gast es braucht.
• Bei Azure Trusted Launch (Gen2) kann das KEK-Update ebenfalls mit Ereignis 1795 hängen. Dort ist laut Microsoft zum Stand Juli 2026 keine Kundenaktion nötig, eine Lösung folgt über künftige Updates.

Linux im Dualboot

Auch Linux-Distributionen booten über einen von Microsoft signierten Shim, und der trug bisher die Signatur der UEFI CA 2011. Nach dem Einspielen der Microsoft UEFI CA 2023 in die DB kann die Firmware auch neue Shims prüfen, die mit dem 2023er Zertifikat signiert sind. Bleibt ein Gerät bei der alten DB, bootet das System weiter, bekommt aber keine neuen Shim-Updates und Sperrlisten mehr. Die Distributoren pflegen eigene Hinweise, schau also in die Dokumentation von Ubuntu, Fedora oder deiner Distribution.

Zur Kontrolle gibt Microsoft für Linux-VMs diese Befehle an, die du auch auf Dualboot-Notebooks nutzen kannst. Jeder Befehl muss eine passende Zeile zurückgeben:

mokutil --db | grep "UEFI CA 2023"
mokutil --kek | grep "KEK 2K CA 2023"

Wichtig ist die Reihenfolge: Erst kommen die Zertifikate in die Firmware, danach sind laut Microsoft die Shim-Updates der Distribution unproblematisch. In unserem Beispiel gehen die zwei Entwickler-Notebooks deshalb in die erste Pilotgruppe.

Geräte mit deaktiviertem Secure Boot

Wo Secure Boot ausgeschaltet ist, bekommt die Firmware die neuen Zertifikate nicht, und die Geräte bleiben gegen Bootkits verwundbar. Der Ablauf ändert daran nichts, denn der Schutz bestand vorher auch nicht. Ein deaktiviertes Secure Boot ist trotzdem ein Befund und gehört in dein Inventar.

Status prüfen: Welche Geräte haben noch die alten Zertifikate?

Bevor du ausrollst, brauchst du ein Bild deiner Flotte. Das Inventar ist die Grundlage: Hersteller, Modell, BIOS-Version und -Datum. Wenn du dein IT-Asset-Management gepflegt hast, hast du diese Daten bereits. Wenn nicht, ist das hier der Anlass, sie zu erheben.

Ein einzelnes Gerät prüfen

Auf einem Gerät gibt es drei Wege, vom einfachsten zum genauesten.

Windows-Sicherheit. Unter Start, Einstellungen, Datenschutz und Sicherheit, Windows-Sicherheit, Gerätesicherheit steht im Abschnitt "Sicherer Start" der Status. Seit April 2026 zeigt Windows dort auch den Stand der Zertifikate. Ein grünes Häkchen allein genügt nicht, achte auf den Text "Secure Boot is on and all required certificate updates have been applied" beziehungsweise die deutsche Entsprechung. Gelb steht für eine Empfehlung, etwa wegen einer Firmware-Grenze, Rot für ein Boot-Sicherheitsupdate, das dieses Gerät nicht bekommen kann. Auf verwalteten Windows-Clients und auf Servern sind diese Anzeigen standardmäßig aus. Du schaltest sie über den Registry-Wert HideSecureBootStates mit 0 ein, unter HKLM\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Device security. Für die Flotte brauchst du aber ohnehin eine zentrale Auswertung.

PowerShell. In einer PowerShell mit Administratorrechten prüfst du zuerst, ob Secure Boot überhaupt läuft:

Confirm-SecureBootUEFI

Der Befehl gibt True zurück, wenn Secure Boot an ist. Danach liest du die DB lesbar aus. Der Parameter -Decoded ist mit den monatlichen Updates vom 14. April 2026 dazugekommen:

Get-SecureBootUEFI -Name db -Decoded

In der Ausgabe suchst du nach dem Subject CN=Windows UEFI CA 2023. Steht nur CN=Microsoft Windows Production PCA 2011 in der Liste, ist die Firmware noch auf dem alten Stand. In Microsofts Beispielausgabe siehst du auch die Gültigkeit: Das PCA 2011 ist bis 2026-10-19 gültig, das Windows UEFI CA 2023 bis 2035-06-13. Dasselbe gilt für den KEK: Mit -Name KEK statt -Name db suchst du dort nach Microsoft Corporation KEK 2K CA 2023.

Registry und Ereignisanzeige. Windows protokolliert den Fortschritt unter HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. Der Wert UEFICA2023Status steht auf NotStarted, InProgress oder Updated. Bei einem Fehler steht in UEFICA2023Error ein Code ungleich 0. Im System-Ereignisprotokoll sind zwei Ereignisse wichtig: 1801 ist ein Fehlerereignis und heißt, dass die neuen Zertifikate noch nicht angewendet sind. 1808 ist ein Informationsereignis und bestätigt, dass die Firmware die neuen Zertifikate hat. Für die Statusabfrage nimmst du UEFICA2023Status, nicht WindowsUEFICA2023Capable.

Die ganze Flotte auswerten

Für mehr als eine Handvoll Geräte brauchst du ein Skript, das diese Werte einsammelt. Microsoft stellt dafür ein Beispielskript zur Inventarisierung bereit. Auf Geräten mit den Updates ab dem 12. Mai 2026 liegt es im Ordner %systemroot%\SecureBoot\ExampleRolloutScripts. Es liest Registry-Werte, Hardware-Daten und die Ereignisse 1801 und 1808 aus und gibt das Ergebnis als JSON aus. In Intune läuft dieses Skript als Erkennungsskript einer Remediation, ohne etwas auf den Geräten zu verändern. Die Ergebnisse siehst du im Intune-Portal und exportierst sie als CSV.

Wichtig für die Planung ist die Konfidenzstufe, die Microsoft jedem Gerät zuordnet:

Das Ergebnis ist eine Tabelle mit einer Zeile pro Gerät und den Spalten Modell, BIOS, Konfidenz, Status. Aus ihr baust du die Pilotgruppen.

Wie rollst du die 2023er Zertifikate aus?

Microsoft beschreibt mehrere Wege, und die Dokumentation rät, sie nicht auf demselben Gerät zu mischen. Welcher passt, hängt davon ab, wie du deine Geräte verwaltest. Die Zertifikate kommen auch mit den kumulativen Updates, also brauchst du ein funktionierendes Patch-Management.

Weg 1: Windows Update und Microsoft-Assists

Der bequemste Weg ist, nichts Besonderes zu tun und die monatlichen Updates sauber zu verteilen. Geräte in High-Confidence-Buckets bekommen die Zertifikate dann automatisch. Der Registry-Wert HighConfidenceOptOut steuert das: 0 oder nicht vorhanden heißt Teilnahme, 1 heißt Ausstieg. Der Controlled Feature Rollout wird über MicrosoftUpdateManagedOptIn aktiviert (0 oder nicht vorhanden heißt aus, ein Wert ungleich 0 heißt an) und braucht die erforderlichen Diagnosedaten.

Wenn du Updates über Ringe bewusst verzögerst, kommen die Zertifikate entsprechend später an. Verlass dich bei Geräten, die nicht in einer High-Confidence-Gruppe liegen oder keine Diagnosedaten senden, nicht auf die Assists.

Weg 2: Intune

In Intune legst du unter Geräte, Geräte verwalten, Konfiguration eine neue Richtlinie an. Plattform ist Windows 10 und höher, Profiltyp ist der Einstellungskatalog. Über die Einstellungsauswahl suchst du nach "Secure Boot" und findest drei Einstellungen, die den Registry-Werten entsprechen:

• Enable Secureboot Certificate Updates stößt den Rollout auf dem Gerät an (entspricht AvailableUpdates).
• Configure High Confidence Opt-Out steuert, ob die automatischen Updates über Windows Update laufen.
• Configure Microsoft Update Managed Opt In meldet Geräte für den Controlled Feature Rollout an.

Weise die Richtlinie einer Gerätegruppe zu, nicht allen Geräten auf einmal. Ein bekanntes Problem betraf Pro-Editionen: Bis Ende Januar 2026 wurden Secure-Boot-Einstellungen dort mit dem Fehlercode 65000 abgelehnt. Das hat Microsoft über den Lizenzdienst behoben, ältere Lizenzen erneuern sich monatlich von selbst. Wenn du auf Windows 11 23H2 Pro dennoch den Fehler siehst, hilft das Update vom 14. April 2026 (KB5082052).

Weg 3: Gruppenrichtlinie

Für Domänen-PCs und Server gibt es eine Gruppenrichtlinie. Du lädst zuerst die Administrativen Vorlagen (ADMX), die Microsoft als Download bereitstellt. Danach findest du die Einstellungen unter Computerkonfiguration, Administrative Vorlagen, Windows-Komponenten, Secure Boot:

• Enable Secure Boot Certificate Deployment startet den Rollout (Registry: AvailableUpdates).
• Automatic Certificate Deployment via Updates steuert die automatische Verteilung über Windows Update. Achtung bei der Logik: "Enabled" blockiert hier die automatische Verteilung.
• Certificate Deployment via Controlled Feature Rollout meldet Geräte beim Rollout durch Microsoft an.

Zwei Hinweise aus der Microsoft-Dokumentation sind für die Praxis wichtig. Erstens: Entfernst du die Richtlinie wieder, bleibt der Registry-Wert bestehen. Zweitens: Einmal in die Firmware geschriebene Zertifikate lassen sich aus Windows nicht mehr entfernen, sondern nur noch über die Firmware-Oberfläche. Die Richtlinie ist also kein Schalter, den du bei Problemen einfach zurückdrehst.

Weg 4: Registry und Skript

Wenn du weder Intune noch Gruppenrichtlinien einsetzt, bleibt der Registry-Weg. Du setzt auf jedem Zielgerät den Wert AvailableUpdates auf 0x5944. Das ist der Wert, der alle nötigen Schritte auslöst: die neuen Zertifikate in die DB, das neue KEK und den neuen Boot-Manager. Für einen Test auf einem einzelnen Gerät führst du diese Befehle aus Microsofts Dokumentation einzeln in einer PowerShell mit Administratorrechten aus:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Der Wert fällt zunächst auf 0x4100. Dann startest du das Gerät neu und führst den geplanten Task noch einmal aus, damit Windows den neuen Boot-Manager installiert. Normalerweise läuft der Task beim Systemstart und danach alle 12 Stunden. Der Auslöser selbst erzwingt keinen Neustart, das Gerät muss aber irgendwann neu starten. Für die Planung gibt Microsoft etwa 48 Stunden und mindestens einen Neustart je Gerät an.

Windows arbeitet die Schritte in fester Reihenfolge ab: erst die Windows UEFI CA 2023 in die DB, dann (falls die UEFI CA 2011 in der DB liegt) die Microsoft UEFI CA 2023 und die Option ROM UEFI CA 2023, danach der KEK und zuletzt der Boot-Manager, der mit der Windows UEFI CA 2023 signiert ist. Scheitert ein Schritt, bleibt sein Bit gesetzt, und der Task versucht es beim nächsten Lauf erneut.

Firmware vom Hersteller

Der KEK-Schritt braucht die Mitarbeit des Geräteherstellers. Den KEK darf nur ändern, wer den Plattformschlüssel (PK) kontrolliert, und der gehört dem OEM. Der Hersteller muss Microsoft dafür einen mit dem PK signierten KEK liefern, den Windows dann mit den Updates ausliefert. Fehlt er, bleibt das Update an dieser Stelle hängen: AvailableUpdates behält das KEK-Bit (0x0004), und im System-Ereignisprotokoll taucht wiederholt Ereignis 1803 auf. Microsoft schreibt dazu, dass es für diesen Zustand keinen unterstützten manuellen Weg gibt. Das betrifft vor allem ältere Geräte, für die der Hersteller keine Firmware mehr pflegt. Ereignis 1795 deutet dagegen auf einen Firmware-Fehler beim Schreiben der Variablen hin. Dann prüfst du, ob es ein BIOS-Update gibt.

Neuere Geräte, die in den letzten ein bis zwei Jahren gebaut wurden, haben die 2023er Zertifikate unter Umständen schon ab Werk, aber den neuen Boot-Manager noch nicht installiert. Auch dieser letzte Schritt ist laut Microsoft entscheidend, prüf also auch Geräte, die "neu genug" aussehen.

Wo die Firmware die Updates nicht korrekt verarbeitet und es kein BIOS-Update mehr gibt, empfiehlt Microsoft den Ersatz des Geräts. Bis dahin ist es eine dokumentierte Ausnahme, mehr dazu weiter unten.

Wie vermeidest du BitLocker-Recovery-Überraschungen?

BitLocker versiegelt seinen Schlüssel gegen Messwerte, die der TPM beim Start erfasst. Ändert sich die Secure-Boot-Konfiguration oder der Boot-Manager, kann ein Gerät beim nächsten Start nach dem Wiederherstellungsschlüssel fragen. Microsoft beschreibt im Troubleshooting-Leitfaden drei Szenarien, die du kennen solltest, bevor du ausrollst.

Einmalige Recovery nach dem Update. Beim ersten Start nach dem Update meldet die Firmware die neuen Werte noch nicht, wenn Windows den BitLocker-Schutz neu versiegelt. Das Gerät verlangt deshalb einmal den Wiederherstellungsschlüssel. Beim nächsten Start stimmen die Werte, und es passiert nichts mehr. Prüf trotzdem, ob für das Modell ein neueres BIOS vorliegt.

Wiederholte Recovery bei PXE als erstem Startgerät. Ist das Netzwerk-Boot-Gerät vor der Festplatte eingestellt, schlägt der PXE-Start fehl, und die Firmware fällt auf den Boot-Manager auf der Platte zurück. Dann misst der TPM zwei verschiedene Signaturketten in einem Startvorgang: das PXE-Image mit der Microsoft UEFI CA 2011 und den lokalen Boot-Manager mit der Windows UEFI CA 2023. BitLocker findet keine stabilen Messwerte und verlangt bei jedem Start den Schlüssel. Abhilfe: Boot-Reihenfolge ändern, PXE abschalten oder die PXE-Infrastruktur auf einen 2023-signierten Windows-Bootloader umstellen. Wenn du Geräte über PXE neu installierst, gehört das in deine Pilotphase.

Boot-Fehler nach Zurücksetzen auf Firmware-Standard. Setzt jemand im BIOS Secure Boot auf die Werkseinstellungen zurück, löscht das die Datenbanken. Läuft das Gerät dann bereits mit dem 2023-signierten Boot-Manager, fehlt der Firmware das Zertifikat dafür, und das Gerät bootet nicht mehr. Microsoft beschreibt eine Rettung über einen USB-Stick: Von einem zweiten PC mit dem Juli-2024-Update oder neuer kopierst du SecureBootRecovery.efi aus dem Windows-Bootverzeichnis auf einen FAT32-Stick als \EFI\BOOT\bootx64.efi und startest das Problemgerät davon. Das Programm schreibt nur die Windows UEFI CA 2023 zurück in die DB. Danach brauchst du ein aktuelles BIOS und musst die übrigen Zertifikate erneut einspielen. Die einfache Regel: BIOS-Standardwerte nicht laden, solange der Hersteller keine Standardwerte mit den 2023er Zertifikaten liefert.

Daraus folgt die Vorbereitung. Prüfe vor dem Pilot, ob die Wiederherstellungsschlüssel aller Geräte in Entra ID oder Active Directory hinterlegt sind und der Helpdesk darauf zugreifen kann. Informiere die Anwender, dass nach dem Neustart einmalig eine Abfrage kommen kann und wen sie dann anrufen. Und lass Geräte im Homeoffice nicht am Freitagabend neu starten. Eine saubere Verschlüsselungsstrategie klärt die Schlüsselfrage vorab, denn ohne auffindbaren Recovery-Schlüssel wird aus einem Neustart ein Datenverlust-Szenario.

Pilotgruppen: So gehst du in den verbleibenden Tagen vor

Microsoft empfiehlt, in Stufen zu arbeiten: erst eine kleine Gruppe, dann mehr, und je Kategorie (Hersteller, Modell, Firmware-Version) mindestens vier Testgeräte, bevor du breit ausrollst. Du änderst Systeme im Boot-Pfad, das gehört durch deinen Change-Management-Prozess, mit Freigabe, Rückfallplan und Dokumentation.

Für unsere Beispielfirma sieht der Plan so aus:

Während der Wellen beobachtest du drei Dinge: wie viele Geräte UEFICA2023Status auf Updated haben, wie viele Ereignis 1808 melden und welche Geräte UEFICA2023Error mit einem Wert ungleich 0 zeigen. Hinter Fehlerfällen steckt häufig die Firmware, dann hilft die Herstellerseite, nicht ein weiterer Versuch. Bei Servern brauchst du Wartungsfenster, und bei VMs gehören die Host-Updates dazu.

Nachweis im ISMS: Was du dokumentierst

Der Zertifikatswechsel ist ein Beispiel für Schwachstellen- und Änderungsmanagement im Kleinen, mit klarem Termin und klarem Ergebnis. Auditoren wollen die Frage "Wo stehen wir?" belegt sehen, nicht erzählt bekommen. In der ISO 27001 ordnet sich das bei Control A.8.8 (Umgang mit technischen Schwachstellen) und A.8.32 (Änderungssteuerung) ein.

Ein tragfähiger Nachweis besteht aus fünf Bausteinen:

1. Risiko. Du legst ein Risiko an: "Geräte ohne 2023er Secure-Boot-Zertifikate erhalten keine Boot-Sicherheitsupdates mehr." Eintrittswahrscheinlichkeit und Schadenshöhe bewertest du mit deiner üblichen Matrix. Das Risiko verknüpfst du mit den betroffenen Assets.
2. Maßnahme. Der Rollout wird als Maßnahme mit Verantwortlichem, Termin und Wirksamkeitsprüfung geführt. Wirksam ist sie, wenn die Auswertung zeigt, dass UEFICA2023Status auf allen unterstützten Geräten Updated lautet.
3. Inventar mit Status. Die Geräteliste mit Modell, BIOS, Konfidenz und Status vom Stichtag ist dein Hauptnachweis. Exportiere sie am 19. Oktober und danach monatlich.
4. Ausnahmenliste. Für jedes Gerät, das die Zertifikate nicht bekommt, brauchst du Begründung, Kompensation (zum Beispiel Ersatz bis Quartal X, kein Zugriff auf sensible Systeme) und eine Risikoakzeptanz durch den Verantwortlichen.
5. Change-Unterlagen. Freigabe, Pilot-Protokoll, Rückfallplan und Abschlussbericht für die Änderung.

ISMS Lite führt diese Bausteine zusammen: Das Risiko wird mit den Assets verknüpft, die Maßnahme trägt Verantwortliche und Termin, und die Ausnahmen lassen sich als eigene Risiken mit Wiedervorlage pflegen. Wenn du Gerätedaten bereits in einem Inventarsystem hast, kannst du sie über die API pflegen, statt sie von Hand zu übertragen.

Der Wechsel ist außerdem eine gute Gelegenheit, dein Verzeichnis kryptografischer Elemente zu prüfen. Zertifikate haben ein Ablaufdatum, und in vielen Firmen kennt niemand alle, die in Firmware, Geräten und Diensten stecken. Wie du so ein Zertifikats- und Krypto-Inventar aufbaust, zeigen wir in einem eigenen Artikel, und die Regeln für Algorithmen und Lebenszyklen gehören in deine Kryptografie-Richtlinie.

Checkliste: Secure-Boot-Zertifikate bis zum 19. Oktober

Bestandsaufnahme

• Alle Geräte mit Hersteller, Modell, BIOS-Version und -Datum inventarisiert
• Secure-Boot-Status je Gerät erhoben (Confirm-SecureBootUEFI)
• Geräte mit deaktiviertem Secure Boot oder Legacy-BIOS als Befund dokumentiert
• UEFICA2023Status und UEFICA2023Error zentral ausgewertet (Intune-Remediation, Skript oder Management-Tool)
• Konfidenzstufe je Gerätemodell erfasst
• Windows-10-Geräte: ESU-Status geprüft, Verlängerung für das zweite Jahr geklärt
• Server und VMs inventarisiert, Hyper-V-Hosts und Gäste mit Updates ab März beziehungsweise April 2026

Vorbereitung

• BitLocker-Wiederherstellungsschlüssel aller Geräte in Entra ID oder Active Directory geprüft
• PXE-Boot-Reihenfolge auf allen Geräten bekannt, PXE-Infrastruktur geprüft
• Aktuelle BIOS-Versionen der Hersteller je Modell geprüft
• Administrative Vorlagen für die Gruppenrichtlinie geladen oder Intune-Richtlinie vorbereitet
• Change-Antrag mit Rückfallplan freigegeben
• Anwender und Helpdesk über mögliche einmalige BitLocker-Abfrage informiert

Pilot und Rollout

• Pilot mit mindestens vier Geräten je Modell durchgeführt
• Linux-Dualboot-Geräte getestet (mokutil --db, mokutil --kek)
• Rollout in Wellen, Neustarts eingeplant
• Ereignisse 1801 und 1808 sowie UEFICA2023Error beobachtet
• Fehlerfälle einzeln geklärt, Hersteller-Support eingebunden
• BIOS-Standardwerte nicht geladen, solange der Hersteller keine neuen Standardwerte liefert

Nachweis

• Risiko und Maßnahme im ISMS angelegt und mit Assets verknüpft
• Geräteliste mit Status am Stichtag exportiert und abgelegt
• Ausnahmen mit Begründung, Kompensation und Risikoakzeptanz dokumentiert
• Wirksamkeitsprüfung terminiert (monatlicher Abgleich)

Häufige Fehler beim Zertifikatswechsel

Nur auf Windows Update verlassen. Die Assists sind Hilfen, keine Garantie, und Microsoft sagt das selbst. Geräte ohne Diagnosedaten, mit zurückgehaltenen Updates oder in unbekannten Gerätegruppen kommen nicht von allein auf den neuen Stand. Wer nicht misst, merkt es erst, wenn der nächste Boot-Fix auf diesen Geräten nicht ankommt.

Alle Geräte auf einmal ausrollen. Firmware ist das Risiko, nicht Windows. Ein Modell mit fehlerhafter DB-Verarbeitung kann nach dem Neustart nicht mehr booten, und bei hundert Geräten gleichzeitig hast du hundert Fälle gleichzeitig. Zwei Pilotgeräte pro Modell reichen nicht, Microsoft empfiehlt vier.

BIOS auf Werkseinstellungen zurücksetzen. Das ist der klassische Helpdesk-Reflex bei Bootproblemen. Läuft das Gerät schon mit dem 2023er Boot-Manager, löscht der Reset das passende Zertifikat, und das Gerät startet nicht mehr. Schreib das in die Arbeitsanweisung des Helpdesks.

Secure Boot abschalten, um Ruhe zu haben. Das beseitigt die Warnung und nimmt den Schutz. Microsoft rät ausdrücklich davon ab. Wenn überhaupt, ist das eine befristete, dokumentierte Ausnahme für ein einzelnes Gerät und kein Mittel für die Flotte.

Ausnahmen ohne Dokumentation. Ein Gerät, das die Zertifikate nicht bekommt, ist kein Fehler, sondern eine Entscheidung. Ohne Begründung, Termin für den Ersatz und Risikoakzeptanz ist es im Audit eine offene Schwachstelle ohne Eigentümer.

Fazit: Der Stichtag ist weich, der Nachweis nicht

Der Ablauf legt kein Gerät lahm, aber er teilt deine Flotte in Geräte, die künftige Boot-Sicherheitsupdates annehmen können, und solche, die es nicht mehr können. Fang diese Woche mit dem Inventar und dem Pilot an, denn knapp wird die Zeit für Neustarts und Firmware-Fälle, nicht der Aufwand für die Einstellung selbst. Wer den Wechsel als Risiko mit Maßnahme, Geräteliste und Ausnahmen im ISMS führt, hat nach dem Stichtag nicht nur sichere Geräte, sondern auch den Beleg dafür.

Weiterführende Artikel

• Bare-Metal-Recovery testen: Vom Totalausfall zur laufenden Maschine
• Microsoft Secure Score: Was er misst und wie du ihn verbesserst
• Microsoft Defender for Business: Lohnt sich der Umstieg vom klassischen Virenscanner?
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen
• ISO 27001 A.8.1-8.8: Technologische Controls für sichere Systeme