Secure Boot certificates 2026: three Microsoft deadlines and what IT teams need to check now

On 19 October 2026, the third and final Microsoft Secure Boot certificate from the 2011 infrastructure expires: the Windows Production PCA 2011. Two earlier certificates have already expired: the Key Exchange Key CA 2011 on 24 June and the UEFI CA 2011 on 27 June. For well-managed Windows environments, the new 2023 certificates have already been deployed automatically via Windows Update. But in almost every device fleet there are systems that have not yet received those updates — and now is the time to act.

Devices without updated certificates will still start up normally. The immediate danger is not that systems will crash or users will be locked out. The indirect danger is more serious: after the expiry date, these devices can no longer receive new boot-level security updates. Think of revocation lists for compromised bootloaders, updates to the Secure Boot database, and mitigations for vulnerabilities discovered in the boot process after that date. In environments with compliance requirements, a device without current Secure Boot certificates is also a risk that must be explained and justified.

What is Secure Boot and why are the certificates so critical?

Secure Boot is a security feature in a device's UEFI firmware that verifies that all software in the boot process is cryptographically signed by trusted parties. Without a functioning Secure Boot chain, an attacker with physical access — or a UEFI implant — can bypass the operating system before Windows has even started. At that point, antivirus, EDR solutions, BitLocker, and Intune policies are all rendered ineffective.

The Secure Boot chain of trust relies on three levels managed by Microsoft. The Key Exchange Key (KEK) determines which entities may modify the Secure Boot database. The UEFI CA enables signing of Linux bootloaders and third-party UEFI components. The Windows Production PCA guarantees the signing of the Windows Boot Manager and the Windows kernel itself. All three were created in 2011 and are now expiring in sequence.

What happens concretely after the expiry date?

A Windows device on which the old 2011 certificates are still active will continue to function normally after the expiry date. Existing drivers and bootloaders signed with those certificates will keep working. The problem lies in future updates: after the expiry date, Microsoft cannot deliver new boot-level security updates built exclusively on the new 2023 certificates to devices that do not yet recognise those new certificates.

Concretely this means the Secure Boot Forbidden Signature Database — the revocation list that blocks known compromised bootloaders — will over time only function fully on devices with the 2023 certificates. Devices without the update may remain vulnerable to bootloader exploits for which mitigations have been released but that they can no longer receive.

Which devices are at most risk?

In most well-managed Windows 10 and Windows 11 environments, the 2023 certificates have already been deployed via Windows Update, provided devices are up to date. Four categories of devices now require extra attention. First, devices that have been offline for an extended period or are strictly isolated from Windows Update: production OT systems, kiosks, medical devices, and meeting-room equipment. Second, devices with older UEFI firmware that does not support automatic certificate roll-out via Windows Update and requires an OEM firmware update.

Third, dual-boot systems running Linux distributions that depend on the UEFI CA 2011 for signing their bootloader. Linux distributions have published their own migration paths for these devices, but the IT administrator must verify whether those have been followed. Fourth, virtual machines where Secure Boot is enabled but the VM templates have not been refreshed — particularly in Hyper-V and Azure environments running on long-lived images.

What should IT administrators do now?

Four concrete steps for the period up to 19 October. First: inventory which devices have already received the 2023 certificates. In Microsoft Intune you can pull a compliance report based on Secure Boot status. In Microsoft Defender for Endpoint, device entries show which devices have issues with firmware integrity checks.

Second: review Windows Update management. Devices managed via Windows Update with less than thirty days of update lag have in virtually all cases already received the new certificates. Check via Intune Update Rings and Update Compliance whether any devices have a significant update backlog — these are almost certainly also the devices with outdated Secure Boot certificates.

Third: check whether OEM firmware updates are available for older hardware. On some systems, replacing the certificates requires not only a Windows Update but also a UEFI firmware update from the manufacturer. Most major manufacturers, including Dell, HP, and Lenovo, have made firmware updates available for current models. Use management tools such as Dell Command Update, HP BIOS Connect, or Lenovo System Update via Intune to handle firmware management systematically.

Fourth: check Azure and Hyper-V VM images. For virtual machines, Secure Boot certificates reside in the virtual firmware. Generation 2 VMs in Hyper-V and Azure VMs receive updates from Microsoft, but VM templates, snapshots, and golden images that have not been refreshed for some time may need to be updated manually.

What should you definitely not do?

One 'solution' sometimes suggested is to disable Secure Boot in order to avoid certificate-related warnings. Do not do this. Disabling Secure Boot removes the entire protection layer against boot-level malware. A device without Secure Boot is vulnerable to UEFI rootkits and bootkits that become active before the operating system loads — and are therefore completely beyond the reach of antivirus software, EDR, and BitLocker.

Devices without Secure Boot also fail to meet the security baselines of Intune, the recommendations of Microsoft Defender for Endpoint, and the requirements of common frameworks such as ISO 27001, NIS2, and most cyber insurers. The correct approach is always to update via the appropriate channel: Windows Update for supported devices, OEM firmware for hardware that requires it, and replacement for devices whose firmware is too old to update.

Practical plan for the coming weeks

Before 1 September, produce a report of all devices in your management system with their Secure Boot status and update lag. Prioritise devices with a Windows Update deferral of more than ninety days. Set up a deployment schedule for OEM firmware updates via Intune or your management tool. Before 1 October, report internally which devices have not yet been updated and what the plan is for remaining exceptions.

Does your organisation need support in inventorying Secure Boot compliance, setting up firmware update processes in Intune, or assessing which hardware needs to be replaced? Zarioh helps IT teams tackle this type of infrastructure security question systematically. Contact us for a no-obligation analysis of your current situation.