Microsoft Secure Boot Updates: New Certificates Coming Soon

Table of Contents

Microsoft updates Secure Boot certificates for Windows devices

  • Microsoft is automatically replacing Secure Boot certificates on Windows devices before older certificates begin expiring in 2026.
  • The original 2011 certificates are set to expire between June and October 2026, prompting what Microsoft calls a “generational refresh.”
  • Most Windows 11 users will get the new certificates through regular platform updates, with little or no action required.
  • Devices that don’t receive the refresh may keep working, but in a “degraded security state” that can limit future boot-level protections.

Secure Boot Certificate Refresh Rollout
– What changed: Microsoft has started rolling out refreshed Secure Boot certificates (issued in 2023) to replace 2011-era certificates that begin expiring in mid-to-late 2026.
– Where it’s stated: Microsoft’s Windows IT Pro guidance and Microsoft Support documentation describe the 2026 expirations and the certificate refresh plan; The Verge summarizes the rollout and notes KB5074109 as an early Windows 11 delivery vehicle.
– Practical signal to look for: If your Windows 11 devices are receiving current cumulative updates (including KB5074109), they’re on the primary path for automatic certificate delivery; exceptions are called out for some specialized systems and a fraction of devices needing OEM firmware.
– References (public):
– Microsoft Support: https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
– Windows IT Pro Blog (Tech Community): https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235
– The Verge coverage: https://www.theverge.com/tech/876336/microsoft-windows-secure-boot-certificate-renewal

Overview of Microsoft’s Secure Boot Certificate Update

Microsoft is rolling out new Secure Boot certificates to Windows devices ahead of the original certificates’ expiration that have underpinned the feature since 2011. The company says it will deliver the refresh as part of regular Windows platform updates, aiming to replace boot-level security credentials before they start expiring.

The move is significant because Secure Boot sits below the operating system, at the boundary between firmware and the earliest stages of Windows startup. It relies on cryptographic certificates—effectively a chain of trust—to ensure that only trusted, digitally signed components can run during boot. In practice, those trust anchors are stored in UEFI firmware databases (commonly referenced as the Key Enrollment Key (KEK) and the Secure Boot signature database (DB)), which is why certificate rotation has to be handled carefully. When those certificates age out, the platform’s ability to validate and update that trust chain becomes harder to maintain.

Secure Boot Trust Components
– KEK (Key Enrollment Key): The firmware store that controls who is allowed to update Secure Boot databases.
– DB (Signature Database): The firmware list of allowed signing certificates/hashes used to validate what can run during boot.
– Revocation list (often discussed as DBX): A firmware list used to block known-bad or vulnerable boot components.
– “Chain of trust”: The step-by-step verification path from firmware → bootloader → OS components; if a link can’t be updated (because certificates expired), future boot-level fixes and revocations can be harder to apply.

Microsoft has framed the change as routine security hygiene. In its announcement, the company described the update as a “generational refresh” and emphasized that certificate and key rotation is standard practice as cryptographic security evolves. The practical goal is continuity: keep Secure Boot functioning as a modern root-of-trust mechanism across both new PCs and older hardware that didn’t ship with the latest certificates.

Microsoft says new Secure Boot certificates began arriving with a recent Windows 11 update (KB5074109), and many newer Windows-based devices sold since 2024 include the refreshed certificates issued in 2023. Older systems, however, will need to receive the update through Windows’ servicing pipeline—and in some cases, through additional firmware support from device makers.

Importance of Secure Boot in Windows Security

Secure Boot was introduced in 2011 as part of the industry shift to UEFI-based boot, designed to protect systems from unauthorized changes during the boot process. The security problem it targets is simple but severe: if an attacker can run malicious code before the operating system loads, they can potentially undermine everything that comes after—security tools included.

At a technical level, Secure Boot uses cryptographic validation to ensure only trusted, signed software executes during startup. Certificates stored in firmware—commonly referenced in Microsoft documentation as being in areas like the Key Enrollment Key (KEK) and the Secure Boot signature database (DB)—help determine what bootloaders and components are allowed to run. This is why Secure Boot is often discussed as a “root of trust”: it establishes a baseline for integrity before Windows is fully online.

Secure Boot Risk Boundaries
If you’re deciding how urgent this is for your environment, it helps to think in terms of what Secure Boot can and can’t do:
– Helps block:
– Bootkits/rootkits that try to run before Windows loads
– Unauthorized bootloaders or tampered early-boot components (when they’re not signed by trusted keys)
– Known-bad boot components after they’re added to revocation lists (when the device can still receive those updates)
– Doesn’t automatically block:
– Malware that runs after Windows is up (phishing, credential theft, ransomware delivered via user space)
– Attacks that use legitimately signed but vulnerable components until revocations/mitigations are shipped and applied
– Why the certificate refresh matters:
– Even if Secure Boot is enabled, expired/obsolete trust anchors can reduce your ability to accept future boot-level fixes and revocations.

