Intune Secure Boot Zertifikat Update: Was du vor dem Ablauf 2026 tun musst

In diesem Beitrag zeige ich dir, wie du deine Intune Geräte auf das Secure Boot Zertifikat Update vorbereitest. Microsoft stellt die alten Secure Boot Zertifikate von 2011 ein. Diese Zertifikate steuern, ob dein Gerät neue Bootloader erkennt und zukünftige Updates erhält. Das Thema klingt klein, betrifft aber jedes Windows Gerät mit Secure Boot. Deshalb solltest du jetzt handeln.

Damit du den Überblick behältst, habe ich eine kurze Zusammenfassung und alle nötigen Schritte zusammengestellt.

Letzte Aktualisierung: 16. März 2026.
Ich aktualisiere diesen Beitrag, sobald Microsoft neue Empfehlungen oder Monitoring-Funktionen veröffentlicht.

Die Änderung kurz zusammengefasst

• Die Zertifikate von 2011 laufen 2026 ab.
• Alle Geräte müssen auf die 2023-Zertifikatskette wechseln.
• Windows Update oder OEM-Firmware-Updates liefern die neuen Zertifikate.
• Du kannst das Update über einen Registry-Key und einen Scheduled Task auslösen.
• Der Intune Settings Catalog hat zwar Secure Boot Einstellungen, verursacht aber auf vielen Geräten Probleme (siehe unten).
• Ein einfaches Platform Script ist der zuverlässigste Weg für Intune Business- und Enterprise-Kunden.

Was du tun musst

Wenn du die Zertifikate nicht rechtzeitig aktualisierst, drohen folgende Konsequenzen:

• Keine Secure Boot Sicherheitsupdates mehr nach Juni 2026
• Kein Vertrauen in neue Software, die mit den 2023-Zertifikaten signiert ist
• Keine Sicherheitsfixes für den Windows Boot Manager nach Oktober 2026

Was Secure Boot Zertifikate sind

Secure Boot prüft, ob der Bootprozess nur vertrauenswürdige Komponenten lädt. Das Vertrauen basiert auf vier Zertifikatslisten in der UEFI-Firmware.

• PK
• KEK
• DB
• DBX

Für uns sind vor allem DB und DBX relevant. DB enthält erlaubte Signaturen. DBX enthält widerrufene Signaturen. Microsoft signiert Bootloader und Treiber mit Zertifikaten. Die älteren Zertifikate von 2011 laufen 2026 ab. Die neuen 2023-Zertifikate ersetzen sie.

Verwendet ein Gerät nach dem Ablauf noch die alten Zertifikate, kann es neue Bootloader nicht mehr validieren. Das betrifft Updates und Sicherheit gleichermassen. Darum müssen wir die Geräte vor 2026 aktualisieren.

Was die Deadline 2026 bedeutet

Die Secure Boot Zertifikate laufen in zwei Wellen während 2026 ab. Nach dem Ablauf kann das Gerät neuere Secure Boot Komponenten nicht mehr validieren. Microsoft liefert die neuen Zertifikate über Windows Update oder OEM-Firmware-Updates.

Falls die Firmware das Update blockiert, ist das Gerät nicht zukunftsfähig. Ich habe das bereits bei älteren Geräten gesehen. Diese Geräte brauchen ein Firmware-Update oder einen Ersatz.

Ich plane den Rollout deutlich vor der Juni-Deadline abzuschliessen.

So funktioniert das Update

Der Mechanismus dahinter ist unkompliziert. Windows führt alle 12 Stunden einen Scheduled Task aus. Dieser prüft den Registry-Key AvailableUpdates unter HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot auf Bits, die anstehende Updates anzeigen. Sobald du den richtigen Wert setzt, nimmt der Task die Arbeit auf. Danach stellt er die neuen Zertifikate bereit und wendet sie nach einem oder mehreren Neustarts an.

Der Wert 0x5944 löst alle relevanten Update-Flags aus. Das ist die vollständigste Option und hat sich in Produktionsumgebungen als stabil erwiesen.

Warum der Settings Catalog problematisch ist

Microsoft hat Secure Boot Einstellungen zum Intune Settings Catalog hinzugefügt. In der Theorie ist das der sauberste Weg für den Rollout. In der Praxis verursacht dieser Ansatz aber erhebliche Probleme.

