Secure Boot Zertifikate: Was Unternehmen jetzt prüfen sollten

Microsoft erneuert zentrale Secure-Boot-Zertifikate. Mehrere Zertifikate, die seit 2011 in Betrieb sind, laufen zwischen Juni und Oktober 2026 aus. Für Unternehmen bedeutet das: Es handelt sich nicht um ein gewöhnliches Windows-Update, sondern um ein Thema rund um UEFI, Bootloader, Boot Manager und frühe Startkomponenten — also um die grundlegende Vertrauenskette beim Systemstart.

Systeme werden in der Regel nicht von einem Tag auf den anderen nicht mehr starten. Das eigentliche Risiko liegt in einem degradierten Sicherheitszustand: Künftige Secure-Boot-bezogene Updates, neue Boot-Komponenten oder Sperrlisten für kompromittierte Boot-Dateien könnten unter Umständen nicht mehr sauber angewendet werden — mit potenziellen Folgen für die Systemintegrität und langfristige Wartbarkeit.

Die Grundlage dieses Beitrags bilden die aktuellen Hinweise von Microsoft und Broadcom/VMware. Vor produktiven Änderungen sollten stets die jeweils aktuellen Herstellerinformationen geprüft werden.

Was ändert sich bei Secure Boot?

Secure Boot und die Vertrauenskette beim Systemstart

Secure Boot ist ein UEFI-Mechanismus, der sicherstellt, dass beim Systemstart ausschließlich digital signierte und vertrauenswürdige Boot-Komponenten geladen werden. Dazu gehören der Boot Manager, der Betriebssystem-Loader sowie frühe Treiber und Startkomponenten.

Die Vertrauensbasis wird durch Zertifikate in der UEFI-Datenbank (DB) definiert. Microsoft erneuert diese Zertifikate, weil die bisher genutzten — teilweise seit 2011 im Einsatz — bis Oktober 2026 auslaufen. Das bedeutet konkret: Neue Secure-Boot-fähige Boot-Komponenten werden künftig mit den neuen 2023er-Zertifikaten signiert. Systeme, die diese Zertifikate nicht in ihrer DB aufgenommen haben, könnten künftige DB- und DBX-Updates nicht mehr vollständig verarbeiten. Das Risiko ist nicht ein sofortiger Totalausfall, sondern ein schrittweise degradierter Sicherheitszustand.

Warum Unternehmen das Thema jetzt prüfen sollten

Die eigentliche Herausforderung liegt nicht im Update selbst, sondern in der Inventarisierung, Pilotierung und kontrollierten Umsetzung in heterogenen IT-Landschaften. Unternehmen betreiben in der Regel eine Mischung aus:

• Windows-Workstations unterschiedlicher Generationen und Firmwarestände
• physischen Windows-Servern mit unterschiedlichen UEFI-Konfigurationen
• virtuellen Maschinen unter VMware oder Hyper-V
• Systemen mit und ohne aktivem Secure Boot
• Systemen mit unterschiedlichen Wartungsfenstern und Verfügbarkeitsanforderungen

Für geschäftskritische Server, Produktivsysteme und Hypervisor-Umgebungen ist ein koordinierter, kontrollierter Rollout deutlich sinnvoller als eine ungeplante Massenaktualisierung. Wer heute beginnt, den Bestand zu erfassen und Pilotgruppen zu bilden, hat ausreichend Zeit für eine strukturierte Umsetzung.

Windows Workstations: Status überwachen und kontrolliert ausrollen

Viele moderne Windows-Workstations können die Secure-Boot-Zertifikatsumstellung über vorhandene Microsoft-Update-Mechanismen erhalten. Das bedeutet jedoch nicht, dass Unternehmen das Thema unbeobachtet laufen lassen sollten.

Empfehlenswert ist ein strukturierter Ansatz:

