Original publish date: October 22, 2026
KB ID: 5132953
As of October 19, 2026, Microsoft Secure Boot certificates originally issued in 2011 have reached their 15-year expiration. This expiration does not cause computers to stop turning on or prevent Windows from starting. Existing devices continue to start up and run Windows normally. For more detail on how certificate expiration affects Windows devices, see When Secure Boot certificates expire on Windows devices. For background on the broader 2026 Secure Boot certificate expiration schedule and replacement authorities, see Windows Secure Boot certificate expiration and CA updates.
Target audience
This article is intended for IT professionals, enterprise administrators, and deployment engineers who manage physical Windows fleets, server workloads, virtual machines, and installation media.
If you are a home or personal computer user whose device is updated automatically through Windows Update, you do not need to take any action described in this article. Windows Update automatically manages certificate and startup file updates for personal devices. For consumer-focused guidance, see Windows devices for home users, businesses, and schools with Microsoft-managed updates.
What is changing?
To protect systems against pre-boot malware and unauthorized tampering, Windows executable files rely on digital signatures verified at two distinct operational stages:
Pre-boot Secure Boot verification: Before Windows loads, UEFI firmware verifies the digital signature of the Windows bootloader (such as
bootmgfw.efiandcdboot.efi) against trusted authorities in the firmware Allowed signature database (DB).In-Windows operating system runtime verification: After Windows boots, the operating system kernel and security features verify the Authenticode digital signatures of drivers (
.sys), system services, and application binaries (.exe,.dll).
As of October 19, 2026, the Microsoft Windows Production PCA 2011 certificate has reached its scheduled expiration, and Microsoft has transitioned both signing domains to modern certificate authorities:
Secure Boot and bootloader updates (pre-boot)
Bootloader freeze in static binary form: The final Windows Boot Manager releases signed with the 2011 certificate are frozen in static binary form across all supported Windows servicing branches and will not receive future code servicing or security patches.
Future bootloader updates require Windows UEFI CA 2023: All subsequent security patches for the Windows bootloader are signed exclusively with the Windows UEFI CA 2023 certificate chain. For details on general bootloader servicing, device status checks, and registry tracking, see Secure Boot certificate update status in the Windows Security app, Registry key updates for Secure Boot, and Windows Secure Boot certificate expiration and CA updates.
Installation media bootloader transition: In a future update media release, Microsoft-distributed installation media will transition to booting by default with the 2023-signed bootloader, while retaining the frozen 2011 bootloader on media. A media reversion script will be provided to configure media to boot with the frozen 2011 bootloader for systems requiring it. Detailed media plans and reversion tooling are described in the Boot media and in-OS setup behavior section.
In-Windows operating system binary and catalog signing (runtime)
Transition to replacement signing authorities: Windows operating system content (including binaries with embedded Authenticode signatures and components authenticated through signed Windows security catalogs) transitions from the retiring Windows Production PCA 2011 to replacement Microsoft certificate authorities. Note that signing certificate authorities remain subject to change in the future as cryptographic standards and signing practices evolve.
Cessation of PCA 2011 binary signing: As of October 19, 2026, Microsoft no longer digitally signs any binary or security catalog using the 2011 PCA certificate. Existing binaries already installed on systems continue to execute normally, but will not receive further updates signed with the 2011 certificate.
Application control and verifier implications: Custom App Control for Business (WDAC) policies, signed security catalogs, or CI/CD verification tools that pin trust to the PCA 2011 authority may block updated binaries. Guidance on reviewing policies and verifying third-party software is described in Operational considerations and potential impact section.
Operational considerations and potential impact
While supported, fully updated Windows installations transition smoothly, organizations that enforce custom application control policies, build-verification pipelines, or specific signing certificate checks must evaluate the following operational areas:
Application control policies (App Control for Business / WDAC)
If your organization uses App Control for Business or signed security catalogs, review your policies for rules that authorize Microsoft-signed code by a specific certificate authority, issuer, or thumbprint, such as Microsoft Windows Production PCA 2011. Because updated Windows binaries and security catalogs are signed with replacement certificate authorities - and not the 2011 PCA certificate - files might not match these rules and could be blocked when enforced. Note that binary signing certificate authorities remain subject to change in the future:
Potential symptoms: Cumulative security updates failing to install, services failing during startup, application executable or DLL blocks, and Code Integrity Event 3077 in the event log.
Certificate agility and future changes: While updated Windows binaries and security catalogs transition to replacement authorities, signing certificates and certificate authorities will change in the future as cryptographic standards advance. For this reason, App Control policies and security catalogs should avoid pinning to specific certificate authorities, subjects, or thumbprints, and should instead use well-known publisher rules or policy inheritance that remain compatible as Microsoft rotates signing certificates over time.
Required action: Search your policy XML for signer rules that reference Microsoft CAs, including rules inherited from example base policies. Deploy policy changes in audit mode first and review results before enforcing. For detailed policy review steps and ecosystem guidance, see Preparing the Windows Ecosystem for Next-Generation Code Signing.
Applications with custom certificate validation, CI/CD pipelines, and security software
Most Windows applications are unaffected. Applications are at risk only if they use custom validation tied to specific Microsoft certificates or signing algorithms, or if they maintain a private trust store. Organizations managing Windows applications, CI/CD pipelines, or third-party security tools should evaluate the following areas (noting that binary signing certificate authorities remain subject to change in the future):
Custom application certificate validation: Any application or service that performs custom validation and assumes the presence of PCA 2011, validates specific certificate chains, pins to certificate subjects, or relies on fixed signing characteristics may experience failures or reject Microsoft-signed files that Windows recognizes as trusted. Update application validation to use supported Windows trust APIs (such as WinVerifyTrust) rather than custom checks tied to fixed certificates or signing algorithms.
Software using private trust stores: Verify that any application, container, or service that maintains a private trust store has a process to recognize legitimate Microsoft certificate rotations.
Build validation and CI/CD pipelines: Automated build gates and static scanners that enforce a static allowlist of expected certificate authorities may report verification failures (such as policy mismatch errors) on newly updated Windows components. Update static signer allowlists to recognize replacement Microsoft certificate authorities, and establish verification processes that accommodate future certificate authority rotations as signing standards evolve.
Third-party security and antivirus software: Certain third-party antivirus, endpoint protection, and application-protection products inspect Authenticode signatures directly. Confirm with your software vendors that they have reviewed and tested compatibility with replacement Microsoft signing certificates. For technical verifier guidance, see Preparing the Windows Ecosystem for Next-Generation Code Signing.
Boot media deployment on older hardware
With future update media releases, official installation media will transition to booting by default with the Windows UEFI CA 2023 Boot Manager:
Potential symptoms: Booting updated media on physical hardware whose UEFI firmware lacks the 2023 certificate in its Allowed signature database (DB) will fail with a Secure Boot violation.
Required action: For older hardware without an updated OEM BIOS that trusts the 2023 certificate, a media reversion script will be provided to configure the media to boot using the frozen 2011 bootloader.
Boot media and in-OS setup behavior
The transition of installation media and operating system setup differs between existing Windows versions and future Windows releases:
Installation media for existing Windows versions
Default boot path on installation media: Future installation media releases for currently supported versions of Windows will stage the 2023-signed Windows Boot Manager at \EFI\Boot\bootx64.efi as the default startup file for booting media.
Media reversion for older firmware: Installation media packages both 2023-signed and 2011-signed boot binaries, retaining the existing directory structure on the media and the target EFI System Partition (ESP). For hardware requiring 2011 boot files, a media reversion script will be provided to configure the media to boot using the frozen 2011 Boot Manager.
In-place upgrade behavior: When performing an in-place upgrade, Windows Setup inspects the firmware Allowed signature database (DB). If the firmware already trusts the Windows UEFI CA 2023, Setup provisions the target EFI System Partition (ESP) with the 2023-signed Boot Manager. If the firmware trusts only PCA 2011, Setup provisions the 2011-signed Boot Manager to preserve startup capability. After upgrade, standard Windows servicing manages certificate updates to the firmware DB, and subsequent quality updates transition the ESP to the 2023 bootloader once firmware trust is established.
Azure Marketplace media transition: Azure first-party VM gallery images and host deployment pipelines align with the 2023-default boot media schedule.
Installation media for future Windows versions
In future major client and server releases of Windows, installation media will carry only 2023-signed boot binaries, and 2011-signed boot binaries will be completely removed from the media.
Firmware trust requirement for future releases: Future major releases of Windows require the Windows UEFI CA 2023 certificate in the firmware Allowed signature database (DB) to boot installation media and complete Windows Setup.
Media generation and fallback scripts
Media management across different generations of hardware is supported through the following scripts:
Updating downlevel media: For existing installation media that defaults to the 2011 bootloader, update the media to default to the 2023 bootloader using Make2023BootableMedia.ps1. For complete script parameters and download instructions, see Updating Windows bootable media to use the PCA2023 signed boot manager.
Media reversion script for older firmware: When deploying media onto systems with firmware awaiting an OEM update for the 2023 certificate, the mentioned media reversion script may configure the media to boot using the frozen 2011 bootloader.
Frequently asked questions
Does updating the bootloader trigger BitLocker recovery?
While Windows servicing works to coordinate platform measurements during updates, unexpected BitLocker recovery prompts can occur depending on device protector configuration, firmware behaviors, and system state. Administrators and device owners should ensure BitLocker recovery keys are securely backed up before applying any boot-chain, firmware, or Secure Boot updates, including monthly Windows quality updates.How are virtual machines affected in Hyper-V, Azure, and VMware?
Generation 2 Hyper-V VMs receive updated certificates via standard cumulative Windows updates. Azure Trusted Launch and Confidential VMs receive updates via Azure platform servicing. For VMware vSphere, ensure ESXi hosts and VM hardware versions are updated to releases that include the 2023 certificates in guest UEFI templates. For details, see Trusted Launch VMs and Confidential VMs in Azure.What happens if a device never receives the 2023 certificate?
The device will continue to boot using the frozen 2011-signed bootloader, but it will not receive new bootloader security fixes if future boot-level vulnerabilities are discovered. In addition, future major releases of Windows will require the 2023 certificate in the Allowed signature database (DB), and installation media will block installation on devices that lack it.
Related links
Windows Secure Boot certificate expiration and CA updates (KB5062710)
Preparing the Windows Ecosystem for Next-Generation Code Signing
Updating Windows bootable media to use the PCA2023-signed boot manager (KB5053484)
Registry key updates for Secure Boot: Windows devices with IT-managed updates
Change log
| Change date | Change description |
|---|---|
| October 22, 2026 | Initial publication covering the October 19, 2026 Windows Production PCA 2011 expiration, the bootloader freeze, future installation media updates, application control implications, and fallback conversion tools. |