Das Hauptproblem ist Error 65000. Viele Geräte melden diesen Fehler, sobald du die Settings Catalog Policy deployst. Die Ursache ist ein Lizenzcheck innerhalb von Windows. Die Secure Boot CSP-Einstellungen blockieren auf Windows Pro Editionen. Das betrifft auch Geräte, die per Subscription Activation von Pro auf Enterprise geupgraded wurden. Obwohl diese Geräte in Intune und in den Systemeinstellungen als Enterprise erscheinen, behandelt die interne Licensing-Engine sie weiterhin als Pro.

Microsoft hat das als Known Issue bestätigt und den Intune Licensing Service am 27. Januar 2026 aktualisiert. Geräte, die ihre Lizenz vor diesem Datum erhalten haben, brauchen eine Lizenzerneuerung. Laut Microsoft löst sich das bis zum 27. Februar 2026 automatisch. In der Praxis sehen viele Tenants den Error 65000 aber weiterhin. Besonders betroffen sind Geräte mit veralteten kumulativen Updates oder veralteten Lizenz-Metadaten.

Zusätzlich zum Error 65000 bietet die Settings Catalog Policy keine Deployment-Visibilität. Du siehst zwar, ob das Profil zugewiesen und angewendet wurde. Den tatsächlichen Rollout-Status der Secure Boot Zertifikate siehst du aber nicht. Es gibt keine Ansicht, die dir zeigt, welche Geräte bereitgestellt, aktualisiert oder fehlgeschlagen sind. Microsoft hat kurzzeitig einen Secure Boot Status Report in Intune eingeführt, diesen aber wieder zurückgezogen, weil die Daten nicht zuverlässig waren.

Das bedeutet: Der Settings Catalog Ansatz liefert unzuverlässiges Deployment ohne Rollout-Visibilität. Für die meisten Umgebungen ist ein skriptbasierter Ansatz praktikabler.

Die bessere Alternative: Ein Platform Script

Anstatt auf den Settings Catalog zu setzen, verwende ich ein Intune Platform Script. Dieses prüft den aktuellen Secure Boot Status und löst das Update direkt aus. Der Ansatz funktioniert auf allen Windows Editionen. Kein Lizenz-Gate, keine CSP-Abhängigkeit und kein Error 65000.

Das Script macht folgendes in einem Durchlauf:

1. Prüft, ob das Gerät eine 64-Bit PowerShell mit erhöhten Rechten ausführt.
2. Prüft, ob Secure Boot aktiviert ist.
3. Liest den Registry-Wert UEFICA2023Status aus.
4. Wenn der Status “Updated” und WindowsUEFICA2023Capable = 2 ist, ist das Gerät fertig.
5. Wenn der Status “InProgress” ist, wartet das Gerät auf einen Neustart.
6. Wenn der Status “NotStarted” ist und der Trigger noch nicht gesetzt wurde, setzt das Script AvailableUpdates auf 0x5944 und startet den Scheduled Task \Microsoft\Windows\PI\Secure-Boot-Update.

Hier ist das vollständige Script:

Update Secure Boot Cert Script @GitHub

<#
.SYNOPSIS
    Intune Platform Script to check and remediate Secure Boot CA 2023 certificate update.
.DESCRIPTION
    Checks if Secure Boot is enabled and if the CA 2023 update has been applied.
    If not started, sets the AvailableUpdates registry trigger and starts the scheduled task.
    Designed to run as a single Intune Platform Script (not a remediation).
.NOTES
    Author: Florian Salzmann | @FlorianSLZ | https://scloud.work
    Version: 1.0
    Run As: System
    Created: 2026-03-13
#>

$ScriptName = "WIN-S-D-SecureBoot-CA2023-Update"
Start-Transcript -Path "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\$ScriptName.log" -Force

$AvailableUpdatesValue = 0x5944
$ScheduledTaskName = "\Microsoft\Windows\PI\Secure-Boot-Update"

