Secure Boot Certificate Expiration 2026: What IT Teams Must Do Now

Microsoft has warned enterprise IT teams that the root Secure Boot certificates baked into most Windows devices since 2012 will begin expiring in 2026, and it is rolling out a new 2023 certificate chain to prevent boot‑time security updates from failing — a change that requires coordinated action by device owners, OEMs, and firmware vendors to avoid losing the ability to patch boot components or to inadvertently block newly signed boot loaders and option ROMs.

Background​

Secure Boot is a UEFI firmware feature that prevents unsigned or improperly signed pre‑boot code from running on a device. The firmware stores three key variables — the signature database (DB), the revoked signatures database (DBX), and the Key Enrollment Key (KEK) — which together determine which bootloaders, option ROMs, and EFI executables the platform will trust. Microsoft has historically supplied a set of CA certificates that OEMs include in the firmware; those same Microsoft certificates are used to sign Windows boot components and are relied upon by many third‑party OS boot chains (for example, Linux shim-based flows).
Over a decade old, the 2011 Microsoft UEFI certificates are time‑bound. Microsoft’s guidance and the Windows IT Pro communications make two points that are simple but critical: the 2011 certificates begin to expire in June 2026 (some Windows‑signing certificates expire in October 2026), and devices that are not transitioned to the 2023 certificates before those dates may lose the capability to receive Secure Boot‑related security updates — a risk that can leave the pre‑boot environment unpatchable and exposed.

Which certificates and when​

• Microsoft Corporation KEK CA 2011 — expires June 2026; replacement: Microsoft Corporation KEK CA 2023, stored in KEK, used to sign DB and DBX updates.
• Microsoft UEFI CA 2011 — expires June 2026; replacement: Microsoft UEFI CA 2023 (and a separate Microsoft Option ROM UEFI CA 2023) stored in DB to sign third‑party boot loaders, EFI apps, and option ROMs.
• Microsoft Windows Production PCA 2011 — expires October 2026; replacement: Windows UEFI CA 2023, stored in DB and used to sign the Windows bootloader and boot components.

These dates and the certificate mapping are the load‑bearing facts that drive the operational timeline; Microsoft has stated that both the 2011→2023 replacement and the phased rollout must complete before the expiry windows to preserve Secure Boot continuity.

---

What Microsoft is offering and how it affects IT‑managed devices​

Microsoft’s public guidance splits the world into two broad operational models: (A) devices where Microsoft can manage updates (the recommended, mostly automated path) and (B) IT‑managed or air‑gapped environments where administrators control updates themselves. For many organizations, the practical choice will be a mix of both approaches depending on policy, regulatory constraints, and the presence of sensitive or isolated systems.

Option 1 — Microsoft‑managed (automated) rollout​

For a large portion of consumer and managed enterprise devices, Microsoft will deliver the new 2023 certificates via Windows Update. To participate in the Microsoft‑managed rollout IT administrators must allow required Windows diagnostic telemetry (Universal Telemetry Client / required diagnostic level) and opt devices into the Microsoft managed stream. Microsoft groups devices by firmware and hardware profiles and deploys updates gradually, monitoring telemetry for regressions so it can pause rollouts if a widespread problem is detected.
Microsoft provides a registry opt‑in key for tenant or device level control for devices under IT management:

• Registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
• Key name: MicrosoftUpdateManagedOptIn (DWORD)
• Recommended DWORD value: 0x5944 (indicates device may be updated in a way that preserves current security profile and updates boot manager trust).

This path reduces the manual burden for many fleets, but it requires changing telemetry policies — an organizational policy decision that privacy‑sensitive or regulated environments may not accept.

Option 2 — Self‑service or partially automated solutions​

For enterprise environments that cannot send telemetry (for example, air‑gapped manufacturing systems, sensitive government devices, or strict privacy environments), Microsoft is evaluating and will publish self‑service and partially automated guidance and tooling. In the interim, Microsoft has published manual DB/KEK update steps and a GitHub repo with Secure Boot object content that organizations can use to build their own update processes. These are explicitly intended for IT professionals who will plan, test, and deploy Secure Boot variable updates in their own change control windows.

---

Technical realities and operational gotchas​

