In 2026, the certificates that are part of Microsoft Windows, and used for the last 15 years by Secure Boot are set to expire.

Secure Boot is a core security feature that protects devices from malware during the startup process.

For most up-to-date consumer devices, this change will be handled automatically through Windows Update and will require no action.

However, for organisations managing fleets of Windows devices, this expiry has operational implications:

• Firmware updates may be required on some devices to ensure compatibility with the updated Secure Boot certificates.
• Old or outdated Windows installation media (including Autopilot, WinPE, and custom images) may no longer boot after the expiry if they rely on signatures from the expiring certificates.
• Legacy or unsupported hardware may face boot failures if not updated.
• OS deployment and provisioning processes may need to be reviewed and refreshed before June 2026 to avoid service disruptions.

This is a relatively simply change to manage ahead of time, but requires proactive preparation across firmware, deployment tools, and image maintenance, particularly for enterprises using Intune, Autopilot, or custom deployment pipelines.

How does Secure Boot work?

• Your motherboard/UEFI holds a list of trusted cryptographic certificates/keys.
• When the system boots, it checks whether bootloader and OS files are signed by one of those trusted keys.
• If something within the bootloader has been tampered with, for example, to include malware or rootkits then Secure Boot blocks the boot process, protecting the device.

Secure Boot helps ensure:

• Protection from boot-level malware
• Only legitimate OS loaders run (e.g., Windows Boot Manager)
• Compliance for organisations (e.g., Microsoft Intune, Windows Autopilot, BitLocker CSP requirements)

What are the Microsoft Secure Boot certificates expiring in June 2026?

Since Windows introduced Secure Boot support, all Windows-based devices have carried the same set of Microsoft certificates in the KEK and DB. These original certificates are nearing their expiration date, and your device is affected if it has any of the listed certificate versions. To continue running Windows and receiving regular updates for your Secure Boot configuration, you will need to update these certificates.

Terminology

• KEK: Key Enrollment Key
• CA: Certificate Authority
• DB: Secure Boot Signature Database
• DBX: Secure Boot Revoked Signature Database

Expiring Certificate	Expiration date	New Certificate	Storing location	Purpose
Microsoft Corporation KEK CA 2011	June 2026	Microsoft Corporation KEK 2K CA 2023	Stored in KEK	Signs updates to DB and DBX.
Microsoft Windows Production PCA 2011	Oct 2026	Windows UEFI CA 2023	Stored in DB	Used for signing the   Windows boot loader.
Microsoft UEFI CA 2011*	June 2026	Microsoft UEFI CA 2023	Stored in DB	Signs third-party boot loaders and EFI applications.
Microsoft UEFI CA 2011*	June 2026	Microsoft Option ROM UEFI CA 2023	Stored in DB	Signs third-party option ROMs

What does this mean for you?

If you are a normal Windows user, then in most cases, nothing. Windows Update will update the Secure Boot trust chain silently. Your PC should continue to boot normally as long as you are running supported Windows versions.

If you manage devices in a Modern Workplace environment (Intune, Autopilot, enterprises), then this does matter, and here’s how;

Firmware/UEFI updates may be required

Some older devices have the expiring certificates embedded in firmware and cannot boot signed Windows components after expiration unless:

• A firmware update is installed, or
• Windows updates the allowed certificates via Secure Boot DB/DBX updates.

Devices without vendor support may face issues.

Older OS images / Autopilot / OSD may break

If you’re using

• Old Windows installation media (ISO/WIM), or deploying Images using SCCM for example
• Offline Autopilot images
• Old WinPE or custom bootloaders

…these may contain components signed with certificates that expire in 2026. As such, devices might refuse to boot the installer or enter recovery loops when Secure Boot enforces the new trust chain.

Virtual machines are not exempt…

Hyper-V, VMware, and Azure Generation 2 VMs using Secure Boot also rely on these certificates. Updated VM templates will be required.

What do you need to do?

Ensure all devices stay fully patched

Windows Update will carry updated Secure Boot policies.

Update firmware on all models in your fleet

Especially:

• Dell
• Lenovo
• HP

They’ll release UEFI updates to replace old certificates before expiration.

Refresh all deployment media

Rebuild:

• Windows installation ISOs/WIMs
  • Update any SCCM Task Sequences using legacy media
• WinPE/WinRE images
• Autopilot reference images
• Golden images (e.g. Citrix/VDI)

What happens if you do nothing?

• Older/unpatched PCs may fail to boot.
• Out-of-date deployment tools / installers will fail Secure Boot verification.
• Enterprises could see Autopilot and OSD failures.

How to configure Intune in preparation…

Effectively, the “fix” at least for Windows Updates, is to enable a value within Registry to check for Secure Boot updates. Using Intune, we can make use of the native configuration profiles to do this. Here’s how…

From Intune, goto Devices > Windows > Configuration Profiles and create a new Configuration Profile for Windows 10 and later devices. Use Settings Catalog as the profile type.

Give the policy a name and description.

Browse Settings Catalog for “Secure Boot” and there should be three options, tick these and include them in your Configuration Profile.

Enable the settings as desired.

Then assign it to your devices as desired.

Below, I’ve included the descriptions published by Microsoft. I’ve done this, as there will undoubtedly be some questions around “Configure High Confidence Opt-out”, which, by default is Disabled… (so consider that).

Configure Microsoft Update Managed Opt In

This policy allows enterprises to participate in a Controlled Feature rollout of Secure Boot certificate update managed by Microsoft. In order for this to work, there is a prerequisite in that the device(s) must send required diagnostic data to Microsoft.

• Enabled: Microsoft assists with deploying certificates to devices enrolled in the rollout.
• Disabled (default): No participation in controlled rollout.

This setting corresponds to the registry key MicrosoftUpdateManagedOptIn within HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\.

Configure High Confidence Opt-Out

This policy controls whether Secure Boot certificate updates are applied automatically through Windows monthly security and non-security updates. Devices that Microsoft has validated as capable of processing Secure Boot variable updates will receive these updates as part of cumulative monthly updates and apply them automatically. Because not all hardware and firmware combinations can be exhaustively validated, Microsoft relies on targeted testing and diagnostic data to determine device readiness. Only devices with sufficient diagnostic data can be considered with high confidence; if diagnostic data is unavailable for a given device, it cannot be classified with high confidence.

• Enabled: Automatic deployment through monthly updates is blocked.
• Disabled (default): Devices that have validated their update results will automatically get certificate updates as part of the monthly updates.

This setting corresponds to the registry key HighConfidenceOptOut within HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\.

Enable Secureboot Certificate Updates

This policy controls whether Windows initiates the Secure Boot certificate deployment process on devices.

• Enabled: Windows automatically begins deploying updated Secure Boot certificates.
• Disabled (default): Windows does not deploy certificates automatically.

The task that processes this setting runs every 12 hours. Some updates may require a restart to complete safely. Once certificates are applied to firmware, they cannot be removed from Windows. Clearing certificates must be done through the firmware interface.

This setting corresponds to the registry key AvailableUpdates within HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\.

Note: Windows cannot update the active variables of the Secure Boot certificates if Secure Boot is disabled.

Don’t forget… in addition to this, the device(s) may also need BIOS/Firmware updates. So, ensure you have your BIOS/Firmware update processes in check too…