try {
    # Check Secure Boot
    try { $sbEnabled = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue } catch { $sbEnabled = $false }
    if (-not $sbEnabled) {
        Write-Warning "Secure Boot is disabled, cannot proceed."
        Exit 1
    }

    # Read current status
    $servicingPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
    $sbPath        = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
    $status    = (Get-ItemProperty -Path $servicingPath -Name "UEFICA2023Status" -ErrorAction SilentlyContinue).UEFICA2023Status
    $capable   = (Get-ItemProperty -Path $servicingPath -Name "WindowsUEFICA2023Capable" -ErrorAction SilentlyContinue).WindowsUEFICA2023Capable
    $available = (Get-ItemProperty -Path $sbPath -Name "AvailableUpdates" -ErrorAction SilentlyContinue).AvailableUpdates

    Write-Host "Status=$status, Capable=$capable, AvailableUpdates=$available"

    switch ($status) {
        "Updated" {
            if ($capable -eq 2) {
                Write-Host "Secure Boot CA 2023 update complete. No action needed."
            } else {
                Write-Warning "Status is Updated but Capable=$capable (expected 2)."
            }
        }
        "InProgress" {
            Write-Host "Update in progress, waiting for reboot or task completion."
        }
        "NotStarted" {
            if (($available -band $AvailableUpdatesValue) -eq $AvailableUpdatesValue) {
                Write-Host "Trigger already set, waiting for task or reboot."
            } else {
                Set-ItemProperty -Path $sbPath -Name "AvailableUpdates" -Value $AvailableUpdatesValue -Type DWord
                Write-Host ("AvailableUpdates set to 0x{0:X}" -f $AvailableUpdatesValue)
                Start-ScheduledTask -TaskName $ScheduledTaskName
                Write-Host "Scheduled task triggered. Reboot may be required."
            }
        }
        default {
            Write-Warning "Unknown UEFICA2023Status: $status"
        }
    }
    Exit 0
}
catch {
    Write-Error "Unexpected error: $_"
    Exit 1
}

Stop-Transcript

Dieses Script basiert auf den Remediation Scripts von @MrTbone_se. Ich habe es auf die wesentliche Logik reduziert. Das Original enthält umfangreiche Diagnostik mit TPM Event Log Parsing, EFI-Zertifikats-Analyse auf Byte-Ebene und OS Patch Level Validierung. All das habe ich entfernt, damit das Platform Script minimal bleibt und sich auf eine einzige Aufgabe konzentriert: das Update auslösen, falls es noch nicht gestartet ist.

So deployst du das Platform Script

1. Öffne das Microsoft Intune Admin Center.
2. Navigiere zu Devices > Scripts and remediations > Platform scripts > Windows.
3. Klicke auf Add.
4. Lade das Script hoch.
5. Setze Run this script using the logged on credentials auf No (das Script braucht den SYSTEM-Kontext).
6. Setze Run script in 64-bit PowerShell host auf Yes.
7. Weise das Script einer Gerätegruppe zu.

Das Script läuft einmal pro Gerät. Ist der Status bereits “Updated”, passiert nichts. Ist der Status “NotStarted”, setzt es den Trigger und startet den Scheduled Task. Nach einem oder mehreren Neustarts schliesst Windows das Zertifikats-Update selbstständig ab.

Damit deckst du Intune Business, Enterprise und Education lizenzierte Geräte ab. Keine Settings Catalog Policy nötig. Kein Error 65000. Keine Abhängigkeit von Diagnosedaten oder Microsoft Controlled Feature Rollouts.

Alternative: Deployment als Remediation Package

Falls du das Intune Remediation Modell (Proactive Remediation) dem Platform Script vorziehst, kannst du die gleiche Logik in ein Detection- und Remediation-Script aufteilen. Der Vorteil dabei: Du erhältst das integrierte Intune Remediation Reporting mit Compliant/Non-Compliant Zählung, einer Gerätestatusübersicht und den Pre/Post-Remediation Output Strings im Portal.

Detection & Remediation for Secure Boot Cert Update @GitHub

So deployst du das Remediation Package

1. Öffne das Microsoft Intune Admin Center.
2. Navigiere zu Devices > Scripts and remediations > Remediations.
3. Klicke auf Create script package.
4. Lade das Detection Script als Detection Script hoch.
5. Lade das Remediation Script als Remediation Script hoch.
6. Setze Run this script using the logged on credentials auf No.
7. Setze Run script in 64-bit PowerShell host auf Yes.
8. Lege den Zeitplan fest (z.B. täglich) und weise es einer Gerätegruppe zu.

Die Detection Output Strings enthalten die Registry-Werte. So kannst du in der Spalte “Pre-remediation detection output” im Intune Portal den genauen Gerätestatus vor der Remediation einsehen. Das gibt dir bessere Rollout-Visibilität als das Platform Script, das nur einmal läuft und nicht auf die gleiche strukturierte Weise zurückmeldet.

Verwende das Platform Script für einen einfachen einmaligen Push. Verwende das Remediation Package, wenn du laufendes Monitoring und wiederholte Remediation-Versuche bei fehlgeschlagenen Geräten brauchst.

Secure Boot Einstellungen im Intune Settings Catalog

Microsoft hat explizite Secure Boot Einstellungen zum Intune Settings Catalog hinzugefügt. Damit kannst du Secure Boot Zertifikat-Updates direkt über Intune verwalten. Ausserdem macht es das Verhalten sichtbar und auditierbar.

