Microsoft Secure Boot Certificates Expire June 27: Your Windows Fleet Needs Attention

Microsoft’s original Secure Boot UEFI certificates expire on June 27, 2026. After that date, any Windows device still relying on these certificates will stop receiving boot-level security updates. For most consumer PCs on automatic updates, the transition will happen silently. For businesses running managed update policies through WSUS, SCCM, or Intune, or those with older hardware and custom firmware, this is not automatic. It requires manual attention, and the deadline is 10 weeks away.

This post covers what’s happening, why it matters for your business, and exactly what your IT team (or your MSP) should be doing right now to prepare.

What Secure Boot Certificates Actually Do

Secure Boot is a feature built into your computer’s UEFI firmware that verifies every piece of software loaded during startup. Before Windows, drivers, or bootloaders execute, Secure Boot checks their digital signatures against a set of trusted certificates stored in the firmware. If a signature doesn’t match a trusted certificate, the system refuses to boot. This prevents rootkits, bootkits, and other firmware-level malware from loading before your operating system’s security tools even start.

The certificates that make this work have expiration dates, just like your SSL certificates or your driver’s license. Microsoft’s original Secure Boot signing certificates, issued when Windows 8 launched in 2012, expire on June 27, 2026. Microsoft has already created replacement certificates with a new expiration date of 2035 and has been rolling them out through Windows Update since 2024.

The problem is that the rollout requires multiple sequential updates installed in a specific order, with reboots between each step. According to Microsoft’s Secure Boot playbook, the full transition involves updating the Secure Boot certificate database (DB), installing new boot managers signed with the replacement certificates, and updating the Secure Boot Forbidden Signature Database (DBX) to revoke the old certificates. If any step in this chain was missed or blocked, your device is stuck on the expiring certificates.

Why Managed Update Policies Create Risk

If your business uses Windows Update with no restrictions, your devices have likely received these updates already. Microsoft has been pushing them incrementally since 2024, and devices on the default update channel should be current by now.

But most businesses with 50 or more endpoints don’t run unrestricted Windows Update. They use tools like Windows Server Update Services (WSUS), Microsoft Endpoint Configuration Manager (SCCM/MECM), or Microsoft Intune to control which updates deploy and when. These tools exist for good reason: they prevent untested updates from rolling out to production machines. The trade-off is that updates requiring manual approval can sit unapproved for months.

The Secure Boot certificate updates are especially easy to miss because they’re classified as firmware updates or optional updates depending on the deployment channel. They may not show up alongside your regular cumulative updates. An IT admin who diligently approves monthly security patches could still miss the Secure Boot updates entirely because they appear in a different category within the management console.

Microsoft’s April 2026 advisory explicitly calls out this scenario: organizations using “managed update environments” need to verify that all Secure Boot-related updates have been approved and installed. The burden falls on the IT team to confirm, device by device, that the full update chain completed successfully.

Older Hardware and Firmware Dependencies

Even with the right updates approved, some devices won’t accept the new certificates without a firmware update from the hardware manufacturer. The Secure Boot certificate database lives in UEFI firmware, and older systems may need a BIOS/UEFI update before they can store and trust the replacement certificates.

This primarily affects machines manufactured before 2020. Dell, HP, Lenovo, and other OEMs have published firmware updates for supported models, but “supported” is the key word. If your fleet includes desktops or laptops that are past their manufacturer’s support lifecycle, you may not have a firmware update available. In that case, the device may not be able to complete the certificate transition at all.

There’s a secondary concern for systems running custom boot configurations, dual-boot setups, or third-party boot managers. The DBX update that revokes the old certificates can break boot processes that still rely on them. Linux dual-boot configurations and some specialized industrial systems are particularly vulnerable to this. If you have any non-standard boot configurations in your environment, test the full update sequence on one device before rolling it out.

How to Audit Your Fleet

Your first step is figuring out which devices have completed the transition and which haven’t. Here’s a practical approach.

Check Secure Boot status on individual devices. Open PowerShell as an administrator and run Confirm-SecureBootUEFI. This tells you whether Secure Boot is enabled, but not whether the certificates are current. To check the actual certificate database, use the Get-SecureBootUEFI cmdlet or review the Secure Boot variables in your UEFI firmware settings directly.

Use your endpoint management tool to report compliance. If you manage devices through Intune, SCCM, or a similar platform, run a compliance report for the specific KB articles associated with the Secure Boot updates. Microsoft’s playbook lists the relevant KB numbers for each phase of the rollout. Cross-reference your installed update history against that list.

Prioritize by risk. Not every device carries the same risk if it misses the deadline. Focus first on:

