Secure Boot Certificates Expiring in 2026: The MSP Device Audit

Secure Boot certificates expiring in 2026 should not send MSPs into panic mode. It should send them into inventory mode.

Microsoft's original Secure Boot certificate set from 2011 starts expiring in June 2026, with another Windows boot certificate expiring in October 2026. Devices usually will not brick on the expiration date. That is the trap. The device can keep booting while its early-boot security path gets stuck in the past.

Quick answer: MSPs should treat the 2026 Secure Boot certificate deadline as a paid device audit and remediation project. Find which endpoints, servers, and virtual machines still rely on 2011 certificates, update firmware first, pilot the Windows certificate update, confirm BitLocker recovery readiness, then turn the findings into roadmap and quote work.

This is not a normal patch Tuesday footnote. It sits below Windows, below your RMM agent, below the EDR console, and below most client conversations about "are we secure?"

What is actually expiring?

Secure Boot is the UEFI trust chain that decides whether the machine should load early boot components. Microsoft says Windows devices have carried Microsoft certificates in the KEK and DB stores since Secure Boot support began. Those older certificates are now aging out.

The practical certificate dates are:

Certificate	Store	Expiration	Replacement path
Microsoft Corporation KEK CA 2011	KEK	June 24, 2026	Microsoft Corporation KEK 2K CA 2023
Microsoft UEFI CA 2011	DB	June 27, 2026	Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023
Microsoft Windows Production PCA 2011	DB	October 19, 2026	Windows UEFI CA 2023

The KEK signs updates to the Secure Boot DB and DBX. The DB trusts boot loaders and EFI applications. The DBX blocks known-bad boot components. If those terms make the client's eyes glaze over, use this version:

The machine may still start, but future boot-level protections can get blocked if the trust chain is not updated.

Microsoft says devices without the newer 2023 certificates can continue to start and install standard Windows updates. The problem is narrower and more dangerous: they may stop receiving new protections for the early boot process, including Boot Manager updates, Secure Boot database changes, revocation lists, and mitigations for new boot-level vulnerabilities.

That is not a "will the laptop turn on?" problem. It is a "can this endpoint keep receiving pre-OS security protection?" problem.

If you already have a Windows 10 EOL plan for MSP clients, this belongs in the same client inventory conversation. Unsupported operating systems, old firmware, TPM readiness, Secure Boot state, and device refresh age all point to the same decision: fix, replace, bridge, or document the exception.

Why MSPs should care before clients ask

Clients will not ask about KEK, DB, and DBX. They will ask why a laptop shows a Windows Security warning, why BitLocker wants a recovery key, why a firmware update is suddenly urgent, or why a perfectly usable PC now needs budget.

That is where the MSP either looks prepared or looks surprised.

The real work is not clicking "update." The real work is answering these questions:

• Which client devices still show old Secure Boot certificate state?
• Which hardware models need OEM firmware before Windows can apply the certificate update cleanly?
• Which servers or VMs have Secure Boot enabled and separate UEFI state from the host?
• Which BitLocker-enabled devices need recovery keys checked before the pilot?
• Which devices are old enough that this should become a replacement quote instead of another exception?

That list is client-facing work. It belongs in assessment, roadmap, budget, and quote scope. If you quietly absorb it under normal support, the client learns that firmware risk, pilot testing, after-hours recovery, and exception reporting are all included forever. Nice of you. Terrible business.

Use the same discipline you would use for a shared responsibility matrix: name what the MSP owns, name what the client funds, and name what stays an accepted risk if the client declines remediation.

The MSP audit checklist

Start with a fleet audit that a client can approve, not a raw export from Intune or an RMM.

For every relevant device, capture:

1. Client, user, device name, model, serial, and business role
2. Windows version, Windows edition, and support status
3. Secure Boot enabled status
4. Current Secure Boot certificate update status
5. Relevant event IDs or registry status, including UEFICA2023Status
6. Firmware version and OEM update availability
7. BitLocker state and recovery-key escrow status
8. Boot order, especially PXE or network boot before local disk
9. Recommended path: update, firmware remediation, replacement, VM work, or documented exception
10. Client approval status and target maintenance window

Microsoft's troubleshooting guidance calls out exactly the kind of signals MSPs should inventory: Secure Boot certificate status, Event ID 1801, Event ID 1795, and whether UEFICA2023Status is set to Updated. It also warns that broken or outdated firmware can produce Secure Boot validation errors, BitLocker recovery prompts, startup hangs, or devices that fail to boot.

This is why the audit comes before the rollout.

If a client has 70 endpoints, the useful answer is not "70 devices need attention." The useful answer is "44 can ride the normal Windows path, 12 need firmware first, 6 need BitLocker key validation before pilot, 5 are old enough to replace, and 3 need a signed exception."

