Hallo zusammen,
wir haben uns das ebenfalls etwas genauer angesehen.
Nach meinem Verständnis werden die beiden Empirum-Felder **nicht einfach nur per String-Match auf den Rohinhalt von `Get-SecureBootUEFI db`** befüllt, sondern dienen dazu, den **Status der neuen Secure-Boot-CA-Umstellung** für die 2023er Zertifikate zu inventarisieren. Matrix42 beschreibt die beiden neuen Felder in Empirum 25.4 ausdrücklich als Werte, mit denen man Geräte nach den **neuen Anforderungen an UEFI-Bootzertifikate** filtern kann.
Der technische Unterschied zwischen den beiden Zertifikaten ist laut Microsoft:
* **Windows UEFI CA 2023**
signiert den **Windows-Bootloader / Windows Boot Manager**
* **Microsoft UEFI CA 2023**
signiert **Drittanbieter-Bootloader und EFI-Anwendungen**
Damit ist auch erklärbar, warum auf manchen Geräten nur **„Windows UEFI CA 2023 = 1“** steht:
Dann ist der neue Windows-Boot-Pfad bereits vorhanden bzw. relevant, aber die zusätzliche Drittanbieter-CA **Microsoft UEFI CA 2023** wurde auf dem Gerät nicht gesetzt oder wird dort nicht benötigt. Microsoft schreibt selbst, dass **nicht alle Geräte** zwingend beide neuen Zertifikate benötigen.
Zu der Beobachtung mit PowerShell:
Der Test
```powershell
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
```
zeigt erst einmal nur, dass der String irgendwo in den ausgelesenen DB-Daten vorkommt. Das ist **nicht zwingend identisch** mit der Logik, die Empirum intern für die Felder verwendet. Microsofts aktuelle Monitoring-/Detection-Ansätze für die 2023er Secure-Boot-Umstellung stützen sich außerdem nicht nur auf die UEFI-DB, sondern zusätzlich auf **Registry-/Servicing-Status** und laufen explizit **als SYSTEM**, damit alle Informationen sauber gelesen werden können.
Der Hinweis von Chozen mit dem **Systemkontext** passt daher sehr gut ins Bild. Microsoft nennt für die Erkennung ebenfalls ausdrücklich, dass solche Abfragen **als SYSTEM** laufen sollen, um Secure-Boot- und Registry-Werte korrekt lesen zu können.
Meine praktische Interpretation der Werte wäre daher momentan:
* **1** = Zertifikat / Status wurde von Empirum als vorhanden bzw. erfüllt erkannt
* **0** = nicht vorhanden bzw. Anforderung nicht erfüllt
* **-1** = vermutlich **nicht ermittelbar / Abfrage fehlgeschlagen / nicht im passenden Kontext gelaufen**
Für `-1` habe ich allerdings keine offizielle Matrix42-Doku gefunden, daher ist dieser Punkt eher eine technische Herleitung als eine bestätigte Herstellerdefinition.
Für Odoms Frage zum Hardware-Inventory-Paket:
Entscheidend ist nicht nur, **dass** Inventory verteilt wird, sondern **wie** der Scan am Client tatsächlich ausgeführt wird. Wenn der Scan nicht im echten **SYSTEM-Kontext** läuft oder der Kontext beim Aufruf wechselt, können genau solche Abweichungen entstehen. Das würde ich daher als erstes prüfen.
**Fazit:**
Ich würde die Empirum-Werte aktuell eher als **Status-/Compliance-Felder für die 2023er Secure-Boot-Umstellung** verstehen und nicht als bloße 1:1-Abbildung eines einfachen `Get-SecureBootUEFI db`-Stringmatches. Dass ein PowerShell-Match `true` liefert, während Empirum `0` oder `-1` zeigt, ist deshalb durchaus plausibel.
**Referenzen:**
Matrix42 Empirum 25.4 Release Notes:
[
https://docs.matrix42.com/en_US/3637604 ... date-notes](
https://docs.matrix42.com/en_US/3637604 ... date-notes)
Microsoft – Ablauf des Windows Secure Boot-Zertifikats und Updates der Zertifizierungsstelle:
[
https://support.microsoft.com/de-de/top ... b95457578e](
https://support.microsoft.com/de-de/top ... b95457578e)
Microsoft – How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932:
[
https://support.microsoft.com/en-us/top ... ff139f832d](
https://support.microsoft.com/en-us/top ... ff139f832d)
Microsoft – Monitoring Secure Boot certificate status with Microsoft Intune Remediations:
[
https://support.microsoft.com/en-au/top ... 4965adc87f](
https://support.microsoft.com/en-au/top ... 4965adc87f)
