TL;DR:
Ab 2026 sind die alten Secure-Boot-Zertifikate nicht mehr gültig. Microsoft stellt deswegen schrittweise auf neue Zertifikate um.
Bei der Umstellung können unvorbereitete Systeme eventuell nicht mehr starten.
Besonders kritisch ist die Umstellung bei Geräten mit älterer Firmware, Servern und eigenen Virtualisierungen.
Eine technische Vorbereitung sollte jetzt beginnen.
Warum ersetzt Microsoft die Zertifikate?
Die bisherigen Secure-Boot-Zertifikate stammen aus dem Jahr 2011 und sind somit mehr als 10 Jahre alt. Neben dem Ablaufdatum spielen auch moderne Angriffsszenarien eine Rolle.
Ohne die neuen Zertifikate kann es dazu kommen, dass sicherheitsrelevante Updates für den Bootprozess nicht mehr angewendet werden können und Firmware-Manipulationen ermöglicht werden.
Microsoft hat deshalb die Windows UEFI CA 2023 eingeführt und rollt die Zertifikate schrittweise über Windows Updates aus.
Es handelt sich dabei nicht um ein klassisches Windows-Update, sondern um Änderungen auf Firmware-Ebene.
Was genau wird aktualisiert?
Im Rahmen der Umstellung greift Microsoft in die Secure-Boot-Vertrauenskette ein. Konkret betrifft das mehrere sicherheitskritische Komponenten:
- die Secure-Boot-Datenbank (db) wird erweitert um die Windows UEFI CA 2023 als neue vertrauenswürdige Signaturstelle
- die Sperrliste (dbx) wird aktualisiert, um veraltete oder kompromittierte Signaturen perspektivisch auszuschließen
- eine zusätzlich signierte Version des Windows Boot Managers wird bereitgestellt, die sowohl von der bisherigen als auch von der neuen CA validiert werden kann
Die Umstellung erfolgt dabei nicht in einem einzigen Schritt, sondern kontrolliert über mehrere Update-Phasen. Erst wenn alle Voraussetzungen erfüllt sind, werden die neuen Zertifikate vollständig aktualisiert und aktiviert.
Wen betrifft die Umstellung?
Grundsätzlich betroffen sind:
- Windows Clients mit aktiviertem Secure Boot
- Windows Server mit UEFI-Firmware
- Virtuelle Maschinen mit aktiviertem Secure Boot
Nicht betroffen sind:
- Legacy-BIOS-Systeme
- Geräte ohne Secure Boot
- Nicht-Windows-basierte Plattformen außerhalb der Microsoft-Signaturkette
In der Praxis betrifft die Umstellung nahezu jede moderne Windows-Unternehmensumgebung.
Welche Auswirkungen sind zu erwarten?
- für Clients:
Auf aktuellen Client-Systemen mit gepflegter Firmware verläuft die Umstellung meist unauffällig.
Probleme können auftreten, wenn ältere Firmware-Versionen die neuen Zertifikate nicht korrekt verarbeiten können.
- für Server:
Bei Server-Systemen ist besondere Vorsicht geboten.
Ein fehlerhafter oder unvollständiger Rollout kann dazu führen, dass Systeme aufgrund inkonsistenter Zertifikate nicht mehr starten. In solchen Fällen kann ein manuelles Zurücksetzen der Zertifikate (UEFI-Secure-Boot-Keys) im BIOS erforderlich sein.
Befindet sich BitLocker im Einsatz, ist mit einem möglichen Wechsel in den Recovery-Modus zu rechnen. Es empfiehlt sich, BitLocker für die Umstellung zu deaktivieren oder sicherzustellen, dass Wiederherstellungsschlüssel verfügbar sind.
- für Virtuelle Maschinen:
Cloud-Plattformen aktualisieren die zugrunde liegende Host-Infrastruktur in der Regel eigenständig.
Bei selbst betriebenen Virtualisierungs-Umgebungen liegt die Verantwortung jedoch vollständig beim Unternehmen. Hier muss sichergestellt werden, dass sowohl die Firmware des Hypervisor-Hosts als auch die eingesetzte Hypervisor-Version die neuen Zertifikate unterstützen. Dazu haben wir einen gesonderten Blogartikel.
Zusätzlich ist die Konfiguration der virtuellen Maschinen zu prüfen. Insbesondere, ob UEFI und Secure Boot korrekt aktiviert sind und mit der bestehenden Windows-Installation kompatibel sind.
Was sollten Unternehmen jetzt tun?
Die Umstellung sollte nicht als kleines Update betrachtet werden, sondern als sicherheitsrelevante Umstellung.
Unternehmen sollten deshalb:
- die eigene Hardware- und Firmware-Landschaft bewerten
- geschäftskritische Systeme und Abhängigkeiten prüfen
- potenzielle Risiken in Server- und Virtualisierungs-Umgebungen identifizieren
- einen strukturierten statt flächendeckenden Rollout planen
Gerade in gewachsenen IT-Landschaften mit älteren Firmware-Versionen oder Virtualisierungs-Umgebungen können unerwartete Nebeneffekte auftreten.
Wir empfehlen daher eine ganzheitliche Betrachtung der Umgebung – inklusive Firmwarestand, Update-Strategie, Monitoring und Recovery-Konzept.
Wie geht man bei Fehlerquellen vor?
Ein Recovery-Konzept muss konkret regeln, wie im Fehlerfall vorzugehen ist.
Dazu gehören:
- ein Verfahren zum Zurücksetzen der Zertifikate (UEFI-Secure-Boot-Keys)
- Out-of-Band-Zugriff
- eine BitLocker-Strategie mit zentral hinterlegten Wiederherstellungsschlüsseln
Nur so lässt sich die Bootfähigkeit eines Systems im Ernstfall kontrolliert wiederherstellen.
Wie geht man praktisch und kontrolliert vor?
Die Umstellung sollte strukturiert, nachvollziehbar und in klar definierten Phasen erfolgen. Neben der Planung sind eine technische Vorbereitung und die Kontrolle der betroffenen Systeme erforderlich.
1. Geräte-Kompatibilität prüfen
Vor Beginn des Rollouts ist eine vollständige Bestandsaufnahme sinnvoll.
Auf Basis der Bestandsaufnahme und den relevanten Herstellerinformationen sollte dann geprüft werden, ob die jeweilige Plattform die Zertifikate unterstützt.
Ist die Kompatibilität nicht gegeben oder nicht eindeutig dokumentiert, sind, wenn möglich, entsprechende Firmware-Updates einzuplanen.
Ziel ist es, die technische Kompatibilität für die eigentliche Umstellung sicherzustellen.
2. Vorbereitung des Betriebssystems
Vor der Umstellung ist sicherzustellen, dass alle von Microsoft vorgesehenen Vorbereitungsupdates installiert sind und nicht durch Richtlinien blockiert werden.
In verwalteten Umgebungen kann die Steuerung beispielsweise erfolgen über:
- Gruppenrichtlinien
- Gerätekonfigurationsprofile (z. B. Intune)
- zentrale Update-Mechanismen
Dabei sind die von Microsoft vorgesehenen Systemparameter und Aktivierungsmechanismen zu berücksichtigen.
Eine unvollständige Vorbereitung kann zu fehlerhaftem Einspielen der Zertifikate und damit zu blockierten Bootvorgängen und/oder BitLocker-Wiederherstellungen führen.
3. Kontrollierte Aktivierung gemäß Microsoft-Vorgehen
Die Aktivierung der neuen Zertifikate erfolgt mehrstufig und sollte daher nicht flächendeckend ausgelöst werden.
Empfohlen wird ein gestaffelter Rollout:
- Pilotphase mit definierten Testsystemen
- erweiterte Testgruppe
- produktiver Rollout
Die Aktivierung kann gezielt angestoßen und gesteuert werden, beispielsweise durch die von Microsoft beschriebenen Systemmechanismen, Registry-Parameter oder geplante Systemtasks. In Cloud- oder MDM-verwalteten Umgebungen kann dies über entsprechende Verwaltungsrichtlinien erfolgen.
Ziel ist es, die Umstellung und ihre möglichen Fehler kontrollierbar zu halten.
4. Technische Verifikation und Statuskontrolle
Nach der Aktivierung ist eine technische Überprüfung erforderlich, um Fehler rechtzeitig zu erkennen.
Hierzu gehören unter anderem:
- Kontrolle der Secure-Boot-Datenbank auf erfolgreiche Hinterlegung der neuen Zertifizierungsstelle
- Überprüfung der aktualisierten Sperrliste
- Analyse relevanter Ereignisprotokolle im Bereich Secure Boot und BitLocker
- Prüfung systemseitiger Statusindikatoren über geeignete Shell-Kommandos oder Registry-Abfragen
Diese Kontrollen können manuell oder automatisiert erfolgen und sollten dokumentiert werden, um den Systemzustand nachvollziehbar zu halten.
5. Dokumentation und Monitoring
Während und nach erfolgreicher Umstellung empfiehlt sich eine strukturierte Dokumentation des Systemzustands sowie ein temporäres Monitoring geschäftskritischer Systeme.
So lassen sich mögliche Folgewirkungen frühzeitig erkennen und bewerten.
Fazit
Mit der Einführung der neuen Zertifikate stärkt Microsoft die Sicherheit des Bootvorgangs nahezu aller Windows-Systeme.
Unternehmen sollten daher die Zertifikatsablösung nicht wie ein reguläres Windows-Update behandeln, sondern als eine sicherheitsrelevante Umstellung.
Wer frühzeitig Transparenz schafft und strukturiert vorgeht, vermeidet operative Risiken.
Unterstützung bei der Umsetzung
Die Umstellung der Secure-Boot-Zertifikate betrifft direkt den Systemstart von Windows-Systemen und sollte daher sorgfältig ausgeführt werden.
Eine strukturierte Planung, kontrollierte Aktivierung und technische Validierung sind entscheidend, um operative Risiken zu vermeiden und Fehler zu minimieren.
Gerne unterstützen wir Sie bei der Analyse Ihrer bestehenden Infrastruktur, der Bewertung möglicher Risiken sowie bei der strukturierten Umsetzung der Zertifikatsumstellung.
- Matthias Weber
- Consultant
- anfrage@netlogix.de