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

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Entra Private Access is a powerful zero-trust network access solution that is remarkably simple to install and configure. Administrators can quickly install the Global Secure Access (GSA) agent on their endpoints, then install the Entra Private Network Connector to enable secure remote access to private, internal resources. However, the ease with which Entra Private Access can be configured can potentially lead to connectivity issues in some scenarios. This post demonstrates how to diagnose port exhaustion issues and expand the available port range to address them.

Entra Private Network Connector

The Entra Private Network Connector is a key component of the Entra Private Access solution. The Private Network Connector is essentially the old Azure Application Proxy, enhanced to support TCP and UDP applications in addition to HTTP-based web applications. It is installed on an on-premises Windows server to provide GSA clients with access to internal data and applications.

Network Connectivity

The GSA client is not a virtual network adapter like most traditional VPN clients. Instead, the GSA client installed on the client operates as a filter driver in the network stack, selectively intercepting traffic and tunneling it over the GSA tunnel based on configured policy. As such, it does not appear as a network adapter in the operating system and does not have its own IP address.

Translation

When traffic from the GSA client is routed over the Entra Private Network Connector, the traffic egressing from the connector server to the internal network is effectively translated. That is, the source IP address of traffic destined for an internal resource is the connector server’s IP address, not the client’s original source IP address.

Port Exhaustion

The ephemeral port range on Windows servers spans from 49152 to 65535, leaving only 16,384 ports available. This can easily be exhausted when many clients are connected to a single Entra Private Network Connector server. This pool can also be depleted by poorly written or badly behaving applications that needlessly open many socket connections to internal resources.

Troubleshooting

Administrators can view the ephemeral port configuration for both TCP and UDP by running the following commands.

netsh.exe interface ipv4 show dynamicportrange protocol=tcp

netsh.exe interface ipv4 show dynamicportrange protocol=udp

To determine if port exhaustion is an issue, open an elevated PowerShell command window and run the following command.

Get-NetTcpConnection | Where-Object State -match ‘established’ | Measure-Object

Next, run the following PowerShell command to identify the number of ports consumed exclusively by the Entra Private Network Connector.

$ProcessId = Get-CimInstance -ClassName win32_service | Where-Object Name -eq ‘WAPCSvc’ | Select-Object -ExpandProperty ProcessID

Get-NetTCPConnection | Where-Object { $_.State -match ‘established’ -and $_.OwningProcess -eq $ProcessId } | Measure-Object

If the number of ports consumed by the Entra Private Network Connector approaches the upper limit of available ports, administrators should increase the ephemeral port range to ensure the connector server operates reliably.

Note: Use the Get-NetUdpEndpoint PowerShell command to monitor UDP port consumption on Entra Private Network Connector servers.

Resolution

To increase the ephemeral port range on the Entra Private Network Connector server, open an elevated command window and run the following commands.

netsh.exe interface ipv4 set dynamicportrange protocol=tcp startport=10000 numberofports=55535
netsh.exe interface ipv4 set dynamicportrange protocol=udp startport=10000 numberofports=55535
netsh.exe interface ipv6 set dynamicportrange protocol=tcp startport=10000 numberofports=55535
netsh.exe interface ipv6 set dynamicportrange protocol=udp startport=10000 numberofports=55535

Running these commands will increase the number of available ephemeral ports on the server to more than 50,000, well above the default. In most cases, this should be sufficient to handle many GSA client connections. However, administrators are cautioned to monitor port usage on the Entra Private Network Connector servers to ensure continued reliable operation. It may be necessary to deploy additional connector servers to process the existing workload.

Summary

Entra Private Network Connectors can exhaust the default 16,384-port ephemeral range when many GSA clients access internal TCP/UDP resources. Administrators can diagnose the issue by filtering Get-NetTCPConnection results by the WAPCSvc process, then expanding the range to over 50,000 ports using netsh.exe, as shown above. Monitor usage continuously in high-load environments to ensure consistent and stable access. And if you find you need more than 50,000 ports per server, it’s probably time to deploy additional connector servers. 😊

Additional Information

Microsoft Entra Private Access

Entra Private Access Channels are Unreachable

Microsoft Entra private network connectors

Always On VPN RRAS and PowerShell 7

PowerShell is an essential tool for administrators supporting Microsoft Always On VPN. It is critical for configuring supporting infrastructure services, such as Routing and Remote Access (RRAS) and Network Policy Server (NPS), as well as provisioning and managing Always On VPN client configuration settings on endpoints. The current version of PowerShell, PowerShell 7.5.3, is a game-changer for scripting and automation, bringing a host of improvements over its predecessors. PowerShell 7 offers better performance, lower memory usage, and cross-platform support (Windows, macOS, and Linux), making it more versatile than ever.

Problem in PowerShell 7

Recently, I discovered an oddity with PowerShell 7 when reviewing the configuration of an RRAS server. Specifically, PowerShell 7 differs in the way it produces output for the Get-RemoteAccess command, preventing administrators from viewing the details of the currently configured TLS certificate used for SSTP VPN connections in RRAS.

PowerShell 5

Running Get-RemoteAccess in PowerShell 5 provides detailed information about the SslCertificate property in the output of the command, as shown here.

Note that the data returned in the SslCertificate property is of the type X509Certificate2.

PowerShell 7

In PowerShell 7, Get-RemoteAccess displays only a string of numbers instead of detailed certificate information.

Notably, the data returned in the SslCertificate property is of the type System.Byte.

Solution

While PowerShell 7 doesn’t output the certificate details in human-readable form, you can easily convert the data using the following PowerShell command.

[System.Security.Cryptography.X509Certificates.X509Certificate2]::new((Get-RemoteAccess).SslCertificate) | Format-List

AovpnTools Module

To simplify administration, I’ve added a function to my AovpnTools PowerShell module called Get-VpnServerTlsCertificate. This function allows you to view the currently configured SSTP certificate details directly with a single command. In addition, you have the option to save the certificate to a file for further inspection and troubleshooting.

The GetVpnServerTlsCertificate function is included in AovpnTools v1.9.8 and later. You can install AovpnTools from the PowerShell gallery by running the following command.

Install-Module -Name AovpnTools

You can also find the AovpnTools PowerShell module on GitHub.

Summary

With PowerShell 7, RRAS certificate details display differently, but administrators can quickly resolve this using a simple conversion or the Get-VpnServerTlsCertificate function in the AovpnTools module. Either way, administrators can continue to use PowerShell 7 to manage their Windows Server RRAS servers.

Additional Information

Installing PowerShell 7 on Windows

AovpnTools in the PowerShell Gallery

AovpnTools on GitHub