MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

UEFI Secure Boot/BlackLotus/PKFail

Im Sommer 2025 gingen einige Meldungen durch die Presse, dass Windows bald nicht mehr booten könnte, weil Zertifikate ablaufen und alte PCs, die keine BIOS-Updates mehr bekommen würden, davon betroffen sind. Und dann gibt es noch "BlackLotus". Beide haben was mit einer "Windows UEFI 2011 CA", die schon lange nicht mehr vertrauenswürdig ist.

Die im folgenden beschrieben Lücken durch BlackLotus und PKFail ist bedingt kritisch, da man zur Ausnutzung auf dem Geräte als lokale Administrator/System sein muss, um dann eine persistente Malware zu hinterlegen, die mit geeigneten Mitteln vermutlich erkannt werden kann. Nur wer achtet auf die Zeichen, wenn man es nicht weiß? Der zwangsweise Wechsel bis zum Okt 2026 ist da aus meiner Sicht das größere Risiko.
Wenn der Hersteller es Betriebssystems (nicht nur Microsoft)  nach dem Okt 2026 einen neuen Bootloader veröffentlicht, werden die Computer ohne das entsprechende Update vermutlich nicht mehr booten.

Ich habe das Thema auch als Audiodatei für einen Podcast aufbereitet
uefi_secure_boot_blacklotus.mp3

Am 13. Nov 2025 hat Microsoft eine Vorgehensweise beschrieben.
Secure Boot playbook for certificates expiring in 2026
https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235 

Worum geht es?

Um sicherzustellen, damit beim Start eines Computers sich keine Malware schon an früh im System verankert, wenn z.B. noch kein Virenscanner aktiv sein kann, hat sich das UEFI-Forum die Funktion "Secure Boot" definiert. Schon das Bios des Herstellers soll beim Booten prüfen, dass der Windows Bootloader (bootx64.efi) digital signiert ist, ehe dieser dann das ebenfalls signierte Windows-Betriebssystem startet. Dazu muss das System die Zertifikate der Zertifizierungsstellen hinterlegt haben und einige laufen im Oktober 2026 aus.

Aber das nicht nicht alles. Am Mai 2023 Patchday hat Microsoft auch den Support-Artikel KB5025885 veröffentlicht, welcher eine Schwachstelle beschreibt, über die das "BlackLotus-Boot-Kit" ein System trotz Secure Boot kompromittieren kann. Diese Updates sind in jedem Security Updates seit Mail 2023 mit enthalten aber noch nicht (Stand Juli 2025) by Default aktiv. Wir haben also zwei Aktionen zum Thema Secure Boot:

  1. UEFI-Zertifikate prüfen/erneuern
    Hier sollte ein normaler Windows Client mit Updates schon länger kein Problem damit haben aber zur Sicherheit können wir dies testen. Microsoft will in dem Zuge auch die Zertifikate aktualisieren, die zur Signatur von Linux UEFI-Loadern signiert werden
  2. Absicherung gegen BlackLotus
    Solange Microsoft die hierzu notwendigen Schritte nicht per Default aktiviert, können Sie diese vorab selbst durchsetzen.
  3. Ggfls. Developer PK-Key entfernen
    AMI hat es geschafft, ein Test-Zertifikat auf produktive Systeme zu installieren, dessen privater Schlüssel öffentlich ist.

Ich nehme die Themen zum Anlass, mir das Thema "Secure Boot" genauer anzuschauen. Danach sollten Sie wissen, wie sie die UEFI-Zertifikate prüfen können und die Schutzmaßnahmen gegen "BlackLotus" schon früher aktivieren.

Achtung:
Windows Clients werden per Windows Updates automatisch aktualisiert, wenn es laut Telemetriedaten "sicher" ist.
Wenn Sie Telemetrie abgeschaltet haben, bekommen Sie angeblich keine automatische Updates.
Server und VMs werden wohl nicht automatisch aktualisiert.

Wann Secure Boot nicht mehr bootet

Die Funktion "Secure Boot" schützt ihr Endgerät davor, dass Angreifer sehr früh ihr System zu ihrem Nachteil verändern. Die Absicherung der Startumgebung gibt es nicht nur auf PCs mit Windows, sondern auch bei Smartphones und anderen Geräten und ist quasi "üblich" und sollte nicht abgeschaltet werden.

Secure Boot uses certificate-based trust hierarchy to ensure that only authorized software runs during system startup. At the top of this hierarchy is the Platform Key (PK), typically managed by the OEM or a delegate, which acts as the root of trust. The PK authorizes updates to the Key Enrollment Key (KEK) database, which in turn authorizes updates to two critical signature databases: the Allowed Signature Database (DB) and the Forbidden Signature Database (DBX). 
Quelle: Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog
https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856

Ehe wir auf die Fehlerszenarien eingehen, daher in einfachen Worten noch mal die Eckpunkte zum Verständnis. Es gibt vier "Speicher" in ihrem Computer, die für UEFI und Zertifikate relevant sind.


Quelle: Microsoft https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#13-secure-boot-pki-requirements

Die Funktion der Speicher ist

Speicher Update durch Beschreibung

Platform Key (PK)

Vendor

Das sind die "Stammzertifizierungsstellen", von denen alle anderen Zertifizierungsstellen abgeleitet sind. In dem Speicher liegt genau ein PK-Zertifikat des Herstellers. Wenn kein Zertifikat vorhanden ist, sollte das Bios in einen "Setup"-Mode gehen, damit sie ein Zertifikat einspielen können. Offiziell kann nur der Hersteller durch ein Firmware Updates auch diesen Key ersetzen. Es gibt Anleitungen, wie sie einen eigenen Key einspielen. Das Risiko ist aber hoch den PC unbrauchbar zu machen, z.B. wenn z.B. das ROM der Grafikkarte ebenfalls mit dem PK des Herstellers signiert ist.

Key Exchange Key (KEK)

Vendor, Microsoft, Admin

Die Zertifikate im KEK-Speicher dienen dazu, die Updates für die DB und DBX-Datenbank zu verifizieren. Es kann mehrere KEK-Zertifikate geben aber auch dieses Liste wird durch den Hersteller durch Firmware-Updates aktualisiert. Hier gibt es ein "Microsoft Corporation KEK CA 2011", welches ebenfalls 2026 ausläuft.

The Microsoft Corporation KEK CA 2011 is set to expire in 2026, and all OEMs must create, sign, and submit updates for the new Microsoft Corporation KEK CA 2023 to Microsoft
Windows Secure Boot Key Creation and Management Guidance
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11

Sie können die Zertifikat auch selbst in den Speicher hochladen. Allerdings muss das Update durch den passenden Platform Key (PK) signiert sein.

https://aka.ms/KEKUpdatePackage

https://github.com/microsoft/secureboot_objects/

DB

Vendor, Microsoft, Admin

Liste der Zertifizierungsstellen oder Hashwerte von EFI Bootloader oder Programmen. Ein Update hängt in der Regel weitere Zertifikate einfach hinten an. Das Update muss durch ein KEK-Zertifikat signiert sein.

https://github.com/microsoft/secureboot_objects/

Windows UEFI CA 2023.crt
https://go.microsoft.com/fwlink/?linkid=2239776 

DBX

Vendor, Microsoft, Admin

Liste der Zertifizierungsstellen, die aktiv zurückgezogen wurden. Ein Update hängt in der Regel weitere Zertifikate einfach hinten an. Das Update muss durch ein KEK-Zertifikat signiert sein.

https://github.com/microsoft/secureboot_objects/