Over time, Secure Boot also became a mainstream Windows expectation rather than a niche enterprise feature. It later became one of Windows 11’s hardware requirements, reflecting Microsoft’s broader push to raise baseline security across the Windows ecosystem.

The certificate refresh matters because cryptographic systems are not “set and forget.” As Microsoft’s Nuno Costa put it in the company’s announcement, certificates and keys must be periodically refreshed to maintain strong protection, and retiring old certificates helps prevent aging credentials from becoming a weak point. In other words, Secure Boot’s value depends not just on being enabled, but on the continued ability to update and maintain the trust chain it relies on.

Timeline for Expiration of Original Secure Boot Certificates

The urgency behind Microsoft’s update is driven by a clear deadline: the original Secure Boot certificates issued in 2011 are set to expire between June 2026 and October 2026—roughly 15 years after Secure Boot’s introduction.

Microsoft and related documentation identify multiple 2011-era certificates with different expiration points across that window, including:

2011-era certificate (commonly referenced) Expiration (month/year) Why it matters in practice
Microsoft Corporation KEK CA 2011 June 2026 Impacts the ability to update Secure Boot trust stores (KEK-controlled updates).
Microsoft UEFI CA 2011 June 2026 Affects validation of UEFI boot components signed under this CA.
Microsoft Windows Production PCA 2011 October 2026 Tied to Windows boot-related signing chains; expiration can constrain future boot-level servicing.

That staggered schedule matters for IT teams because it creates a period where some devices may still appear “fine” while parts of the trust chain are approaching end-of-life. Microsoft’s messaging is that PCs will continue to function even if certificates expire, but the security posture changes: systems can fall into what the company calls a “degraded security state.”

In practical terms, the risk is less about an immediate mass failure to boot and more about losing the ability to receive future boot-level security updates—such as updates to the Windows Boot Manager, Secure Boot databases, and revocation lists. Those are precisely the mechanisms used to respond when new boot-level threats are discovered.

The timeline also intersects with device lifecycle realities. Many organizations still operate older PCs, specialized endpoints, or long-lived embedded systems. For those fleets, the 2026 window is not far away in operational planning terms: testing, firmware coordination with OEMs, and staged deployment can take months, especially where downtime is costly.

Introduction of New Secure Boot Certificates

To replace the expiring 2011 credentials, Microsoft issued a new batch of Secure Boot certificates in 2023. These newer certificates are intended to carry Secure Boot forward under updated cryptographic expectations and to ensure Windows devices can continue receiving boot-level security maintenance.

Microsoft says many new Windows-based devices sold since 2024 already shipped with the 2023 certificates. That reduces the burden for buyers of recent hardware, but it leaves a large installed base of older PCs that need the refresh delivered through updates.

The 2023 set includes certificates that map to different roles in the Secure Boot trust chain. In Microsoft’s Windows IT Pro guidance, examples of the updated certificates include:

2023 certificate (as referenced in Microsoft guidance) Firmware store What it generally controls
Microsoft Corporation KEK 2K CA 2023 KEK Who can update Secure Boot databases going forward.
Microsoft Corporation UEFI CA 2023 DB Which UEFI boot components are allowed to run.
Microsoft Option ROM UEFI CA 2023 DB Trust for certain option ROM / pre-OS components (device/firmware extensions).
Windows UEFI CA 2023 DB Trust for Windows-related UEFI boot components under the refreshed chain.

While end users rarely interact with these components directly, the distinction matters for compatibility and control. Secure Boot isn’t a single switch—it’s a system of allowed signers and trusted databases that determine what can execute at boot. Updating certificates is therefore not just a paperwork exercise; it’s a foundational maintenance event for the platform’s startup integrity.

Microsoft’s framing is that this is standard industry practice: rotate credentials before they become a weak point. The company is also signaling continuity: the goal is to keep Secure Boot viable across the Windows ecosystem, rather than letting certificate expiration become a silent cliff that fragments security posture between “new enough” devices and everything else.

Automatic Deployment of Secure Boot Certificates

For most Windows 11 users, Microsoft’s plan is straightforward: the new Secure Boot certificates will be installed automatically through regular Windows platform updates, requiring no additional action. The company has begun the rollout, noting that new certificates started arriving with the Windows 11 KB5074109 update.

This approach is designed to minimize disruption. Secure Boot touches firmware-level trust, which can be intimidating for users and risky for organizations if handled manually at scale. By pushing the refresh through the normal servicing channel, Microsoft is effectively treating certificate rotation as part of routine platform maintenance—similar in spirit to how operating systems regularly update security components that users never see.

