Making Intune Devices ready for the Secure Boot certificate rollover in 2026

Simone Termine

Secure Boot certificate rollover

Microsoft is in the middle of a Secure Boot certificate transition that every Windows fleet with Secure Boot enabled should care about. The “old” Microsoft Secure Boot certificates (2011-era) begin expiring in June 2026 (and one critical one in October 2026), and devices that don’t move to the 2023 certificates risk losing the ability to stay secure and serviceable in the pre-boot chain.

If you manage Windows updates yourself (typical enterprise scenario), Microsoft provides multiple supported deployment methods (registry keys, GPO, Intune method, WinCS). The tricky part isn’t “how to trigger it”, it’s making the rollout operationally safe and measurable at scale.

This post explains the approach I built and why it’s designed the way it is.

What’s changing (and why you should act before 2026)

Several Secure Boot certificates that have been present since Windows 8 / Windows Server 2012 are expiring. Microsoft’s guidance is clear: devices need updated 2023 certificates in UEFI DB and KEK to maintain Secure Boot continuity.

At a high level:

• A Microsoft KEK certificate in firmware is used to sign updates to DB/DBX.
• DB holds the trust anchors for boot loaders and other EFI components.
• Microsoft is moving from 2011 trust to new 2023 certificates (including Windows UEFI CA 2023 for the Windows boot manager).

The enterprise mechanism: registry key trigger + scheduled task

For IT-managed updates, one of the supported deployment options is registry-based.

The trigger

Microsoft documents the key:

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates

Setting AvailableUpdates = 0x5944 triggers deployment of the needed certificates and the boot manager update (the “do it all” option).

The engine behind it

Windows processes these operations through a scheduled task (runs every ~12 hours) that checks which bits in AvailableUpdates still need processing.

Microsoft even documents the expected progression, for example:

• Start: 0x5944
• … eventually –> 0x4100 (a “reboot required / boot manager not applied yet” state)
• … finally –> 0x4000 (boot manager applied, and the 0x4000 bit remains)

This is gold, because it gives us a deterministic way to monitor rollout state.

The monitoring keys that matter

Microsoft provides two monitoring values under:

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Key ones:

• UEFICA2023Status (string): NotStarted, InProgress, Updated
• UEFICA2023Error (DWORD): non-zero indicates failure; Microsoft recommends checking Secure Boot related event logs when it’s non-zero

There’s also WindowsUEFICA2023Capable (0/1/2) but Microsoft notes it’s for limited scenarios; they recommend using UEFICA2023Status for most cases.

The real-world rollout problem: “looks fine” vs “actually finished”

In practice, you can run into an annoying operational gap:

• A device can show UEFICA2023Status = InProgress (which feels reassuring),
• while AvailableUpdates = 0x4100 indicates the system is waiting for the reboot cycle that allows the boot manager step to complete.

Microsoft’s documentation explicitly calls out that the key can quickly change to 0x4100, and rebooting (and letting the task run again) moves it forward to the final state.

If your goal is to drive the rollout and report “ready”, you probably don’t want to mark those devices as “done” until the reboot requirement is cleared.

That’s exactly the policy choice I made in my detection logic.

My Intune solution: Proactive Remediation that’s safe, repeatable, and measurable

I built an Intune Proactive Remediation with two scripts:

• Detection: reports compliance state in a way that aligns with operations (including reboot pending visibility).
• Remediation: sets AvailableUpdates = 0x5944 only when it’s safe and useful, avoiding infinite re-trigger loops.

Detection: what it checks (conceptually)

The detection script evaluates, in this order:

1. AvailableUpdates
   • If it is 0x4100, the device is treated as Non-compliant (reboot pending, by policy).
2. UEFICA2023Error
   • Any non-zero value → Non-compliant (needs investigation).
3. UEFICA2023Status
   • InProgress or Updated → Compliant (unless reboot pending already caught above).
4. Fallback check (UEFI DB)
   • Looks for "Windows UEFI CA 2023" inside Secure Boot DB via Get-SecureBootUEFI db (useful as a last signal, but not the only one).
   • Note: “certificate present” is not always the whole story, which is why the registry-based state comes first. Supporto

Remediation: guardrails first, action second

The remediation script is intentionally conservative:

• If AvailableUpdates = 0x4100, it does nothing (don’t fight the reboot requirement).
• If UEFICA2023Status is InProgress or Updated, it does nothing (don’t reset a running workflow).
• If UEFICA2023Error is non-zero, it does nothing (don’t keep forcing, escalate troubleshooting).
• Only if the device is eligible and idle, it sets AvailableUpdates = 0x5944 to trigger the process.

Optionally, it can start the scheduled task (\Microsoft\Windows\PI\Secure-Boot-Update) so you don’t wait for the next 12-hour cycle (useful in pilots).

Troubleshooting notes I include (because someone will hit them)

Two important Microsoft-documented failure patterns worth calling out:

• KEK update failure can happen if the OEM hasn’t provided a KEK signed by the device Platform Key (PK).
• Firmware errors while applying DB/KEK updates can log specific event IDs (for example 1795), and Microsoft provides a dedicated event reference.

My scripts don’t try to “heal firmware”. They detect, avoid looping, and give you clean signals to triage.

Get the scripts + README

Everything is documented and ready to use here:

• Repo (MicrosoftIntune): https://github.com/SimoneTermine/MicrosoftIntune
• Secure Boot remediation folder: https://github.com/SimoneTermine/MicrosoftIntune/tree/main/scripts/00-Devices/Remediations/SecureBoot_UpdateCerts

(Those READMEs include prerequisites, how to deploy in Intune, expected states, and notes.)

Final reminder

Microsoft’s own guidance: avoid mixing deployment methods on the same device (for example, don’t run registry triggers and a different mechanism simultaneously). Pick one approach per device/ring, pilot it, then scale.

If you want, paste your final detection/remediation scripts as you plan to publish them and I’ll turn this post into a polished “copy/paste-ready” blog article (with a tighter narrative, a simple rollout checklist, and a short FAQ at the end).

If you prefer using Intune Settings Catalog instead of Proactive Remediations (for example, to manage the Secure Boot servicing trigger via policy at scale), I covered that approach step-by-step in a dedicated article here.