Damit können wir folgende vereinfachte Aussagen machen:

  • SecureBoot verhindert, dass fremder Code ausgeführt wird und stellt eine sichere Startumgebung bereit
    Zu dem Zeitpunkt gibt es noch keine Virenscanner aber auch keinen Zugriff auf Internet (CRLs)
  • Die Firmware/Bios des PCs prüft jede Codesignatur gegen die Zertifikate
    Die Zertifikate in DB/DBX müssen durch ein Stammzertifikat in PK signiert sein.
    Ist der Signierer in DBX: Ja -> Abbrechen, Nein -> Weiter
    Ist der Signierer in DB: Ja -> Booten, Nein -> Abbruch
  • Zeitstempel statt aktueller Zeit
    Eine Signierung durch ein abgelaufenes Zertifizierungsstellenzertifikat ist nicht automatisch ungültig. In der Signatur ist ein Zeitstempel enthalten, auf den sich der Zeitpunkt bezieht. Daher können Sie ja auch noch
  • Rückruf nur durch DBX
    Wenn ein Zertifizierungsstellenzertifikat oder ein Bootloader nicht mehr "vertrauenswürdig" ist, dann muss es über die DBX-Datenbank gesperrt werden, z.B.: um ein schwaches Zertifikat zu sperren, welches von der "BlackLotus"-Lücke genutzt wird.

Die beiden folgenden Abschnitte beschreiben die beiden Probleme, die Computer-Administratoren seit Mai 2023 und bis Oktober 2026 beschäftigen.

Elefant 1: Ablauf Issuing CAs (KEK/DB)

In dem Bild mit den Zertifikaten sehen Sie, dass es ein Plattform-Zertifikat "PK" und je ein Zertifikat in KEK und DB gibt. Die beiden von Windows auch 2025 noch genutzten Zertifikate laufen 20265 aus. Das ist eigentlich nicht überraschend, da jegliches Zertifikat eine endliche Gültigkeit hat. Schon im Jahr 2011 hat Microsoft damals die erste Zertifizierungsstelle für UEFI aufgebaut und über die Hersteller hinterlegen lassen. Die "Microsoft RootCA" hat damals eine Gültigkeit von 25 Jahren, was aus damaliger Sicht schon sehr lange war. Denken Sie nur an die Haltbarkeit von Computern und Betriebssystemen. zudem gibt es Issuing CAs, die mit 15 Jahren kürzer gültig sind und genau die laufen im Okt 2026 aus. Microsoft schreibt dazu:

Microsoft requires every OEM to include the same three certificates managed by Microsoft for Windows and in support of the third-party hardware and OS ecosystem. These include the Microsoft Corporation KEK CA 2011 stored in the KEK database, and two certificates stored in the DB called the Microsoft Windows Production PCA 2011, which signs the Windows bootloader, and the Microsoft UEFI CA 2011 (or third-party UEFI CA), which signs third-party OS and hardware driver components. All three of these Microsoft certificates expire in 2026.
Quelle: Updating Microsoft Secure Boot keys | Windows IT Pro blog
https://techcommunity.microsoft.com/blog/windows-itpro-blog/updating-microsoft-secure-boot-keys/4055324

Daher hat Microsoft schon 2023 neue Zertifikate bereitgestellt, die seit März 2023 in jedem Security Update für Windows immer wieder enthalten sind. Sie werden aber anscheinend nicht noch automatisch installiert. Microsoft schreibt dazu.

All three of these Microsoft certificates expire in 2026. So, in collaboration with our ecosystem partners, Microsoft is preparing to roll out replacement certificates that will set new UEFI CA trust anchors for the future. Microsoft will be rolling out Secure Boot database updates in phases to add trust for the new DB and KEK certificates. The first DB update will add the Microsoft Windows UEFI CA 2023 to the system DB. The new Microsoft Windows UEFI CA 2023 will be used to sign Windows boot components prior to the expiration of the Windows Production CA 2011. This DB update will be optional for the February 2024 servicing and preview updates, and can be manually applied to devices. Microsoft will slowly roll out this DB update as we validate devices and firmware compatibility globally. The full DB update’s controlled-rollout process to all Windows customers will begin during the 2024 April servicing and preview updates, ahead of the certificate expiration in 2026. Meanwhile, efforts to update the Microsoft UEFI CA 2011 (aka third-party UEFI CA) and Microsoft Corporation KEK CA 2011 will begin late 2024, and will follow a similar controlled rollout process as this DB update.
Quelle: Updating Microsoft Secure Boot keys | Windows IT Pro blog
https://techcommunity.microsoft.com/blog/windows-itpro-blog/updating-microsoft-secure-boot-keys/4055324

Zum Zeitpunkt des Artikels (Aug 2025) hatte noch keines meiner Systeme eines der neuen Zertifikate. Es ist also höchste Zeit dies vor der Deadline Okt 2026 zu prüfen solange der Computer noch läuft. Die erforderlichen Updates hat Windows seit Feb 2024 bekommen.

The DB update is available on February 13, 2024, along with manual steps to allow customers to test for firmware compatibility, especially for organizations with fleets of devices. If you would like to manually apply the DB update to validate that your system is compatible, please read the following instructions.
Quelle: Updating Microsoft Secure Boot keys | Windows IT Pro blog
https://techcommunity.microsoft.com/blog/windows-itpro-blog/updating-microsoft-secure-boot-keys/4055324

Für die meisten Aktionen benötigen Sie lokale Admin-Rechte

Zuerst könnten wir ja einmal prüfen, ob im UEFI-BIOS schon die nachfolge-CA von Microsoft installiert ist. Das geht recht schnell per PowerShell:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).bytes) -match 'Windows UEFI CA 2023'

Das Commandlet "Get-SecureBootUEFI" liest mit dem Parameter "-Name DB" die Datenbank aus. Die Rückgabe ist leider Binäre aber es reicht aus, das Byte-Array zu einem Text zu konvertieren und nach dem String der neuen DB-CA zu suchen.

Ein "True" sagt, dass alles die aktualisierte Zertifizierungsstellt schon installiert ist. Im gleichen Zug sollten sie auch prüfen, ob das KEK-Zertifikat ebenfalls schon installiert ist

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

Auch hier sollte ein "True" kommen. Dann ist ihr Computer zumindest darauf vorbereitet, dass Microsoft irgendwann die  Boot-Loader auch mit diesen neuen Zertifizierungsstellen digital signiert. Sollte das aber nicht der Fall sein, dann könnte ihr System nicht mehr starten, wenn folgende Bedingungen zusammenfallen:

  1. Es ist nach dem 13. Okt 2026 sein
    Denn dann ist das Windows UEFI CA 2011 nicht mehr vertrauenswürdig.
  2. Secure Boot ist aktiviert
    Das dürfte aktuell bei den meisten Computer zutreffen.
  3. Der UEFI Loaders ist mit einem nicht vertrauenswürdigen Zertifikat signiert
    Er wurde mit der "Microsoft Windows Production PCA 2011" signiert, die dann abgelaufen oder zurückgezogen wurde.
    Er wurde mit einer neueren CA signiert, die auf dem Computer nicht hinterlegt ist.

Das ist dann natürlich noch lösbar, indem Sie z.B. Secure Boot abschalten, was aber beim Start die Eingabe eines Bitlocker-Keys erforderlich macht. Ein Firmware-Update auf dem PC könnte auch helfen. Ebenso der Start mit einem anderen Betriebssystem um die DB/KEK/PF-Schlüssel zu erweitern. 

Elefant 2: BlackLotus

Der zweite Thematik ist durch eine Sicherheitslücke begründet, über die Angreifer mit physikalischem Zugriff auf den Computer die Secure Boot-Umgebung unbemerkt verändern kann. Er könnte also einen alternativen Bootloader oder eine Malware im System unterbringen ohne das die Computerfirmware beim Start dies erkennt und verhindert. Das Kit installiert sich auf die EFI-Partition und wird nach dem Neustart am Anfang geladen und kann sich damit im System trotz Secure Boot verankern und Virenscanner und andere Schutzprogramme schon am Start hindern.

