Mads Johansen

Mads Johansen

Follow this blog to get hints/tips for doing awesome things in Intune!

Whats up with the Secure Boot certificates expiring in 2026?

3 minute read

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.

Thumbnail

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

Microsoft can manage the rollout for your automatically. But for them to do that, there is 2 requirements:

Requirement #1: 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

Policy

Requirement #2: You need to deploy a registry key for your devices to tell Microsoft that you are opting in to the automatic rollout. The reg key needs to be deployed like so:

  • Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
  • Key name: MicrosoftUpdateManagedOptIn
  • Key type: DWORD
  • DWORD value: 0x5944

To make sure it’s deployed, we can use Intune to deploy this using a PowerShell script:

$Path  = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
$Name  = 'MicrosoftUpdateManagedOptIn'
$Value = 0x5944  # 22852 decimal

if (!(Test-Path $Path)) {New-Item -Path $Path -Force}
New-ItemProperty -Path $Path -Name $Name -PropertyType DWord -Value $Value -Force

You can also download it from my github here

Note: Meeting these requirements doesn’t mean all devices update at once. Microsoft rolls out updates gradually, grouping devices by hardware and firmware, monitoring feedback, and pausing if issues appear.

Otherwise 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.

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

UPDATE, 4th of September 2025: Per Larsen has created a Remediation to check if the updated certs are already on your device, and if not, they will be flagged as “With Issue”. You can find it here

Wrapping up

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 — as long as you’ve prepared properly. If you’re running hardware from major OEMs like Dell, HP, or Lenovo and keeping them updated, you’re likely already covered. 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 :)

UPDATE, 3rd of September 2025: Some sources cite that all devices onboarded in autopatch is automatically enrolled into the secure boot rollout, thus deploying the reg key is not necessary - But it’s currently unclear. I’m chasing Microsoft for an official response and clarification regarding the scope/impact of setting the registry key mentioned in Requirement #2, if this is in fact necessary.

UPDATE, 4th of September 2025: Initial response from Microsoft suggests that if you are using autopatch, you do not have to set the registry key as outlined in Requirement #2. It’s still being clarified. Will update this blog post once I know more.

UPDATE, 7th of September 2025: In a new response from Microsoft they have let us know that a more detailed blog post, documentation and FAQ is on the way. ETA is 2-3 weeks. They also underlined the staged rollout will be intentionally slow, due to the risks involved.

You May Also Enjoy