Secure Boot 2026: Warum KMU ihre Windows-Geräte jetzt prüfen müssen

Was ist Secure Boot?

Secure Boot ist eine Sicherheitsfunktion der UEFI-Firmware moderner Computer. Sie arbeitet bereits vor dem eigentlichen Start von Windows. Die Firmware kontrolliert anhand digitaler Signaturen, ob Bootloader, Firmware-Erweiterungen und andere frühe Systemkomponenten als vertrauenswürdig eingestuft werden können.

Damit schützt Secure Boot eine besonders sensible Phase: Schadsoftware, die sich vor dem Betriebssystem einnistet, kann sich der Erkennung durch klassische Virenscanner und andere Windows-Sicherheitsfunktionen entziehen. Solche sogenannten Bootkits können beispielsweise den Startvorgang manipulieren oder weitere Schadsoftware laden.

Welche Software ausgeführt werden darf, wird unter anderem über Zertifikate und Signaturdatenbanken in der Firmware geregelt. Die erlaubten Signaturen liegen in der Secure-Boot-Datenbank, häufig kurz DB genannt. Gesperrte beziehungsweise widerrufene Signaturen werden in der DBX hinterlegt. Der Key Enrollment Key, kurz KEK, autorisiert Änderungen an diesen Datenbanken.

Warum ist das Thema im August 2026 weiterhin aktuell?

Die ursprünglichen Microsoft-Zertifikate stammen aus dem Jahr 2011. Nach rund 15 Jahren endet ihr vorgesehener Lebenszyklus. Microsoft ersetzt sie durch neue Zertifikate aus dem Jahr 2023. Diese Umstellung betrifft nicht nur Windows selbst, sondern auch die UEFI-Firmware der Geräte, Bootmedien, Serverplattformen und bestimmte virtuelle Maschinen.

Der Juni-Stichtag ist also bereits überschritten. Gleichzeitig besteht bis zum Ablauf des dritten Zertifikats im Oktober ein zusätzlicher Anlass, den Status der gesamten Geräteflotte jetzt nachvollziehbar zu erfassen. Besonders Systeme, die selten eingeschaltet werden, Updates nur verzögert erhalten oder nicht zentral verwaltet werden, können durch das Raster fallen.

Was passiert mit nicht aktualisierten Geräten?

Microsoft weist ausdrücklich darauf hin, dass Geräte mit den alten Zertifikaten in der Regel weiter starten und reguläre Windows-Updates installieren. Ein abgelaufenes Secure-Boot-Zertifikat führt daher nicht automatisch zu einem sichtbaren Totalausfall.

Das eigentliche Problem ist weniger offensichtlich: Fehlen die neuen Zertifikate, kann das Gerät künftige Aktualisierungen für den frühen Startprozess möglicherweise nicht mehr vollständig übernehmen. Dazu gehören neue Versionen des Windows Boot Managers, Änderungen an den erlaubten Signaturen und aktualisierte Sperrlisten gegen verwundbare Boot-Komponenten.

Das System bleibt damit auf einem älteren Vertrauensstand stehen. Werden später neue Schwachstellen in Bootloadern oder UEFI-Komponenten bekannt, kann Microsoft die notwendigen Schutzmaßnahmen auf solchen Geräten unter Umständen nicht mehr wirksam ausrollen. Auch zukünftige Betriebssysteme, Hardware-Erweiterungen oder Software mit Secure-Boot-Abhängigkeit können langfristig Kompatibilitätsprobleme verursachen.

Welche Systeme sollten KMU einbeziehen?

Zusätzlich sollten Unternehmen Windows-10-Geräte beachten. Nicht mehr unterstützte Windows-Versionen erhalten grundsätzlich keine regulären Sicherheitsupdates. Eine Ausnahme können Geräte sein, die ordnungsgemäß am Extended-Security-Updates-Programm teilnehmen. Die Secure-Boot-Prüfung ersetzt deshalb keine Entscheidung über die weitere Nutzung oder Ablösung von Windows 10.

Secure-Boot-Migration: Vorgehen in sieben Schritten

1. Vollständige Geräteübersicht erstellen

   Erfassen Sie PCs, Notebooks, physische Server, virtuelle Maschinen, IoT-Geräte und Reservehardware. Zur Bestandsaufnahme gehören Gerätemodell, Windows-Version, Firmware-Version, Secure-Boot-Status, BitLocker-Status und die Art der Updateverwaltung.

2. Support- und Updatezustand prüfen

   Installieren Sie die aktuellen kumulativen Windows-Updates auf unterstützten Systemen. Prüfen Sie bei älteren Geräten außerdem, ob der Hersteller eine aktuelle BIOS- beziehungsweise UEFI-Firmware bereitstellt. Manche Modelle benötigen ein Firmware-Update, bevor die neuen Zertifikate zuverlässig eingespielt werden können.

3. Zertifikatsstatus zentral auswerten

   Microsoft nennt Ereignisprotokolle und Registrierungssignale als geeignete Datenquellen. Ein noch nicht abgeschlossener Zustand kann sich beispielsweise über die Ereignis-ID 1801 oder einen nicht auf „Updated“ gesetzten Wert für UEFICA2023Status zeigen. Solche Signale sollten über das vorhandene Management- oder Monitoring-System gesammelt und nicht nur stichprobenartig an Einzelgeräten kontrolliert werden.

