Secure Boot Certificate Transition 2026: A PKI Team’s Guide

The Secure Boot certificate transition is Microsoft’s 2026 replacement of the original 2011 Secure Boot trust anchors with a new 2023 certificate set, so Windows devices can keep receiving trusted pre-boot security updates. It is the first major refresh of the Secure Boot certificate hierarchy since the feature arrived more than a decade ago. The change does not stop devices from booting, but systems that miss the update gradually lose access to future Secure Boot protections, trust database updates, and revocation updates.

Microsoft has entered a major Secure Boot trust transition in 2026. Beginning in June 2026, several certificates that form the foundation of the Secure Boot ecosystem reach the end of their planned lifecycle, and Microsoft is replacing the original 2011 certificates with a set introduced in 2023. For most organizations, devices will not suddenly stop booting when the legacy certificates expire. The more important consequence is that devices that do not receive the updated certificates may lose access to future Secure Boot protections, trust database updates, and revocation updates. Over time, that can create security and compliance gaps across an enterprise fleet.

The change sits inside the Secure Boot ecosystem, but it carries a broader lesson for Public Key Infrastructure teams. Trust infrastructure has a lifecycle. Certificates expire, trust anchors evolve, and security foundations need continuous modernization. The Secure Boot certificate transition is a high-visibility example of a problem that every PKI program faces. This guide explains what is changing, what it means for enterprise security, and the practical steps PKI teams should take now.

Quick Answer: What Is the Secure Boot Certificate Transition and Why Does It Matter?

The Secure Boot certificate transition is Microsoft’s phased replacement of the 2011 UEFI trust anchor certificates with a 2023 hierarchy, running June through October 2026. Devices that do not receive the updated certificates will continue to boot normally but will gradually lose access to future Secure Boot trust database and revocation updates, creating a silent, growing security gap. PKI teams must inventory affected devices and establish repeatable processes before trust paths expire.

Key Takeaways

• Three Microsoft Secure Boot certificates are expiring on a phased schedule: the Microsoft Corporation KEK CA 2011 (June 24, 2026), Microsoft Corporation UEFI CA 2011 (June 27, 2026), and Microsoft Windows Production PCA 2011 (October 19, 2026). Devices that do not receive the 2023 replacements will not stop booting but will progressively lose access to future Secure Boot protections and revocation updates.
• The June 27, 2026 expiry of the Microsoft UEFI CA 2011 is the most urgent deadline for mixed environments. This certificate signs the shim bootloader relied upon by RHEL, Ubuntu, and Fedora. Systems that have not enrolled the Microsoft UEFI CA 2023 in firmware will be unable to boot updated shim versions signed by the new certificate after that date.
• According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced certificate-related downtime in the past year. The same visibility and governance gaps that cause TLS certificate outages cause missed firmware trust anchor updates. The root cause in both cases is the absence of a complete, continuously maintained certificate and trust inventory.
• The Secure Boot transition and AD CS ML-DSA support (available on Windows Server 2025 with the May 2026 cumulative update) are separate projects that point in the same direction: trust infrastructure must evolve continuously. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and NSA CNSA 2.0 mandates exclusive reliance on quantum-resistant algorithms for National Security Systems by 2030.
• The lasting lesson is not the certificate replacement itself. It is the need to build repeatable trust anchor lifecycle processes, continuous inventory, and crypto-agility before the next rotation arrives rather than after. Organizations that treat each trust update as a one-time exercise will face the same emergency effort at every future transition.

Who Should Care About the Secure Boot Certificate Transition

The Secure Boot certificate transition is a cross-functional challenge. Every role below has a direct stake in ensuring the fleet receives the 2023 certificates before the legacy hierarchy loses the ability to deliver future protections.

