Secure Boot Certificate Expiration 2026: Update to Windows UEFI CA 2023

Microsoft has issued a platform-level warning: the Secure Boot certificates first issued around 2011 that underpin Windows’ pre-boot trust model begin expiring in June 2026, and although most updated systems will continue to boot, devices that do not receive the replacement certificate family will enter a degraded security state that limits future boot‑time protections, firmware updates, and the ability to validate newer boot components. ([support.microsoft.microsoft.com/en-us/help/5062713)

Background​

Secure Boot is a UEFI firmware feature that verifies digital signatures on the earliest pieces of code your PC runs—the boot manager, option ROMs, shim loaders used by Linux distributions, and WinRE (Windows Recovery Environment). This trust model depends on a small set of certificate authorities (CAs) and signing certificates stored in firmware (the UEFI DB/KEK/PK databases). Those Microsoft-supplied certificates, originally provisioned beginning in 2011, were always intended to be rotated when their cryptographic lifetime ended. Microsoft and OEM partners have prepared a 2023 certificate family to replace the 2011 anchors; the coordinated delivery and installation of that new CA family must complete before the 2011 roots begin expiring in mid‑2026.
This change is not a software bug or a sudden exploit; it’s a planned cryptographic lifecycle event with real operational consequences. If a system relies exclusively on the 2011 certificates when those certificates expire, the firmware and OS may refuse to accept new, properly signed pre‑boot components or later boot‑level mitigations—putting the machine into a state where it can still start but cannot be patched at the pre‑OS layer. Microsoft’s guidance and IT blogs make clear this is a calendar‑driven transition and that the most straightforward defense is to receive the new certificates via normal update channels.

---

Why this matters: the practical security and compatibility consequences​

• Loss of future boot‑level updates: Once the 2011 certificate anchors are expired for a given platform, Microsoft cannot push future Secure Boot updates or revocations to that machine unless the 2023 certificates are present. That means newly discovered pre‑OS vulnerabilities could remain unpatched at the firmware/boot level.
• Compatibility problems for signed firmware and option ROMs: Some GPU GOP option ROMs, third‑party EFI drivers, or Linux shim components signed under the old CA may no longer validate unless the new CA is present or OEM firmware is updated. Systems that cannot accept the 2023 CA may refuse certain device firmware at POST or block OS upgrades that rely on the new signing chain.
• Operational risk to servers and air‑gapped devices: Servers, virtual machine images, and isolated or regulated environments that intentionally delay or block Windows Update are particularly vulnerable because the rollout requires coordinated firmware and OS-level changes; these systems may need manual intervention or a different update path.
• User confusion and recovery complexity: Although most PCs will continue to boot, systems that hit firmware corner cases, vendor‑specific UEFI behaviors, or non‑standard boot configurations may need recovery media, firmware reflashes, or professional support to restore a trusted boot state.

---

Which devices face the highest risk​

Not every Windows PC is at equal risk. The highest‑risk categories include:

• Older PCs with firmware that hasn’t been updated in years (BIOS/UEFI vendors that no longer release updates).
• Systems still running unsupported Windows releases that are not receiving Microsoft-managed updates (notably Windows 10 devices that are not enrolled in Extended Security Updates).
• Servers, industrial endpoints, and air‑gapped systems where updates are delayed by policy or operational constraints.
• Virtual machines and nested virtualization hosts where Secure Boot and WinRE updates require special handling; Hyper‑V or cloud images may need separate attention.
• Dual‑boot or Linux systems that rely on Microsoft-signed shim binaries: distributions that expected the old Microsoft key may require updated shims or vendor intervention.

By contrast, most modern consumer laptops and desktops from major OEMs that have kept firmware reasonably current, and systems that receive automatic updates from Microsoft, are likely to get the new 2023 CA family through the standard servicing pipeline before the deadlines. OEMs such as ASUS and Lenovo have published guidance saying the rollout is phased and that many devices will be updated automatically via Windows servicing and coordinated firmware updates.

---

Microsoft’s timeline and what actually changes​

Microsoft’s public guidance (support articles and Windows IT Pro posts) lists the relevant certificates and the calendar for expiration. The key points verified against Microsoft’s guidance and Microsoft’s IT Pro documentation are:

• The original Microsoft UEFI/KEK/DB certificates issued around 2011 begin expiring in June 2026, with a final set following through October 2026 for some boot‑signing production CAs.
• Microsoft produced a replacement family labeled informally as the Windows UEFI/KEK/CA 2023 set; those certificates are being delivered via a combination of Windows cumulative updates (where the OS injects DB entries) and OEM firmware updates for devices that require firmware‑level changes.
• Microsoft has released targeted Dynamic Updates (Safe OS / Setup dynamic updates such as KB5079270 and KB5079271, and Safe OS updates like KB5078169) to enable the certificate transition during Windows feature upgrades or repair environments; administrators should review the update rollouts for their specific OS versions.

These are not speculative dates; Microsoft’s support documentation is explicit about the timing and the replacement CA family. Treat the mid‑2026 window as an operational deadline rather than an abstract advisory.

---

Clear, prioritized actions for home users (what to do today)​

If you use a Windows PC for anything important—work, finances, health records—don’t wait for panic. Follow these steps in order; most are straightforward and safe.

• Install all pending Windows updates now. Restart at least once after updates to ensure any scheduled Secure Boot update tasks can run. This is the single most effective step because Microsoft is delivering the replacement certificates through normal servicing for many devices.
• Check whether Secure Boot is enabled and whether the 2023 CA is present: open PowerShell as Administrator and run Confirm-SecureBootUEFI to confirm Secure Boot is enabled, and then run a quick verification to look for the 2023 certificate:
• Confirm-SecureBootUEFI (returns True/False).
• [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).bytes) -match 'Windows UEFI CA 2023' — if this returns True, the new CA is present. These PowerShell commands are the supported way to confirm the DB contents on Windows systems.
• Check your PC manufacturer’s support site for firmware/BIOS/UEFI updates and apply them if available. Firmware updates are often necessary for the device to accept OS‑initiated DB injections or to persist new KEK/DB values across resets. If the vendor has posted a Secure Boot transition FAQ or an OEM tool to run the update task, follow their guidance.
• For older machines where firmware updates are unavailable, consider one of: upgrading the hardware, enrolling the device in a supported servicing program (see below for ESU), or planning a migration path off that machine for sensitive tasks.
• Create a full backup and a bootable Windows recovery USB now. If you later encounter unexpected boot or firmware behavior, a known good backup and recovery media will shorten downtime and reduce data‑loss risk. This is standard best practice before performing firmware or low‑level security changes.

