Secure Boot certificates expiring in 2026 — an SCCM playbook

Microsoft issued the current generation of Secure Boot signing certificates in June 2011. The validity period of those certificates was set to fifteen years, and the first of them — Microsoft Corporation KEK CA 2011 — reaches its notAfter date on June 24, 2026. Two further certificates in the same family expire shortly after, with the bootloader-signing root following in October. After those dates, no new signature material can chain to the affected certificates. Devices that boot today will continue to boot, but the firmware will refuse to accept new Boot Manager binaries, Secure Boot variable updates, or revocation list extensions signed by any successor that does not chain to an updated CA in the firmware database.

Microsoft has been distributing replacement certificates since 2023 and folded the deployment logic into Windows cumulative updates as part of the long-running mitigation campaign that began with CVE-2023-24932. The rollout is intentionally cautious: certificates are queued through a scheduled task, written to firmware variables only when a set of preconditions hold, and tracked through dedicated registry markers and event-log identifiers. For Windows Update–managed estates, the process is mostly invisible. For estates managed by Configuration Manager, WSUS, or fully air-gapped patch routines, it is not. The following article documents the mechanism, the SCCM-driven detection and remediation surface, the event-log signals, and the edge cases that decide whether a fleet completes the transition before the deadline.

Why this is urgent

The expiration window is short and overlaps with two operational realities. First, an estate that does not finish the transition before late June 2026 stops receiving new Secure Boot protections. Microsoft has been explicit that "as new threats emerge, a device in this expired state becomes progressively less protected." Second, several of the post-expiration update paths — Boot Manager replacement, DBX revocations for previously-trusted PCA 2011 components, and SVN firmware advances — are gated on a successor certificate already being present in the firmware DB. A device that misses the window faces a slow rather than sudden degradation, but the recovery path is markedly more invasive (firmware reset, recovery-media boot, and potentially a vendor BIOS update) than the in-OS upgrade that is available today.

Three further factors compress the timeline:

• OEM firmware coverage. The OS-side rollout writes into UEFI variables managed by the firmware. Some platforms — notably HP devices with Sure Start, certain Qualcomm Arm64 systems, and older fleet hardware — require a vendor firmware update before they accept the new certificates. The vendor update cycle is independent of Windows Update and is not always available for end-of-life models.
• BitLocker interaction. Boot Manager updates and certain DB changes trigger BitLocker recovery prompts unless protectors are suspended for the affected restart cycles. A fleet that runs BitLocker without coordinated suspension during the rollout window risks recovery-key dialogs at scale.
• Dual-boot estates. Linux distributions sign their shim binaries with the same Microsoft UEFI CA root. RHEL, Fedora, Ubuntu, openSUSE, and others are shipping 2023-signed shims, but the deployment order is significant: Windows must install the 2023 CAs before a Linux update that depends on them is applied, or the Linux partition becomes unbootable.

The remainder of this article focuses on what can be done from a Configuration Manager environment to drive the transition explicitly, monitor its progress, and recover from the predictable failure modes.

The Secure Boot trust chain in one page

Secure Boot is implemented in the platform firmware (UEFI). At boot, the firmware verifies the signature of the bootloader image against a database of trusted certificates and individual signatures stored in non-volatile UEFI variables. Four such variables define the trust state:

• PK (Platform Key) — the root of trust, set by the OEM. A signed update to the PK requires the existing PK to sign it.
• KEK (Key Exchange Key) — one or more keys authorised by the PK to sign updates to DB and DBX. Microsoft owns a KEK entry on virtually every Windows-compatible UEFI platform.
• DB (Allowed Signature Database) — certificates and hashes that the firmware will accept as valid signers for boot components. The Microsoft-issued bootloader signing CAs live here.
• DBX (Forbidden Signature Database) — explicit revocations. Components signed by entries in DBX are rejected even when their signer is otherwise trusted.