Role	Why It Matters	Action Item
PKI Admins	Own the certificate inventory, trust dependency mapping, and verification that devices carry the new KEK and DB certificates; responsible for ensuring the OCSP and CRL infrastructure supporting the 2023 certificates is operational	Build or update cryptographic inventory using CBOM Secure; map all devices relying on Secure Boot trust anchors; verify 2023 certificate enrollment status across managed fleet
Infrastructure / Endpoint Teams	Own the device update delivery mechanism; Windows Update delivers the 2023 certificates automatically on most devices, but older hardware and some enterprise configurations require OEM firmware updates or manual intervention	Audit fleet for devices requiring OEM firmware updates rather than Windows Update delivery; confirm Windows Update policy pushes the 2023 certificates to all in-scope endpoints; track enrollment status in endpoint management tooling
Security Architects	Own the trust model assessment confirming the 2023 hierarchy meets enterprise security requirements; responsible for the parallel ML-DSA CA hierarchy planning for AD CS PQC readiness	Review the 2023 certificate hierarchy for trust model completeness; begin planning the parallel ML-DSA CA hierarchy on Windows Server 2025 with the May 2026 cumulative update; assess CNSA 2.0 compliance timeline for National Security System environments
Compliance Teams	Must demonstrate that device Secure Boot trust states meet regulatory and audit requirements; the degraded security state of devices on the legacy hierarchy creates compliance evidence gaps	Include Secure Boot certificate enrollment status in quarterly audit scope; document the transition plan and timeline as a formal change management record; confirm fleet status for any regulatory submissions requiring device security posture attestation
CISOs	Own the risk posture for the enterprise fleet’s Secure Boot security state; hundreds or thousands of devices quietly falling behind on boot-level protection is a material, silent security risk	Require a Secure Boot transition project with named owner and completion date before October 19, 2026; fund CBOM Secure for cryptographic inventory; include Secure Boot trust state in enterprise security reporting to the board

Understanding the Secure Boot Trust Chain

Secure Boot is a security feature built into UEFI firmware that ensures only trusted software loads during startup. Before Windows begins loading, firmware validates the digital signatures of boot components against trusted certificates held in Secure Boot databases. If a component cannot be verified, Secure Boot can block it, which helps defend against bootkits, rootkits, and other pre-operating-system malware.

The trust model is a hierarchy. It starts with the Platform Key (PK), usually owned by the hardware manufacturer. Below it sits the Key Exchange Key (KEK), which can include a Microsoft KEK alongside OEM keys. Two databases complete the picture: the allowed signature database (DB), which lists trusted signers, and the disallowed signature database (DBX), which lists revoked signatures. Any holder of a valid KEK can authorize updates to the DB and DBX.

Since 2011, Microsoft-managed certificate authorities have signed Windows boot components, third-party EFI applications, Secure Boot policy updates, and revocation databases within this model. As those certificates approach expiry, Microsoft is moving devices to a new 2023 hierarchy to preserve the integrity of the chain.

Which Secure Boot Certificates Are Expiring in 2026

Microsoft is replacing several core certificates on a phased schedule that runs from June through October 2026. The table below maps each legacy certificate to its 2023 replacement, its role, and its expiration date.

Legacy Certificate (2011)	2023 Replacement	Primary Role	Expiration
Microsoft Corporation KEK CA 2011	Microsoft Corporation KEK 2K CA 2023	Authorizes updates to the DB and DBX databases	June 24, 2026
Microsoft Corporation UEFI CA 2011	Microsoft UEFI CA 2023	Signs third-party boot loaders and EFI applications	June 27, 2026
Microsoft Windows Production PCA 2011	Windows UEFI CA 2023	Signs Windows boot components	October 19, 2026

One detail is worth noting for PKI practitioners. When the Microsoft Corporation UEFI CA 2011 is renewed, Microsoft splits the function across two certificates so that boot loader signing is separated from option ROM signing. A system that needs to trust option ROMs can add the Microsoft Option ROM UEFI CA 2023 without also trusting third-party boot loaders, which gives administrators finer control over trust.

The transition is not about replacing Secure Boot itself. It refreshes the trust anchors so the platform can keep receiving future protections, and the new 2023 certificates are designed to remain valid for well over a decade.

Will Systems Stop Booting: What the Change Actually Means

The most common misconception is that systems will stop booting when the 2011 certificates expire. Microsoft’s guidance is explicit that this is not the case. Devices that have not received the 2023 certificates continue to start and operate normally, and standard Windows updates continue to install.

The real concern is the slow loss of future trust information. As new vulnerabilities surface and malicious boot components are identified, Microsoft distributes updates to Secure Boot trust databases and revocation lists. A device that remains on the legacy trust hierarchy may eventually be unable to apply those updates or to trust newly signed components, which Microsoft describes as a degraded security state.