• Bestand erfassen: Welche Systeme sind UEFI-basiert und haben Secure Boot aktiv?
• Pilotgruppe bilden: Zunächst einige repräsentative Geräte aktualisieren und den Status prüfen.
• Wellen-Rollout planen: Schrittweise Ausweitung auf alle Workstations, möglichst außerhalb kritischer Produktionsphasen.
• Zielzustand verifizieren: Den Registry-Status nach der Aktualisierung kontrollieren, um sicherzustellen, dass der gewünschte Zustand erreicht wurde.

Auch bei Workstations können ältere Hardware-Generationen, spezielle OEM-Firmwarestände oder besondere UEFI-Konfigurationen dazu führen, dass nicht alle Systeme identisch reagieren.

Windows Server: Wartungsfenster und Pilotierung sind Pflicht

Bei Windows-Servern ist besondere Sorgfalt geboten — nicht weil das Update grundsätzlich riskanter ist, sondern weil Fehlkonfigurationen oder ungeplante Neustarts bei geschäftskritischen Systemen direkte betriebliche Auswirkungen haben können.

Wichtige Punkte für den Server-Rollout:

• Das Thema ist nur relevant, wenn auf dem jeweiligen System UEFI und Secure Boot aktiv sind. BIOS-basierte Systeme sind nicht betroffen.
• Vor jedem Rollout einen Pilotserver pro Plattform (z. B. je eine physische Maschine, eine VM unter VMware, eine VM unter Hyper-V) testen.
• Neustarts einplanen: Die Secure-Boot-Zertifikatsumstellung erfordert in der Regel einen Systemneustart. Wartungsfenster müssen entsprechend geplant werden.
• Nach der Aktualisierung den Status und mögliche Fehlereinträge (UEFICA2023Status, UEFICA2023Error) kontrollieren.
• Cluster- und Hochverfügbarkeitsumgebungen erfordern koordinierte Rollout-Pläne, um Ausfallrisiken zu minimieren.

VMware-Umgebungen: Hypervisor-Ebene gesondert betrachten

VMware: Mehr als nur der Windows-Gast

In VMware-Umgebungen reicht es nicht aus, ausschließlich den Windows-Gastzustand zu betrachten. Zusätzliche Abhängigkeiten müssen berücksichtigt werden:

• ESXi- und vCenter-Stand: Die VMware-Plattform selbst muss auf einem aktuellen und kompatiblen Stand sein, bevor Änderungen an virtuellen Maschinen vorgenommen werden.
• Virtuelle Firmware: Jede VM hat eine eigene virtuelle Hardware-Konfiguration, die auch die Secure-Boot-Unterstützung beeinflusst.
• VMs nach Secure Boot und vTPM klassifizieren: VMs ohne vTPM folgen einem anderen Update-Pfad als VMs mit vTPM. Letztere sollten besonders sorgfältig und mit zusätzlichem Testaufwand behandelt werden.
• Hypervisor-Ebene zuerst: Vor dem Windows-seitigen Rollout sollte die Hypervisor-Ebene geprüft und ggf. aktualisiert werden.

Die jeweils aktuellen VMware-/Broadcom-Hinweise sollten vor der Umsetzung geprüft werden. Dokumentierte Pfade für verschiedene VM-Konfigurationen sind bei Broadcom verfügbar.

Hyper-V-Umgebungen: Näher am Windows-Pfad, aber kein Selbstläufer

Hyper-V-Umgebungen sind in ihrer Secure-Boot-Behandlung näher am Windows-Standardpfad als VMware-Umgebungen. Dennoch sollten auch hier keine pauschalen Annahmen getroffen werden.

• Hosts und Gäste getrennt betrachten: Sowohl der Hyper-V-Host als auch die einzelnen Gast-VMs müssen gepatcht und überprüft werden.
• Pilot-VMs zuerst: Zunächst einzelne Test-VMs aktualisieren und den Status im Gast kontrollieren, bevor ein breiter Rollout erfolgt.
• Bekannte Microsoft-Hinweise berücksichtigen: Microsoft stellt Dokumentation zu möglichen Besonderheiten in Hyper-V-Umgebungen bereit, die vor der Umsetzung gesichtet werden sollte.
• Wartungsfenster einplanen: Auch in Hyper-V-Umgebungen sind Neustarts erforderlich — sowohl für den Host als auch für die Gast-VMs.