Updates to DB and DBX are signed by a KEK entry. Updates to KEK are signed by the PK. The chain is hierarchical and asymmetric: a compromise of the DB-signing key does not propagate to KEK, and a compromise of the KEK does not propagate to PK.

A Microsoft-signed Boot Manager presents to the firmware as a binary signed by Microsoft Windows Production PCA 2011. The firmware looks up Windows Production PCA 2011 in DB, finds a match, and proceeds. Third-party bootloaders — Linux shim, VMware ESXi, and others — chain to Microsoft Corporation UEFI CA 2011, which also lives in DB.

Three of those entries are scheduled to expire in 2026.

What expires when

The following dates are taken from the certificates as issued and from Microsoft's published expiration guidance. Storage location refers to the UEFI variable that contains the certificate.

The UEFI CA 2011 is replaced by two distinct certificates: one continues to sign third-party bootloaders (Microsoft UEFI CA 2023), while a separate certificate now signs option ROMs (Microsoft Option ROM UEFI CA 2023). The split was introduced during the 2023 reissue to decouple two trust paths that had been folded into a single CA for historical reasons.

The Windows Boot Manager itself is being re-signed by Windows UEFI CA 2023. The transition therefore involves four certificates added to the firmware (one in KEK, three in DB) and a re-signed Boot Manager binary deployed to the EFI system partition.

What breaks — and what continues to work

The most important practical observation is that expired certificates do not cause running devices to stop booting. The firmware verifies the signature, not the current validity of the signing certificate at boot time. A bootloader signed in 2024 by Microsoft Windows Production PCA 2011 continues to validate after the certificate's notAfter date as long as the certificate itself remains present in DB.

What stops working after expiration is the issuance of new trust material. Specifically:

• No new Boot Manager updates. When Microsoft releases a Boot Manager update signed by Windows UEFI CA 2023 — which is the path forward — devices whose DB does not contain that CA will reject the new binary.
• No new Secure Boot DB/DBX updates from Microsoft. Updates to those variables are signed by Microsoft's KEK. Once KEK CA 2011 expires, the firmware will not accept variable updates from that signer; updates signed by KEK CA 2023 require KEK CA 2023 to be present in KEK.
• No new boot-component revocations. When future vulnerabilities require revoking previously-trusted bootloaders, the revocation requires a DBX update signed by a current KEK. Devices stuck on the expired KEK cannot receive that revocation, leaving them vulnerable to known-bad components.

Microsoft summarises the steady-state outcome: a device in this position "will still start and operate normally," but it "will no longer be able to receive new security protections for the early boot process." Standard Windows updates continue to install; the freeze is specific to the pre-OS environment.

The corollary is that any device that completes the transition before its KEK 2011 entry expires retains the ability to receive future updates throughout the lifetime of KEK 2023 (issued June 2023, valid through 2038).

Microsoft's rollout mechanism

The Windows component that performs the certificate update on the OS side is a scheduled task that reads a single registry value, executes the corresponding subset of updates, and records its progress in further registry values and the System event log.

The registry path

All control values for the rollout live under one key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

Two values matter:

• AvailableUpdates — REG_DWORD, bitmask. Each bit represents one specific update action. Setting the value enables those updates to be applied at the next run of the scheduled task. Microsoft also processes this value on its managed-update path; setting it manually is only required for IT-managed estates that do not use Windows Update.
• MicrosoftUpdateManagedOptIn — REG_DWORD, also under the same SecureBoot key. Setting this value to 0x1 opts the device into Microsoft's managed update path. This is the modern recommended setting for organisations whose devices receive updates through Windows Update or Windows Update for Business.

Under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing, status flags reflect the outcome:

• UEFICA2023Status — REG_SZ. Values: NotStarted, InProgress, Updated. Set by the scheduled task as it processes the requested actions.
• UEFICA2023Error — REG_DWORD. Zero on success; non-zero on failure, in which case the System event log carries the corresponding event.
• WindowsUEFICA2023Capable — REG_DWORD. Reflects the device's compatibility for the 2023 transition (typically a firmware check).

