Microsofts alte Secure-Boot-Zertifikate erreichen am heute, am 24. Juni 2026 einen wichtigen Ablaufpunkt. Besonders relevant ist der Termin für Administratoren mit älteren Google Cloud Compute Engine Shielded VMs, aktivem Secure Boot, BitLocker, LUKS oder vTPM-gebundenen Geheimnissen. Google Cloud empfiehlt vor der Umstellung eine Prüfung von Recovery Keys, Backups und Zertifikatsstatus. Damit bleibt das Thema ein zentraler Stichtag für Windows-Administratoren, betrifft aber auch Linux-Instanzen mit signierten Bootloadern.
Der Hintergrund liegt in mehreren Microsoft-Zertifikaten aus dem Jahr 2011. Das Microsoft Corporation KEK CA 2011 läuft heute am 24. Juni 2026 ab. Es dient zur Aktualisierung der Secure-Boot-Datenbanken db und dbx. Am 27. Juni folgt das Microsoft Corporation UEFI CA 2011, das unter anderem Drittanbieter-Bootloader wie den Linux Shim signiert. Am 19. Oktober 2026 läuft zusätzlich das Microsoft Windows Production PCA 2011 aus, das den Windows Boot Manager signiert.
Der Stichtag bedeutet nicht automatisch, dass betroffene Systeme sofort nicht mehr starten. Microsoft erklärt, dass Windows-Geräte weiter starten und normale Updates erhalten können. Das Risiko liegt tiefer im Bootprozess. Systeme ohne neue 2023-Zertifikate können später keine neuen Schutzmaßnahmen für Boot Manager, Secure-Boot-Datenbanken, Revocation-Listen oder künftige Bootloader-Signaturen mehr sauber übernehmen.
Google Cloud warnt vor alten Shielded VMs mit Secure Boot
Google Cloud grenzt die betroffenen Instanzen genau ein. Handlungsbedarf besteht vor allem bei Compute-Instanzen, die vor dem 7. November 2025 erstellt wurden, Secure Boot aktiviert haben und noch nicht aktualisiert wurden. Instanzen ab diesem Datum enthalten die neuen Standardzertifikate bereits in den UEFI-Firmware-Variablen. Auch Instanzen ohne Secure Boot sind nach Google Cloud nicht direkt betroffen.
Für ältere Shielded VMs empfiehlt Google Cloud eine Prüfung der Zertifikate in KEK und db. Auf Linux-Systemen kann das mit efitools oder mokutil erfolgen. Auf Windows-Systemen verweist Google Cloud auf PowerShell-Abfragen über Get-SecureBootUEFI und Confirm-SecureBootUEFI. Wichtig ist dabei nicht nur ein einzelnes Zertifikat. Sowohl KEK als auch db müssen auf die neue 2023-Generation vorbereitet sein.
Besonders kritisch sind verschlüsselte Systeme. Bei BitLocker, Virtual Secure Mode und LUKS können Änderungen an UEFI-Variablen den PCR7-Messwert im vTPM verändern. Danach kann BitLocker einen Recovery Key verlangen. LUKS-Systeme können beim Boot eine Passphrase fordern. Google Cloud empfiehlt deshalb, Wiederherstellungsschlüssel, Passphrasen und aktuelle Backups vor der Umstellung verfügbar zu haben.
| Zertifikat | Ablauf | Rolle |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | 24. Juni 2026 | Aktualisiert db und dbx |
| Microsoft Corporation UEFI CA 2011 | 27. Juni 2026 | Signiert Drittanbieter-Bootloader wie Linux Shim |
| Microsoft Windows Production PCA 2011 | 19. Oktober 2026 | Signiert den Windows Boot Manager |
Auch die Reihenfolge spielt eine Rolle. Google Cloud empfiehlt, neue db– und KEK-Zertifikate vor neuen Kernel-, Bootloader- oder Shim-Updates einzuspielen. Andernfalls kann Secure Boot später eine Signatur nicht mehr validieren. Für Linux-Admins ist dieser Punkt besonders wichtig, weil neue Shim- oder Bootloader-Versionen künftig stärker auf die 2023-Zertifikate setzen können.
Windows und Linux brauchen unterschiedliche Prüfpfade
Windows-Admins sollten zuerst klären, ob Secure Boot aktiv ist, ob BitLocker oder VSM genutzt wird und ob Event ID 1801 im Systemprotokoll auftaucht. Diese Meldung weist auf benötigte Secure-Boot-Schlüsselupdates hin. Anschließend sollten Recovery Keys geprüft und die neuen Zertifikate kontrolliert werden. Der ältere Ghacks-Hinweis zu Secure-Boot-Zertifikaten im Juni 2026 bleibt dafür die passende Grundlage.
Linux-Admins müssen zusätzlich auf Shim, Bootloader, Kernel-Updates und eigene Schlüsselmodelle achten. Google Cloud nennt einen Bootfehler vor allem dann als möglich, wenn Secure Boot aktiv ist, die db-Variable die Microsoft UEFI CA 2023 nicht vertraut und ein neuer Shim oder Bootloader nur noch mit dem 2023-Zertifikat signiert wurde. Das ist kein sofortiger Massenfehler, aber ein klares Risiko für spätere Wartungsfenster. Der Blick auf Linux-Kernel-Sicherheitslücken zeigt, warum Bootloader- und Kernel-Updates nicht dauerhaft blockiert werden dürfen.
Custom Images und eigene Secure-Boot-Schlüssel erhöhen die Komplexität. Google Cloud schreibt, dass Standard-Update-Dateien bei eigenen PK- oder KEK-Konfigurationen nicht einfach greifen. UEFI verlangt dann Signaturen mit dem privaten Schlüssel aus der eigenen Schlüsselhierarchie. Unternehmen mit eigenen Secure-Boot-Variablen müssen die Updates also selbst signieren oder über ihre eigene Zertifikatsstelle verwalten.
Der Admin-Fokus sollte deshalb auf einer klaren Reihenfolge liegen: betroffene Instanzen inventarisieren, Secure-Boot-Status prüfen, Recovery Keys sichern, Snapshots oder Backups erstellen, KEK und db aktualisieren, danach Bootloader- und Kernel-Updates planen. Für produktive Server gehört ein Wartungsfenster dazu. Das gilt umso mehr bei verschlüsselten Systemen, weil ein ungeplanter Recovery-Prompt aus einem normalen Zertifikatsupdate einen Ausfall machen kann.
Die Zertifikatsumstellung reiht sich in eine breitere Phase sicherheitskritischer Infrastrukturpflege ein. Betreiber mussten zuletzt auch bei Chrome-Zertifikatsregeln und bei Veeam Backup & Replication schnell reagieren. Secure Boot ist weniger sichtbar als eine klassische Schwachstelle, schützt aber genau den frühen Startpfad, den Bootkits und spätere Bootloader-Angriffe ausnutzen können.
Der 24. Juni 2026 ist deshalb kein Panikdatum, aber ein klarer Admin-Stichtag. Systeme mit alten Secure-Boot-Zertifikaten laufen nicht sofort aus dem Betrieb. Ohne Prüfung und Umstellung steigt jedoch das Risiko, dass spätere Bootloader-, Kernel- oder Sicherheitsupdates nicht mehr sauber funktionieren. Für Windows-, Linux- und Cloud-Teams ist jetzt der richtige Zeitpunkt, Zertifikate, Schlüssel, Recovery-Prozesse und Rollback-Pläne zusammenzuführen.