---

For IT teams and administrators: an operational playbook​

Large organizations need a short, auditable checklist. The consequences scale with fleet size; a single blocked firmware update can be multiplied across thousands of machines.

• Inventory: Use Microsoft’s sample PowerShell scripts and MDM/Intune detection tools to inventory Secure Boot status and whether the Windows UEFI CA 2023 entries exist in each device’s DB. Microsoft published sample reporting outputs and commands specifically for this transition.
• Prioritize high‑risk assets: Servers, air‑gapped systems, test benches, imaging systems, and custom appliances should be highest on the remediation list. These systems are often excluded from normal Windows Update flows and require manual workflows.
• Firmware readiness testing: Validate OEM BIOS updates in lab images before mass deployment. For images used to provision VMs or Cloud PCs, ensure source images are updated to include the 2023 CA entries. Microsoft’s Windows 365 guidance specifically calls out Cloud PC images as needing updates ahead of the expiration.
• Controlled pilot rollout: Start with a pilot containing multiple hardware families. Validate WinRE and Setup behavior (use the Safe OS dynamic updates and test feature upgrade paths KB5079270 / KB5079271). Watch for Event IDs (1795/1808/1802 etc.) that Microsoft documents as indicators of update problems.
• Communication and fallback: Inform helpdesk and desktop support teams about expected user symptoms and recovery steps (how to verify Secure Boot DB, how to apply OEM firmware, how to use recovery USB). Pre‑generate vendor recovery images where possible.

---

How to verify certificate status (practical PowerShell checks)​

Use an elevated PowerShell session (Run as Administrator) and these supported commands. These are the same checks Microsoft recommends and that OEMs reference in their transition guides:

• Confirm if Secure Boot is enabled:
• Confirm-SecureBootUEFI — returns True or False.
• Inspect the DB for the new CA entry:
• [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).bytes) -match 'Windows UEFI CA 2023'
• If the above returns True, the Windows UEFI CA 2023 certificate is present in the active DB. This is the simplest direct verification method.
• Use Get-SecureBootUEFI -Name DB or Get-SecureBootUEFI -Name PK to export individual database blobs if you need to capture evidence for support tickets. Microsoft’s support articles and many OEM pages include sample commands for inventorying and exporting DB contents.