Die eigentliche Schwachstelle wurde schon 2022 gefixt aber dadurch gültig digitalisierte Programme wurden nicht sofort ungültig erklärt, so dass sie immer noch aktiv werden können. Da man allein aufgrund der Menge nicht alle Bootloader auf eine Revokation-List setzen kann, ist die Lösung eine Sperrung der "Microsoft UEFI CA 2011", die zum Signieren genutzt wurde. Daher möchte Microsoft dieses Zertifikat lieber heute als morgen "ungültig" machen. Das geht aber nur, wenn die Trusted CA-Liste in der UEFI-Firmware aktualisiert wurden.

Es reicht also nicht auf den Oktober 2026 zu hoffen, ab dem die "Microsoft UEFI CA 2011" abgelaufen ist. Damit werden Signaturen davor signierter Dateien noch nicht ungültig.

Die "BlackLotus"-Lücke ist ein eigener Vorgang aber betrifft natürlich auch das im Oktober 2026 ablaufende "Microsoft UEFI 2011 CA"-Zertifikat.

Elefant 3: PKFail

Als wenn dem noch nicht genug ist, gibt es seit 2024 noch ein Risiko. Ganz am Anfang habe ich erläutert, wie der Hersteller der Hardware einen "Plattform-Key" mit dem Computer ausliefert, der dann die KEK Datenbank signiert. In der sind die Zertifizierungsstellen hinterlegt, mit denen die KEK, DB und DBX-Datenbanken aktualisiert werden können. Es beginnt also alles beim Vertrauen in das Plattform-Key Zertifikate des Herstellers. Die gibt es von AMI, LENOVO, MICROSOFT, DELL, HP und einigen anderen.

Dumm nur, wenn der Hersteller des Bios einen "Test-Schlüssel" verwendet, dessen dazugehöriger private Schlüssel nicht wirklich privat ist. Der BIOS-Hersteller AMI hat dazu extra einen "Test-Key" der den String "CN=DO NOT TRUST - AMI Test PK" oder "CN=DO NOT SHIP - AMI Test PK" Als Issuer und CN hat. Damit kann ein Angreifer mit dem bekannten Schlüssel eigene Bootloader auf solchen Computern platzieren

Das ist natürlich kein Fehler im UEFI/EFI Secure Boot Konzept an sich, denn irgendwo muss ja die Wurzel des Vertrauens liegen und der BIOS/Motherboard-Hersteller ist die erste Instanz, die ihren Plattform-Key installiert. Die Nutzung "Test-Schlüssels" ist natürlich eine große Lücke im Build-Prozess. Die Details werden wohl im Dunkeln bleiben. Sie können aber schauen, ob einer der Computer eine Firmware mit einem solchen einen solchen PK-Schlüssel hat.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"

"$False" ist gut und ein "$True" ist schlecht, denn dann kann das Gerät durch PKFail kompromittiert werden und benötigt ein Firmware-Update des Herstellers, bei dem aber auch alle PK KEK und DB-Einträge zurückgesetzt werden müssen.

 

 

Ob PKFail aber schon aktiv war und welche sonstige Malware auf dem Computer ist, ist damit nicht ermittelbar. Im Zweifel nehmen sie das Gerät ab besten offline, kopieren Daten, solange dies noch geht, prüfen diese auf Malware-befall und installieren den Computer nach dem Firmware Update neu. Es könnte sein, dass er nach dem Firmware-Update sowieso nicht mehr bootet

DE Proof of Concept for PKfail (Linux version)
https://www.youtube.com/watch?v=CveWt3gFQTE

Proof of Concept for PKfail
https://www.youtube.com/watch?v=SPl7zfC-CmQ

Eventlog

Es ist natürlich klar, dass Microsoft die Millionen Endgeräte nicht ins Verderben laufen will. Über Windows Update hat Microsoft dasWerkzeug,nichtnur Windows Fehler und Sicherheitslücken zu korrigieren, sondern auch Zertifikate zu aktualisieren und sogar Firmware-Updates zu verteilen. Dazu benötigt Microsoft natürlich die Informationen über ihr Gerät, um zum einen den aktuellen Status der Zertifikate zu sehen und auch verfügbare Updates für z.B. das BIOS ihres Computers ermitteln zu können.

Es ist dazu laut Microsoft erforderlich, dass Sie die Telemetrie-Funktionen nicht ausgeschaltet haben.

Aber auch dann werden nicht alle Computer der Welt zur gleichen Zeit umgestellt. Microsoft steuert über Windows Updates, dass erst ein paar Systeme aktualisiert werden und aus den Telemetriedaten dann weitere Systeme ausgewählt werden. Bei Problemen kann Microsoft zumindest für die nächsten gleichen Systeme das Update verzögern und Fehler korrigieren. Sie können die Aktionen auch im Eventlog nachvollziehen.  Suchen Sie einfach nach "UEFI" im System-Eventlog. Hier ein Beispiel:

Folgende Events habe ich bislang im System-Eventlog gefunden:

Protokollname: System
Quelle:        Microsoft-Windows-TPM-WMI
Datum:         20.01.2026 10:25:17
Ereignis-ID:   1808
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      FC-T14G5
Beschreibung:
Dieses Gerät hat die Zertifizierungsstelle/Schlüssel für den sicheren Start aktualisiert. Diese Gerätesignaturinformationen sind hier enthalten.
DeviceAttributes: FirmwareVersion:R2LET37W (1.18 );OEMManufacturerName:LENOVO;OEMModelSKU:LENOVO_MT_21MC_BU_Think_FM_ThinkPad T14 Gen 5;OSArchitecture:amd64;
BucketId: 3d543305c3de3f5284de501776f5ee02dc9c1043d2e7344b795527964ebe1b41
BucketConfidenceLevel: 
UpdateType: Windows UEFI CA 2023 (DB), Option ROM CA 2023 (DB), 3P UEFI CA 2023 (DB), KEK 2023, Boot Manager (2023)
Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2301018.

Interessanterweise kommt die Meldung mehrfach:

 

Laut Microsoft sind die Events 1801 und 1808 interessant und können entsprechend überwacht werden:

Get-WinEvent `
   -FilterHashtable @{LogName='System'; ID=@(1801,1808)} `
   -MaxEvents 20

Der 1808 ist ein "Erfolgreich"-Event, während der 1801 einen Fehler meldet und sie alarmieren sollte

Geordnetes Rollout über "AvailableUpdates"

Wir haben also zwei "Elefanten im Raum", über die niemand gerne spricht aber nachdem sie bis hier gelesen haben, können Sie es nicht mehr verschwiegen. Es gibt sogar zwei Elefanten

  • Ablauf der PCA 2011 CA im UEFI-Bios
  • Sperren der PCA 2011 CA  als Schutz gegen BlackLotus

Danach gibt es auf jeden Fall neue UEFI Loader und die neue IssuingCA muss auf ihrem Computer installiert sein. Vermutlich wird Microsoft schon vorher die letzte Phase ein Wellen einleiten, um über die Telemetrie zu erfahren, wie es nach dem Ablaufen der CA aussieht. Wenn wir den KB-Artikel zu BlackLotus anschauen, dann ist Microsoft in der vorletzten Phase:


Quelle: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support
https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d

Ich würde schon jetzt anfangen, die Umstellung auf die neue CA durchzuführen.

Ich habe mir daher im Sommer 2025 die nachfolgende Checkliste erstellt und auch getestet. Mittlerweile hat Microsoft selbst aber eine eigene Beschreibung veröffentlicht, die aber andere Werte für den "AvailableUpdates" verwendet. Bei meiner Checkliste wird der Wert durch den geplanten Task immer wieder auf "0" zurückgesetzt. Bei der alternativen Microsoft-Beschreibung wird der Schlüssel auf unterschiedliche Werte geändert. Aus der Beschreibung habe ich folgende Bedeutung der der Bit generiert.