The scheduled task

Microsoft\Windows\PI\Secure-Boot-Update

The task is registered by default on supported Windows builds. It runs every twelve hours under SYSTEM and can be triggered explicitly:

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

The task reads AvailableUpdates, attempts each requested action in order, clears the corresponding bit on success, and writes the status flags. Because the task issues firmware variable writes, certain actions require a restart before the firmware commits the change — DB and KEK updates typically apply at the next boot; the Boot Manager replacement occurs during the same scheduled run because the binary is on disk, not in firmware.

The AvailableUpdates bitmask

Microsoft's master reference for the bitmask is KB5025885. The bit values evolved across the campaign; the values relevant to the 2026 transition are summarised below.

The composite 0x5944 is the value most IT-managed deployments will set. The individual bits within it are documented by Microsoft as a single combined step rather than as a publicly enumerated subset, because Microsoft expects the steps to be performed as one atomic operation in nearly all environments.

The order of operations

The transition is a four-step sequence that should be respected:

1. Install the 2023 certificates into DB and KEK, and deploy the new Boot Manager (AvailableUpdates = 0x5944).
2. Verify the result through registry, PowerShell, and event log.
3. Optional, only after Step 1 is universally complete: Apply the DBX revocation of the 2011 PCA (AvailableUpdates = 0x80).
4. Optional, only after Step 3 is universally complete: Apply the SVN firmware update (AvailableUpdates = 0x200).

For most enterprise environments, only Step 1 is required before the 2011 KEK expires. Steps 3 and 4 are revocations that close residual attack surface and can be sequenced over months following Step 1, in line with broader vulnerability remediation campaigns and after recovery-media refresh.

Detecting the current state on a single device

Before driving the transition through SCCM, every operator should be able to read a device's state directly. Two PowerShell paths are available.

Quick substring check

The fastest verification is to decode the firmware variable as ASCII and grep for the expected certificate name:

function Test-SecureBootCert2023 {
  [pscustomobject]@{
    Kek_KEK2KCA2023        = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
    Db_WindowsUEFICA2023   = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'
    Db_MicrosoftUEFICA2023 = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Microsoft UEFI CA 2023'
    Db_OptionROMCA2023     = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Microsoft Option ROM UEFI CA 2023'
    UEFICA2023Status       = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -EA SilentlyContinue).UEFICA2023Status
    UEFICA2023Error        = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -EA SilentlyContinue).UEFICA2023Error
  }
}

Test-SecureBootCert2023

Get-SecureBootUEFI requires elevation and a UEFI system with Secure Boot enabled. The substring match is a legitimate detection in this case because the certificate subject contains the CA name and the firmware database is a packed structure of certificate blobs — the byte sequence appears verbatim in the variable contents. A fully-transitioned device returns True for all four certificate properties and Updated for UEFICA2023Status.

Structured enumeration

For deeper inspection (for example, to extract the certificate validity period or to confirm the SHA1 thumbprint), Get-SecureBootUEFI supports a -Decoded parameter on Windows builds from KB5093574 (April 2026) onwards. The parameter parses the EFI_SIGNATURE_LIST structure and returns X.509 objects directly:

(Get-SecureBootUEFI -Name db -Decoded).Certificates |
  Select-Object Subject, NotAfter, Thumbprint

Trevor Jones published a comprehensive parser ahead of the -Decoded parameter that walks the EFI_SIGNATURE_LIST entries manually and works on older builds as well; that script remains useful in mixed-version estates.

Confirming Secure Boot is in use at all

A device that is not running Secure Boot (legacy BIOS boot, Secure Boot disabled in firmware, or a non-UEFI Windows installation) cannot apply the 2023 certificates because there is no firmware variable to write into. Confirm-SecureBootUEFI returns $true only when Secure Boot is enabled and in user mode. The detection routine should gate on it:

if (-not (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)) {
  return 'NotApplicable: Secure Boot is not enabled'
}

SCCM Configuration Baseline — detection