For an enterprise managing thousands of devices across data centers, remote offices, and hybrid environments, this becomes a trust management challenge rather than a simple patching exercise. A single unmanaged device may pose little immediate risk. Hundreds or thousands of them, quietly falling behind on boot-level protection, become a security, compliance, and operational concern. The risk is also silent, because an affected device looks identical to a healthy one until a boot chain update requires the new certificates.

Organizations running Linux or dual-boot environments face additional complexity. The Microsoft UEFI CA 2011, which signs the shim bootloader relied upon by major Linux distributions including RHEL, Ubuntu, and Fedora, expires on June 27, 2026. Systems that have not enrolled the Microsoft UEFI CA 2023 in device firmware will be unable to boot updated shim versions signed by the new certificate.

Linux distribution vendors have released updated shim packages carrying signatures from both the 2011 and 2023 certificates, but the 2023 CA must be enrolled in firmware first. Enterprise PKI teams managing mixed environments should confirm that the new CA has been enrolled across both Windows and Linux endpoints before June 27, 2026.

What the Transition Teaches PKI Teams

Secure Boot operates below the operating system, yet the transition mirrors the challenges PKI teams face every day. Trust relationships have lifecycles, certificates expire, cryptographic standards evolve, and legacy trust models eventually require modernization.

Many organizations still lack visibility into certificates embedded in firmware, operating systems, appliances, and specialized hardware. The Secure Boot certificate transition reinforces why certificate inventory, lifecycle management, and trust anchor governance are strategic security functions rather than administrative chores. The same discipline that keeps enterprise PKI healthy applies directly to Secure Boot trust management. The contrast between the old way and the modern way is instructive.

Area	Legacy Approach	Modern Approach	Operational Benefit
Secure Boot trust	2011 certificate hierarchy	2023 certificate hierarchy	Continued access to Secure Boot protections
Certificate visibility	Manual validation and inventory checks	Centralized monitoring and reporting	Faster identification of affected systems
PKI operations	Reactive certificate replacement	Lifecycle management and automation	Reduced operational risk
Cryptography strategy	Static trust assumptions	Crypto-agility and modernization planning	Faster adaptation to future threats
Security governance	Periodic trust reviews	Continuous monitoring and compliance tracking	Improved audit readiness

The lesson is that Secure Boot modernization is not a one-off certificate update. It reflects a broader shift toward lifecycle-based trust management across enterprise PKI. That shift connects directly to a parallel development now under way in enterprise PKI platforms: post-quantum cryptography support.

Secure Boot Modernization and Post-Quantum Readiness

The Secure Boot certificate transition arrives alongside a larger cryptographic modernization effort. AD CS on Windows Server 2025 added support for issuing post-quantum cryptography certificates using ML-DSA, the Module-Lattice-Based Digital Signature Standard standardized by NIST in FIPS 204. That capability reached general availability in May 2026.

AD CS supports all three ML-DSA parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87, which lets organizations balance security strength against key and signature size. ML-DSA is a signature-only algorithm, so it applies to signing scenarios such as certificate authorities and Online Certificate Status Protocol (OCSP) responders rather than to key exchange or encryption. Microsoft recommends building a parallel ML-DSA certificate authority hierarchy to evaluate post-quantum issuance without disrupting the existing one.

ML-DSA support and the Secure Boot certificate replacement are separate projects, but they point in the same direction: trust infrastructure must evolve continuously to stay secure. Organizations planning PKI modernization should treat Secure Boot updates, certificate lifecycle management, crypto-agility, and post-quantum readiness as parts of one trust modernization strategy rather than disconnected efforts.

For organizations bound by US government requirements, the NSA’s Commercial National Security Algorithm Suite (CNSA 2.0) provides the clearest migration timeline. For software and firmware signing, the category most directly relevant to Secure Boot, CNSA 2.0 mandates LMS and XMSS as defined in NIST SP 800-208. More broadly, CNSA 2.0 specifies ML-DSA-87 for digital signatures and ML-KEM-1024 for key establishment. National Security Systems are expected to support CNSA 2.0 algorithms by 2026 and to rely on them exclusively by 2030. Begin PQC readiness planning via the PQC Readiness assessment and the PQC Center of Excellence.