If a PowerShell cmdlet fails with an access error, the firmware may not support OS-initiated key management; in that case the OEM firmware interface (BIOS/UEFI setup) or vendor tools must be used to install the new certs. Lenovo, Dell, and ASUS have documented both the PowerShell checks and OEM‑specific tasks to trigger the update where firmware permits.

---

Windows 10, Extended Security Updates, and the tricky edge cases​

Windows 10 reached its mainstream end of support in October 2025; Microsoft has said that devices running unsupported Windows versions will not automatically receive the Secure Boot certificate refresh unless they are enrolled in the Extended Security Updates (ESU) program or otherwise managed to receive Microsoft-managed updates. That means many Windows 10 systems that stopped receiving updates after end‑of‑support will not get the 2023 certificates unless organizations or consumers have an ESU enrollment or other supported servicing arrangement. If you are a Windows 10 user, verify your update eligibility immediately.
Microsoft and independent outlets have emphasized that the rollout is phased and telemetry‑gated—updates are delivered after Microsoft sees sufficient successful update signals on a hardware class—so device classes that historically show update failures may be slower to receive the 2023 CA via Windows Update. For Windows 10 devices that did not enroll in ESU and are no longer receiving cumulative updates, administrators must treat them as out of scope for automatic certificate injection.

---

Recovery and contingency planning — what to do if a system won’t start​

Microsoft’s documentation and community experience show a range of recovery options that can help restore a machine to a workingthe Windows Recovery Environment (WinRE) and use Startup Repair or restore a previously created system restore point. Microsoft has pushed Safe OS/WinRE updates to ensure recovery images are aware of the new certificate family; keep recovery media updated after installing recent cumulative updates.

• If the system can’t validate a signed boot component because the DB is out of date, a firmware update or a vendor utility that persists the 2023 CA may resolve the problem. That is why OEM firmware releases are critical.
• If a device becomes unbootable because of a vendor-specific UEFI quirk, vendor support and a reflashed firmware image are often the necessary path; maintain contact channels with your OEM for these scenarios.
• Use a bootable image (USB WinPE or recovery drive) that includes the updated WinRE/Boot Manager signed with the 2023 CA where possible; Microsoft’s dynamic updates include WinRE components to help with this.

Before attempting any firmware reflash, back up all data. If you are not comfortable with BIOS updates or recovery procedures, consult vendor support—improper firmware flashing can permanently brick devices.

---

Risks, unknowns, and where to be cautious​

• OEM variability: Firmware implementations of UEFI vary. Some vendors will inject the 2023 DB entries themselves; others rely on Windows to apply DB updates. The availability and persistence of updates depends on firmware design. That means identical hardware families from different OEMs (or different firmware revisions from the same OEM) may behave differently. Treat vendor documentation as authoritative for a given model.
• Timing and telemetry gating: Microsoft is using a staged rollout that checks for healthy update signals; some hardware families may be slower to receive the update. Don’t assume “it will come later” if the device is a server, air‑gapped, or VDI/Cloud image. Plan to test and apply manual remediation where necessary.
• Linux and dual‑boot scenarios: Several Linux distributions and components (shim, signed kernels) rely on Microsoft’s signing infrastructure. Some distros already documented steps they will take, but users who run Linux on Secure Boot systems should verify shim and bootloader chain support for the 2023 CA and follow distro guidance. If your Linux installation depends on a shim signed with the old Microsoft key, it could require maintenance.
• Social engineering and fake updates: As this topic gains attention, expect phishing and scam pages offering “fix utilities” or “one-click updates.” Only use official Microsoft KBs, OEM support pages, and vendor firmware tools. Never run unsigned update utilities from untrusted sources.

---

Monitoring and information sources — what to watch and where to get help​

• Microsoft support documentation is the primary authoritative source for the exact expiry dates, replacement certificate names, and supported remediation steps; check the Secure Boot certificate guidance and the “frequently asked questions” pages for updates.
• The Windows IT Pro blog and Tech Community posts contain operational playbooks and sample PowerShell scripts useful for device inventory and scale deployment planning.
• Major OEM support pages (Lenovo, ASUS, Dell) publish model‑specific guidance and tools; consult them before mass firmware deployments.
• Independent coverage from reputable outlets (Ars Technica, Windows Central, SecurityWeek) provides additional context on likely impacts for consumers and examples of corner cases reported by early adopters. Cross‑reference these stories with Microsoft OEM guidance before acting.

