Microsoft has warned that the Secure Boot certificates first deployed in 2011 will begin to expire in mid‑2026, and organizations that don’t update their trust chain risk losing the ability to receive security fixes for pre‑boot components — and in rare, poorly‑prepared environments, may encounter update or boot interruptions. This change is not a simple certificate rollover; it touches firmware, OEM signed keys, Windows servicing logic, and enterprise update policies, and it demands proactive inventory, testing, and remediation now — not at the last minute.
Background: what is Secure Boot and why certificates matter
Secure Boot is a UEFI‑level security mechanism that ensures the platform boots only code that is signed and trusted by the firmware’s certificate store. The UEFI variables — commonly called
PK (Platform Key),
KEK (Key Exchange Key),
DB (allowed signature database) and
DBX (revoked signature database) — are the root of trust used to validate bootloaders, option ROMs, and other pre‑OS components.
Microsoft historically provided three widely‑distributed Microsoft certificates in these firmware variables to support Windows and third‑party boot components. Those certificates were issued around 2011 and have long lifetimes, but they are not permanent. Certificates expire, and once the old certificate authorities (CAs) in firmware expire, Windows cannot apply new signatures or security updates for boot‑time components that rely on those CAs. To avoid that outcome, Microsoft and OEM partners created a new set of
2023 certificates that must be applied to the KEK and DB variables before the older
2011 CAs expire.
This is fundamentally a platform‑level trust update: it’s similar to replacing a root certificate in a PKI — but the replacement happens in firmware variables and sometimes requires OEM cooperation to be signed by the device’s Platform Key (PK). Because firmware is involved, both Microsoft servicing and OEM BIOS/UEFI updates play a role.
Timeline and the certificates that are changing
- June 2026 (beginning) — the Microsoft certificates stored in KEK and some DB slots (the Microsoft Corporation KEK CA 2011 and Microsoft Corporation UEFI CA 2011) are scheduled to begin expiring. Devices that still rely on those CA versions must transition to the new 2023 certificates before this window.
- October 2026 — the Microsoft Windows Production PCA 2011 certificate (used to sign the Windows boot manager) expires later in 2026, so the boot manager signing trust must also be transitioned by then.
- Microsoft has issued new certificate variants (Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, and Microsoft Corporation KEK 2K CA 2023) to replace the expiring entries and to allow finer control (for example, separating option ROM trust from bootloader trust).
These dates and the set of replacement certificates are the product of a coordinated rollout between Microsoft and OEMs. OEM advisories and manufacturer support pages confirm the same broad dates and the need for firmware updates or Windows‑driven certificate application.
Who is affected and how severe is the risk?
Short answer: most Secure Boot‑enabled Windows devices manufactured since about 2012 are potentially affected. The level of risk depends on several factors:
- Devices that are kept fully patched and are running supported Windows releases with normal Windows Update behavior are likely to receive the required certificate updates automatically via Windows servicing or OEM firmware updates.
- Systems with IT‑managed update policies, devices in isolated networks, machines without recent firmware updates, or platforms that are out of OEM support are at higher risk because they may not accept the certificate changes or may not be included in Microsoft’s automated rollout.
- Virtual machines and cloud environments can be impacted if the hypervisor or cloud provider doesn’t include the new certificates in the virtual firmware image or doesn’t allow the guest to update its firmware variables.
- Some third‑party bootloaders and pre‑OS components (including some Linux shim/GRUB chains and option ROMs) can be affected depending on what CA entries they rely on; not all devices include the same Microsoft CA entries in firmware so the precise scope varies by platform.
Consequences of failing to update before expiration:
- Loss of ability to install future Secure Boot–related security updates for pre‑boot components.
- Inability for the device to trust new boot loaders or option ROMs signed with the new CA after the old CA expires.
- In rare or poorly configured environments, update failures can cascade into boot problems — particularly on virtualized hosts, devices with older firmware, or systems that don’t follow the recommended update flow.
It’s important to emphasize that the most common outcome will be update or signing failures for pre‑boot components, not wholesale device bricking. Still, the consequences for security compliance and exposure to boot‑level threats (bootkits, compromised firmware) are material.
How Microsoft and OEMs are rolling this out
Microsoft’s approach to this transition is multi‑pronged:
- Windows‑driven updates: Microsoft has built logic into Windows that can apply the new certificates to firmware variables. A scheduled task runs periodically and processes a registry flag that triggers a series of steps: add the Windows UEFI CA 2023 to DB, add optional UEFI CA entries if the previous 2011 UEFI CA was present, apply a KEK signed by the OEM’s PK, and finally update the Windows boot manager to one signed by Windows UEFI CA 2023. The sequence is designed to ensure each step completes before the next runs.
- Controlled Feature Rollout (CFR) and diagnostic telemetry: Microsoft can manage certificate deployment across “high‑confidence” buckets of devices. For CFR to work, devices must have diagnostic data enabled and opt into the rollout. Microsoft will not rely on CFR to remediate every device; it’s an assist for many, but not a full fix for fleets with unique constraints.
- OEM firmware updates: OEMs have been working with Microsoft to include the 2023 certificates in platform firmware so the updated certificates are present by default on new devices and available via BIOS/UEFI updates for existing hardware. Many OEMs began shipping firmware with the new certificates in 2024 and have been distributing firmware updates during 2024–2025.
- Windows Update channel: Microsoft will deliver the necessary firmware variable payloads (signed and appropriately packaged) via the cumulative update infrastructure, honoring OEM PK signing where required. This is why device restart cycles tied to monthly updates matter; some boot manager updates wait for a restart to be applied.
OEMs (including major vendors) are publicly advising customers to keep firmware current, and many provide lists of affected platforms and minimum BIOS versions required for a smooth transition.
The technical mechanics: what actually happens during the update
The certificate update is a sequence of firmware variable changes and a replacement of the Windows boot manager image. The high‑level flow that Windows follows is:
- A device is targeted for the update and a registry bit is set that instructs a scheduled task to run.
- The scheduled task (running about every 12 hours) processes bits in the AvailableUpdates registry key in a specific order:
- Apply Windows UEFI CA 2023 to DB.
- If the 2011 UEFI CA exists in DB, conditionally apply Microsoft Option ROM UEFI CA 2023 and Microsoft UEFI CA 2023.
- Add the Microsoft Corporation KEK 2K CA 2023 (this step requires the OEM‑signed KEK delivered by the OEM).
- Update the Windows boot manager to a binary signed by Windows UEFI CA 2023 (this requires a restart to complete).
- Each step logs event entries; administrators can monitor these events to confirm success. There are defined event IDs for success and failure scenarios and registry keys (like UEFICA2023Status, UEFICA2023Capable, and UEFICA2023Error) to report status and error conditions.
- If firmware rejects an update or if the OEM’s PK has not been used to sign the KEK replacement, the process will surface errors that require OEM intervention or firmware updates.
This careful ordering prevents the system from trusting a new boot manager before the new CA hierarchy is in place, and prevents incomplete transitions that could leave the system unable to accept future secure updates.
Verifying certificate status: checks and tools for admins
Administrators should proactively verify which devices in their fleet are ready. Practical verification methods include:
- GUI quick check (device‑by‑device):
- Settings > Privacy & Security > Windows Security > Device security — the Secure boot entry should say “On.”
- Command line: run the Confirm‑SecureBootUEFI PowerShell cmdlet; it returns True if Secure Boot is enabled.
- Registry inspection: look for keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot, including:
- SecureBootEnabled
- AvailableUpdates
- Servicing keys such as UEFICA2023Status, UEFICA2023Capable, UEFICA2023Error
Monitor these to see whether the scheduled task has been targeted and whether updates have been applied.
- Event logs: watch for Secure Boot‑related event IDs (for example, there are event IDs that indicate successful CA update completion or firmware errors during the update).
- Inspect the boot manager signer: mount the EFI system partition and examine the certificate used to sign the Windows boot manager binary (for example, using the Get‑PfxCertificate command on the bootmgfw.efi file) to see whether it’s signed by Microsoft Windows Production PCA 2011 or the new Windows UEFI CA 2023. This is a low‑level forensic check useful in labs or for spot checks.
Microsoft also published PowerShell scripts and deployment guidance intended to inventory devices at scale, validate Secure Boot enablement, gather device attributes (manufacturer, model, firmware version), and report whether the device is ready to process the certificate update. These scripts were added to the official guidance to help IT run fleet‑wide checks.
Step‑by‑step remediation plan for IT teams (recommended sequence)
- Inventory and prioritize:
- Identify all Secure Boot‑enabled devices (Confirm‑SecureBootUEFI or management console).
- Tag critical systems and devices out of vendor support for earlier remediation.
- Establish a test matrix:
- Create a representative sample set (by manufacturer, model, firmware version). Microsoft recommends multiple samples per unique device category to catch firmware inconsistencies.
- Confirm telemetry and CFR readiness:
- If you plan to rely on Microsoft’s CFR assist for some portion of your fleet, ensure required diagnostic data settings are enabled and devices are opted into the CFR flow as outlined by Microsoft.
- Update firmware where required:
- Check OEM support pages for firmware that includes the 2023 certificates or minimum BIOS versions required.
- Apply firmware updates to test devices first; validate that Secure Boot CA updates apply cleanly and that the device reboots properly.
- Deploy in waves:
- Use a phased rollout, monitoring event logs and registry indicators (AvailableUpdates bits, UEFICA2023Status) and application of event ID 1808 (indicating successful CA update completion).
- Monitor and remediate:
- Track devices that fail the KEK step or return firmware errors (event IDs are defined for these cases). If KEK update fails, OEM intervention is required because the KEK must be signed by the OEM PK.
- Replace unsupported hardware:
- For devices where firmware cannot be updated and OEMs are no longer in support, plan device replacement; continuing to run such hardware poses a security and compliance risk once the 2011 CAs expire.
Practical checklist for home users and small businesses
- Ensure Windows Update is enabled and that your system is running a supported Windows build.
- Install any pending Windows cumulative updates and reboot as needed — the certificate update often requires restarts to complete final boot manager updates.
- Check Device security > Secure boot in Windows Security to confirm Secure Boot is enabled.
- Keep your firmware (BIOS/UEFI) up to date by checking the OEM’s support site and applying vendor firmware updates.
- Back up critical data and create a recovery image before applying firmware updates, as with any firmware change.
Virtualization and cloud environments: special considerations
Virtual machines depend on the hypervisor’s firmware implementation. For VMs:
- Cloud providers and hypervisor vendors can patch the virtual firmware image to include the new certificates for newly provisioned VMs.
- For long‑lived VMs, Windows can apply the CA updates if the virtual firmware supports variable updates; if the hypervisor does not support updates to the virtualized KEK/DB, guests may not be able to complete the transition.
- Administrators should consult cloud/hypervisor vendor guidance and test VMs in a controlled environment to verify updates apply cleanly. For large cloud estates, coordinate with the cloud vendor’s maintenance schedule.
Risks, edge cases and things that can go wrong
- OEM PK / KEK dependency: Because the KEK replacement step requires an OEM‑signed KEK (the PK owner must sign the new KEK), devices from OEMs that haven’t completed their signing process may stall at the KEK step. This requires OEM follow‑up and may show a persistent registry bit that won’t clear until the KEK is present.
- Firmware bugs: Firmware that incorrectly handles authenticated variable updates or rejects properly signed payloads can cause failures; such cases usually surface as firmware error event logs and demand OEM firmware fixes.
- Devices out of support: Older hardware outside OEM support windows might not receive a BIOS update and could remain on expiring certificates; replacement may be the only practical option.
- Dual‑boot / Linux compatibility: Some Linux distributions use shim/GRUB and rely on UEFI trust chains; changes in the Microsoft UEFI CA set can affect the ability of some Linux boots to continue under Secure Boot. Not all devices include the same Microsoft UEFI CA entries; outcomes vary by platform.
- Telemetry opt‑out: Devices that suppress the required diagnostic data or are blocked from participating in Controlled Feature Rollout will not benefit from Microsoft’s automated assist and will need manual remediation.
- Scale and timing: Large fleets with strict change windows or tightly controlled update policies (air‑gapped, staged, or long lead time change approvals) must allow for the rollout time and testing overhead. Microsoft estimates the collection of steps may require multiple restarts and up to a 48‑hour window for completion in normal conditions.
Where a claim about affected device counts or exact failure rates would be useful, such figures are not publicly enumerated; the precise number of devices at risk depends on each organization’s inventory, OEM update cadence, and telemetry participation. That means administrators should assume there is non‑trivial exposure until they verify their own fleet.
Recommendations — practical and prioritized
- Treat this as a high‑priority maintenance project. Schedule inventorying, testing, firmware updates, and staged deployment now; don’t wait until 2026.
- Build a small but representative test lab that reflects the diversity of your hardware estate.
- Engage OEM support early for models you manage at scale; get firmware timelines and any required signing artifacts from vendors.
- If you manage devices with strict update policies, create an exception window or a targeted deployment plan to allow these critical Secure Boot updates.
- For cloud and virtualization teams, coordinate with the cloud/hypervisor vendor and plan for either a provider‑level firmware update or guest‑level remediation if supported.
- Use the published event IDs, registry indicators, and PowerShell inventory scripts to track progress and identify devices that need manual remediation.
- Maintain recovery images and backups as a standard precaution before mass firmware or pre‑boot updates.
Why this matters for security and compliance
Boot‑level security is the foundation for many modern protections. If secure boot trust cannot be updated because the intermediate signing CA in firmware has expired, Microsoft cannot deliver future pre‑boot mitigations, and that enlarges the attack surface for bootkits and firmware attacks. For regulated environments and security‑conscious operations, ensuring the new certificates are applied is part of basic compliance hygiene.
This transition is also an opportunity: the new boot manager signed with the Windows UEFI CA 2023 includes improvements, and the split of option ROM signing from bootloader signing allows administrators to have more granular control over what gets trusted in the pre‑OS environment.
Conclusion: act now, validate thoroughly, and coordinate with OEMs
The Secure Boot certificate transition is a coordinated platform lifecycle event, not a routine security patch. Microsoft and major OEMs are delivering tooling, firmware updates, and deployment aids — but the ultimate responsibility for ensuring a device can accept the updated CA chain lies with device owners and IT administrators. Inventory your fleets, test on representative hardware, monitor the registry and event logs for update status, and maintain communication with OEMs for firmware fixes.
Start the work today: validate that Secure Boot is enabled on critical systems, confirm firmware update availability, enable monitoring and diagnostic data where necessary for controlled rollouts, and schedule a staged deployment. Doing so will avoid last‑minute scramble in mid‑2026 and ensure devices remain secure and serviceable during and after the certificate rollover.
Source: The Windows Club
Windows Secure Boot Certificates to expire in 2026