The method Microsoft uses to deliver the certificate updates matters: Windows Update installs the new certificates into the active KEK/DB variables in firmware. Active variables can be overwritten or cleared if Secure Boot is toggled off, or if firmware resets defaults. That means an update pushed via Windows Update may not be persistent across a firmware default reset unless the OEM also writes the new certificates into the firmware default variables via a UEFI firmware (BIOS/UEFI) update. Microsoft is coordinating with OEMs to deliver firmware updates that embed the 2023 certificates into default variables, which is the only reliable way to make the change persistent across firmware resets.
Practical consequences:

• If a device’s firmware never receives the 2023 certificates in its defaults, toggling Secure Boot Off → On or resetting firmware to defaults can remove the Windows‑delivered active updates. That would leave the device with only the old 2011 certs (or none), potentially blocking future Secure Boot updates.
• Applying certificate updates without appropriate OEM firmware and driver validation can trigger BitLocker recovery, cause pre‑boot signing mismatches, or in the worst case render a device unbootable if keys or signatures don’t match expected values. Administrators must suspend BitLocker and back up recovery keys before attempting firmware or UEFI variable changes.
• Virtual machines and cloud IaaS: Hypervisors that present UEFI to guests (Hyper‑V, VMware, and cloud platforms) must also update their guest firmware or platform metadata to expose the new CA entries; consult your hypervisor or cloud provider.

Industry commentary and vendor advisories reinforce these points: major OEMs such as Dell have already identified affected server generations and are scheduling firmware updates to add the 2023 certificates into firmware defaults, and third‑party analysis warns that Linux distributions and other non‑Windows boot flows using Microsoft‑signed shims will need to coordinate re‑signing and acceptance of the 2023 CAs.

---

Risk analysis: strengths and weaknesses of Microsoft’s approach​

Strengths​

• Centralized remediation for most devices. Rolling the change through Windows Update and grouping by firmware profile simplifies the majority path and reduces manual effort for most organizations.
• Phased, telemetry‑driven rollout. Microsoft’s plan to group devices and pause rollouts when telemetry indicates a problem is the right risk mitigation approach for a platform‑wide change of this kind.
• Better signing granularity. Separating bootloader signing from option ROM signing (introducing a dedicated Option ROM CA 2023) provides finer trust control and reduces the blast radius when choosing what third‑party pre‑boot code to trust.

Weaknesses and operational risks​

• Firmware dependency. The biggest operational blocker is OEM firmware. If OEMs don’t ship updates for older models (or older server generations are out of service), those devices may require manual intervention or retirement. This is a real problem for long‑lived industrial controllers and some server platforms.
• Telemetry opt‑in friction. Organizations that intentionally restrict telemetry cannot use the Microsoft‑managed path without changing telemetry posture or using the self‑service approach, which increases friction and administrative overhead.
• Potential for boot and recovery failures. Updating Secure Boot variables is not a zero‑risk operation: BitLocker recovery, driver signing mismatches, or broken recovery media can surface if testing and sequencing aren’t tightly controlled.

Given these trade‑offs, the safest posture is to treat the certificate transition as a programmatic change project rather than a single‑patch event: inventory, prioritize, stage, test, and execute.

---

Recommended, pragmatic action plan for IT teams (prioritized)​

The following checklist is a pragmatic, sequenced plan that condenses Microsoft guidance and community best practice into operational steps IT teams can follow now.