Bit 00   0x0001
Bit 01   0x0002
Bit 02   0x0004  ADdiere den "KEK" Key Exchange Key, welcher durch den Platform Key (PK) des OEM signiert ist
Bit 03   0x0008
Bit 04   0x0010
Bit 05   0x0020
Bit 06   0x0040  Addiere Windows UEFI 2023 Zertifikat in die Secure Boot DB
Bit 07   0x0080  Setze "Microsoft Windows Production PCA 2011" auf die Sperrliste
Bit 08   0x0100  Ersetze den alten Bootmanager durch einen durch die Windows UEFI CA 2023 signierten Bootmanager
Bit 09   0x0200  SVN-Zähler aktivieren
Bit 10   0x0400
Bit 11   0x0800  Addiere "Microsoft Option ROM UEFI CA 2023" in die Datenbank.  
Bit 12   0x1000  Addiere "Microsoft UEFI CA 2023" Key in die Datenbank
Bit 13   0x2000
Bit 14   0x4000  "Microsoft Corporation UEFI CA 2011" muss erst in der DB sein, ehe Bit 11 und 7 wirken
Bit 15   0x8000

Microsoft beschreibt auf https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f ein empfohlenes Vorgehen: Sie setzen den Wert einfach auf 0x5944 und dann durchläuft Windows Update die Phasen alleine.

Start: 0x5944
0x0040 → 0x5904 (Applied the Windows UEFI CA 2023 successfully)
0x0800 → 0x5104 (Applied the Microsoft Option ROM UEFI CA 2023 if needed)
0x1000 → 0x4104 (Applied the Microsoft UEFI CA 2023 if needed)
0x0004 → 0x4100 (Applied the Microsoft Corporation KEK 2K CA 2023)
0x0100 → 0x4000 (Applied the Windows UEFI CA 2023 signed boot manager)

Die "Arbeit" macht natürlich ein alle 12 Stunden geplanter Task, den wir auch manuell starten können.

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x5944
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”

Allerdings werden wohl nicht alle Aktionen auf einen Rutsch durchgeführt, sondern ggfls. sind Neustarts erforderlich. Über den Registrierungsschlüssel können Sie acuh den Status abfragen

if ((Get-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates”) -ne 0){
  Write-Host "UEFI-Updates stehen noch aus"
}

Der Eintrag kann aber auch für Fehlersuche genutzt werden.

The AvailableUpdates registry key on a device is set to 0x4104. If it doesn't clear the 0x0004 bit even after multiple restarts, the device doesn't progress past deploying the new Key Exchange Key (KEK) certificate. If you encounter this error, check with your OEM to confirm they have followed the steps
Quelle: https://support.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f

 

Damit sollte ein Rollout mit den WindowsUpdates von Feb 2026 auf den meisten Systemen möglich sein.

Auf seiner Seite schreibt Microsoft, dass ein Wert von "0x5944 = 0001 0111 0011 1000" alles macht. Allerdings sind hier auch Bit 3, 4, 5, 10,12 gesetzt, zu denen ich keine Bedeutung kenne.

Ich lasse daher meine Checkliste von damals noch bestehen, bis ich weitere Informationen habe. Ich gehe aber auch davon aus dass Microsoft über Windows Updates vermutlich eh alle Updates so nach und nach automatisch ausrollt und Sie als Administrator sich erst einmal auf die Überwachung konzentrieren sollten.

Checkliste für manuelle Aktualisierung

Die Checkliste führt die entsprechenden Aktivitäten weiter aus:

Prüfschritt Erledigt

Microsoft UEFI 2023 CA installiert?

Prüfen Sie, ob die neue "Microsoft UEFI 2023 CA" schon auf ihrem Computer ist.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

Ansonsten können Sie das Update wie folgt installieren:

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

Der Registrierungsschlüssel wird durch den Task wieder auf 0x0 zurück gestellt. Im Eventlog finden sie dazu:

Log Name: System
Source: Microsoft-Windows-TPM-WMI
Event ID: 1036
Task Category: None
Level: Information
Keywords: 
User: SYSTEM
Description:
Secure Boot Db update applied successfully 

Die Suche mit Get-SecureBootUEFI liefert danach ein True.

Achtung: Damit die neue CA auch aktiv wird, ist ein oder manchmal zwei Reboots des Computers erforderlich.

Wer signierte den aktuellen Bootmanager?

Dazu mounten Sie zuerst die EFI-Partition und lassen sich den Aussteller der Signatur anzeigen.

# PowerShell als Admin 
mountvol S: /S
(Get-PfxCertificate -FilePath "S:\EFI\Microsoft\Boot\bootmgfw.efi").issuer
(Get-PfxCertificate -FilePath "S:\EFI\Boot\bootx64.efi").issuer
mountvol S: /D
  

Auf meinem Windows 11 24H2 stand am 4. Aug 2025 aber auch noch.

Wenn es noch "CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ist, dann steht ein Update des Bootloaders an.

Es könnte sein, dass danach ihr System nicht bootet. Sie sollten sich vorher die Bitlocker-Schlüssel sichern. Zudem sollten sie ein eventuell vergebenes BIOS-Kennwort kennen.

Die Installation besteht aus einem Registrierungsschlüssel und einen geplanten Task und die Prüfung.

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

Wenn Sie erst kurz vorher die 2023 CA addiert haben, dann könnten Sie zuerst folgende Meldung sehen:

Log Name: System
Source: Microsoft-Windows-TPM-WMI
Event ID: 1800
Task Category: None
Level: Warning
Keywords: 
User: SYSTEM
Description:
A reboot is required before installing the Secure Boot update. Reason: 3

Der Registrykey bleibt aber gesetzt, d.h. direkt nach dem Neustart wird dann der Bootloader signiert. Im Eventlog sollten sie folgende Meldung sehen:

Protokollname: System
Quelle: Microsoft-Windows-TPM-WMI
Ereignis-ID: 1799
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:
Benutzer: SYSTEM
Beschreibung:
Boot Manager signed with Windows UEFI CA 2023 was installed successfully

Wer vorsichtig ist, prüft hier noch mal den Signierer des Bootmanager mit

# PowerShell als Admin
mountvol S: /S
(Get-PfxCertificate -FilePath "S:\EFI\Microsoft\Boot\bootmgfw.efi").issuer
(Get-PfxCertificate -FilePath "S:\EFI\Boot\bootx64.efi").issuer

Das Ergebnis sollte wie folgt aussehen:

Wer auf Nummer sicher gehen möchte, dass die neue Konfiguration funktioniert. sollte vor dem nächsten Schritt einen Neustart durchführen. Noch könnten Sie den Bootloader ja wieder durch eine ältere Version tauschen oder ein Backup einspielen.

  

"Microsoft Windows Production PCA 2011" sperren

Wenn Sie sicher sind, dass die neue Umgebung funktioniert, sollten Sie das zu sperrende CA-Zertifikat in die  DBX-Datenbank hochladen.

Achtung: Damit werden alle vorherigen Backups des Betriebssystem mit dem alten Bootloader nicht mehr startfähig.
Es kann also sinnvoll sein, diesen Schritt erst anzugehen, wenn einige Backups gelaufen sind und Sie ein Recovery-Image gezogen haben.

Achtung: Einige Firmen installieren weitere EFI-Loader z.B. für Diagnose-Partitionen etc. Prüfen Sie, ob all diese auch mit einer andere CA signiert sind.

Vielleicht ist das aber auch schon erfolgt. Die Existenz in der DBX-Datenbank kann wie folgt geprüft werden.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'

Sollte Sie noch nicht gesperrt sein aber alle vorherigen Schritte erfolgreich gewesen sein, dann können Sie die Sperrung aktivieren. Auch dies erfolgt nach dem schon bekannten Schema:

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

