Windows Secure Boot UEFI Certificates Expiring June 2026

For IT administrators responsible for managing Windows devices, a crucial certificate update milestone is coming in June 2026 that could result in degraded security for systems that are not updated. Specifically, the Microsoft certificates that manage UEFI Secure Boot trust will expire, potentially allowing untrusted or malicious software to load on affected machines during system boot.

Secure Boot

Windows Secure Boot is a UEFI firmware security feature that ensures a computer boots only with trusted, digitally signed operating system loaders and drivers, preventing malicious code (such as rootkits or compromised bootloaders) from loading during startup. Introduced with Windows 8, it verifies the cryptographic signatures of boot components against a database of authorized keys, blocking unauthorized or tampered software to protect system integrity from the earliest stages of boot.

Chain of Trust

The UEFI Platform Key (PK) is the ultimate root of trust in Secure Boot. It is a single public key owned by the device manufacturer and stored in firmware. The PK certificate signs the Key Exchange Key (KEK) and grants authority to modify the other Secure Boot databases, such as the allowed database (DB) and the disallowed database (DBX). The DB and DBX contain certificates and signatures for authorized and unauthorized software, respectively.

Microsoft Secure Boot Certificate Expiration

Two crucial Microsoft Secure Boot certificates are set to expire in June 2026. They are:

  • Microsoft Corporation KEK CA 2011 (stored in KEK)
  • Microsoft UEFI CA 2011 (stored in DB)

In addition, another critical Microsoft Secure Boot certificate expires in October 2026.

  • Microsoft Windows Production PCA 2011 (stored in DB)

When these certificates expire, devices may fail to recognize trusted bootloaders, and future Secure Boot policies may not be applied. Updating the certificates ensures continued protection against malicious rootkits and ensures Windows firmware compliance

View Certificate Information

Ideally, administrators could use PowerShell to view these UEFI Secure Boot certificates. Sadly, the output of the Get-SecureBootUEFI PowerShell command is not particularly helpful and does not display any pertinent certificate details.

Get-SecureBootUEFI -Name KEK

PowerShell Script

To address this limitation, I’ve created a PowerShell script that allows administrators to view all UEFI certificates, including PK, KEK, and DB certificates, and optionally save them as base64-encoded files. The script is available on GitHub and in the PowerShell gallery.

Install-Script -Name Get-UEFICertificate -Scope CurrentUser

View UEFI Certificates

After downloading the Get-UEFICertificate PowerShell script, run the following command to view the KEK database.

Get-UEFICertificate -Type KEK

In this example, the only KEK certificate is the expiring Microsoft Corporation KEK CA 2011 certificate. Running the command and specifying the DB type shows only the expiring Microsoft Windows Product PCA 2011 certificate.

Note: UEFI also includes hashes of specific executables in the DB and DBX databases. By default, this script focuses on UEFI certificates and omits hash calculations for brevity. Use the -IncludeHashes switch to view this information.

Updating Microsoft UEFI Certificates

With the October 2025 updates, Microsoft introduced new registry keys to enable and monitor the update status of these UEFI Secure Boot certificates.

Status

To begin, administrators can check the status of the update process by reading the value of the UEFICA2023Status registry key.

Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ -Name UEFICA2023Status | Select-Object UEFICA2023Status

Update

To initiate the update process, set the value of AvailableUpdates to 0x5944.

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot’ -Name ‘AvailableUpdates’ -Value 0x5944

Next, start the Secure-Boot-Update scheduled task.

Start-ScheduledTask -TaskName ‘\Microsoft\Windows\PI\Secure-Boot-Update’

Once complete, the UEFICA2023Status indicates InProgress.

After a reboot, start the Secure-Boot-Update scheduled task once more. The UEFICA2023Status should indicate that it has been updated (may require one more reboot!).

Updated Certificates

After the update process completes, run the Get-UEFICertificate PowerShell script to confirm that new certificates have been added to UEFI Secure Boot.

Updated Microsoft KEK Certificates

Updated Microsoft DB Certificates

Summary

With multiple Microsoft Secure Boot CA certificates expiring in 2026, organizations need to ensure devices are updated to maintain a valid UEFI trust chain. This guide shows how to view existing firmware certificates, apply Microsoft’s Secure Boot CA 2023 updates, and confirm that new KEK and DB certificates have been installed. Completing this process now will ensure devices remain protected from tampered or malicious boot components as the 2026 expiration dates approach.

Additional Information

Windows Secure Boot certificate expiration and CA updates

Registry key updates for Secure Boot: Windows devices with IT-managed updates

Get-UEFICertificate PowerShell Script on GitHub

Get-UEFICertificate PowerShell Script in the PowerShell Gallery

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune

PKI Fundamentals with Microsoft AD CS Training Course

I’m excited to announce that I’ve partnered once again with the fine folks at the ViaMonstra Online Academy to deliver a new live training course entitled PKI Fundamentals with Microsoft Active Directory Certificate Services (AD CS). The event consists of six weekly live webinars beginning on Thursday, January 15, 2026, at 3:00 PM CST.

Why AD CS Training?

Digital certificates are strong, phishing-resistant credentials that are an excellent choice for authentication to critical workloads like Always On VPN and enterprise Wi-Fi. However, managing certificate services infrastructure can be daunting. This course provides administrators with a fundamental understanding of enterprise PKI with Microsoft AD CS.

Course Overview

The event format for this course consists of six weekly live sessions on Thursdays starting on January 15, 2026. The classes are two hours long, running from 3:00 PM CST to 5:00 PM CST each day. During the course, we’ll cover the following topics.

  • PKI concepts and certificate use cases
  • Designing and deploying certificate authorities (CAs)
  • Configuring templates and enrollment
  • Managing revocation and maintenance

Who Should Attend

Organizations planning to use certificate authentication for enterprise VPN and Wi-Fi workloads will benefit from this training course. Also, those considering a new AD CS deployment will find this training beneficial. In addition, administrators managing an existing production AD CS environment will gain valuable insight.

Enroll Now

Registration for this training class is available now. The cost is $295.00—an incredible bargain! Don’t miss out on this fantastic opportunity to gain foundational AD CS skills. Click the registration link below and reserve your spot today!

Additional Information

Public Key Infrastructure (PKI)

Enterprise PKI

Cloud PKI for Microsoft Intune