For most organizations, nothing visibly disruptive will occur when the 2011 certificates expire in 2026. Devices will continue to power on, Windows will load normally, and users will work without interruption. The absence of failure, however, should not be mistaken for the absence of risk.The transition from the 2011 to the 2023 certificate generation is not a visible failure event. It is a forward-compatibility shift in the firmware trust model that underpins every modern Windows computer.
As Microsoft phases out dual-signing and moves fully to 2023 certificates, devices that have not transitioned will progressively lose the ability to consume new boot-chain protections and revocation updates. They will continue operating, but outside the current security baseline.
The challenge is not deploying a single update. The challenge is knowing, with certainty, which devices in your environment have transitioned, which have not, and which cannot. In computer fleets spanning multiple OEMs, firmware versions, and management states, that visibility gap is where risk accumulates.
Secure Boot 2026 is not about whether devices boot. It is about whether your firmware trust chain remains aligned with the modern security standard, and whether you can prove it.
|
Year |
What It Represents |
Why It Matters |
|
2011 |
Original Secure Boot trust model created |
Foundation now expiring |
|
2023 |
New CAs introduced |
Migration path begins |
|
2024–2025 |
Transition window |
Safest remediation period |
|
June 2026 |
First certificate expirations |
Start of degraded security state |
|
October 2026 |
Additional expirations |
Legacy trust effectively obsolete |
|
Post-2026 |
Ongoing divergence |
Governance and lifecycle risk |
Since the introduction of UEFI Secure Boot, Microsoft’s 2011 Certificate Authorities (CAs) have served as the root of trust for the boot chain on virtually every modern Windows PC. These signing certificates underpin the Key Exchange Key (KEK), the Signature Database (DB), and the Forbidden Signature Database (DBX). Together, these three components determine which code is permitted to execute before the operating system loads.
Images source: Learn.microsoft.com - https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
In 2026, these certificates reach the end of life in a phased process. The Microsoft Windows Production PCA 2011 certificate expires in June 2026. The Microsoft UEFI CA 2011 follows in October 2026. This is not a single expiration event but a transition window spanning several months.
Microsoft has introduced replacement 2023 signing certificates and has been staging updates so that the new certificates are added to devices before the old ones expire. During the transition period, boot components are dual-signed to maintain compatibility.
Critical distinction: in most configurations, devices will not stop booting when these certificates expire. There is no immediate “brick” scenario for the vast majority of hardware.
Certificate expiration does not automatically invalidate firmware-stored trust anchors. The actual impact depends on each platform’s UEFI implementation and how it handles certificate validity checks.
Over time, however, devices that have not transitioned to the 2023 certificates will progressively lose the ability to accept new boot chain protections. As Microsoft phases out dual-signing, new Boot Manager versions or revocation list (DBX) updates signed exclusively with the 2023 certificates will not apply to untransitioned devices. In some configurations, this could eventually affect boot capability itself.
The practical distinction is between availability and integrity. A device that boots successfully today is not necessarily a device that will remain secure, or even bootable, as the transition progresses.
Standard Windows cumulative updates operate within the operating system layer. Secure Boot certificate transitions are fundamentally different because they affect firmware-level trust anchors, the layer beneath the OS that validates everything above it.
Depending on the hardware and firmware version, this transition may require OEM-specific firmware updates in addition to OS-level patches. It also intersects with BitLocker recovery in certain scenarios.
If the Secure Boot state changes, PCR measurements shift, or firmware settings are modified during the update process, BitLocker recovery may be triggered. This is not a guaranteed consequence of the certificate transition itself, but it is a risk that must be validated during pilot deployments.
Across computer fleets spanning multiple hardware vendors, models, and firmware revisions, the transition introduces long-tail technical debt that cannot be resolved with a single deployment action.
Perhaps most importantly, it creates a silent risk. A device running 2011 certificates looks and operates identically to one running 2023 certificates, until a boot chain update requires the new certificates.
At that point, the gap becomes visible, but remediation at scale is significantly more complex under time pressure.
Risk Categories to Consider
Security exposure: Devices that have not transitioned to the 2023 signing certificates face increasing risk over time. Whether a given DBX revocation or boot update applies depends on firmware state, KEK/DB/DBX contents, update packaging, and vendor implementation, but the trajectory is clear: untransitioned devices will progressively fall behind on boot-level protections.
Compliance considerations: While no mainstream regulatory framework currently mandates a specific Secure Boot certificate generation, organizations subject to security audits or compliance standards that require demonstrable firmware integrity should anticipate that reliance on expired certificates will face increasing scrutiny.
Firmware support limitations: Some older hardware may not receive OEM firmware updates to fully support the 2023 certificates, though in many cases, the new certificates can be delivered via Windows Update. Platform support varies significantly by vendor, and firmware updates are required only in specific scenarios. Where devices genuinely cannot transition, these become lifecycle decisions.
Capital planning impact: Devices confirmed to be incapable of transitioning may need accelerated replacement, affecting hardware budgets and refresh cycles.
Microsoft’s recommended approach centers on Intune-based deployment for organizations using modern management. The transition involves applying Windows cumulative updates that carry the 2023 certificate payloads, followed by validation that the firmware has accepted the new certificates.
Microsoft’s guidance emphasizes controlled, consistent deployment across the fleet. This is not a strict prohibition against other deployment methods, but a strong best-practice recommendation. Mixing approaches or deploying updates in different sequences across device groups can leave devices in partially updated states that are harder to diagnose and fix.
A disciplined pilot-first model is essential. Organizations should begin with a representative sample of hardware models and firmware versions, validate BitLocker behavior and boot integrity post-update, and only then expand to broader deployment rings. Continuous monitoring of certificate status throughout the rollout is foundational to avoiding regressions.
Several realities complicate fleet-wide execution. Some older OEM firmware may not fully support the 2023 certificates, though the scope of this issue varies significantly by vendor. In many cases, certificates are delivered through Windows Update rather than requiring a separate firmware update. Gaps in telemetry across management tools make it difficult to confirm which devices have successfully updated. Virtual machines may not support Secure Boot or may require hypervisor-level configuration changes. Devices without Secure Boot enabled, whether by policy gap or legacy configuration, present a separate remediation track. And devices outside their OEM firmware support window represent lifecycle decisions, not patching decisions.
The technical steps to deploy 2023 certificates are well documented. The actual challenge for most organizations is not the deployment mechanism; it is knowing the state of every device in the fleet with confidence.
Specifically, IT leaders need to answer:
Which devices have Secure Boot enabled?
Of those which have successfully transitioned to the 2023 certificates?
Which are still running on 2011 certificates?
Which are not Secure Boot capable at all?
And which devices are simply not reporting, creating blind spots in the governance picture?
Tracking remediation status across multiple hardware models, OEM vendors, and firmware versions introduces significant operational complexity. Without structured observability, organizations face the risk of drift, where devices that were compliant at one point silently regress, or where new devices enter the fleet without proper certificate configuration.
This is why the Secure Boot transition is best understood as a fleet governance challenge, not a patching exercise. It requires fleet-level observability tooling to solve.
Applixure Analytics now detects whether each Windows device in your environment has the old Secure Boot 2011 certificates in use, has successfully updated to the 2023 certificates, or is not Secure Boot capable. This detection requires Applixure Agent version 202601301622 or newer and a recent Windows cumulative update on each endpoint.
Devices that are not fully updated display a notification in the Firmware section of the device details screen. If no notification is shown, the data is either unavailable, the certificates are already up to date, or the device is not Secure Boot capable. Critically, the entire fleet can be queried using a single search filter:
SecurityState.IsSecureBoot2023CAInUse = false
This query immediately surfaces every device still running 2011 certificates, enabling IT teams to move from uncertainty to structured action. Fleet-wide segmentation by certificate status, hardware model, and OEM vendor becomes possible within minutes, not weeks. Remediation campaigns can be prioritized by risk, firmware readiness, or organizational unit.
Find other use cases and features in the Applixure Use Case library, here.
With Applixure, Secure Boot certificate readiness becomes a standard part of how you assess device health, not an afterthought discovered during an audit. Certificate status integrates into the broader view of lifecycle governance, firmware compliance monitoring, and security posture.
This matters because the 2011 → 2023 transition is not a one-time campaign to be executed and forgotten. New devices enter the fleet. Firmware updates change device state. Configurations drift. Treating certificate status as an ongoing quality metric, monitored continuously alongside OS patch level, hardware age, and application health, is the only approach that prevents regression.
The most dangerous outcome of the Secure Boot transition is not a visible failure. It is the slow, undetected accumulation of devices that can no longer accept new boot chain protections. These devices look healthy in every other dimension; they boot, they run applications, they report to management tools, but they are progressively falling behind on boot-level security coverage.
Applixure directly addresses this risk by making certificate status visible, searchable, and trackable over time.
The practical operational model follows a clear sequence:
Identify devices still on 2011 certificates.
Segment by hardware model and firmware readiness.
Remediate through the appropriate combination of Windows cumulative updates and OEM firmware updates where required.
Validate at fleet level that transitions have succeeded.
Monitor continuously to catch drift and new devices entering the environment.
The Secure Boot certificate transition is a specific instance of a broader shift in enterprise IT: the move from reactive endpoint management to condition-based device governance.
Organizations that build the operational muscle to manage firmware-level transitions, with real data, structured segmentation, and continuous validation, gain capabilities that extend well beyond this single event.
These capabilities include data-driven lifecycle decisions, where hardware refresh is triggered by actual device condition rather than arbitrary age thresholds.
They include reduced unmanaged firmware risk, where every device in the fleet has a known and validated firmware state. And they include the alignment of security, operations, and capital planning around a shared, objective view of fleet health.
Applixure provides the observability layer that makes this shift practical, not as a one-time project tool, but as a continuous governance platform for fleet quality management.
The expiration of Microsoft’s Secure Boot 2011 certificates in 2026 is a phased transition, not a single event. In most configurations, devices will continue to boot after the certificates expire.
However, devices that have not transitioned to the 2023 signing certificates and updated key material will gradually lose the ability to receive new boot chain protections, revocation updates, and Secure Boot policy changes as Microsoft completes the transition to the new certificate generation. The exact impact depends on firmware implementation, update sequencing, and vendor support.
The organizations that treat it as firmware-level lifecycle management, with structured identification, segmentation, remediation, validation, and continuous monitoring, will remain secure beyond 2026. Those who treat it as a routine patch will discover their blind spots when it matters most.
Applixure gives you the visibility to act now, the segmentation to act precisely, and the monitoring to stay ahead.
This transition is not something to leave to assumptions or scattered reporting. A structured fleet-level review will give you clarity on which devices have transitioned, which are still on legacy certificates, and where remediation or lifecycle decisions may be required.
If you manage more than 200 computers, Sign up for an Applixure Health Check to assess your Secure Boot readiness and overall firmware posture across your environment.