Der Task setzt auch hier den Registrierungsschlüssel nach Abschluss wieder auf 0x0 zurück. Eine Kontrolle zeigt dann, dass die 2011 CA in der Sperrliste ist.

Im Eventlog habe ich dann folgenden Eintrag gefunden. 

Protokollname: System
Quelle:        Microsoft-Windows-TPM-WMI
Ereignis-ID:   1037
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:
Benutzer:      SYSTEM
Beschreibung:
Das Update für den sicheren Start von Dbx zum Widerrufen von Microsoft Windows Production PCA 2011 wurde erfolgreich angewendet

Auch hier sollten Sie einmal einen Neustart ausführen, um die Funktion zu verifizieren.

  

SVN Zähler

Alle bisherigen Maßnahmen verhindern nicht, dass es auch zukünftig "schlechte" Bootloader gibt. Dazu hat Microsoft ein Schutzverfahren über einen "Zähler eingebaut, der im Bootmanager seit dem 9.7.2024 immer weiter hochgezählt wird. Das Updates des Zählers in der Firmware erfolgt nicht automatisch. Das kann ein Administrator manuell machen. Wenn beim Start der Zählen im Bootloader niedriger als in der Firmware ist, startet der Bootloader nicht mehr. Damit wird ein Rollback auf einen älteren Stand verhindert, was sich natürlich auch auf Backups etc. auswirkt.

Mit folgenden Zeilen wird die aktuelle SVN-Nummer in die Firmware übertragen.

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

Einen einfachen Weg den Erfolg zu kontrollieren, habe ich noch nicht gefunden. Ein Reset des EFI-Speichers wäre eine Variante, die sich in einer virtuellen Maschine vermutlich einfach prüfen lässt.

 

Deployment mit GPOs

Am 29. Sep 2025 hat Microsoft einen neuen Artikel veröffentlich, dass Sie als Administrator nun per Gruppenrichtlinien das Rollout vorgeben können. Überraschend ist dies nicht. Bis zum 14. Oktober war sogar noch WIndows 10 im Support. Danach gilt der Artikel nur noch für Windows 11 und Windows Server 2022 und neuer.

Voraussetzung ist natürlich, dass Sie die aktuellen ADMX-Dateien zur Verwaltung installieren. Erst dann finden Sie die neuen Einstellungen in der GPMC

Administrative Templates (.admx) for Windows 11 2025 Update (25H2) - V2.0
www.microsoft.com/en-us/download/details.aspx?id=108428

Das MSI-Setup extrahiert die Vorlagen per Default nach "C:\Program Files (x86)\Microsoft Group Policy\Windows 11 Oct 2025 Update (25H2)\PolicyDefinitions\". Der Pfad kann aber angepasst werden. Wer auf SYSVOL einen Ordner "PolicyDefinitions" hat, kopiert die neuen Vorlagen einfach dort hinein. Danach können Sie über Gruppenrichtlininen drei Einstellungen aktivieren.

Sie können hier also nicht "einzelne Bits" setzen, sondern einfach nur "Enable", "Disable" und "nicht konfiguriert" angeben. Alle Einstellungen wirken auf die bekannten Schlüssel unter SYSTEM\CurrentControlSet\Control\SecureBoot\

AvailableUpdatesPolicy      Enabled=22852, Disabled=0
HighConfidenceOptOut        Enabled=    1, Disabled=0
MicrosoftUpdateManagedOptIn Enabled=22852, Disabled=0 

Aus 22852dez wird 0x5944 oder Bit 2,5,7,10,11,13, von denen aber auch nicht alle genau bekannt sind. Wir können nur drauf vertrauen, dass Microsoft das irgendwie richtig macht.

WinCSFlags

Seit Oktober sollte sich auf jedem Client (Windows 11 und Server 2022 und höher) auch das Programm "WinCSFlags.exe" befinden, welche als Administrator gestartet die Details des Rollouts liefern und Vorgaben setzen kann. Mit dem Parameter "/query" bekommen Sie die aktuelle Einstellung:

Die Beschreibung gibt nicht sehr viel her aber über Suchmaschinen landen Sie schnell auf den entsprechenden Seiten:

F33E0C8E001 Die neuen SecureBoot Zertifikate sind noch nicht aktiv
F33E0C8E002 Feature_AllKeysAndBootMgrByWinCS neuen SecureBoot Zertifikate werden aktiviert oder sind schon aktiv

Im Grunde liest und schreibt die EXE wohl auch nur die Registrierungsschlüssel. Um SecureBoot zu aktualisieren, müssen Sie die Konfiguration "F33E0C8E002" anwenden, z.B. mit

WinCsFlags.exe /apply --key "F33E0C8E002"

Das bedeutet aber noch nicht, dass die Konfiguration aktiv ist der "geplante Task" läuft nur alle 12 Stunden.

Linux?

Bei der Entwicklung der UEFI hat sich natürlich Microsoft sehr stark engagiert und sehr schnell haben Hersteller "Secure Boot" als neuen Default aktiviert. Damit waren nicht signierte Bootloader nicht mehr startfähig, es sei denn sie haben SecureBoot wieder abgeschaltet. Man wollte aber auch nicht, das jeder, der einen eigenen Bootloader schreibt, auch ein Signing-Zertifikat bekommt. Microsoft hat das Problem so entschärft, dass Sie einen minimalen Linux-Bootloader ("Shim") signiert haben, der zwischen Bios und eigentlichem Linux-Loader steht.

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that are signed by Microsoft. Most modern systems will ship with Secure Boot enabled - they will not run any unsigned code by default. Starting with Debian version 10 ("Buster"), Debian supports UEFI Secure Boot by employing a small UEFI loader called shim which is signed by Microsoft and embeds Debian's signing keys. This allows Debian to sign its own binaries without requiring further signatures from Microsoft. Older Debian versions did not support Secure Boot, so users had to disable Secure Boot in their machine's firmware configuration prior to installing those versions.
Quelle: SecureBoot - Debian Wiki https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot.3F

So können auch Linux-basierte Betriebssysteme auf Computern starten, die Secure Boot aktiv haben. Es soll sogar Systeme geben, bei denen SecureBoot nicht abgeschaltet werden kann.

Der Linux-Shim ist aber auch mit dem "Microsoft PCA 2011"-Zertifikat signiert, die am 17. Okt 2026 abläuft und ein danach installiertes oder aktualisiertes Linux kann einen neueren "Shim" mitbringen, der dann natürlich von einer Zertifizierungsstelle signiert wurde. Wenn diese dann aber nicht im UEFI-Speicher, d.h. der "DB"-Datenbank liegt, startet der Client nicht. Für Linux würde ich daher folgende Schritte vorsehen:

  1. Kontrolliere die Zertifikate in DB
    Hier sollte auch das Microsoft PCA 2023-Zertifikat erscheinen. Ansonsten installieren Sie es von Hand, da ich vermute, dass zukünftige Linux-"Shim" nach dem 17. Okt 2026 damit signiert werden
  2. Kontrolliere das Zertifikat im KEK
    Auch das von Microsoft zur Aktualisierung der Zertifikate in DB/DBX genutzte Zertifikat läuft aus. Prüfen Sie, ob das "Microsoft KEK 2K 2023"-Zertifikat installiert ist. Wenn nicht, dann sollten Sie nach einem Firmware-Update des Herstellers schauen
  3. Ggfls. PCA 2011 sperren
    Microsoft will das PCA 2011 Zertifikat wohl noch vor dem Ablaufdatum sperren, um "BlackLotus" Angriffe zu verhindern. Wenn ihr Linux-Shim schon von einem neueren Zertifikat signiert ist, könne Sie da auch für ihr Linux machen.

Das entsprechende Werkzeug für all diese Aktionen unter Linux ist MOKUTIL. Zuerst sollten Sie mal prüfen, ob ihr Linux mit Secure Boot gestartet wurde.