Windows Certificate Update Rollout
Rollout path (with quick checkpoints):
1) Windows 11 (typical client PCs)
– Expected path: Windows Update / regular platform updates deliver the refreshed certificates.
– Checkpoint: Devices are receiving current cumulative updates (Microsoft notes KB5074109 as an early delivery point).
2) Windows 11 (specialized / tightly managed systems)
– Expected path: Your organization’s servicing method (WSUS/ConfigMgr/Intune or equivalent) still needs to approve and deploy the relevant updates.
– Checkpoint: Pilot a representative hardware set first; confirm Secure Boot remains enabled and the device reboots cleanly.
3) “Fraction of devices” needing OEM firmware
– Expected path: A separate firmware/BIOS update from the device manufacturer may be required.
– Checkpoint: Verify OEM firmware availability and schedule maintenance windows before broad rollout.
4) Windows 10
– Expected path: Microsoft states Windows 10 devices need Extended Security Updates (ESU) enrollment to receive the new certificates.
– Checkpoint: Decide ESU vs migration timeline early enough to avoid a last-minute scramble near the 2026 expiration window.

However, Microsoft also acknowledges that not every Windows device fits the consumer PC model. Some specialized systems—such as certain server or IoT deployments—may follow different update processes. And for “a fraction of devices,” Microsoft says a separate firmware update from third-party manufacturers may be required to apply the new certificates correctly.

That OEM dependency is a familiar pattern in the Windows ecosystem: even when Microsoft delivers the OS-side logic, firmware updates often remain the responsibility of the device maker. Microsoft’s guidance is to check OEM support pages for device-specific instructions and updates.

Windows 10 adds another wrinkle. Microsoft says Windows 10 users will need to enroll in Extended Security Updates (ESU) to receive the new certificates—an important detail for organizations still running Windows 10 fleets and planning their security maintenance beyond standard support timelines.

Implications for Devices Not Receiving Updates

Microsoft’s message to users who don’t receive the new certificates is nuanced: the PC will “continue to function normally,” but it may enter a degraded security state. That distinction is crucial, because it suggests the immediate user experience might not change—until it does, in ways that matter most during future security events.

The core implication is loss of future boot-level security updates. Without refreshed certificates, a device may be unable to accept updates to components like the Windows Boot Manager, Secure Boot databases, or revocation lists. Those updates are part of how the platform responds to newly discovered threats that operate before the OS loads.

Delayed Certificate Refresh Consequences
If a device misses the certificate refresh, the outcome is usually not “it won’t boot tomorrow” — it’s a slower squeeze on security and maintainability:
– What stays the same (initially):
– The PC can keep booting and running day-to-day workloads.
– What gets worse:
– Boot-level security becomes harder to maintain because future updates to Secure Boot trust stores and revocations may not apply.
– You can end up with a permanently “behind” pre-OS security baseline compared with the rest of your fleet.
– What can break later:
– Compatibility with future boot components, firmware expectations, or Secure Boot–dependent changes may become more fragile over time.
– Operational cost:
– These machines become security outliers: they still work, but they’re harder to bring back into compliance once the ecosystem moves on.

The security risk is not hypothetical. Boot-level malware—often discussed in terms of rootkits and bootkits—targets the earliest stages of startup precisely because it can evade many defenses that rely on the OS being intact. Microsoft documentation and related reporting have pointed to threats such as the BlackLotus UEFI bootkit (CVE-2023-24932) as an example of why maintaining Secure Boot’s trust chain and revocation capabilities matters.

There are also forward-compatibility concerns. Microsoft has warned that devices stuck on expired certificates could face compatibility issues with future hardware or software. Secure Boot is an ecosystem feature: firmware, bootloaders, and OS components evolve together. If a device can’t update its trust anchors, it may be increasingly out of step with what newer platform components expect.

Finally, there’s an operational implication for managed environments: devices that miss the update can become “security outliers” inside a fleet—machines that still run, still do business tasks, but can’t be brought up to the same boot-level security baseline as the rest.

Recommendations for IT Administrators

For IT administrators, the certificate refresh is less about a single patch and more about lifecycle management: inventory, testing, deployment, and coordination with OEM firmware channels. Microsoft’s approach—automatic for most Windows 11 devices—reduces effort, but it doesn’t eliminate the need for planning, especially in heterogeneous fleets.