The most effective monitoring surface in a Configuration Manager environment is a Configuration Baseline composed of multiple Configuration Items. Each CI checks for one of the four 2023 certificates and reports compliance individually. This shape produces clean compliance reporting: a partially-transitioned device shows as non-compliant against the specific CI for the missing certificate, which directs operators to the right diagnostic action.

Configuration Item design

For each of the four certificates, create a Configuration Item with the following shape:

• Setting type: Script
• Data type: Boolean (or String, if discrete state values are preferred)
• Discovery script (PowerShell): A script that returns True when the certificate is present and False otherwise
• Compliance rule: Equals True
• Remediation: None at this layer (remediation is handled by a separate package; see below)

Example discovery script for the Windows UEFI CA 2023 CI:

# CI: Windows UEFI CA 2023 present in DB
if (-not (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)) { return $false }
try {
  $bytes = (Get-SecureBootUEFI -Name db).bytes
  [Text.Encoding]::ASCII.GetString($bytes) -match 'Windows UEFI CA 2023'
} catch {
  return $false
}

Four CIs of this shape — one each for Microsoft Corporation KEK 2K CA 2023, Windows UEFI CA 2023, Microsoft UEFI CA 2023, and Microsoft Option ROM UEFI CA 2023 — give granular visibility. A fifth CI checking for Microsoft Windows Production PCA 2011 in DBX confirms that Step 3 (the revocation) has been applied where that step is in scope.

Configuration Baseline composition

The Baseline groups the CIs. Deployment is straightforward — target a collection that contains every UEFI Windows device in the estate. The default evaluation schedule (every 7 days) is acceptable for monitoring; for the rollout window itself, shorten it to daily.

Reporting

Once deployed, the standard ConfigMgr report List of assets by compliance state for a configuration baseline under Monitoring → Reporting → Reports → Compliance and Settings Management enumerates devices and per-CI state. For a custom dashboard, the underlying SQL view v_LocalizedCIProperties_SiteWide joined to v_CICurrentComplianceStatus produces a per-device, per-CI matrix that drives Power BI reporting cleanly.

A typical query shape:

SELECT
  rs.Netbios_Name0,
  ci.LocalizedDisplayName AS CI,
  ccs.ComplianceStateName,
  ccs.LastComplianceMessageTime
FROM v_CICurrentComplianceStatus     ccs
JOIN v_LocalizedCIProperties_SiteWide ci  ON ccs.CI_ID         = ci.CI_ID
JOIN v_R_System                        rs  ON ccs.ResourceID    = rs.ResourceID
WHERE ci.LocalizedDisplayName LIKE '%Secure Boot 2023%'
ORDER BY rs.Netbios_Name0, ci.LocalizedDisplayName;

For devices where Configuration Manager hardware inventory should also reflect Secure Boot state, the Win32_DeviceGuard and Win32_Tpm WMI classes can be added via a custom MOF edit, but this is rarely necessary for the 2023 transition itself — the Configuration Baseline already produces the operational view.

SCCM-driven remediation

Two patterns are available for applying the transition, both compatible with ConfigMgr.

Pattern A — Package / Program with run-once script

The simpler approach. A small SCCM Package contains a single PowerShell script that performs the registry write and triggers the scheduled task. The Program is deployed to a collection of non-compliant devices (populated by a query on the Configuration Baseline compliance result).

The script:

# Enable Step 1: install 2023 certs to DB + KEK, deploy new Boot Manager
$key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
New-ItemProperty -Path $key -Name 'AvailableUpdates' -PropertyType DWord `
                 -Value 0x5944 -Force | Out-Null

# Trigger the Secure-Boot-Update scheduled task immediately
try {
  Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'
} catch {
  Write-Output "Scheduled task start failed: $_"
  exit 1
}

# Emit a marker file so the SCCM detection method can confirm execution
$marker = "$env:ProgramData\MAS\SecureBoot2023-Triggered.txt"
New-Item -Path (Split-Path $marker) -ItemType Directory -Force | Out-Null
"$(Get-Date -Format o)" | Out-File $marker -Force

exit 0

A complementary Configuration Item or detection method confirms the marker file's presence so that ConfigMgr's deployment status does not perpetually re-trigger the program.

The trade-off of this pattern is that the script does not wait for the firmware to actually commit the change. The scheduled task runs asynchronously, and the firmware write may require one or more restarts to complete. The detection-only Configuration Baseline (above) covers the verification step on a separate evaluation schedule.

Pattern B — Configuration Item with Discovery + Remediation

A single Configuration Item per certificate, with both Discovery and Remediation scripts populated. Discovery is identical to Pattern A's detection script. The Remediation script for each CI sets AvailableUpdates to 0x5944 and starts the scheduled task.

The advantage is that compliance evaluation, remediation, and re-evaluation happen on a single CI evaluation cycle, which produces a cleaner end-to-end record. The disadvantage is that four CIs each attempting to remediate the same way results in four redundant scheduled-task starts in quick succession — harmless in practice but noisy in the event log.

A practical compromise: keep four CIs for detection (one per certificate) but assign Remediation only to the first CI in evaluation order. The remaining three CIs are detection-only.

Bitlocker coordination

Boot Manager replacement and KEK changes can trigger BitLocker recovery prompts on reboot if BitLocker protectors are not suspended. The safer SCCM-driven pattern wraps the registry write with a BitLocker suspension for the required restart count:

# Suspend BitLocker for two restarts before triggering the Secure Boot update
$osDrive = $env:SystemDrive
Manage-Bde -Protectors -Disable $osDrive -RebootCount 2 | Out-Null

# (then perform the registry write + scheduled task start as above)

BitLocker resumes automatically after the configured reboot count. For estates that run Credential Guard or Device Guard (which depend on Virtual Secure Mode), the same protector suspension covers the additional restart that VSM may require.

Event log signals

The Secure Boot update task writes to the standard System event log under provider TPM-WMI. The relevant identifiers for the 2023 transition are documented below. They are the most reliable acceptance signal — registry status flags can lag the actual firmware write, but the event log records each commit individually.

Event ID 1808 is the single acceptance criterion for a fully-transitioned device. A SCOM rule, a scheduled Sentinel query, or a SCCM custom hardware-inventory class can each be used to surface 1808 events across the estate; for a one-shot view, the following remote PowerShell query produces a per-device report:

$events = Get-WinEvent -ProviderName 'Microsoft-Windows-TPM-WMI' -ErrorAction SilentlyContinue |
  Where-Object Id -in 1799, 1801, 1808 |
  Sort-Object TimeCreated -Descending |
  Select-Object -First 1

if (-not $events) {
  'NotStarted'
} else {
  switch ($events.Id) {
    1808 { 'Complete' }
    1799 { 'BootManagerReplaced' }
    1801 { 'Staged_AwaitingFirmwareCommit' }
  }
}

The wrapper script is straightforward to deploy as a hardware-inventory custom class extension or as a Configuration Item with a String data type that maps to the four returned states.

Failure modes and recovery

The transition is engineered to be resilient, but several failure modes are documented and require operator attention.

Update fails repeatedly (Event 1795 or 1796). The firmware returned an error code when writing the variable. Common causes are a BIOS that requires a vendor update to accept the 2023 KEK, a TPM in a non-ready state, or an active BitLocker protector. Diagnostic order: (1) check Get-Tpm for TpmReady = True, (2) check Event 1032 for BitLocker conflict, (3) check vendor firmware release notes for 2023 KEK acceptance.

Status stuck at InProgress. The scheduled task ran but the firmware has not committed. A restart is required; on HP devices with Sure Start, the update may also require a vendor firmware update before the platform accepts the new KEK at all. The HP Sure Start case is the most-reported instance and shows up in the Microsoft Q&A archive as the typical "stuck" pattern.

Event 1797 — DBX update blocked. The DBX update intentionally fails until DB contains Windows UEFI CA 2023. Order matters: install the DB and KEK content (Step 1) first; only then apply the DBX revocation (Step 3).

Event 1803 — PK-signed KEK not found. The platform does not have a PK signature on its KEK, which is unusual and typically indicates a custom UEFI configuration (custom OEM, secure platform, or a previous administrative reset). Resolution requires the OEM to reseat the KEK with a PK-signed entry; this is outside the scope of OS-side remediation.

Device becomes unbootable after Step 3 or Step 4. Microsoft is explicit that the revocation steps are non-reversible while Secure Boot remains enabled. The documented recovery path is:

1. Enter UEFI setup, disable Secure Boot.
2. Reset Secure Boot keys to factory defaults from the firmware UI.
3. Boot Windows from the system disk. If that fails, run from a recovery medium:
   text Copy

   mountvol s: /s
   del s:\*.* /f /s /q
   bcdboot %systemroot% /s S:

4. Re-enable Secure Boot. The Windows recovery binary C:\Windows\boot\efi\securebootrecovery.efi re-establishes the Windows UEFI CA 2023 entry in DB after a factory key reset.

For estates that apply Steps 3 and 4 at scale, refreshing the standard recovery media to contain a Windows UEFI CA 2023–signed Boot Manager is a prerequisite. Pre-revocation recovery media cannot boot a post-revocation device.

Edge cases

BitLocker

Already covered above. The operative pattern is two-restart suspension (Manage-Bde -Protectors -Disable -RebootCount 2) wrapping the registry write, with three restarts for VSM-enabled estates. Pre-stage the BitLocker recovery keys in Active Directory or Azure AD so that any unexpected prompt has a clear resolution path that does not block the user.

Dual-boot with Linux

Linux distributions sign their bootloader (shim) with Microsoft UEFI CA 2011 today. Red Hat, Fedora, Ubuntu, openSUSE, and SUSE have all shipped, or are shipping, dual-signed shim binaries that carry signatures from both the 2011 and 2023 UEFI CAs. The deployment order on a dual-boot device is:

1. Apply the Windows 2023 certificate update first (Step 1 above). The 2023 CAs land in firmware DB.
2. Apply the Linux distribution update that ships the 2023-signed shim.
3. Reboot through Linux to confirm the shim continues to validate.

Reversing the order — applying a Linux update that depends on 2023 trust before Windows has populated the DB — renders the Linux partition unbootable until the firmware DB is updated.

ARM64 platforms running RHEL receive a shim signed only with the 2023 CA from RHEL 9.7 onwards. On those platforms, the firmware must have the 2023 CA before any post-9.7 shim is deployed, with no 2011 fallback.

Virtual machines

Generation 2 Hyper-V VMs that use the Microsoft Windows Secure Boot template behave the same as physical devices and are eligible for the same transition. VMware ESXi guests follow the host's firmware emulation; VMware has documented several scenarios where the in-guest Secure Boot update succeeds but the host's vTPM does not retain the firmware variable change across snapshots or VM imports. The Broadcom knowledge base article on Secure Boot certificate expirations in VMware VMs is the canonical reference for that ecosystem.

The practical consequence for ConfigMgr-managed virtual estates is straightforward: the same Configuration Baseline detects state correctly, and the same remediation package applies the registry write. Verification through Event ID 1808 on virtual machines must be paired with the hypervisor's view of the vTPM state to confirm the firmware variable is actually persisted across VM lifecycle events.

OEM firmware and end-of-life hardware

A subset of fleet devices will not accept the 2023 certificates without a vendor BIOS update. The pattern is well-known: HP Sure Start on certain EliteBook generations, Surface devices with locked-down firmware, certain Lenovo ThinkPad generations, and Qualcomm Arm64 systems. The vendor's release notes are authoritative; OEMs have generally been transparent about which platforms have shipped 2023 KEK support and which still require an in-flight firmware update.

For devices whose OEM has declared end-of-support and will not issue a compatible firmware update, the only options are hardware replacement before June 2026 or an exception process that documents the device as accepting the post-expiration risk profile.

VDI and golden images

For VDI estates with periodic golden-image refresh, the practical approach is to update the golden image once (including a successful Step 1 transition), then redeploy the image to the persistent or non-persistent fleet. Persistent-disk VDI receives the new firmware variables on its first boot from the updated image. Non-persistent VDI inherits the firmware state from its parent disk, and the image refresh is the only required action.

For Windows 365 Cloud PCs and Azure Virtual Desktop, Microsoft drives the transition centrally; no enterprise action is required for the underlying virtual hardware.

Alternative deployment routes

The SCCM-driven approach above is the most direct one for ConfigMgr-managed estates. Three alternative routes exist for environments where SCCM is not the management surface.

Intune (Settings Catalog and Remediations)

Intune ships two settings under Devices → Configuration → Settings catalog in the Secure Boot category:

• Enable Secureboot Certificate Updates — opts the device into the standard rollout.
• Configure Microsoft Update Managed Opt In — sets the MicrosoftUpdateManagedOptIn = 1 registry value.

For verification, Intune Remediations (formerly Proactive Remediations) run a detection script identical to the SCCM CI detection above; a remediation script applies the registry write. The detection-only mode is sufficient for monitoring.

Group Policy

Under Computer Configuration → Administrative Templates → Windows Components → Secure Boot, three policies are available:

• Enable Secure Boot Certificate Deployment — equivalent to MicrosoftUpdateManagedOptIn = 1.
• Automatic Certificate Deployment via Updates — controls whether the device participates in the controlled feature rollout.
• Certificate Deployment via Controlled Feature Rollout — allows administrators to defer or accelerate the rollout.

The ADMX template that defines these policies ships with Windows 11 23H2 and later. Older administrative workstations need an updated central store before the policies appear.

Direct PowerShell

For ad-hoc remediation on a single device or a small batch, the registry write and scheduled task start can be issued through PowerShell remoting:

Invoke-Command -ComputerName <target> -ScriptBlock {
  $key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
  New-ItemProperty -Path $key -Name 'AvailableUpdates' -PropertyType DWord `
                   -Value 0x5944 -Force | Out-Null
  Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'
}