# Anzeigen, ob Secure Boot aktiv ist
$ sudo mokutil --sb-state

Oder

$ sudo apt install systemd-boot
$ bootctl

System:
      Firmware: UEFI x.xx (American Megatrends x.xx)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Measured UKI: yes
  Boot into FW: supported

Wenn es ohne Secure Boot mit dem BIOS-CSM läuft, dann ist das Thema heute noch nicht relevant

Mit MOKUTIL können Sie aber heute schon ihre Schlüssel in den verschiedenen Speichern anschauen.

# KEK anzeigen
$ mokutil --kek

# Platform Key (PK) anzeigen: 
$ mokutil --pk

# DB Keys anzeigen
$ mokutil --db

# DBX Keys anzeigen
$ mokutil --dbx

Sie können sogar eigene Zertifikate als vertrauenswürdig addieren, wenn Sie unbedingt eigene Bootloader kompilieren und einsetzen wollen

$ mokutil --import MOK.der

Hinweis: Eine Signierung ist auch nach Ablauf des Gültigkeitsdatum weiter gültig, da der Zeitstempel der Signierung und nicht die aktuelle Uhrzeit des Systems maßgeblich ist.

Hyper-V und andere Virtualisierer

Die Probleme mit UEFI, Secure Boot, unsicheren Bootloadern und Zertifikaten ist nicht auf Physik beschränkt. Auch eine virtuelle Maschine (VM) unter Hyper-V, VMWare, Proxmox und anderen Virtualisierer hat genau das Problem. Es ist zwar eine virtuelle Umgebung, aber jede VM hat ein UEFI-BIOS und einen eigenen Konfigurationsspeicher  mit Platzt für die PF/KEK/DB/DBX-Datenbanken.

Theoretisch könnte eine VM-Plattform natürlich auch vom Host aus die Zertifikate in allen VMs aktualisieren und austauschen. Ein Hypervisor könnte auch einen Snapshot der unverschlüsselten EFI-Partition anlegen und die Signatur der EFI-Dateien prüfen. All was müsste gar nicht im Gast ablaufen. Auf meinem Windows 2019 Hyper-V Server lief Anfang August 2025 ein Windows 2019 Gast und folgende Schritte habe ich ausgeführt

  1. Analyse mit  [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
    Liefert ein FALSE
  2. Regkey auf 0x40 und Task gestartet
    Der Task hat das Zertifikat installiert, den RegKey auf 0x0 gesetzt, Danach konnte ich die Eventlog-Meldung finden und die 2023 CA ist im DB-Speicher gelandet. Danach war ein Neustart erforderlich
  3. Regkey auf 0x100 und Task gestartet
    Der Task hat den Bootloader gegen einen neuen Bootloader ausgetauscht, der von der 2023er CA signiert war
  4. Regkey auf 0x80 und Task gestartet
    Die 2011er CA ist in der DBX Datenbank. Die Windows 2019 VM bootet problemlos

Ich kann also sagen, dass bei diesem einen Fall der Wechsel auf die neue 2023 CA problemlos erfolgt ist. Parallel installierte VMs haben davon nichts mitbekommen. Das bedeutet aber auch, dass der UEFI-Firmware-Speicher für jede VM separat zu betrachten und entsprechend zu aktualisieren ist.

Auf meinem HyperV Host habe ich neben der VHDX-Dateien auch eine VMRS-Datei gefunden. Mit Notepad kann ich darin die Namen der Zertifikate erahnen. Das könnte der "nicht flüchtige" UEFI-Speicher für die Konfiguration sein.

Ich habe damit nicht gesagt, dass Sie einfach diese Date tauschen müssten, um die DB/DBX-Einträge von VMs zu ändern.

Leider habe ich keine VMWare, XEN, Proxmox oder andere Hyperscaler im direkten Zugriff. Vielleicht teilt ein Leser gerne seine Erfahrungen oder ich reichte die Daten nach, wenn ich bei einem Kunden den Wechsel begleitet habe.

Windows 365

Im Juli 2025 habe ich auch einen Windows365 PC in der Cloud betrieben. Technisch war es Windows 11 24H2 Build 26100.4652 und auch hier war der Stand, dass die alte Zertifizierungsstelle noch nicht über die DBX-Datei gesperrt wurde aber die neue Zertifizierungsstelle als auch das Aktuelle KEK Zertifikat schon integriert war.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
True

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
False

Der Bootloader war aber noch mit der alten Zertifizierungsstelle signiert.

Beste Voraussetzungen hier den Wechsel anzustoßen. Also Registrykey gesetzt, Task gestartet, Bestätigung im Eventlog gesehen. und Voila, die neue CA war im Store drin. Dann schnell den neuen Bootloader aktiviert und geprüft. Nach dem nächsten Neustart habe ich dann noch die alte CA 2011 in den  DBX-Store importiert, damit von dieser CA signierte Bootloader nicht mehr vertrauenswürdig sind. Auch der darauf folgende Neustart hat geklappt.

Damit kann ich bestätigen, dass auch ein Windows 365 PCs problemlos den Prozess durchlaufen kann.

Ohne Telemetrie kein automatisches Update!

Microsoft plant eigentlich die erforderlichen Updates automatisch umzusetzen. Allerdings möchte Microsoft dabei natürlich möglichst wenig Probleme auf den Clients verursachen. Ein wesentlicher Aspekt ist dabei zu wissen, welche Clients Probleme machen und welche problemlos arbeiten. Es ist ja nicht allein ein Windows-Thama sondern auch der Hersteller hat ggfls. einen Teil beizutragen. Microsoft möchte daher über die Windows Telemetrie einige Details zum Endgerät wissen, ehe Sie ein Update verteilen.

Option 1: Fully automated (only for Microsoft managed devices)
By choosing this option, your devices will automatically receive the latest Secure Boot updates, helping keep your devices safe and secure. To enable this, you will need to participate in and allow Microsoft to collect Universal Telemetry Client (UTC) diagnostic data from your devices. This step ensures your devices are enrolled in the Microsoft managed program and will receive all updates seamlessly as part of our standard rollout.
Quelle: Windows devices for businesses and organizations with IT-managed updates
https://support.microsoft.com/de-de/topic/windows-devices-for-businesses-and-organizations-with-it-managed-updates-e2b43f9f-b424-42df-bc6a-8476db65ab2f

Wenn eine Firma die Übermittlung von Telemetriedaten auf dem Client oder über den Proxy allerdings unterbunden haben, dann bekommen Sie erst einmal keine entsprechenden Updates.

Sie müssen sich also selbst drum kümmern. Microsoft hat noch keine klaren Anweisungen außer, dass mit Telemetrie alles besser wäre. Ich könnte mir aber vorstellen, dass Microsoft erst Telemetriedaten von den Clients sammelt und später auch Clients anhand einer Allow-Liste im Update selbst auch ohne Telemetrie aktualisiert.

Sie sollten also zumindest "Required " erlauben.

Computer>Administrative Templates>Windows Components>Data Collection and Preview 
Builds>Allow Diagnostic Data

Dann können Sie per Registrierung die Verwaltung der Updates zulassen.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000000
"MicrosoftUpdateManagedOptIn"=dword:00005944

Das Argument "Telemetrie" kann ich verstehen, aber es ist schon ein Unterschied, ob ein Client aktiv Informationen über sich versendet oder ob er nur als Empfänger arbeitet. Ich gehe davon aus dass sehr viele Systeme ihre Telemetriedaten senden und Microsoft vielleicht eine entsprechende Datenbank für lokale Prüfungen bereitstellen könnte. Bislang steht auf der Seite nur:

However, we realize that this is not a feasible option for a variety of devices such as air-gapped devices in government, manufacturing, and so forth. In these cases, Microsoft support will be limited to recommending known steps or methods for deploying these updates as well as sharing data gathered from our rollout stream. This will be provided through updated versions of this article.
Quelle: Windows devices for businesses and organizations with IT-managed updates
https://support.microsoft.com/de-de/topic/windows-devices-for-businesses-and-organizations-with-it-managed-updates-e2b43f9f-b424-42df-bc6a-8476db65ab2f

All diesen Administrator würde ich empfehlen, Microsoft ein Feedback auf https://aka.ms/SecureBootCA/ReadinessSurvey zu geben und regelmäßig auf https://aka.ms/getsecureboot nachzuschauen.

Sobald ich eine Bestätigung habe, aktualisiere ich diese Seite.

Prüfen mit Intune

Im Frühjahr 2026 hat Microsoft entsprechende Reports in Intune addiert. Im Intune-Portal können Sie unter "Windows Autopatch" einen "Secure Boot Status"-Report aufrufen

Dort finden Sie alle Computer mit der Informationen, ob die Zertifikate schon aktuell sind.

 

Prüfen mit PowerShell

Solange die Deadline Okt 2026 noch nicht erreicht ist und der Computer noch läuft, können Sie auf mehrere Wege ihr System prüfen.

Für die meisten Aktionen benötigen Sie lokale Admin-Rechte

Zuerst könnten wir ja einmal prüfen, ob im UEFI-BIOS schon die Nachfolge-CA von Microsoft installiert ist. Das geht recht schnell per PowerShell.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -name db).bytes) -match 'Windows UEFI CA 2023'