Übersicht der Secure Boot Einstellungen

Einstellung	Funktion	Empfohlener Wert
Enable Secureboot Certificate Updates	Erlaubt dem Gerät den Empfang aktualisierter Secure Boot Zertifikate	Enabled
Configure Microsoft Update Managed Opt In	Nutzt Microsoft-gesteuertes Windows Update für die Rollout-Steuerung	Enabled
Configure High Confidence Opt Out	Schliesst das Gerät von Secure Boot Zertifikat-Updates aus	Disabled

Hinweis

• Diese Einstellungen gelten nur für Geräte mit aktiviertem Secure Boot.
• Der Microsoft Managed Opt-In ist die sicherste Option für gemischte Hardware-Umgebungen.
• Den Opt-Out solltest du nur für getestete Ausnahme-Hardware verwenden.
• Diese Einstellungen blockieren aktuell auf Pro-Editionen und Geräten mit Subscription Activation (Error 65000).
• Microsoft hat den Licensing Service am 27. Januar 2026 aktualisiert. Nicht alle Geräte sind aber bereits behoben.

Die Namen und das Verhalten dieser Einstellungen findest du in der offiziellen Microsoft Intune Dokumentation zu Secure Boot Zertifikat-Updates.

Falls du den Error 65000 mit dem Settings Catalog hast oder einen einfacheren Deployment-Weg suchst, verwende den Platform Script Ansatz oben. Dieser setzt die gleichen Registry-Keys, ohne den CSP-Layer zu durchlaufen.

Registry Opt-In (Legacy oder Fallback)

Damit das Gerät das Secure Boot Zertifikat-Update erhält, brauchst du diesen Key:

$Path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\"
$Key = "MicrosoftUpdateManagedOptIn"
$KeyFormat = "DWORD"
$Value = "1"

if(!(Test-Path $Path)){New-Item -Path $Path -Force}
if(!$Key){Set-Item -Path $Path -Value $Value
}else{Set-ItemProperty -Path $Path -Name $Key -Value $Value -Type $KeyFormat}

Sobald der Key gesetzt ist, wird das Gerät für das Update berechtigt. Ab hier übernimmt Windows Update.

Microsoft erwähnt den Registry-Key als Möglichkeit für den Opt-In. Einen genauen Zeitplan oder eine Garantie, wann das Update auf dem Gerät ankommt, gibt Microsoft aber nicht.

Das Platform Script oben ist der direktere Weg. Anstatt auf den Opt-In zu setzen und auf Microsofts Push zu warten, löst es den Prozess sofort aus. Es setzt AvailableUpdates und startet den Scheduled Task.

Secure Boot Status Report in Intune

Microsoft hat einen integrierten Secure Boot Status Report zum Intune Admin Center hinzugefügt. Dieser Report gibt dir eine tenant-weite Übersicht, welche Geräte Secure Boot aktiviert haben und ob ihre Zertifikate aktuell sind. Du brauchst dafür keine Scripts auszuführen oder Geräte manuell zu prüfen.

Den Report findest du hier:

Intune Admin Center > Reports > Windows Autopatch > Windows quality updates > Reports Tab > Secure Boot status

Der Report zeigt drei Status pro Gerät:

Zertifikatsstatus	Bedeutung	Aktion
Up to date	Gerät hat die 2023-Zertifikate	Keine
Not up to date	Gerät verwendet noch 2011-Zertifikate	Update erforderlich
Not applicable	Secure Boot ist nicht aktiviert	Keine Zertifikatsaktion nötig

Für Geräte mit dem Status “Not up to date” kannst du den Eintrag auswählen. So siehst du, welche spezifischen Zertifikate fehlen. Das hilft dir bei der Entscheidung, ob ein skriptbasierter Push, ein Firmware-Update oder ein Geräteaustausch nötig ist.

Das Ziel ist natürlich, dass alles grün ist 🙂

Wichtige Hinweise zum Report:

• Der Report gilt aktuell für Geräte, die über Windows Autopatch verwaltet werden. Ohne Autopatch zeigt der Report möglicherweise keine Daten an. In dem Fall ist das Remediation-basierte Monitoring unten die beste Option.
• Microsoft hat den Report kurzzeitig eingeführt, dann aber zurückgezogen, weil die Datenqualität nicht zuverlässig war. Inzwischen ist er wieder verfügbar. Behalte die Microsoft Dokumentation im Auge.
• Auch wenn der Report “Up to date” anzeigt, empfehle ich eine Stichprobe per Registry-Keys (UEFICA2023Status = “Updated” und WindowsUEFICA2023Capable = 2).
• Microsoft bietet ausserdem ein offizielles Monitoring-only Intune Remediation Script an. Dieses sammelt den Secure Boot Status als JSON und meldet ihn ans Intune Portal zurück. Es ändert nichts am Gerät. Der Output erscheint unter Remediations > Monitor > Device status und lässt sich als CSV exportieren.