What PKI and Infrastructure Teams Should Do Now

The transition rewards early, methodical action. Use the checklist table below to map each action item to its business impact, recommended action, and owner.

Issue / Gap	Business Impact	Recommended Action	Owner	Deadline
Devices not carrying Microsoft UEFI CA 2023 in firmware	Linux/dual-boot systems unable to boot updated shim versions after June 27, 2026; silent Secure Boot trust degradation	Build device inventory using CBOM Secure; confirm Microsoft UEFI CA 2023 enrollment across all Windows and Linux endpoints	PKI Admin / Endpoint Team	Before June 27, 2026
Devices not carrying Microsoft Corporation KEK 2K CA 2023	Unable to authorize future DB and DBX updates; Secure Boot trust database stagnates and cannot receive new revocations	Verify KEK enrollment via Windows Security or endpoint management tooling (Intune, SCCM); push OEM firmware updates to devices that do not receive the KEK via Windows Update	Endpoint Team / PKI Admin	Before June 24, 2026
Devices not carrying Windows UEFI CA 2023	Unable to trust newly signed Windows boot components after October 19, 2026	Confirm Windows Update delivery of the Windows UEFI CA 2023 across managed fleet; audit OEM firmware for devices requiring manual update delivery	Endpoint Team	Before October 19, 2026
No repeatable trust anchor rotation process	Each future Secure Boot or PKI trust anchor rotation requires a new emergency project; organizational knowledge lost between rotations	Document the current rotation process, device inventory methodology, and update verification steps; integrate Secure Boot trust state into CertSecure Manager ongoing monitoring	PKI Admin / Security Architect	Q4 2026
No parallel ML-DSA CA hierarchy for AD CS PQC readiness	Organization is not positioned to issue post-quantum certificates when regulatory or partner requirements mandate them; PQC migration is delayed	Deploy parallel ML-DSA CA hierarchy on Windows Server 2025 with May 2026 cumulative update; begin PQC readiness assessment via the PQC Center of Excellence	Security Architect / PKI Admin	2026 planning cycle
No cryptographic bill of materials covering firmware trust anchors	Blind spot in cryptographic posture: firmware trust dependencies are not visible alongside TLS and code signing certificates; PQC migration is incomplete	Run CBOM Secure across enterprise to build a Cryptographic Bill of Materials covering algorithms, key sizes, certificate authorities, and firmware trust dependencies	PKI Admin / CISO	Ongoing

Common Mistakes to Avoid

The most common mistake is assuming a system is healthy simply because it still boots. A device can operate normally while quietly falling behind on Secure Boot trust updates, creating a hidden gap that surfaces only during a vulnerability assessment, an audit, or an incident investigation. The risk is compounding: each missed trust database update leaves the device less protected than the one before, without any visible failure signal.

A second mistake is treating the transition as a one-time patching exercise. The lasting challenge is establishing repeatable processes that support future trust updates, certificate rotations, and cryptographic migrations. Organizations that struggle with Secure Boot updates often face the same difficulties in certificate lifecycle management and PKI modernization, because all three depend on visibility, governance, ownership, and lifecycle control. A third mistake specific to mixed environments is not separating the Linux/dual-boot deadline (June 27, 2026) from the Windows endpoint deadline (October 19, 2026) and addressing each with the appropriate urgency.

Security Best Practices for Secure Boot and PKI Trust Governance

• Maintain accurate certificate inventories and monitor certificate lifecycles continuously using CertSecure Manager for enterprise-wide visibility
• Track trust dependencies and assign clear ownership for certificate and trust management across firmware, operating systems, appliances, and applications
• Keep PKI platforms on supported operating systems and software versions; Windows Server 2025 with the May 2026 cumulative update is required for ML-DSA CA hierarchy deployment
• Review trust architectures regularly for modernization opportunities, incorporating Secure Boot, TLS, code signing, and PQC readiness into a single trust modernization program
• Establish monitoring and reporting for visibility into certificate deployment status and trust-related changes across the environment; use CBOM Secure for cryptographic bill of materials covering firmware trust anchors
• Protect CA private keys in a Hardware Security Module validated to FIPS 140-3: at minimum Level 2 for issuing CAs, Level 3 for root CAs in most enterprise environments; federal and CMMC-regulated environments may mandate Level 3 or higher; some offline root CAs operate at Level 4
• Treat trust infrastructure as a living system requiring continuous maintenance, not a static deployment; design for crypto-agility so each future algorithm or trust anchor rotation is a managed operation rather than an emergency project