Die Nähe zum Windows-Standard-Update-Pfad bedeutet nicht, dass ein unbeobachteter automatischer Rollout in Produktionsumgebungen empfehlenswert ist.

Kurze PowerShell-Prüfung für Administratoren

Administratoren können den Status der Secure-Boot-Zertifikatsumstellung auf Windows-Systemen über die Registry und die geplante Aufgabe Secure-Boot-Update prüfen. Die folgenden Befehle sollten mit administrativen Rechten ausgeführt werden.

Wichtiger Hinweis: Die ersten Abfragen lesen lediglich den vorhandenen Status aus und verändern keine Systemeinstellungen. Die späteren Befehle zum Setzen von AvailableUpdates und zum Starten der geplanten Aufgabe verändern den Systemzustand und sollten ausschließlich in Pilotgruppen, Tests oder geplanten Wartungsfenstern eingesetzt werden. Eine pauschale manuelle Auslösung auf allen Systemen gleichzeitig wird nicht empfohlen.

Haftungsausschluss: opticom übernimmt keine Haftung für die Richtigkeit, Vollständigkeit oder Aktualität der nachfolgenden PowerShell-Skripte. Die Ausführung erfolgt auf eigene Verantwortung. Vor dem Einsatz in produktiven Umgebungen sollten die Skripte sorgfältig geprüft und die jeweils aktuellen Herstellerhinweise von Microsoft berücksichtigt werden.

# ---------------------------------------------------------------
# LESENDER STATUS-ABRUF (verändert keine Systemeinstellungen)
# Mit administrativen Rechten ausführen
# ---------------------------------------------------------------

# Secure-Boot-Zertifikatsstatus aus der Registry auslesen
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
  | Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent, WindowsUEFICA2023Capable

# Erklärung der Registry-Werte (Richtwerte laut Microsoft-Dokumentation):
# UEFICA2023Status        = Aktueller Verarbeitungsstatus der Zertifikatsumstellung
# UEFICA2023Error         = Fehlercode, wenn ein Problem aufgetreten ist
# UEFICA2023ErrorEvent    = Ereignis-ID des zuletzt protokollierten Fehlers
# WindowsUEFICA2023Capable = Gibt an, ob das System die Umstellung unterstützt

# Secure Boot aktiv?
Confirm-SecureBootUEFI

# Geplante Aufgabe für das Secure-Boot-Update anzeigen
Get-ScheduledTask -TaskName "*Secure Boot*" -ErrorAction SilentlyContinue

# ---------------------------------------------------------------
# SYSTEMVERÄNDERNDE BEFEHLE
# NUR in Pilotgruppen, Tests oder geplanten Wartungsfenstern!
# Verändert Systemzustand — Neustart erforderlich!
# ---------------------------------------------------------------

# AvailableUpdates-Flag setzen (löst Verarbeitungslogik aus)
# Nur für gezielt ausgewählte Pilotsysteme verwenden!
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
  -Name "AvailableUpdates" -Value 1 -Type DWord

# Geplante Aufgabe manuell starten (nur Pilotgeräte / Wartungsfenster)
Start-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"

# Hinweis: Nach diesen Änderungen ist ein Neustart des Systems erforderlich.
# Den Status anschließend erneut mit dem lesenden Abfrage-Block prüfen.

Secure Boot 2026 ist kein Panikthema — aber ein Wartungs- und Sicherheitsprojekt, das strukturiert angegangen werden sollte. Wer Bestand erfasst, Pilotgruppen bildet und Wartungsfenster plant, hat den größten Teil der Arbeit bereits getan.

— opticom IT-Systemhaus GmbH

Wie opticom Unternehmen bei der Secure-Boot-Umstellung unterstützt