• Inventory and classify devices (2–4 weeks)
• Identify endpoints, laptops, desktops, servers, and VMs that use UEFI/Secure Boot. Record OEM, model, firmware/BIOS version, Windows build, and whether Secure Boot is enabled. Use existing CMDB/asset inventory or Intune/ConfigMgr reports.
• Confirm Secure Boot status on representative devices (2 weeks)
• Use System Information (msinfo32 → System Summary → Secure Boot State) or PowerShell: run Confirm‑SecureBootUEFI in an elevated session to return True/False. This verifies whether Secure Boot is enabled and whether the device will accept variable updates.
• Check OEM firmware availability (weeks 1–8)
• Contact OEMs or consult vendor support pages to find firmware updates that add the 2023 certificates into the firmware default variables. Prioritize servers and any systems lacking recent firmware support. Vendors have different timelines; some OEMs have publicly posted plans for affected server generations.
• Prepare recovery posture and test environment (weeks 2–8)
• Rebuild recovery USBs and installation media after vendor updates, and ensure those media are signed/compatible with the new Windows UEFI CA 2023 where necessary. Backup BitLocker recovery keys and suspend BitLocker during firmware changes.
• Pilot certificate updates in a controlled ring (weeks 4–12)
• Create a test group representing major OEM models, firmware versions, and critical apps. Validate boot flows, BitLocker, pre‑boot trusted tools, and recovery scenarios. Use Windows Update, WUfB, or manual MSU installs as needed.
• Decide on Microsoft‑managed opt‑in vs self‑service deployment (weeks 4–12)
• For devices you permit to send required diagnostic data, opt into Microsoft‑managed updates by enabling the required diagnostic data level and/or setting the MicrosoftUpdateManagedOptIn registry value (DWORD 0x5944) via MDM/GPO for scale. For locked environments, assemble a tested manual deployment process.
• Roll out broadly with monitoring and rollback plans (weeks 8–16)
• Deploy in waves, monitoring telemetry and endpoint health. Keep vendor firmware and recovery notes at the ready; be prepared to pull a rollout or isolate a firmware family if problems emerge.
• Special cases: virtualized, Linux, and air‑gapped systems
• Coordinate with cloud and hypervisor vendors for guest firmware updates. For Linux distributions that rely on shims signed by Microsoft, coordinate with distro maintainers and ensure signed binaries are available for the 2023 CA chain. For air‑gapped systems, follow the manual DB/KEK update steps and maintain a secure, auditable process for updating firmware variables.

---

Tactical commands and sample checks​

• Check Secure Boot via System Information: run msinfo32 and look for “Secure Boot State” in System Summary.
• PowerShell check (run elevated): Confirm‑SecureBootUEFI — returns True if Secure Boot is enabled.
• Registry opt‑in (to enable Microsoft‑managed updates): set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\MicrosoftUpdateManagedOptIn (DWORD) = 0x5944 (use Group Policy preferences, PowerShell, or Intune device configuration to set at scale). Set this only after reviewing privacy/telemetry policy.

Example PowerShell to set the registry value (run elevated):

• New‑Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -ErrorAction SilentlyContinue
• Set‑ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "MicrosoftUpdateManagedOptIn" -Value 0x5944 -Type DWord

(Adapt to your change control, test in lab first.)

---

Special considerations and cautions​

• Do not rely on a single method for critical devices. You may need a hybrid strategy: accept Microsoft‑managed rollouts for general‑purpose endpoints while applying manual firmware and DB/KEK changes for isolated or regulated systems.
• Firmware writes are device‑specific. If an OEM does not supply a firmware update that writes the 2023 certs into defaults, the long‑term solution is either coordinated manual management or device replacement. Expect uneven OEM coverage across older consumer and enterprise hardware.
• BitLocker and TPM interaction: changing pre‑boot signing or firmware variables can trigger BitLocker recovery. Suspend BitLocker where appropriate and ensure recovery keys are stored and tested.
• Linux and alternative OS users must track shim and kernel signing changes. Several community and distribution‑level advisories already warn about the compatibility window for shim re‑signing and firmware updates.

Where Microsoft’s public guidance leaves gaps (for example, the exact OEM firmware schedules for every model), treat those items as unverifiable until the OEM publishes an explicit plan and place them into a vendor follow‑up bucket with clear escalation steps. This is especially true for off‑warranty or older hardware where firmware updates may be unavailable.

---

Conclusion — what IT leaders must prioritize now​

The Secure Boot certificate transition is not a distant theoretical issue: the 2011 CA expirations begin in June 2026, and the consequences of inaction include losing the ability to deliver Secure Boot fixes, blocking newly signed boot components, and exposing pre‑boot attack surfaces. The correct organizational response is immediate triage: inventory, test, coordinate with OEMs, and choose the right deployment model for each device class. For many organizations, the fastest path to continuity will be opting into Microsoft’s managed rollout for eligible devices and staging OEM firmware updates for persistence; for others, a carefully governed manual process will be necessary. Either way, plan and test now — treat this as a firmware and deployment program, not a single‑patch event.
This guidance synthesizes Microsoft’s KB guidance and rollout notes together with vendor advisories and community reporting to provide an actionable, security‑first plan for enterprise IT teams managing Windows devices.

---

Source: Microsoft Support Windows devices with IT-managed updates - Microsoft Support