---

Final assessment: how worried should you be?​

• For most home users who keep Windows updated and who buy mainstream branded hardware from major OEMs, the practical risk is manageable: follow the update steps, verify Secure Boot status, and keep firmware current. Most such systems will receive the 2023 certificate family automatically via Windows servicing.
• For organizations, administrators, and power users who manage diverse fleets—especially servers, air‑gapped machines, imaging stations, or specialized workstations—the risk is material and operational. Treat this as a scheduled maintenance event: inventory, pilot, deploy, monitor.
• For unsupported Windows 10 machines not enrolled in ESU, and for older hardware with no firmware updates, the risk is elevated: those devices may not receive the certificates and will lose the ability to receive future boot‑level fixes. Plan migration or ESU enrollment if continued use is essential.

---

Checklist — Immediate to‑do list (copy/paste and follow)​

• Install all pending Windows updates and reboot.
• Run PowerShell (Admin): Confirm-SecureBootUEFI. If True, then run:
  [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).bytes) -match 'Windows UEFI CA 2023' — expect True once the update is applied.
• Check OEM support page for your exact model; apply any firmware updates the vendor publishes.
• Create a full system backup and a bootable recovery USB (updated after recent cumulative updates).
• If you manage a fleet: inventory Secure Boot state via the Microsoft sample scripts or Intune detection scripts; pilot updates on representative models first.

---

Conclusion​

This is a classic example of how long‑lived cryptographic artifacts create systemic operational deadlines: the certificates Microsoft issued a decade and a half ago are simply reaching the end of their intended lifespan. The good news is that Microsoft, major OEMs, and the broader ecosystem prepared a coordinated replacement plan—the Windows UEFI CA 2023 family—and many devices will be updated automatically. The bad news is that a nontrivial set of machines—older hardware, unmanaged endpoints, servers, and unsupported Windows 10 systems—require deliberate attention to avoid a degraded boot security posture after June 2026. Treat the coming months as a maintenance window: inventory, update, test, and back up. If you haven’t looked at your device’s Secure Boot and firmware state in the last 90 days, start now.
End of article.

---

Source: mibolsillo.co https://www.mibolsillo.co/news/warn...-users-should-check-it-out-20260305-0016.html

 

[ChatGPT]

Microsoft and major OEMs are executing a coordinated, time‑bound refresh of the Secure Boot certificate anchors that protect the Windows pre‑boot environment — a change every Windows administrator and power user must treat as an operational deadline, not optional housekeeping. ([support.microsoft.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e)

Background​

UEFI Secure Boot enforces a small set of cryptographic authorities stored in firmware (PK, KEK, DB) to verify signatures for everything that runs before the operating system. Those Microsoft‑issued certificates provisioned around 2011 are scheduled to begin expiring in mid‑2026, and Microsoft has prepared a replacement familced as the Windows UEFI CA 2023 set) to preserve platform trust and updateability.
This is not an abstract advisory. Devices that still rely exclusively on the 2011 certificates after those certificates expire may keep booting, but they can enter a degraded security and update state: Windows and OEMs will not be able to deliver future pre‑boot security updates, WinRE/WinPE component CA may be rejected, and newly signed boot components could fail verification. The coordinated rollout therefore targets both OS‑delivered updates and OEM firmware updates to ensure persistence and broad coverage.

---

What exactly is changing — the technical summary​

• The original Microsoft UEFI certificates (issued circa 2011) have finite cryptographic lifetimes; multiple expirations related to those keys begin in June 2026, with some signing production CAs following through later in 2026.
• Microsoft produced a replacement certificate family — the Windows UEFI CA 2023 set — which is being delivered through a combination of Windows servicing (OS updates, dynamic updates) and coordinated OEM firmware updates for platforms that require firmware‑level key insertion.
• Delivery mechanisms include normal cumulative updates, targeted Setup/Safe OS Dynamic Updates that run during OS upgrade and repair (Microsoft has published specific KBs used in the transition), and firmware updates from vendors where the platform does not support OS‑initiated key management.
• Some device classes — older PCs, servers, air‑gapped systems, unsupported Windows 10 installs not covered by Extended Security Updates (ESU), and certain virtualization host images — are higher risk and may require manual intervention.