Das Commandlet "Get-SecureBootUEFI" liest mit dem Parameter "-name DB" die Datenbank aus. Die Rückgabe ist aber nicht direkt lesbar. Es reicht aber das Byte-Array einfach zu einem Text zu konvertieren und nach dem String der neuen RootCA zu suchen. Ein "True" sagt, dass alles in Ordnung ist. Wenn die neue CA noch nicht enthalten ist, dann sollen Sie diese möglichst bald installieren lassen. Im gleichen Zuge sollten Sie auch KEK CA prüfen und ggfls. aktualisieren.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

Erst wenn diese Vorgaben erfüllt sind, können Sie bei Bedarf den Bootloader durch den neuen Bootloader aktualisieren und die weiteren Schritte durchführen. Folgendes Skripte habe ich mir mit Unterstützung durch Copilot gebaut, um die Zertifikate auszulesen und über einen Errorlevel den Status zu melden.

check-uefibootcertificate20260222.ps1.txt 
Nach dem Download im Explorer entsperren und Erweiterung .TXT entfernen.

Über die Pipeline bekommen Sie ein Objekt mit allen Zertifikaten und einem Status zur Weiterverarbeitung.

Für eine reine Abfrage per Softwareverteilung nutzt ich den Exit-Code.

 0 = Kein Fehler. Neue Zertifikate sind in KEK und DB
 4 = KEK Zertifikat noch nicht installiert
 8 = Fehler beim Lesen der KEK Zertifikate
16 = DB Zertifikat noch nicht installiert
32 = Fehler beim Lesen der DB Zertifikate

Die meisten Inventarlösungen können auch ein PowerShell-Script als Paket auf Clients ausführen lassen und den Exitcode auswerten. Ansonsten steht es ihnen frei, den Code auf eigene Bedürfnisse anzupassen.

Hintergrund: EFI-Paritition

Die folgenden Abschnitte zeigen meine verschiedenen Schritte, die ich beim Erstellen der Seite durchlaufen habe. Zuerst musste ich mal an den Bootloader kommen. der liegt auf einer für das Betriebssystem erst einmal versteckten Parititon, die normalerweise nicht gemountet ist. Sie finden Sie in der Datenträgerverwaltung.

Über den Befehl "Mountvol", kann ich die Partition als Laufwerk verbinden und die Signierer der EFI-Dateien abfragen:

mountvol s: /s

Allerdings sind auf dem S: Laufwerk durchaus weiter ACLs aktiv, so dass Sie den Inhalt nicht einfach mit dem Windows Explorer nun anzeigen können.


Versuch auf einem Windows 365 PC das Laufwerk S: zu öffnen

Nach dem Neustart ist das "S:"-Laufwerk" auch gleich wieder weg. Allerdings können Sie per CMD-Shell oder PowerShell sehr wohl durch die Pfade laufen und Dateien lesen oder kopieren. Hier eine gekürzte Ausgabe von Tree:

Interessant ist hier das Verzeichnis S:/EFI/BOOT

S:\>dir \efi
 Volume in Laufwerk S: hat keine Bezeichnung.
 Volumeseriennummer: 3A38-FB56

 Verzeichnis von S:\efi

13.05.2025  10:52    <DIR>          .
13.05.2025  10:52    <DIR>          ..
13.05.2025  10:52    <DIR>          Microsoft
13.05.2025  10:52    <DIR>          Boot
               0 Datei(en),              0 Bytes
               4 Verzeichnis(se),     64.584.192 Bytes frei

S:\>dir \efi\boot
 Volume in Laufwerk S: hat keine Bezeichnung.
 Volumeseriennummer: 3A38-FB56

 Verzeichnis von S:\efi\boot

13.05.2025  10:52    <DIR>          .
13.05.2025  10:52    <DIR>          ..
08.07.2025  19:12         2.830.632 bootx64.efi
               1 Datei(en),      2.830.632 Bytes
               2 Verzeichnis(se),     64.584.192 Bytes frei

S:\>dir \efi\Microsoft\boot\*.efi
 Volume in Laufwerk S: hat keine Bezeichnung.
 Volumeseriennummer: 3A38-FB56

 Verzeichnis von S:\efi\Microsoft\boot

08.07.2025  19:12           162.688 SecureBootRecovery.efi
08.07.2025  19:12         2.818.464 bootmgr.efi
08.07.2025  19:12         2.579.360 memtest.efi
08.07.2025  19:12         2.830.632 bootmgfw.efi
               4 Datei(en),      8.391.144 Bytes
               0 Verzeichnis(se),     64.584.192 Bytes frei

Hier liegen also die verschiedenen EFI-Dateien. In den Unterverzeichnissen der Sprachen liegen noch weitere Dateien.

Hintergrund: Dateisignatur

Als nächsten Schritt wollen wir die Dateien auf ihre Signatur prüfen. Zuerst dachte ich, dass sich "Get-AuthenticodeSignature " dafür eignet, z.B.

(Get-AuthenticodeSignature s:\efi\boot\bootx64.efi).SignerCertificate | fl

(Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi).SignerCertificate | fl

Es kommen auch nette Ausgaben zurück, die passende aussehen

Allerdings hat dieses Aufruf auch nach dem Wechsel des Bootloaders immer noch die 2011-CA angezeigt.

Erst ein Abruf mit Get-PfxCertificate" hat die richtigen Daten geliefert.

Das gleiche Bild zeigt sich auch bei den anderen EFI-Dateien. Hier muss man also aufpassen.

Anstatt der PowerShell habe ich mir die Datei einfach auf den Desktop kopiert

copy "S:\EFI\Boot\bootx64.efi" C:\temp\ 

Mit dem Windows Explorer kann ich mir die Details der Signatur anzeigen lassen.

PKI  Vor dem Updates mit CA 2011 Nach dem Update mit CA 2023

Dateizertifikat

Unter den Eigenschaften gibt es die Karteikarte "Digitale Signaturen" 

    

Details der Signatur

Über die Details sehen wir, wann die Datei signiert wurde. Bei mir ist dies grade mal ein paar Wochen her gewesen. Anscheinend aktualisiert Windows Update auch diese Dateien manchmal. Hier kann ich mir aber das Signierer-Zertifkat anzeigen lassen. 

    

Erweiterte Informationen