Windows Platform Update Rollout
Practical rollout checklist (aimed at avoiding surprises):
– Inventory and segment
– Identify Windows 11 vs Windows 10 devices, plus any server/IoT/special-purpose endpoints.
– Flag hardware models that historically require OEM firmware updates for security changes.
– Confirm update readiness
– Ensure standard Windows servicing is functioning (patch compliance, reboot cadence, update rings).
– For tightly managed environments, confirm your tooling will actually deploy the relevant platform updates.
– Treat firmware as a dependency
– Check OEM support pages for BIOS/UEFI updates that may be required for the certificate refresh on some models.
– Schedule firmware maintenance windows where needed.
– Pilot before broad deployment
– Test on a representative set (different OEMs, generations, and security configurations like BitLocker).
– Validate: device boots cleanly, Secure Boot remains enabled, and no unexpected recovery prompts occur.
– Decide Windows 10 strategy early
– If Windows 10 remains in scope, plan ESU enrollment (per Microsoft’s guidance) or accelerate migration timelines.
– Monitor through 2026
– Track Microsoft guidance and release notes as the expiration window approaches; treat this as a multi-stage change, not a one-and-done patch.

Start with visibility. Organizations should inventory devices and verify Secure Boot status across endpoints, using available administrative tooling and scripts where appropriate. The key question is whether devices are positioned to receive the 2023 certificates through normal updates, or whether they fall into categories that may require special handling.

Next, treat firmware as a first-class dependency. Microsoft has explicitly said that a fraction of devices may require a separate firmware update from third-party manufacturers. That means administrators should review OEM support pages, validate firmware versions, and plan maintenance windows where firmware updates are needed before or alongside certificate updates.

Pilot deployments matter because boot-level changes can have outsized impact if something goes wrong. Testing on a representative set of hardware models helps surface edge cases—particularly for specialized systems such as certain servers or IoT devices that may not follow the same update path as standard Windows 11 clients.

Windows 10 environments need a separate decision point: Microsoft says Windows 10 users must enroll in Extended Security Updates to receive the new certificates. For organizations still on Windows 10, that ties Secure Boot continuity to broader platform strategy—whether to adopt ESU, accelerate migrations, or segment risk.

Finally, monitor Windows release notes and Microsoft guidance as the 2026 expiration window approaches. The rollout has begun, but certificate refresh is a multi-stage ecosystem change, and administrators will want to track how Microsoft sequences updates and how OEMs support older models.

The Future of Secure Boot in Windows

Understanding the Transition to New Certificates

Microsoft’s certificate refresh underscores a reality of modern platform security: the “root of trust” is not static. Secure Boot depends on cryptographic credentials that must be renewed to stay aligned with evolving security expectations. By issuing new certificates in 2023 and pushing them through Windows updates ahead of the 2026 expiration window, Microsoft is trying to make that renewal feel routine rather than disruptive.

The transition also highlights how Windows security is shared across layers. Microsoft can ship platform updates, but firmware-level trust stores and device-specific behaviors still depend on OEM implementation. That’s why the company is already warning that some devices may need separate firmware updates, and why specialized systems may follow different processes.

Key Updates to Monitor
What to watch next (so this doesn’t sneak up on you):
– Microsoft’s ongoing rollout notes: Expect additional guidance as Microsoft expands beyond early delivery updates (like KB5074109) and clarifies edge cases.
– OEM firmware advisories: Some models may only become “ready” after a BIOS/UEFI update; OEM support pages are often where that shows up first.
– Fleet posture drift: As 2026 approaches, the gap between “fully refreshable Secure Boot” devices and “degraded security state” devices can become a real operational divide.

Ensuring Continuous Security for Windows Devices

The practical takeaway is that continuity requires participation: devices need to keep receiving updates to stay within the supported Secure Boot trust chain. For most Windows 11 users, that will happen automatically. For managed fleets, long-lived endpoints, and Windows 10 environments, it becomes a planning exercise—one that blends patch management, firmware governance, and lifecycle decisions like ESU enrollment.

Microsoft’s warning about a “degraded security state” is a reminder that security failures are not always dramatic. A device can keep running while quietly losing the ability to accept the next critical boot-level mitigation. The certificate refresh is designed to prevent that slow drift—keeping Secure Boot not just enabled, but maintainable.

This perspective is informed by weidemann.tech’s work on building and operating complex, security-sensitive systems across regulated environments (including payments and multi-industry digital transformation), where certificate/key rotation and staged rollouts are routine operational realities.

This note reflects publicly available information at the time of writing, and specifics such as update identifiers, firmware prerequisites, and rollout timing may change as Microsoft and device manufacturers expand deployment. The 2011 certificate expiration window in 2026 remains a key planning constraint, but exact impacts can vary by device and environment. For the latest device-specific steps, refer to Microsoft support guidance and your OEM’s current firmware advisories.

Related Posts

Scroll to Top