• Devices that access sensitive data or critical systems. These are the machines where boot-level security matters most.
• Devices managed through WSUS or SCCM. These are the ones most likely to have missed the updates.
• Devices older than five years. These may need firmware updates before the certificate transition can complete.
• Any device with a non-standard boot configuration. These need testing before deployment.

Document what you find. Build a simple spreadsheet tracking each device’s Secure Boot status, firmware version, and update history against the required KBs. You’ll need this documentation both for remediation planning and for compliance evidence if you operate under any regulatory framework.

Step-by-Step Remediation Before June 27

Once you know which devices need attention, work through this checklist in order.

Step 1: Approve and deploy all Secure Boot-related updates. In your WSUS, SCCM, or Intune console, search for and approve the Secure Boot certificate updates identified in Microsoft’s playbook. These updates must be installed sequentially with reboots between each phase. Don’t batch them with other updates or skip the reboots.

Step 2: Verify firmware compatibility. For devices that don’t accept the updates, check the manufacturer’s support site for UEFI/BIOS updates. Dell, HP, and Lenovo all have model-specific firmware downloads. Apply firmware updates before reattempting the Secure Boot certificate updates.

Step 3: Test on a pilot group first. Before rolling updates to your entire fleet, deploy to a small test group of 5 to 10 devices that represent your hardware diversity. Verify that they boot normally after each update phase and that no applications or boot processes break. Pay special attention to BitLocker-encrypted devices, which may prompt for recovery keys after firmware changes.

Step 4: Stage the rollout. Deploy to your broader fleet in waves, not all at once. If something goes wrong with a specific hardware model, you want to catch it after 20 devices, not 200. Allow adequate time for reboots between update phases.

Step 5: Handle exceptions. For devices that cannot complete the transition due to age, unsupported firmware, or custom boot configurations, you have two options: replace the hardware before the deadline, or accept and document the risk. A device that can’t receive boot-level security updates after June 27 becomes a liability that should be isolated from sensitive network segments.

Step 6: Verify completion. After deployment, re-run your compliance reports to confirm every device in scope has completed all update phases. Any device that shows incomplete status needs individual investigation.

What Happens If You Miss the Deadline

Devices that haven’t transitioned to the new certificates by June 27 won’t stop working. Windows will still boot, and your applications will still run. The immediate impact is that these devices will no longer be able to verify the authenticity of new boot-level updates signed with the replacement certificates.

Over time, this creates a growing security gap. As Microsoft issues new Secure Boot policies, signed boot managers, and DBX updates, devices on expired certificates won’t be able to validate or install them. Your boot-level protection freezes at its current state while new threats evolve past it. For businesses operating under compliance frameworks that require current endpoint security, this gap can also create audit findings.

The longer you wait past the deadline, the harder remediation becomes. Microsoft has warned that the update sequence becomes more complex on devices that fall significantly behind, potentially requiring manual UEFI variable manipulation or recovery scenarios.

How Managed IT Providers Handle This Proactively

This is exactly the kind of issue that falls through the cracks at organizations managing IT internally. It’s not a monthly security patch. It’s not a critical vulnerability with a CVSS score that triggers alarms. It’s a certificate expiration buried in firmware that requires a multi-step, sequential update process with hardware compatibility dependencies.

A managed IT provider with proper tooling tracks these updates as part of their standard endpoint management. The audit, testing, staged deployment, and verification steps described above are operational basics for any MSP that takes endpoint security seriously. The difference is that an MSP does this across hundreds of devices simultaneously using automated compliance reporting, and flags exceptions before they become emergencies.

If your current IT team or provider hasn’t mentioned Secure Boot certificate expiration to you yet, that’s worth a conversation. This deadline has been known since 2024. The remediation path is well-documented. Any provider paying attention to Microsoft’s endpoint security guidance should have this on their project list already.

For a broader look at how automated update management prevents exactly these kinds of gaps, see our post on automated patch management with ConnectWise.

Your Checklist Before June 27

1. Identify your update management method. Are devices on automatic Windows Update, or managed through WSUS, SCCM, or Intune?
2. Audit Secure Boot certificate status across your fleet using PowerShell and compliance reporting.
3. Approve all Secure Boot-related updates in your management console.
4. Check firmware compatibility for devices older than five years.
5. Test on a pilot group before broad deployment, especially BitLocker-encrypted devices.
6. Deploy in waves with reboots between each update phase.
7. Verify completion through compliance reports and address any exceptions.
8. Document everything for compliance and future reference.

If any of those steps feel unclear or your team doesn’t have the bandwidth to execute them in the next 10 weeks, call us at 800-985-1365. This is the kind of project that’s straightforward when you start early and painful when you don’t.