Your fleet's firmware certificate is expiring: What June 2026 means for IT teams

Every Windows device your organization deployed before 2025 carries a set of certificates in its Unified Extensible Firmware Interface (UEFI) firmware. They've been there since 2011, quietly doing the work of validating boot signatures so nothing untrusted runs before the operating system loads. Most IT teams have never had a reason to think about them. That's about to change.

To understand what exactly is changing, let's have a quick look at how Secure Boot uses a hierarchy of keys stored in UEFI firmware:

• At the top sits the Platform Key (PK), which authorizes the Key Enrollment Key (KEK).

• The KEK, in turn, signs updates to two critical databases: the Allowed Signature Database (DB), which lists trusted boot signatures, and the Forbidden Signature Database (DBX), which blocks known-bad entries.

• When a device boots, firmware checks the bootloader's signature against the DB. If it matches and isn't in the DBX, the system proceeds.

According to Microsoft's June 2025 advisory, four certificates that anchor this chain are reaching end of life in 2026:

After the June deadline, affected devices can no longer receive Secure Boot security updates. After October, they stop receiving security fixes for the Windows boot loader entirely—including mitigations for bootkit-class attacks like BlackLotus (CVE-2023-24932). And because the October migration depends on the June one completing first, missing the first deadline could have its impact when you reach the second deadline.

For endpoint teams managing fleets of Windows 10, Windows 11, or Windows Server 2012 through 2025 machines, this is the kind of work that doesn't announce itself but will absolutely consume a period of three months if you let it. It covers more than physical hardware: Hyper-V Generation 2 VMs and VMware VMs with Secure Boot enabled are in scope too, which is the part most teams underestimate.

The problem isn't the certificate, it's the migration    

If this were a normal patch, you'd push the update, run a verification report, and move on. It isn't. The migration from the 2011 certificates to the new UEFI CA 2023 versions are a sequenced workflow with hard prerequisites that the firmware itself enforces.

Before a device can migrate, it has to be running UEFI firmware and Secure Boot has to be enabled. Legacy BIOS machines can't participate. The OEM firmware has to be up-to-date. This is a prerequisite that catches teams off guard, because outdated manufacturer firmware causes mid-migration failures that look like Windows errors until you trace them back to firmware. Only after all of that does setting the AvailableUpdates registry key to 0x5944 and starting the Secure-Boot-Update scheduled task actually begin the migration. Then come the reboots—typically two, with the scheduled task needing to rerun after the first—and the monitoring to confirm that UEFICA2023Status actually reached Updated, not just that the script ran cleanly.

None of this is hard on a single device. The difficulty is that you're doing it across a fleet where machines are in different states—some on Legacy BIOS, some with Secure Boot disabled, some waiting on OEM firmware, some ready right now, some already done. And those states keep shifting as devices get repaired, reimagined, or newly onboarded.

Microsoft supports three deployment methods for the trigger—registry key via PowerShell, Group Policy, and the WinCS APIs—and each has a significant gap. PowerShell gives you no native way to confirm whether the migration actually completed. Group Policy only reaches domain-joined devices, so remote workers off VPN and workgroup machines are silently missed. WinCS is scoped to Windows 11 23H2 and later, domain-joined only, leaving everything else uncovered. Manually reconciling all of this across a real enterprise fleet—checking firmware status per device, coordinating reboots, parsing event logs for errors, confirming completion—is the kind of work that doesn't scale gracefully. It just becomes a larger version of the same problem.

Where the DEX add-on for Endpoint Central comes in    

If you're already running Endpoint Central, the DEX add-on includes a workflow purpose-built for this migration. It handles the parts that registry pushes and Group Policy don't.

The piece doing the heavy lifting is the SecureBoot Upgrade workflow. Before it triggers migration on any device, it validates readiness—firmware type, Secure Boot state, OEM details, capability flag. Devices that aren't ready don't get triggered; they go into a separate queue with the specific blocker surfaced, so you can see exactly which machines need OEM firmware updates and which can't migrate at all. For devices that pass validation, the workflow handles the trigger, sequences reboots with user notification so production users aren't caught off guard, reruns the scheduled task after the first reboot for the second migration phase, and watches UEFICA2023Status and UEFICA2023Error per device throughout. It only signs off on a device when migration is confirmed complete—not assumed because no errors fired.

Feeding the workflow is the Firmware Readiness sensor, which inventories firmware state continuously across the fleet. Not a one-time export that's stale by the next day—a live view of every managed endpoint that updates as devices change state. And the execution itself is handled by the SecureBoot Update script, which sets the registry key and starts the scheduled task, but only on devices the sensor has cleared.

What you end up with is the thing manual execution can't give you: a real, up-to-date count of where your fleet actually stands. How many devices are complete. How many are in progress. How many are firmware-blocked. How many errored and need attention. That's the picture you take to leadership when they ask whether you're ready for June.

What to do now  

If you're on Endpoint Central, enabling the DEX add-on and running the Firmware Readiness Sensor across your fleet gives you an honest baseline of where you stand. From there, the SecureBoot Upgrade Workflow handles the migration itself.

If you'd like to talk through what this looks like in your environment before committing to anything, reach out to one of our product experts. Either way, the work is worth starting now rather than later.