---

Why this matters: security, compatibility, and recoverability​

Secure Boot is a foundational platform control. Rotating root and signing certificates is standard industry practice to avoid long‑term cryptographic weaknesses, but the operational surface area is large: firmware implementations vary, enterprise update policies can block the normal delivery paths, and some recovery images or custom drivers may have been signed only against the older 2011 chain.
Key practical impacts:

• Loss of future boot‑level updates: Devices that do not accept the new CA will not receive future Secure Boot updates and re‑OS vulnerabilities unpatchable at the firmware layer.
• Compatibility issues: Boot managers, WinRE/WinPE images, third‑party option ROMs and some Linux shim chains may need re‑signing or updated shims to validate under the 2023 CA.
• Operational risk for servers and air‑gapped devices: Systems that do not receive regular Windows Update telemetry are likely to need manual updates or support from OEMs — this includes many server and regulated endpoint scenarios.
• Recovery complexity: If a firmware corner case prevents OS‑initiated DB updates, you may need vendor tools or a firmware reflash to recover. Keep updated WinRE/USB recovery media available.

---

Verify firmware and device readiness: practical checks​

Before you deploy anything fleet‑wide, test and verify. These are the supported checks recommended for Windows systems.

Quick locShell)​

Run an elevated PowerShell session (Run as Administrator) and use the built‑in Secure Boot cmdlets:

• Confirm Secure Boot is enabled:
• Confirm-SecureBootUEFI — returns True/False.
• Check for the 2023 CA in the active DB:
• [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).bytes) -match 'Windows UEFI CA 2023'

If the script returns True, the 2023 certificate is present in the firmware DB. These checks are the simplest, evideneps Microsoft and OEMs document. If a cmdlet fails with access or permission errors, firmware may not support OS‑initiated key management and an OEM procedure will be required.

Task Scheduler and telemetry checks​

Windows includes a scheduled task that assists the OS in applying the update when firmware permits:

• Task: Microsoft\Windows\PI\Secure-Boot-Update
• Confirm its Last Result (0x0 indicates success). If the task hasn't run or shows an error, further investigation is warranted — a restart (or two) is recommended because the update often requires a reboot cycle to complete.

Event IDs and logs to watch​

Monitor the following Event IDs during pilot testing and deployment; Microsoft documents these as signals of success/failure:

• Event 1801 / Event 1795 (Secure Boot DB/KEK updates) — informative on whether the DB was changed.
• Event 1808 / Event 1802 — used to flag firmware acceptance failures or lack of support.
• Additional Setup/WinRE event codes may appear when Safe OS dynamic updates run during feature upgrades.

---

Monitoring device readiness at scale​

Inventory and monitoring are the most important steps for large fleets. Plan for instrumentation and reporting before rolling anything out.

• Use PowerShell scripts and the Get‑SecureBootUEFI cmdlets to produce per‑device evidence and exportable artifacts (the DB/PK blobs can be exported for ticketing). Microsoft published sample reporting scripts and outputs for this transition; OEMs have echoed those checks.
• In Intune and other MDMs, create a detection policy that queries:
• Confirm-SecureBootUEFI status
• The presence of a DB entry matching 'Windows UEFI CA 2023'
• Task Scheduler status for Mcure-Boot-Update
• For SCCM/ConfigMgr, use the same PowerShell probes as compliance rules, collect results in hardware inventory, and build query-based collections to prioritize remediation.
• Prioritize and tag high‑risk assets: servers, imaging stations, dedicated lab/test hardware, air‑gapped endpoints, and VM images used to provision Cloud PCs or virtualized services. Microsoft specifically calls out Cloud PC/Windows 365 and server images as requiring early attention.

---

Deployment options and recommended playbook​

Treat the rollout as a controlled maintenance operation. The broad strategy is: Inventory → Pilot → Firmware readiness testing → Phased deployment → Monitor & remediate.

1) Inventory and classification (Day 0–7)​

• Build an inventory of Secure Boot‑enabled devices and record:
• Firmware vendor/model/version
• Secure Boot status (Enabled/Disabled)
• Presence of Windows UEFI CA 2023
• Update channel and last update date
• Flag unsupported Windows 10 devices not on ESU and any systems that do not receive updates automatically.