How Encryption Consulting Can Help

The Secure Boot certificate transition is, at its core, a trust lifecycle management challenge. Encryption Consulting helps organizations modernize PKI environments, improve certificate visibility, automate lifecycle operations, and prepare for cryptographic change.

Post-Quantum Cryptography Advisory

EC’s PQC Advisory Services help organizations identify quantum-vulnerable cryptographic assets, assess exposure risk, and design crypto-agile migration strategies aligned with NIST FIPS 204 and CNSA 2.0. For teams preparing for Secure Boot modernization alongside the shift to post-quantum algorithms, EC maps current cryptographic dependencies and builds a phased transition plan that addresses both near-term certificate renewals and the broader algorithmic migration. Begin with a structured PQC Readiness assessment and explore resources at the PQC Center of Excellence.

PKI Services

Through PKI Services, EC helps organizations assess, design, and operate PKI infrastructure aligned with security, compliance, and operational requirements, including NIST SP 800-57, WebTrust, and applicable regulatory standards. EC consultants help define Certificate Policy and Certification Practice Statements, establish resilient CA architectures, identify trust dependencies, strengthen governance, and build certificate management processes that reduce operational risk and improve audit readiness.

CBOM Secure: Cryptographic Inventory

Before you can manage what you have, you need to know what you have. CBOM Secure builds a Cryptographic Bill of Materials covering algorithms, key sizes, certificate authorities, and dependencies across cloud, on-premises, and hybrid environments. That inventory is the foundation for understanding Secure Boot trust relationships, identifying quantum-vulnerable assets, and planning any phased cryptographic migration. For organizations managing PKI as a Service, CBOM Secure provides the cross-environment visibility that makes a managed PKI program complete.

CertSecure Manager: Lifecycle Automation

For ongoing visibility and lifecycle control, CertSecure Manager provides centralized certificate discovery, monitoring, reporting, and automated lifecycle management. It helps teams locate legacy certificates, track trust dependencies across complex infrastructure, and maintain continuous visibility so the next trust anchor rotation is identified and remediated before it creates a security gap. As organizations prepare for Secure Boot modernization, crypto-agility, and post-quantum adoption, EC provides the expertise to build resilient, future-ready trust architectures.

Conclusion

Microsoft’s Secure Boot certificate transition is not simply a certificate replacement. It is a reminder that trust infrastructure has a lifecycle. Systems that fail to receive the 2023 certificates may keep operating, but they risk falling behind on future Secure Boot protections, revocation updates, and security improvements.

The lesson extends well beyond Secure Boot. Trust systems require continuous maintenance, monitoring, and modernization. Organizations that navigate this transition well will be the ones that maintain visibility into their trust infrastructure, modernize PKI operations, automate certificate lifecycle management, and prepare for cryptographic change such as the move to post-quantum algorithms.

The goal is not merely to replace expiring certificates. It is to build a more resilient, agile, and future-ready trust architecture that supports both today’s security requirements and tomorrow’s post-quantum needs. A practical first step is visibility: inventory every trust anchor and certificate you depend on using CBOM Secure, confirm the Secure Boot updates have reached your fleet, and assign clear ownership for what comes next. To assess your trust architecture and plan the work, reach out to the team at Encryption Consulting.

Frequently Asked Questions

What is the main takeaway from Secure Boot Certificate Transition 2026: A PKI Team’s Guide?

Microsoft is replacing the 2011 Secure Boot certificate hierarchy with a 2023 hierarchy on a phased schedule running June through October 2026. Devices that do not receive the updated certificates will not stop booting, but they will gradually lose access to future Secure Boot trust database and revocation updates, creating a silent, growing security gap. PKI teams must inventory affected devices and establish repeatable processes for future trust anchor rotations rather than treating this as a one-time patching exercise.

Why does the Secure Boot certificate transition matter for enterprise PKI teams?