This is rarely the right pattern at scale but is useful for triage on individual non-compliant devices identified by the SCCM Configuration Baseline.

On-premises and disconnected environments

Two classes of environment warrant explicit consideration: WSUS-only estates without internet egress, and air-gapped operational technology (OT) or industrial control networks.

WSUS-managed estates

The Secure Boot update logic ships in the monthly cumulative updates. Approving the cumulative for the appropriate Windows version delivers the OS-side components — the scheduled task definition, the new Boot Manager binary on disk, and the registry-driven trigger. The certificate database update itself happens on the device, not from WSUS, because the firmware variable is local to the platform.

For estates that manage cumulative-update approvals strictly, the relevant Knowledge Base identifiers to allow through are:

• KB5025885 — the foundational article that introduced the AvailableUpdates mechanism and the scheduled task.
• The February 2026 and subsequent cumulative updates contain the device-targeting logic that performs the staged certificate pipeline and the Boot Manager swap.

The SCCM Configuration Baseline pattern from earlier in this article operates identically on WSUS-managed devices because the verification path is on-device PowerShell and registry, not anything that flows through Windows Update infrastructure.

Air-gapped and OT networks

For devices that never reach Windows Update, the transition must be driven entirely from local administrative tools. The required components are:

• The cumulative update package for the device's Windows version, manually distributed through whatever transport the air-gapped network permits.
• The Configuration Baseline detection scripts, deployed through SCCM if present in the air-gapped network, or through a comparable local management tool.
• The remediation script that sets AvailableUpdates = 0x5944 and starts the scheduled task.