2) Pilot (Day 7–21)​

• Pick a representative pilot across firmware families (Dell, Lenovo, ASUS, vendor OEMs) and device classes (laptops, desktops, servers, Cloud PC images).
• Validate:
• PowerShell DB checks
• Task Scheduler runs and results
• WinRE / Setup dynamic update behavior (test the specific Setup Dynamic Update packages Microsoft published for staged transitions).

3) Firmware testing and OEM coordination​

• Where firmware does not accept OS‑initiated DB injections, coordinate with OEMs to deploy firmware updates that inject the 2023 CA into firmware DB. OEMs are publishing model‑specific guidance; some vendors include tools or BIOS settings to persist DB changes.
• Test updated WinPE/WinRE images signed under the 2023 CA and ensure recovery media used for imaging or recovery is rebuilt with updated components.

4) Phased rollout and automation​

• Use Intune or SCCM to distribute steps that require no firmware change (Windows dynamic updates, Safe OS updates).
• For devices requiring firmware intervention, schedule vendor BIOS/UEFI updates during maintenanc a rollback path.
• Use compliance collections to iterate on remediation and move families through the gating telemetry.

5) Ongoing monitoring & fallbacks​

• Continue to watch the scheduled task results and Event IDs.
• Maintain updated recovery images and tooling for manual DB injection where necessary.
• Communicate with helpdesk and frontline support; provide runbooks and checklists for common failure modes.

---

How to deploy updated certificates: specific tools and packages​

Microsoft is using a combination of servicing technologies. Know the key pieces:

• Windows cDynamic Updates — Microsoft has targeted Safe OS and Setup Dynamic Updates (example KBs surfaced by Microsoft during the rollout) that update boot manager/WinRE during upgrade/repair flows. These are how many client devices get the new CA without firmware changes.
• OEM firmware packages — where firmware restricts OS-initiated DB writes, vendors will ship BIOS/UEFI updates that inject the 2023 CA persistently. Check OEM support advisories for model‑specific instructions. ([lenovopress.lenovo.com](Updating Windows Boot Manager and WinPE with the Windows UEFI CA 2023 Certificate firmware key management — some enterprise platforms support vendor tools for persistent DB changes; others require manual entry via UEFI specific.

Note: For Windows Server, Microsoft published server‑specific guidance to help administrators prepare images and hosts; server servicing behaves differently and often requires manual orchestration.

---

Troubleshooting: common failure modes and recovery steps​

If a device fails to accept or persist the 2023 CA, or you see unexpected boot behaviour, follow a structured remediation approach:

• Verify the issue with the supported PowerShell checks and examine Task Scheduler and Event Log entries. Use Confirm-SecureBootUEFI and export DB blobs for evidence.
• Check the firmware vendor and current UEFI/BIOS version. If an OEM update is available that injects the 2023 CA, apply it in a controlled window.
• If firmware refuses OS-initiated writes (cmdlets return access denied or a mismatch), use vendor tools or the firmware setup UI to add the certificate where supported.
• If a device becomes unbootable or shows persistent boot errors after attempted updates:
• Boot to updated WinRE/WinPE media signed (or rebuilt) with the 2023 CA when possible.
• Use Startup Repair or known working system images.
• If firmware corruption is suspected, coordinate with vendor support for a reflash — warn technicians that improper flashing can brick devices.
• Maintain rollback images and documented recovery playbooks. Test recovery steps in your lab before attempting them on production endpoints.

---

Linux and dual‑boot considerations​

This transition affects non‑ely on Microsoft‑signed shims and keys (common in many Linux distributions). Distributions and the shim project are tracking the change; some distros will publish updated shims or guidance to preserve boot compatibA.

• If you run dual‑boot or Linux images in your estate, validate that the shim and other EFI binaries used by your distro are compatible with the new CA and test the entire boot flow after the update.
• For VMs and nested virtualization, check the hypervisor/OVMF images — these may need updates to include the 2023 CA to allo Boot without host-side modifications.

---

Special cases: servers, Cloud PC images, air‑gapped systems​

• Servers: Microsoft’s Windows Server guidance emphasizes planning and manual orchestration; servers are not automatically guaranteed to receive the same telemetry‑gated rollouts as date boot images, pre‑boot recovery media, and test feature upgrade flows that exercise Safe OS dynamic updatetps://www.microsoft.com/en-us/windows-server/blog/2026/02/23/prepare-your-servers-for-secure-boot-certificate-updates/)
• Cloud PC / Windows 365: Cloud PC images and provisioning flows must be updated ahead of expiration. Microsoft’s Cloud PC guidance calls out managed images and provisioning behaviors that need icrosoft.com]
• Air‑gapped / regulated systems: These endpoints require a manual refresh path. Options include rebuilding recovery images signed for the new CA, working with OEM firmware teams to inject keys, or, in the worst case, platform replacement or ESU enrollment where available.

---

Communication, policy and staffing​

• Update your change calendar and treat this like any major cryptographic or firmware maintenance event windows, staging, and verification gates.
• Train helpdesk staff with short runbooks: how to run the PowerShell checks, how to interpret key Event IDs, and how to perform safe BIOS updates with vendor instructions.
• Prepare customer‑facing communications that explain potential symptoms (e.g., repeated restart loops, WinRE prompting) and the actions being taken to avoid unnecessary escalations.
• Beware of third‑party “one‑click” fixes and phins attention; use only Microsoft KBs and OEM support tools.

---

Step‑by‑step quick checklists​

For home users and single‑device admins​

• Install all pending Windows updates and restart the mactechcommunity.microsoft.com]
• Run PowerShell (Admin): Confirm-SecureBthe DB match for 'Windows UEFI CA 2023'.
• Open Task Scheduler → Microsoft → Windows → PI → Secure-Boot-Update and confirm recent successful runs.
• If the new CA is absent and no Windows update fixes it, check the OEM support site for firmware updates and follow vendor instructions.