4. BitLocker-Wiederherstellung vorbereiten

   Änderungen an Firmware und Secure-Boot-Variablen können eine BitLocker-Wiederherstellungsabfrage auslösen. Vor dem Rollout muss deshalb geprüft werden, ob die Wiederherstellungsschlüssel aller betroffenen Systeme aktuell, vollständig und für autorisierte Mitarbeitende erreichbar hinterlegt sind.

5. Repräsentative Pilotgruppe bilden

   Testen Sie die Migration zunächst auf wenigen Geräten, die unterschiedliche Hersteller, Modelle, Firmwarestände und Nutzungsprofile abdecken. Mindestens ein System jeder relevanten Plattform sollte vertreten sein. Kontrollieren Sie anschließend Neustart, Secure-Boot-Status, BitLocker-Verhalten und Ereignisprotokolle.

6. Gestaffelt ausrollen und überwachen

   Nach einem erfolgreichen Pilotbetrieb folgt der Rollout in überschaubaren Ringen. Geeignete Wege sind je nach Infrastruktur Microsoft Intune, Gruppenrichtlinien, Windows-Konfigurationsrichtlinien oder die von Microsoft dokumentierten Registrierungsmechanismen. Für Server sind geplante Wartungsfenster und eine gesonderte Erfolgskontrolle erforderlich.

7. Boot- und Rettungsmedien testen

   Prüfen Sie nicht nur den normalen Windows-Start. Auch Installationsmedien, Wiederherstellungsumgebungen, Backup-Rettungsmedien, Diagnosewerkzeuge und bootfähige Herstellerprogramme müssen mit dem neuen Vertrauensmodell funktionieren. Ein aktualisierter Server hilft wenig, wenn im Notfall nur ein veraltetes, nicht mehr akzeptiertes Wiederherstellungsmedium vorhanden ist.

Typische Fehler bei der Umstellung

• Nur Windows Update kontrollieren: Ein aktueller Patchstand beweist nicht automatisch, dass die Zertifikate bereits erfolgreich in der Firmware hinterlegt wurden.
• Server wie Arbeitsplatzrechner behandeln: Windows Server erfordern häufig ein gezieltes Anstoßen und Überwachen der Zertifikatsmigration.
• Alle Geräte gleichzeitig aktualisieren: Unterschiedliche UEFI-Versionen reagieren nicht immer identisch. Ein gestaffelter Rollout begrenzt das Betriebsrisiko.
• Firmware- und Secure-Boot-Änderungen unkoordiniert kombinieren: Mehrere tiefgreifende Änderungen im selben Wartungsfenster erschweren Fehlersuche und Wiederherstellung.
• BitLocker-Schlüssel nicht vorab kontrollieren: Ein nicht auffindbarer Wiederherstellungsschlüssel kann aus einem kurzen Wartungsvorgang einen längeren Ausfall machen.
• Ausgeschaltete Reservegeräte vergessen: Geräte im Lager oder selten genutzte Notebooks haben oft über Monate keine Updates erhalten.
• Nur physische Hardware erfassen: Virtuelle Maschinen verfügen ebenfalls über Secure-Boot-Konfigurationen und virtuelle Firmware.

Warum Monitoring nach dem Rollout wichtig bleibt

Eine erfolgreiche Migration ist erst abgeschlossen, wenn der Zustand nach dem Neustart bestätigt wurde. Für KMU mit mehreren Gerätetypen empfiehlt sich daher ein zentraler Nachweis: Welche Systeme enthalten die neuen Zertifikate? Wo war ein Firmware-Update erforderlich? Welche Geräte melden Fehler oder wurden seit Beginn der Maßnahme noch nicht erreicht?

Diese Informationen gehören in die laufende IT-Dokumentation. Sie erleichtern spätere Sicherheitsprüfungen, Hardwarewechsel und Notfallmaßnahmen. Gleichzeitig lassen sich Systeme erkennen, die zwar noch funktionieren, aber keine verlässliche Updatebasis mehr besitzen.

Der Vorgang zeigt exemplarisch, warum professionelles Patchmanagement mehr umfasst als das regelmäßige Installieren sichtbarer Windows-Updates. Betriebssystem, Firmware, Verschlüsselung, Virtualisierung und Wiederherstellungsprozesse müssen zusammen betrachtet werden.

Fazit: Secure Boot gehört jetzt auf die Wartungsagenda

Die Zertifikatsumstellung ist kein Grund für Alarmismus, aber ein konkreter Prüfauftrag für jede professionell betreute Windows-Umgebung. Unternehmen sollten sich nicht darauf verlassen, dass ein weiterhin startender Rechner automatisch vollständig geschützt ist.

Eine saubere Umsetzung beginnt mit einer vollständigen Inventur. Danach folgen aktuelle Windows- und Firmwarestände, gesicherte BitLocker-Schlüssel, ein repräsentativer Pilotbetrieb, der gestaffelte Rollout und eine dokumentierte Erfolgskontrolle. Server, virtuelle Maschinen, Reservegeräte und Wiederherstellungsmedien müssen ausdrücklich einbezogen werden.

Quellen und weiterführende Informationen

• Microsoft Support: Windows Secure Boot certificate expiration and CA updates
• Microsoft Learn: Update Secure Boot Certificates for Windows Devices
• Microsoft Windows Server Blog: Prepare your servers for Secure Boot certificate updates
• Microsoft Windows Blog: Refreshing the root of trust