Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript
The June 2026 Secure Boot certificate expiration is becoming an important readiness milestone for Microsoft environments running Windows endpoints, servers, and virtual machines.
While Microsoft is delivering updated Secure Boot certificates through supported update channels, your organization may still face operational challenges around firmware readiness, reboot orchestration, BitLocker recovery planning, recovery media, and legacy device support.
IT teams that validate their environment can identify gaps, stage firmware updates safely, and avoid unexpected issues as the older 2011 Secure Boot trust chain approaches expiration.
In this blog, we outline the full key readiness areas organizations should assess before June 2026.
Before any remediation begins, build a clear view of every system that may depend on the older Secure Boot certificate chain.
Confirm inventory coverage for:
Many organizations already have inventory, but not the kind of inventory this event requires. A standard asset report may show device name, user, OS version, and serial number, but miss the details that actually matterfor Secure Boot readiness.
Your inventory should capture:
The most common mistake is treating "managed by Intune" as equivalent to "ready," or treating "policy applied" as equivalent to "device protected." Neither is true for this transition. Intune coverage is helpful, but it does not guarantee firmware readiness, certificate presence, BitLocker behavior, or OEM compatibility across every model.
Can your team produce a list today of devices that are running older Secure Boot trust anchors, have outdated firmware, or are unmanaged?
If the answer is no, that is the starting point.
The goal is to ensure devices have the updated Secure Boot trust chain before the older 2011 certificates expire.
Microsoft identifies the expiring certificates as including the Microsoft Corporation KEK CA 2011, Microsoft Corporation UEFI CA 2011, and Microsoft Windows Production PCA 2011, with updated 2023 certificates replacing them across the KEK and DB trust stores.
Validate whether applicable devices have the updated certificates, including:
Use available Microsoft guidance and tools to inspect Secure Boot state through approved methods such as PowerShell, event logs, Windows Update reporting, Windows Autopatch reporting, or enterprise management platforms.
Certificate presence is not always binary from an operational perspective. A device can sit at Stage 4, where the 2023 certificate is already written to the UEFI database, but the machine is still booting from the old 2011 chain. It will sit there for weeks until a reboot happens. From the Intune dashboard, the device looks like it is making progress. In reality, it is not yet protected.
Pay special attention to:
Trusting the compliance dashboard at face value. A green or yellow dashboard often means the certificate landed in the database, not that the device is actually booting from the new trust chain. Those are two different states with two different risk profiles.
Do you have proof that the new Secure Boot certificates are not only present, but actively in use across your endpoint, server, and VM estate, or only an assumption that updates have been applied?
Microsoft is rolling updated Secure Boot certificates through regular Windows update channels for supported endpoint devices, and organizations can also manage the update process using their preferred tools.
For many IT environments, the largest obstacle will not be the update itself. It will be the policies, exceptions, deferrals, and operational habits that prevent the update from reaching every device.
Review update controls across:
Look for good intentions that create hidden risk:
A dashboard showing compliant may only mean compliant with the organization's current update policy, not necessarily compliant with the Secure Boot certificate transition.
Are your update policies accelerating Secure Boot readiness, or quietly delaying it?
This is likely the most underestimated part of the project.
Secure Boot sits at the intersection of Windows, firmware, certificates, hardware drivers, bootloaders, and OEM implementation. Microsoft has emphasized ecosystem collaboration with device manufacturers and firmware partners as part of this Secure Boot refresh.
That means IT teams should treat this like a controlled infrastructure change, not a routine endpoint patch.
Build a firmware readiness plan that includes:
Use a staged rollout model:
Firmware programs often fail because the team treats all laptops as interchangeable. They are not.
Risk varies by:
Do not start with a broad firmware deployment across the whole estate. A single model-specific issue can create a wave of tickets, executive disruption, and rollback complexity.
Have you validated Secure Boot certificate updates on the actual hardware combinations your business runs every day?
Secure Boot changes can affect BitLocker behavior. In some configurations, updates to Secure Boot variables may trigger BitLocker recovery. That does not mean the update is wrong, but it does mean the rollout needs operational discipline.
Before deployment, confirm:
The biggest BitLocker risk is not the recovery event itself. It is the operational scramble when the helpdesk cannot quickly retrieve the recovery key or users do not know whether the prompt is legitimate.
Before rollout, verify:
Suspending BitLocker without a clear resume policy creates a new security gap while trying to close an old one.
If 50 users received a BitLocker recovery prompt tomorrow morning, could your team recover them quickly, securely, and consistently?
Servers are not a smaller version of the endpoint problem. They are a separate problem.
Here is the part most teams miss: Windows Server does not receive the 2023 Secure Boot certificates automatically through Windows Update the way Windows 11 endpoints do. For servers, the certificate update is a manual deployment exercise. Same story for Generation 2 Hyper-V virtual machines. They need the update pushed in, it does not arrive on its own.
If you have 50 servers, that is 50 manual remediation jobs that nobody has started yet.
Review:
Generation 1 Hyper-V VMs do not use UEFI firmware, so they are not affected by this transition. Do not waste cycles remediating them.
Assuming that because servers receive monthly Windows updates, they are also receiving the Secure Boot certificate updates. They are not. This is a manual project for the server fleet, and it has the same June and October 2026 deadlines as everything else.
Who owns the Secure Boot remediation plan for your server estate, and is it on the same timeline as your endpoint plan?
Even if production devices are remediated, outdated provisioning and recovery artifacts can reintroduce the same risk months later.
Recovery media is the sleeper issue here. A WinPE stick, a recovery USB, or an install image created before the 2023 certificates were adopted can fail to boot on firmware that has moved to the new trust chain. You fix the fleet today, six months from now your helpdesk pulls out an old USB to reimage a laptop, and it does not boot. The remediation worked. The recovery process is broken.
Update and validate:
.jpg)
WinPE recovery media Fixing the current fleet while continuing to deploy new devices and recover broken ones from outdated images and media. This creates a slow, invisible regression. Every new build or recovery event reintroduces the old trust chain into your environment.
When was the last time your team rebuilt the WinPE stick that lives in the helpdesk drawer?
This event is a forcing function for hardware lifecycle decisions.
Some devices may be technically possible to remediate, but not operationally wise to keep. Older devices with unreliable firmware support, inconsistent update behavior, or poor visibility may create more risk than value.
Flag devices that are:
Trying to save every aging device can consume more labor than replacing the highest-risk group.
Which devices should be remediated, and which should become part of a controlled refresh plan?
For finance and healthcare organizations, this is more than an IT maintenance task. It intersects with security governance, audit readiness, cyber insurance expectations, and regulatory posture.
Document:
Completing the technical work without preserving evidence leaves IT exposed during audits, incident reviews, or insurance assessments.
The technical project will go smoother if users, helpdesk, security, and leadership understand what is happening.
Prepare communications for:
If your fleet uses Windows Hotpatch, you have a unique exposure. Hotpatching is designed to reduce reboot frequency. That is a feature for normal patching, but for the Secure Boot certificate transition it is a problem.
The 2023 certificate cannot finish activating without a reboot. On a Hotpatch device, that reboot may not happen for weeks. Meanwhile, the device shows up in dashboards as update applied while it is still booting from the 2011 chain.
For Hotpatch fleets, build a scheduled reboot orchestration plan that runs alongside the certificate rollout. Otherwise, the dashboard will keep telling you everything is fine while your real risk does not move.
Do you know which of your devices are on Hotpatch, and when each one last completed a full reboot?
Get a Free Secure Boot Risk Report
Delivered in 3 business days.
The report identifies:
Ready to get ahead of the Secure Boot expiration? Our experts assess your exposure, identify remediation priorities, and provide a clear path to eliminate risk. Grab a few minutes below and get your report.