Whats up with the Secure Boot certificates expiring in 2026?

UPDATED 22nd of November 2025: Removed all of the previous updates, since new information kept surfacing, so I will TL;DR this: New blog post released by Microsoft a few days ago, you can find it here

If you manage Windows devices, you might have noticed some alerts about Secure Boot certificates expiring in 2026. This is a common concern, but there’s no need to panic. I’ve noticed some conflicting information about to manage this issue, hence this blog post to clear things up.

What you need to know

• The existing 2011-era certificates (KEK CA 2011, UEFI CA 2011, and Production PCA 2011) are expiring in mid‑2026, which would disrupt Secure Boot security.
• Failing to update the boot certificates could result in the following implications:

1. Lose the ability to install Secure Boot security updates after June 2026.
2. Not trust third-party software signed with new certificates after June 2026.
3. Not receive security fixes for Windows Boot Manager by October 2026.

Source

Deploying the updated Secure Boot certificates

You have several options for deploying the secure boot certificates. The most interesting options are the following:

Option 1 - Automatic rollout via High-confidence buckets

This is the most hands-off approach, but it also requires a bit of faith that your device has been placed into one of Microsoft’s “high-confidence buckets.” If it hasn’t, the device won’t automatically receive the updated Secure Boot certificates.

Microsoft describes this process as follows:

“Microsoft may automatically include high-confidence device groups in monthly updates based on diagnostic data shared to date, to benefit systems and organizations that cannot share diagnostic data. This step does not require diagnostic data to be enabled.” (Source)

In practical terms, “high-confidence buckets” refer to devices that Microsoft believes are processing updates reliably. However, if you are not sending diagnostic data, Microsoft has a limited view of how your devices behave. As a result, your devices may not be classified correctly—and may not receive the automatic Secure Boot certificate update.

Option 2 - Automatic rollout via Microsoft Controlled Feature Rollout (CFR)

Recent additions to the Intune Settings catalog has allowed us to deploy policies to enable the secure boot rollout on-demand or via a Microsoft-managed rollout. Previously you had to set reg keys to achieve this.

This option corresponds to the registry key “MicrosoftUpdateManagedOptIn”.

By deploying this policy you will participate in a Microsoft-managed rollout also known as Controlled-feature rollout. This rollout will be fully controlled by Microsoft, and usually CFRs involves a careful and staggered rollout approach based on certain criteria, grouping devices by hardware and firmware, monitoring feedback, and pausing if issues appear. In other words: With this option you are also completely in the hands of Microsoft with this one, but it differentiates slightly from the High-Confidence option. Expect the CFR-rollout option to be much slower.

For this option to work you need to ensure you are sending required or optional diagnostic data to Microsoft. If you are already using WufB or Autopatch you probably already are doing it, but know that in March 2025 Autopatch revoked the policy they deploy by default to do this on your behalf (Ref: MC996580). If you want to be sure, you can craft your own policy and apply to devices in scope. Look for the “Allow Telemetry” setting in the settings catalog. Source

If you want to let Microsoft managed the rollout via the CFR process, search for “Secure Boot” in the settings catalog to find the relevant policies. .

NOTE: Testing this policy through intune as of this date (22. November 2025), it gives an error 65000 in Intune. I’m guessing Microsoft will get this fixed/updated soon. If you also face this error, you can find the registry key to deploy this option, as a workaround, in my github here

Option 3 - Self-managed rollout using Intune policies

This option corresponds to the registry key “AvailableUpdates”.

If you want to manage the rollout of the secure boot certificates yourself, search for “Secure Boot” in the settings catalog to find the relevant policies. .

This option can be highly desirable if you want to be in complete control yourself, as this allows you to roll this policy out in your own rings/waves. This option also should not require for you to send diagnostic data to Microsoft.

NOTE: Testing this policy through intune as of this date (22. November 2025), it gives an error 65000 in Intune. I’m guessing Microsoft will get this fixed/updated soon. If you also face this error, you can find the registry key to deploy this option, as a workaround, in my github here

NOTE: There is also a GPO option for all of the above mentioned options if you are not yet in Intune, or haven’t flipped the “Device configuration” workload to Intune yet. You can find more info about the GPOs here

Wrapping up

UPDATE, 19th of November 2025: I have created a remediation you can use to check your devices are running with the updated cert. You can find it here.

Also be aware that Microsoft is already working with OEM’s to also push out BIOS Updates, where the updated certificates are also present. So if you are already keeping your BIOS Up-to-date in your org, chances are, you already received the updated certificates. You can find articles from Dell and HP about how they are adressing things from their end. They are already updating the certificates from their end via BIOS Updates on newer models.

If your devices are in an air-gapped environment or with limited network connectivity, you will have to update these certificates manually. See this article for more information.

The full Microsoft guidance is available in this article

Plenty of scripts online suggest you need to handle this certificate update yourself. For most organizations, that’s not the case. Microsoft will take care of it or you can choose to take matters into your own hands with new easy-to-deploy intune policies. If you’re running hardware from major OEMs like Dell, HP, or Lenovo and keeping them updated, you’re likely already covered to a certain extent. Also, this is issue is also present on servers, so make sure to prepare accordingly for your servers as well.

Hopefully this clears up the confusion and saves you from chasing unnecessary “DIY fixes.”.

Thanks for reading — and have an awesome day :)