The Secure Boot certificate transition is a direct, high-visibility example of the broader trust lifecycle challenge every PKI program faces. Certificates expire, trust anchors evolve, and security foundations require continuous modernization. According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced certificate-related downtime in the past year; the same visibility and governance gaps that cause TLS certificate outages also cause missed firmware trust anchor updates.

What risks increase if the Secure Boot transition is handled manually or ignored?

Risks include: an enterprise fleet falling silently behind on Secure Boot trust database and revocation updates; Linux and dual-boot systems being unable to boot updated shim versions after June 27, 2026 if the Microsoft UEFI CA 2023 is not enrolled in firmware; audit findings surfacing unmanaged device trust states during compliance reviews; and no repeatable process in place for the next trust anchor rotation.

Which teams should own the Secure Boot certificate transition?

PKI admins own certificate inventory and trust dependency mapping. Infrastructure and endpoint teams own device update delivery and enrollment verification. Security architects own the trust model assessment and parallel ML-DSA CA hierarchy planning. Compliance teams own the audit evidence that Secure Boot trust states meet regulatory requirements. CISOs own the risk posture for the fleet’s degraded security state for devices that have not received the 2023 certificates.

How does the Secure Boot transition connect to certificate lifecycle management?

The Secure Boot trust anchor rotation is a certificate lifecycle event at the firmware level. The same visibility, governance, ownership, and automation disciplines that make enterprise TLS certificate management reliable apply directly to Secure Boot trust management. CertSecure Manager provides the centralized discovery, inventory, and lifecycle management that makes both TLS and firmware trust anchor governance sustainable at enterprise scale.

How should organizations measure success for the Secure Boot certificate transition?

Key metrics: percentage of managed devices confirmed to carry the Microsoft Corporation KEK 2K CA 2023 and Microsoft UEFI CA 2023 in their Secure Boot stores (target: 100% before October 19, 2026); percentage of Linux and dual-boot endpoints with the Microsoft UEFI CA 2023 enrolled in firmware (target: 100% before June 27, 2026); and number of devices still on the legacy 2011 hierarchy discovered through quarterly CBOM Secure inventory runs (target: zero by Q4 2026).

What should be audited or monitored regularly for Secure Boot trust health?

Monitor continuously: device enrollment status for the 2023 Secure Boot certificates using endpoint management tooling; Secure Boot audit event logs for boot failures or revoked component blocks; and CBOM Secure cryptographic inventory for algorithm-level visibility across the firmware trust chain. Audit quarterly: the percentage of fleet devices carrying the new KEK and DB certificates; OEM firmware update status for devices requiring non-Windows-Update delivery; and PQC readiness review via the PQC Center of Excellence.

How does the Secure Boot transition affect cloud, hybrid, or multi-OS environments?

In cloud and hybrid environments, the transition affects virtual machines on hardware using UEFI firmware with Secure Boot enabled, as well as on-premises endpoints. For multi-OS environments, the Linux and dual-boot implications are the most time-sensitive: the Microsoft UEFI CA 2011 that signs the shim bootloader used by RHEL, Ubuntu, and Fedora expires June 27, 2026. Enterprise PKI teams managing mixed environments must confirm CA enrollment across both Windows and Linux endpoints before that date.

What common mistakes should teams avoid with the Secure Boot certificate transition?

Assuming a system is healthy because it still boots; treating this as a one-time patching exercise rather than building repeatable trust anchor lifecycle processes; not addressing Linux and dual-boot environments separately from Windows endpoints with the June 27 deadline; and not planning the parallel ML-DSA CA hierarchy for AD CS alongside the Secure Boot transition, missing the opportunity to address both trust lifecycle events as part of a single PKI modernization program.

What should be refreshed quarterly for Secure Boot and PKI trust governance?

Refresh quarterly: device enrollment status confirming the percentage of fleet carrying the 2023 Secure Boot certificates; trust dependency documentation confirming which systems rely on which firmware trust anchors; PQC readiness review via the PQC Center of Excellence for NIST FIPS 203, 204, and 205 migration planning; CBOM Secure cryptographic inventory run confirming no legacy algorithm has re-entered the environment; and the repeatable trust anchor rotation process documentation, updated to reflect any fleet or infrastructure changes since the last review.