The key distinction in air-gapped environments is the recovery story. A failed update on an internet-connected device can be triaged against current Microsoft documentation. The same failure on an air-gapped device requires a pre-staged playbook, pre-staged recovery media containing the Windows UEFI CA 2023–signed Boot Manager, and a documented manual procedure for the four-step recovery sequence (UEFI access, Secure Boot disable, key reset, recovery binary run).

Operational technology fleets — industrial control systems, embedded medical devices, manufacturing PCs running locked-down Windows configurations — frequently cannot accept the BIOS updates that some OEMs require for 2023 KEK support. The applicable mitigation in those environments is documented exception: the device is recorded as remaining on the 2011 trust chain, the residual risk is assessed and accepted, and the device is excluded from the broader fleet's revocation steps (Steps 3 and 4) until a hardware refresh cycle allows replacement.

Timeline and priority order

A reasonable enterprise schedule for the transition, given the expiration dates, is the following.

The June 2026 milestone is the operational deadline for KEK and the bulk of DB. The October 2026 milestone is the deadline for the Windows Boot Manager re-signing; estates that complete Step 1 before June will receive the re-signed Boot Manager as part of normal cumulative updates after that date.

Takeaways

The 2026 Secure Boot certificate transition is a planned operation, not an emergency. Microsoft has built a controlled rollout mechanism, designated registry markers, dedicated event log identifiers, and an explicit four-step deployment sequence. The transition is mostly invisible to consumer devices that receive Windows Update content normally. For estates managed through Configuration Manager, the operation requires explicit detection and remediation; the surface to achieve that is small and well-defined.