That is a roadmap item.

Roll it out like a project, not a vibes-based patch

Microsoft documents several supported deployment paths for managed devices, including Intune, Group Policy, registry keys, and Windows configuration systems. For enterprises using registry controls, Microsoft documents AvailableUpdates as the trigger value and 0x5944 as the setting that deploys needed certificates and updates the device to the PCA2023-signed boot manager.

Do not read that and blast every client device at once.

Run a pilot first:

1. Pick devices from multiple OEMs, firmware versions, and business roles.
2. Update OEM firmware before forcing certificate changes.
3. Confirm BitLocker recovery keys are escrowed and retrievable.
4. Apply the Secure Boot certificate update using the managed path you will use later.
5. Confirm the certificate state shows updated.
6. Reboot more than once.
7. Watch for BitLocker recovery prompts, startup hangs, Secure Boot warnings, and event-log errors.

Microsoft's Windows Security guidance also matters here. A green Secure Boot checkmark alone does not prove the certificate work is done. Microsoft says the fully updated state includes the message that Secure Boot is on and all required certificate updates have been applied.

That wording belongs in your technician runbook.

This is also a good time to review your Microsoft Intune MSP pricing and deployment scope. Intune can push policy and help with compliance reporting, but it does not make old firmware, missing recovery keys, replacement hardware, or client approvals disappear.

BitLocker is the part clients will remember

The client does not care which certificate lives in which UEFI store. They care when a user sees a BitLocker recovery screen at 8:12 a.m.

Microsoft's troubleshooting guidance calls out BitLocker recovery prompts, including repeated prompts or loops, as a higher-risk scenario when firmware is outdated or certificate updates do not apply cleanly. It also recommends pilot groups that include BitLocker-enabled devices and confirms no unexpected BitLocker recovery prompts before broad deployment.

For MSPs, that turns into a simple rule:

No broad Secure Boot certificate rollout until recovery keys are verified.

Check these before touching production:

• BitLocker keys are escrowed in Entra ID, Active Directory, your documentation system, or another approved source.
• Helpdesk knows how to retrieve the key without guessing.
• Users know the support path if they see recovery.
• PXE boot is not ahead of local disk unless the client truly needs it.
• Firmware updates are tested on the same device families the client actually owns.

BitLocker recovery is not automatically a disaster. Surprise BitLocker recovery across a client fleet is a self-inflicted ticket pile.

How to package this work for clients

Do not sell "Secure Boot certificate update" as a tiny technical task. Sell the client outcome: boot-level protection stays current, firmware risk gets surfaced, BitLocker recovery risk gets tested, and unsupported hardware gets moved into a funded decision.

A clean MSP package looks like this:

Workstream	MSP deliverable	Client decision
Secure Boot audit	Inventory, status, firmware needs, BitLocker readiness, exception list	Approve remediation scope
Pilot rollout	Representative device testing, error review, recovery-key test, runbook updates	Approve broad rollout window
Firmware remediation	OEM BIOS/UEFI update plan by model family	Approve maintenance windows and user impact
Certificate deployment	Intune, Group Policy, registry, or managed update path	Approve schedule and rollback limits
Hardware replacement	Quote for devices that cannot be updated cleanly	Fund replacement or sign risk acceptance
Exception management	Written list of devices left behind and review date	Accept or reject residual risk

Tie this to the client roadmap workflow. Secure Boot certificate state is not a one-off nerd finding. It affects endpoint refresh, security posture, compliance evidence, and support boundaries.

If you want assessment findings, roadmap items, and remediation quotes in one client-ready workflow, join Scopable early access.

If the client asks why this is a project, keep the answer plain:

We need to confirm which devices can safely receive the update, which need firmware first, and which need BitLocker recovery planning. The update is small. The blast radius is not.

That is the right tone. Calm, specific, and commercial.

The short version

Secure Boot certificates expiring in 2026 are not a reason to scare clients. They are a reason to audit the fleet before the warning icons, firmware edge cases, and BitLocker calls choose your schedule for you.

Inventory the devices. Check Secure Boot certificate status. Update firmware first. Pilot across real hardware. Verify BitLocker recovery keys. Use Intune, Group Policy, registry keys, or your managed update path only after the scope is clear. Quote replacement and exception work instead of hiding it inside support.

The client does not need a cryptography lecture. They need a funded plan that keeps boot-level protection current and keeps recovery surprises out of Monday morning.

Sources

• Microsoft Support: Windows Secure Boot certificate expiration and CA updates
• Microsoft Learn: Update Secure Boot Certificates for Windows Devices
• Microsoft Support: Registry key updates for Secure Boot on IT-managed Windows devices
• Microsoft Support: Secure Boot certificate update status in the Windows Security app
• Eclypsium: Microsoft Secure Boot certificates expire in 2026