Hier erscheint dann auch das erste Mal die UEFI CA 2023 

    

Zertifikatskette 

    

IssuingCA

Die "Microsoft Windows Production PCA 2011"-CA zum Signieren der ETL-Dateien ist bis 19. Okt 2026 gültig. 

    

Root CA "Microsoft Root Certificate Authoritiy 2010


Wurde damals für 35 Jahre ausgestellt und wir auch für die neue Zertifizierung als Basis genutzt. Der nächste große Wechsel steht also 2035 an.

     

Hintergrund: Geplanter Task

Weiter oben haben Sie häufiger gesehen, dass ein Teil der Änderung durch einen "geplanten Task" erfolgt.

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Den Task finden sie auch in der Aufgabenplanung:

Allerdings sehen wir nicht direkt, welche Funktion der Task aufruf und auch die Protokollierung (Verlauf) ist deaktiviert. Ich habe hier nicht weiter geforscht und vertraue einfach mal darauf, dass der Task eine API startet, die auf sicherer Weise die UEFI-Einstellungen und Bootloader modifiziert.

Hintergrund: Secure Boot abschalten

Solle das Kind sprichwörtlich in den Brunnen gefallen sein und ihr System nicht mehr starten, weil die Signatur des Bootloaders vom UEFI-Bios nicht geprüft werden kann, dann können Sie oft einen Notfall-DVD oder USB-Stick starten und vielleicht damit versuchen, das Zertifikat der Signatur CA in  die DB-Tabelle der Firmware zu hinterlegen. Solange Sie die SNC-Zähler nicht aktiviert haben, können Sie auch einen vorherigen Bootloader aufspielen. Die EFI-Partition ist unterschlüsselt und FAT32-formatiert. Als letzten Anker könnten Sie natürlich "Secure Boot" abschalten. Das geht meinst im BIOS, wenn Sie beim Start ins BIOS springen und die Option finden.

 

 

Bei HyperV können Sie die Konfiguration in den Einstellungen der VM anpassen:

 

Allerdings erkennt dann natürlich auch das Betriebssystem, dass der Start "unsicher" erfolgte und kann bestimmte Informationen nicht mehr aus dem TPM-Chip abrufen. Im Wesentlichen ist dies die Information für Bitlocker, d.h. wenn ihre Betriebssystem-Partition so verschlüsselt ist, dann werden Sie zur Eingabe des sehr langen Bitlocker-Schlüssels aufgefordert.

Achtung: Es gibt mittlerweile Programme, z.B. Spiele, die Secure Boot voraussetzen.

Hintergrund: UEFI und PowerShell

Wenn Sie die PK, KEK, DB, oder DBX-Datenbank mit "Get-SecureBootUEFI auslesen, dann nutz ich bislang einfach eine Konvertierung des Byte-Array in einen String und suche nach dem Namen. Dahinter steckt natürlich eine Datenstruktur, die man auch sauber decodieren kann. Das hat Matt Graeber u.a. z.B. über seine PowerShell-Funktion "Get-UEFIDatabaseSigner" bereitgestellt.

Parses signature data from the pk, kek, db, and dbx UEFI variables. · GitHub
https://gist.github.com/mattifestation/1a0f93714ddbabdbac4ad6bcc0f311f3

Einfach die Datei als PS1-Datei speichern. Ich habe aber noch den Anfang mit "Function  {" und das letzte "}" entfernt. Auf meinem Lenovo liefert es:

(Get-SecureBootUEFI -name pk|  .\Get-UEFIDatabaseSigner.ps1).signature.signaturedata

Thumbprint                                Subject
----------                                -------
49C6331A4B581010FC63F80617C012F5E04F39FA  CN=Lenovo Ltd. PK CA 2012, O=Lenovo Ltd., L=Yokohama, S=Kanagawa, C=JP
PS C:\temp\uefi> (Get-SecureBootUEFI -name kek|  .\Get-UEFIDatabaseSigner.ps1).signature.signaturedata.subject
CN=Lenovo Ltd. KEK CA 2012, O=Lenovo Ltd., L=Yokohama, S=Kanagawa, C=JP
CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Microsoft Corporation KEK 2K CA 2023, O=Microsoft Corporation, C=US
PS C:\temp\uefi> (Get-SecureBootUEFI -name db|  .\Get-UEFIDatabaseSigner.ps1).signature.signaturedata.subject
CN=ThinkPad Product CA 2012, O=Lenovo Ltd., L=Yokohama, S=Kanagawa, C=JP
CN=Lenovo UEFI CA 2014, O=Lenovo, S=North Carolina, C=US
CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US
PS C:\temp\uefi> (Get-SecureBootUEFI -name dbx|  .\Get-UEFIDatabaseSigner.ps1).signature.signaturedata.subject
CN=Canonical Ltd. Secure Boot Signing, OU=Secure Boot, O=Canonical Ltd., S=Isle of Man, C=GB
CN=Debian Secure Boot Signer

Mein Client ist also schon ziemlich aktuell. Da muss ich nur noch die Signatur des Bootloaders prüfen. Es gibt noch jede Menge andere Skripte, z.B.: "Check UEFI KEK, DB and DBX.ps1"

Check UEFI KEK, DB and DBX.ps1
Check-UEFISecureBootVariables/Check UEFI KEK, DB and DBX.ps1 at main · cjee21/Check-UEFISecureBootVariables · GitHub

Es ermittelt eigentlich den kompletten Status und ist eine gute Basis für eigene Auswertungen, die z.B. per Intune verteilt werden können.


Ausgabe von "Check UEFI KEK, DB and DBX.ps1"

Wer also nicht auf Microsofts "Auto Update" vertrauen will, kann sich selbst einen Überblick verschaffen und Updates installieren.

Hintergrund: Registrierung

Sie haben auf der Seite mehrfach gesehen, dass Updates durch einene REgistrierungsschlüssel gesteuert werden, die dann von einem geplanten Task ausgelesen und zurückgesetzt werden. ÜBer diese SChlüssel können Sie ausstehende Aktionen ermitteln. Es gibt aber weitere Schlüssel, die für Auswertungen interessant sind und alle unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot liegen. Hier ein Auszug von meinem Client:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000000
"MicrosoftUpdateManagedOptIn"=dword:00005944

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT]
"UpdateStatus"=dword:00000003

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing]
"WindowsUEFICA2023Capable"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\DeviceAttributes]
"CanAttemptUpdateAfter"=hex:60,31,30,f6,5d,a8,db,01
"OEMManufacturerName"="LENOVO"
"OEMModelSystemVersion"="ThinkPad T14 Gen 5"
"BaseBoardManufacturer"="LENOVO"
"FirmwareManufacturer"="LENOVO"
"FirmwareVersion"="R2LET32W (1.13 )"
"FirmwareReleaseDate"="02/11/2025"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UploadedForCurrentBootCycle]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\State]
"UEFISecureBootEnabled"=dword:00000001
"PolicyPublisher"="{77fa9abd-0359-4d32-bd60-28f4e78f784b}"
"PolicyVersion"=dword:00000001

Den Schlüssel "AvailableUpdates" kennen sie schon zur Genüge. Er sollte auf 0x0 stehen, wenn keine Updates mehr anstehen. Sie können aus den weitern Werten aber sehr einfach den Hersteller, die Firmware-Version samt Datum aber auch anhand dem Schlüssel "WindowsUEFICA2023Capable" erkennen, ob die neue CA schon in der DB-Datenbank ist. So könnten sie ganz ohne PowerShell-Aufruf und Admin-Rechtne sehr einfach ermitteln, welche Clients noch nicht kompatibel sind. Auch Einstellungen wie "CanAttemptUpdateAfter" oder  "UpdateStatus" könnten einbezogen werden. SBAT steht übrigens für "Secure Boot Advanced Targeting".

Weitere Links