For IT teams and enterprise​

• Inventory Secure Boot status and certificate presence across the estate via Intune, ConfigMgr, or PowerShell reporting.
• Pilot on representative hardware families — include servers and Cloud PCE and Setup flows with Microsoft’s Safe OS Dynamic Updates.
• Coordinate OEM firmware updates for models‑level injections. Maintain vendor contacts and test recovery images before mass deployment.
• Roll out in waves, monitor Event IDs and Task Scheduler outcomes, and prepare manual remediation teams for target families that remain non‑compliant.

---

Known unknowns and where to be cautious​

• The rollout is telemetry‑gated for many hardware families: Microsoft stages updates based on signals of successful installs. Don’t assume a later arrival; proactively test high‑risk systems.
• OEM firmware variability is real. The exact persistence model ffers by vendor and firmware version. Treat vendor documentation as authoritative for each model.
• Some edge cases reported in community threads show older or non‑standard firmware rejecting updates; those machines may need vendor engagement or hardware replacement. Flag and track those units early.
• If you run software signed only with the 2011 chain (rare but possible for custom boot components), re‑signing or vendor updates may be required. Test all imaging and provisioning artifacts used in your estate.

---

Final assessment and practical takeaways​

This certificate rotation is significant but manageable with the right discipline:

• For most consumer devices from active OEM lines that receive Windows Update, the update path is automatic and low‑effort: apply updates, reboot, run the simple PowerShell checks, and you’re likely done.
• For enterprises and administrators: treat this as a scheduled maintenance event. Inventory, pilot, test recovery media, coordinate firmware updates with OEMs, and prepare targeted remediation for servers, air‑gapped machines, unsupported Windows 10 devices, and custom imaging systems.
• If you encounter devices that do not accept the 2023 CA, collect evidence (export DB blobs, Task Scheduler results, Event Log entries), escalate to vendor support, and follow vendor recovery steps.

Microsoft and OEMs have published detailed guidance and are actively assisting customers — follow the official update packages and vendor advisories rather than ad hoc fixes. This coordinated certificate refresh preserves Secure Boot’s value as a pre‑OS security control; act deliberately and early to keep your fleet secure and serviceable.
Conclusion
Secure Boot certificate rotation is a platform‑level maintenance item with real operational consequences if ignored. Prioritize inventory and pilot testing now, coordinate firmware readiness with OEMs, verify the presence of the Windows UEFI CA 2023 on representative hardware, and bake remediation and recovery runbooks into your maintenance plans. Doing this work ahead of the mid‑2026 expirations will keep pre‑boot protections intact and avoid last‑minute disruption.

---

Source: Microsoft - Message Center Secure Boot certificate updates explained - Microsoft Technical Takeoff