Wenn du sowohl den schnellen Überblick aus dem Report als auch die detaillierten Gerätedaten aus Scripts brauchst, kannst du beides parallel nutzen. Der Report gibt dir das grosse Bild. Die Remediation Scripts liefern die Details fürs Troubleshooting.

Erweitertes Monitoring für den Installationsstatus

Mit der erweiterten Remediation prüfe ich nicht nur, ob das Zertifikat “Windows UEFI CA 2023” bereits in der Secure Boot Datenbank vorhanden ist. Zusätzlich überwache ich den tatsächlichen Deployment-Status des Microsoft Updates. Dafür lese ich den Secure Boot Servicing Status aus der Registry.

Das Detection Script wertet diese drei internen Windows Indikatoren aus:

• UEFICA2023Status
• WindowsUEFICA2023Capable
• UEFICA2023Error

Damit sehe ich klar die verschiedenen Rollout-Status.

Remediation (Detection) @GitHub

Die Remediation zeigt mir:

• Ob das Zertifikat bereits in die UEFI DB geschrieben wurde
• Ob das Gerät technisch fähig ist, das Update zu empfangen
• Ob der Microsoft Servicing Prozess bereits abgeschlossen ist
• Ob das Update mit einem internen Fehler fehlgeschlagen ist
• Ob das Gerät noch auf die Auslieferung via Windows Update wartet

Basierend auf dem Output erkenne ich klar den tatsächlichen Status:

• Zertifikat vorhanden: Update abgeschlossen
• Status = Updated oder Capable = 2 ohne Fehler: Update deployed
• Kein Status und kein Zertifikat: Update steht noch aus
• Fehlerwert vorhanden: Update fehlgeschlagen, manuelle Untersuchung nötig

Das gibt mir echte Deployment-Visibilität und nicht nur eine Ja/Nein Zertifikatsprüfung. Ich kann klar unterscheiden:

• Geräte, die bereits fertig sind
• Geräte, die opted-in sind und noch warten
• Geräte, die durch Firmware- oder Secure Boot Probleme blockiert sind
• Geräte, bei denen ein Update-Fehler aufgetreten ist

Das macht es sehr einfach, den Rollout in Intune zu verfolgen. So entscheide ich gezielt, wo manuelles Follow-up oder ein Geräteaustausch nötig ist.

UEFICA2023Status	WindowsUEFICA2023Capable	UEFICA2023Error	Zertifikat in DB	Deployment Status	Aktion
Updated	2	0 oder leer	Ja	Update abgeschlossen	Keine
Updated	2	0 oder leer	Nein	Update deployed, DB noch nicht committed	Neustart und erneut prüfen
Leer oder null	2	0 oder leer	Nein	Opted-in, wartet auf Windows Update	Warten
Leer oder null	1 oder 0	0 oder leer	Nein	Gerät noch nicht fähig	Firmware prüfen
Beliebig	Beliebig	> 0	Nein	Update fehlgeschlagen	Manuelle Untersuchung
Beliebig	Beliebig	Beliebig	Ja	Zertifikat bereits vorhanden	Keine
Secure Boot DB nicht lesbar	Beliebig	Beliebig	Unbekannt	Secure Boot oder Firmware Problem	Secure Boot und BIOS prüfen

Was du nicht tun solltest

Aktiviere den High Confidence Opt-Out nicht als allgemeine Sicherheitsmassnahme. Das verhindert, dass Geräte die erforderlichen Secure Boot Trust Updates erhalten.

Mische keine Deployment-Methoden auf dem gleichen Gerät. Wenn du das Platform Script verwendest, weise dem gleichen Gerät nicht zusätzlich die Settings Catalog Policy zu. Wähle einen Ansatz und bleib dabei.

Überspringe das OEM Firmware-Update nicht. Microsoft stellt klar, dass OEM Firmware-Updates die Grundlage bilden. Erst danach kann das Secure Boot Zertifikat-Update korrekt greifen. Prüfe bei deinen Hardware-Herstellern und installiere verfügbare Firmware-Updates, bevor du das Zertifikats-Deployment auslöst.