Microsoft has confirmed a hard deadline of June 2026 for the decommissioning of the original Secure Boot certificates. After that date, PCs still relying on the 2011-era boot certificate will face boot failures, loss of Secure Boot enforcement, or both. IT administrators managing fleets must treat this as a managed endpoint migration — inventorying every device, piloting firmware updates, and using ring-based deployment to meet the cutoff without disrupting users.
What Actually Changes in June 2026
The Secure Boot system validates that only trusted code runs during the boot process. It relies on a chain of certificates. The root certificate issued in 2011 is being retired. After June 2026, the firmware on PCs must trust only the newer 2023 Secure Boot certificate, or they will no longer be able to verify bootloaders signed with the old key. Microsoft has already delivered the new certificate via Windows Update to supported systems, but many devices — particularly older hardware or those without recent firmware updates — may still lack the replacement.
Specifically, the change means:
- UEFI firmware must include the "Microsoft UEFI Certificate Authority 2023" in the Secure Boot database (db). If it does not, any OS component signed with the new certificate won't validate, potentially halting boot.
- Systems that only trust the old 2011 certificate will fail to recognize bootloaders signed with the 2023 certificate, which Microsoft plans to enforce fully by the deadline.
- No automatic revocation of old certificates is planned at the PCI level in most consumer devices, but enterprise-managed endpoints that require strict compliance may see Secure Boot reporting failures in Microsoft Intune and Defender for Endpoint if they aren't updated.
What It Means for You
For Home and Individual Users
If your PC receives Windows Updates and firmware updates from the manufacturer automatically, the transition is likely invisible. Most modern devices manufactured after 2020 already include the 2023 certificate in their UEFI firmware. For custom-built or older machines, you may need to manually install a firmware update from the motherboard vendor. Windows Update might offer a firmware blob that adds the certificate, but not all OEMs push firmware through that channel. Check your device manufacturer's support page.
For IT Administrators and Enterprise Environments
The deadline is a compliance risk. Even if automated patching tools have already deployed the 2023 certificate to some machines, a scattered fleet means some endpoints remain unprotected. These will flag in compliance dashboards like Microsoft Intune's device compliance policies and Secure Score. Worse, if Microsoft releases a bootloader update that enforces the new certificate chain, unpatched machines could blue‑screen on restart, leading to helpdesk chaos.
Key impacts on admin tasks:
- Device inventory becomes critical. You must know exactly which machines already have the 2023 certificate, which ones need it, and which ones cannot receive it (e.g., hardware that never received a recent UEFI update).
- Phased rollout with rings is essential. A sudden mass‑update can brick devices if a firmware bug exists. Test on a small pilot group first.
- Reporting tools need configuration. Microsoft Intune, Autopatch, and Defender for Endpoint can surface Secure Boot certificate status, but only if you set up appropriate compliance policies and reporting dashboards.
For Firmware Developers and OEMs
If you build embedded systems, IoT devices, or industrial PCs, the deadline may require a custom firmware update package. The 2023 certificate must be injected into the Secure Boot database before the cutoff. This is especially urgent for devices that rarely receive updates, such as medical or factory‑floor equipment.
How We Got Here
Secure Boot was introduced with Windows 8 in 2012, using a Microsoft‑issued key that would secure the boot chain for the next decade. In 2023, Microsoft began rolling out a successor certificate — the "Microsoft UEFI Certificate Authority 2023" — through Windows Update and firmware updates. The original plan was to start requiring the new certificate by early 2024 for new hardware, with a final cutoff for all systems later. The June 2026 date marks the end of the transition, after which the 2011 certificate becomes untrusted.
This timeline was designed to give the ecosystem — OEMs, enterprise IT, and users — ample lead time. Yet many organizations are only now waking up to the requirement. The delay is understandable: the change feels abstract until a hard stop appears on the calendar.
What to Do Now: A Practical Migration Checklist
This is not a patch‑and‑pray event. It demands the same rigor as a Windows feature update deployment. Below is a step‑by‑step, ring‑based approach.
1. Inventory Your Fleet Immediately
Before any deployment, you need full visibility. Build a comprehensive report of every endpoint's Secure Boot certificate status.
Tools to use:
- Microsoft Intune (or another MDM): Create a custom compliance policy or script that checks for the presence of the 2023 certificate in the UEFI db. Export a report of non‑compliant devices.
- Defender for Endpoint advanced hunting: Query the DeviceTvmSecureConfigurationAssessment table for the specific configuration ID related to Secure Boot.
- PowerShell on individual machines: Run Confirm-SecureBootUEFI or inspect the Secure Boot variables manually to identify which certificates are trusted.
- SCCM (ConfigMgr) can also inventory firmware versions if you have that data point. Combine it with a hardware lifecycle report to identify machines that may never get a firmware update.
2. Identify Devices That Cannot Be Updated
Some machines are dead‑end hardware. Manufacturers may no longer offer UEFI updates for models older than five years. For these, your options are:
- Replace the hardware before June 2026.
- Disable Secure Boot (not recommended for security posture).
- Explore custom firmware modification (only if you have the expertise and legal approval, as it may void warranties).
Document all dead‑end devices and set a replacement schedule.
3. Pilot on a Representative Subset
Choose 20–50 devices that mirror your production environment — different makes, models, and firmware versions. Apply the certificate update manually or via your deployment tool. Monitor for issues:
- Boot failures or long POST times.
- Application compatibility (rare, but certain encryption tools or custom bootloaders can misbehave with the new certificate).
- Compliance reporting accuracy in dashboards.
4. Create Ring Deployments
Adopt the classic update rings model:
- Ring 1 (IT and early adopters): 5% of the fleet, tested for two weeks.
- Ring 2 (broad pilot): 20% of the fleet, after no issues in Ring 1.
- Ring 3 (production): The remaining 75%, rolled out in phases.
Use Microsoft Intune, Windows Autopatch, or SCCM to target these groups. The certificate update itself is typically a small firmware capsule that installs silently; however, it requires a reboot, so schedule it during maintenance windows.
5. Set Compliance Policies and Reporting
After deployment, ensure your monitoring is airtight:
- In Intune, create a device compliance policy that checks for the 2023 certificate and marks non‑compliant devices. Combine this with Conditional Access to block risky devices from corporate resources.
- Enable Secure Score recommendations to track the Secure Boot posture across your tenant.
- Set up Defender for Endpoint alerts for any device that loses Secure Boot after the deadline (indicating possible tampering or failure).
6. Communicate with Users
A firmware update that requires a reboot can alarm users if not announced. Send advance notice explaining that a security update will require one or two restarts. Provide a timeline and self‑service instructions to avoid confusion.
Outlook
The June 2026 cutoff is a hard stop, not a suggestion. Microsoft is unlikely to extend it. Organizations that start their inventory and piloting now will sail through. Those that wait until the last quarter of 2025 will face a compressed timeline, forced hardware purchases, and increased risk of outage. The migration also offers a chance to clean up the fleet — retiring old hardware and ensuring that every device meets modern security baselines. After the update, Secure Boot will continue to evolve, with future certificate renewals likely on a similar cadence. The lesson is clear: treat firmware trust anchors as living components that need regular lifecycle management, just as you do operating systems and applications.