Detection through a Configuration Baseline of four CIs — one per 2023 certificate, plus an optional fifth for the PCA 2011 revocation — produces clean per-device, per-certificate compliance reporting. Remediation through a Package that sets AvailableUpdates = 0x5944 and starts the Microsoft\Windows\PI\Secure-Boot-Update scheduled task drives the transition under SCCM's existing targeting and reporting machinery. Verification through Event ID 1808 in the System event log is the single most reliable acceptance signal.

The non-reversible steps — the DBX revocation of PCA 2011 (0x80) and the SVN firmware advance (0x200) — should be sequenced after Step 1 has succeeded across the estate and after the recovery media has been refreshed. BitLocker protectors should be suspended for the reboot cycle during which DB and KEK changes apply. Dual-boot devices should receive the Windows transition first, with Linux shim updates following only after firmware DB contains the 2023 CAs.

Devices whose OEM has not shipped a 2023 KEK-compatible firmware update require either a vendor firmware update or a documented exception until the next hardware refresh cycle. Air-gapped and operational technology environments need a pre-staged playbook and pre-staged recovery media because the post-expiration recovery path is not available through their normal connectivity.

Rule of thumb: Detect everywhere, remediate Step 1 everywhere, sequence Steps 3 and 4 cautiously. The detection layer is the most important investment; visibility of who has and has not transitioned across an estate is what makes the rest of the operation tractable.

Tested against the Microsoft KB5025885 documentation as of May 2026, Configuration Manager Current Branch 2503, and Windows 11 24H2 clients with Secure Boot enabled. Event IDs, registry paths, and bitmask values are as published by Microsoft in the linked support articles.

References

• Microsoft Support — Windows Secure Boot certificate expiration and CA updates
• Microsoft Support — When Secure Boot certificates expire on Windows devices
• Microsoft Support — Registry key updates for Secure Boot: Windows devices with IT-managed updates
• Microsoft Support — KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• Microsoft Support — Secure Boot DB and DBX variable update events
• Microsoft Tech Community — Act now: Secure Boot certificates expire in June 2026
• Microsoft Tech Community — Secure Boot playbook for certificates expiring in 2026
• Microsoft Learn — Get-SecureBootUEFI
• Red Hat — Secure Boot certificate changes in 2026: Guidance for RHEL environments
• Trevor Jones — Checking for updated Secure Boot certificates
• Sherry Kissinger / TCSMUG — Secure Boot certificate reporting via Configuration Items in ConfigMgr