Windows 11 Secure Boot Certificate Update: Microsoft’s Phased Auto Rollout

Microsoft has started an automated, phased replacement of expiring Secure Boot certificates on eligible Windows 11 systems, a preventative move to avoid widespread boot‑level serviceability and security loss when long‑running Microsoft certificates issued circa 2011 begin to expire in mid‑2026.

Background / Overview​

UEFI Secure Boot enforces a firmware‑anchored chain of trust that prevents unsigned or tampered pre‑OS code (bootloaders, shim, option ROMs) from executing during system startup. The mechanism relies on a small set of certificate authorities (CAs) stored in firmware variables — PK, KEK, DB and DBX — to validate signatures before code runs. Microsoft and many OEMs historically shipped the same Microsoft CA entries into those firmware variables. Those original Microsoft CAs (commonly identified as the Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, and Microsoft UEFI CA 2011) are scheduled to begin expiring in June 2026 (with the final Windows boot‑signing PCA expiring later in October 2026). If devices still rely on those 2011 entries when they lapse, they will be unable to accept future Secure Boot updates or validate newly signed boot components — a practical loss of boot security and updateability. To avoid that outcome Microsoft and OEM partners prepared a replacement family of certificates issued in 2023 (for example: Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, and Microsoft Corporation KEK 2K CA 2023) and designed a conservative, OS‑side servicing flow to enroll those certs into firmware variables and swap the Windows boot manager to a binary signed under the new PCA — but only after verifying device readiness.

What Microsoft announced and how it’s delivering the fix​

Starting with the January 13, 2026 cumulative updates, Windows quality updates include device‑targeting metadata and servicing logic to begin an automated, phased rollout of the 2023 certificate set to eligible Windows devices. The packaged update is delivered via normal Windows Update channels; Microsoft will only attempt automatic enrollment on devices that demonstrate “sufficient successful update signals” (a telemetry/health gating Microsoft calls high‑confidence), reducing the likelihood of mass disruption. Key points Microsoft made public:

• The new certificate payloads are included in monthly cumulative updates and OS servicing flows.
• Automatic delivery is controlled and telemetry‑gated — Microsoft will not blindly update every device.
• Administrators retain multiple manual deployment options (registry, Group Policy, Windows Configuration System/WinCS, Intune) if they prefer or require direct control.

These facts are documented in Microsoft’s KB and Secure Boot guidance pages and summarized by independent outlets reporting on the January updates.

---

Technical mechanics: how the OS‑side rollout works​

The OS‑side flow is deliberately order‑sensitive to avoid leaving a device with an untrusted boot manager. The high‑level sequence is:

• 1) Add the Windows UEFI CA 2023 to the firmware DB.
• 2) If the old Microsoft UEFI CA 2011 is present, add Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 to DB (these split previous roles to allow finer policy control).
• 3) Add the Microsoft Corporation KEK 2K CA 2023 to KEK (this step often requires OEM‑signed KEK material; firmware cooperation is necessary).
• 4) Replace the Windows boot manager with a version signed under the Windows UEFI CA 2023. This requires a restart and completes the trust hand‑off.

A scheduled servicing task on each endpoint inspects registry triggers and processes these steps in sequence. Event log entries and registry values (for example, UEFICA2023Status, UEFICA2023Error, and the AvailableUpdates bitmask) provide per‑device instrumentation to track progress and troubleshoot failures.

Registry control and enterprise deployment knobs​

Microsoft published supported registry keys that organizations can use when they want to manage rollouts centrally:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates — a REG_DWORD bitmask that triggers update actions (enterprise guidance commonly uses the value 0x5944 to request the full deployment).
• UEFICA2023Status / UEFICA2023Error — status and error reporting for the per‑device flow.
• HighConfidenceOptOut and MicrosoftUpdateManagedOptIn — flags to opt out of Microsoft’s high‑confidence automated buckets or to opt in to Microsoft‑managed assistance (which requires diagnostic data).

The Microsoft guidance explains the recommended pattern: inventory and pilot devices, apply firmware updates where OEMs require them, then stage OS‑side deployments using the registry/GPO/WinCS or allow Microsoft’s controlled rollout for high‑confidence devices.

---

Who is affected (and who is not)​

• A large portion of Windows devices manufactured since roughly 2012 may contain the expiring 2011 certificates in firmware and therefore are potentially affected if not updated before June–October 2026.
• Devices that regularly receive OEM firmware updates and keep Windows Update enabled are the most likely to be updated automatically and without incident.
• High‑risk groups include air‑gapped systems, devices with telemetry disabled or blocked, unsupported legacy hardware where OEMs no longer provide firmware updates, and some virtualized guests on hypervisors whose virtual firmware cannot be modified from inside the guest.

Microsoft’s own FAQ stresses that the company’s managed assist is helpful but not guaranteed for all configurations; administrators are ultimately responsible for ensuring their fleets transition before the expiry windows.

---

Operational impact and realistic worst‑case scenarios​

The practical outcomes if devices fail to transition before the 2011 CAs expire:

• Loss of the ability to install future Secure Boot updates for pre‑boot components on the affected device. This prevents Microsoft from delivering fixes to Windows Boot Manager and other pre‑OS code.
• Devices may refuse to trust new boot manager binaries or other components signed under the new CA if firmware lacks the 2023 entries, producing boot or compatibility errors for updated components.
• In constrained scenarios (locked firmware, missing OEM KEK updates, certain VM platforms), remediation may require OEM firmware updates, online OEM intervention, or, in the worst case, hardware replacement.

Important nuance: sensational headlines about “millions of bricked PCs” are overbroad. For the majority of consumer devices that keep updates and firmware current, the transition should be seamless. However, the deadline nature of certificate expiry and the diversity of OEM firmware behavior mean there are non‑trivial operational risks for certain fleets — especially those with locked down update policies or unsupported hardware. Treat those claims as conditional and require device‑level verification.

---

Cross‑platform and virtual‑environment effects​

• Many Linux distributions rely on a Microsoft‑signed shim to maintain Secure Boot compatibility. The transition impacts the signing chain for those shims: if a platform’s firmware doesn’t include the new Microsoft UEFI CA 2023 entries, newly signed Linux shim/GRUB binaries may not be trusted. Linux distributors have been tracking this transition and recommending dual‑signing or other mitigations.
• Virtual machines running on hypervisors sometimes expose a virtual UEFI firmware that must be updated by the hypervisor vendor. Several virtualization setups (notably older ESXi versions or locked VM firmware settings) have reported inability to update KEK from inside the guest, requiring host‑level action or special VM options. Microsoft Tech Community threads and vendor advisories document these VM caveats.

---

Practical, prioritized checklist for administrators (step‑by‑step)​

• Inventory: identify Secure Boot‑enabled devices and collect firmware versions and OEM model identifiers. Use Confirm‑SecureBootUEFI in PowerShell and Microsoft’s inventory scripts for scale.
• Check OEM guidance: consult OEM advisories (HP, Dell, Lenovo, Surface guidance) for per‑model minimum BIOS versions and apply firmware updates where required before OS‑side certificate enrollment.
• Pilot: pick representative models and test the full flow (registry trigger → DB/KEK updates → boot manager swap). Monitor UEFICA2023Status, UEFICA2023Error and event log IDs for success/failure.
• Decide deployment mechanism:
• Use the registry/GPO/WinCS approach to push 0x5944 to AvailableUpdates for controlled, self‑managed deployments.
• Or enroll devices in Microsoft’s Controlled Feature Rollout (CFR) and ensure required diagnostic data is allowed to leverage Microsoft’s high‑confidence assist.
• Stage rollouts in waves with BitLocker recovery and image rollback plans in place. Validate WinRE and recovery media on pilot devices.
• Track exceptions: build a list of devices that fail KEK updates or report firmware rejection; escalate to OEMs for firmware patches or document replacement plans for unsupported hardware.

Short, practical commands and checks:

• Confirm‑SecureBootUEFI (PowerShell) — returns True if Secure Boot is enabled.
• Inspect registry keys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023Status and UEFICA2023Error.
• Event logs: monitor platform Secure Boot event IDs Microsoft published for success/failure telemetry.

---

Risks, trade‑offs and what can go wrong​

Strengths of Microsoft’s approach:

• The phased, telemetry‑gated rollout mitigates the chance of a mass failure by only targeting devices that show strong update success signals.
• The ordered servicing flow (DB → KEK → boot manager) prevents a device from having a new boot manager without the firmware trusting its signer.

Primary risks and operational friction:

• Firmware variability: different OEMs and models implement UEFI variable handling differently. Some devices require OEM‑signed KEK changes and cannot be updated purely from the OS.
• Telemetry and permissions: Microsoft’s high‑confidence bucket requires diagnostic data; organizations with strict telemetry policies may be opted out of Microsoft‑managed assists and must run manual deployments.
• Virtual machines: many hypervisor/host combinations block or complicate KEK updates from within guest OSes; host or hypervisor updates may be required.
• Recovery/compatibility: improper sequencing of DBX revocations or missing dual‑signing for third‑party boot components could break recovery media or older boot scenarios; DBX revocations can be effectively irreversible on some firmwares. Treat DBX changes with extreme caution.

Unverifiable or exaggerated claims: some third‑party commentary has speculated on very large‑scale bricking scenarios. While those worst‑case outcomes are theoretically possible on unsupported or locked devices, they are not the default outcome and depend on specific firmware limitations or incorrect sequencing. Treat such claims as conditional and require device‑level evidence before assuming broad impact.

---

Guidance for home users and small businesses​

• Keep Windows Update enabled and install the January 2026 (and later) cumulative updates relevant to your build to receive the servicing logic and payload.
• Check your OEM support page for firmware updates and apply them per vendor instructions; for branded laptops/desktops this is often the fastest path to a successful transition.
• Verify Secure Boot is enabled: Settings > Privacy & Security > Windows Security > Device Security will show Secure Boot state. Use Confirm‑SecureBootUEFI for an exact verification.
• If you are not comfortable managing firmware or registry changes, rely on automatic Windows Update behavior; for most consumer devices that stay current this is sufficient.

---

What to watch for in the weeks ahead​

• OEM firmware advisories listing affected platforms and minimum BIOS versions (HP, Dell, Lenovo, Microsoft Surface pages are primary sources). Confirm those lists for any device in your estate.
• Event log and registry changes as pilot deployments run — track UEFICA2023Status and UEFICA2023Error to catch early failures.
• Microsoft KB and support pages for any change in the expiry windows or updated deployment mechanics; Microsoft has already published a Secure Boot FAQ and playbook for IT teams.

---

Final analysis and recommended posture​

This certificate refresh is an unusual but necessary platform‑level maintenance event. It is not a simple “patch,” it is a renewal of cryptographic trust anchors that underpin UEFI Secure Boot and the ability to deliver future pre‑boot security fixes. Microsoft’s approach — packaged certificate payloads, ordered servicing, telemetry gating and a combination of automated and manual deployment methods — prioritizes safety and minimizes blast radius while recognizing the platform dependencies on OEM firmware.
Actionable priorities:

• Treat this as a high‑priority, time‑sensitive operational project for any managed fleet. Inventory, pilot, and schedule firmware updates now.
• For unmanaged or consumer devices, ensure Windows Update and OEM firmware updates are applied; most current systems will likely transition automatically if kept current.
• For air‑gapped, regulated, or telemetry‑off environments, design manual remediation workflows using Microsoft’s documented registry/GPO/WinCS methods and confirm OEM cooperation where KEK updates are required.

This is a coordinated ecosystem task — Microsoft, OEMs, virtualization vendors and third‑party OS maintainers all have roles to play. The technical details and tooling are published; the remaining work falls to device owners and IT teams to inventory, pilot, and act before the June–October 2026 expiry windows to preserve Secure Boot protections and serviceability.

---

Source: SC Media Microsoft automates Secure Boot certificate updates for Windows 11

 

[ChatGPT]

Microsoft has quietly begun rolling out replacement Secure Boot certificates to Windows PCs to prevent a calendar-driven failure when long‑running Microsoft UEFI certificates issued in 2011 begin to expire this June; the changes are being delivered through January 2026 cumulative updates (including KB5074109) and coordinated OEM firmware updates so systems keep trusting boot components and anti‑cheat systems that rely on Secure Boot.

Background / Overview​

Secure Boot is a firmware‑level trust gate in modern PCs that enforces a cryptographic chain of trust during system startup. It uses several on‑device stores to manage trust:

• PK (Platform Key): owner/operator control of platform keys.
• KEK (Key Exchange Key): authorizes changes to the signature databases.
• DB (Allowed Signature Database): lists trusted signers for boot components.
• DBX (Forbidden/Revoked Signature Database): lists signatures to block.

Certificates acting as Certificate Authorities (CAs) live in those stores and expire after a fixed validity period. Microsoft’s widely deployed Microsoft-issued CAs from 2011 are scheduled to start expiring in June 2026 (with a related Microsoft Windows Production PCA expiring in October 2026). Microsoft and OEMs have prepared a replacement set — the 2023 CA family — and have started delivering those to eligible devices via Windows updates and firmware packages. Why this matters: when firmware no longer contains an appropriate, valid CA entry, that platform can stop trusting or be unable to update boot components signed under the new chains. Practically, that breaks the ability to receive Secure Boot‑level security fixes and may block new, properly signed bootloaders or pre‑boot binaries — a material operational and security risk if not addressed ahead of the expiry window.

---

What Microsoft and OEMs are doing now​

Microsoft’s January 2026 cumulative updates include logic to identify devices eligible for OS‑driven certificate enrollment and a controlled, telemetry‑gated rollout of the 2023 certificates. The update KB5074109 and companion servicing packages introduce device‑targeting metadata and the scheduled task that writes certificates into UEFI variables on supported platforms once readiness checks pass. OEMs are participating by:

• Shipping firmware (BIOS/UEFI) updates that accept OS‑driven DB/KEK writes where necessary.
• Publishing per‑model guidance listing minimum BIOS revisions required to accept the new certificates.
• Updating recovery images and provisioning pipelines to avoid surprising failures on recovery media.

Large vendors (Dell, HP, Lenovo, Microsoft Surface, etc. have already published advisory pages and platform lists documenting exact dates and any minimum firmware required — these vendor pages confirm the June/October 2026 window and give administrators the model‑level data needed to plan firmware sequencing. Microsoft’s approach is deliberately phased: only devices that demonstrate successful update telemetry and firmware readiness will receive the new CA entries automatically. This telemetry gating is intended to reduce the risk of mass regressions while the ecosystem coordinates firmware and OS changes.

---

The exact certificate targets and expiry dates​

Microsoft’s published breakdown identifies the expiring 2011 certificates and their 2023 replacements. Precise expiry dates vary slightly by documentation and vendor notices (OEM pages sometimes list a specific day), but the canonical grouping is:

• Microsoft Corporation KEK CA 2011 — expires June 2026 → replacement Microsoft Corporation KEK 2K CA 2023.
• Microsoft Corporation UEFI CA 2011 — expires June 2026 → replacements Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 (splitting previous roles).
• Microsoft Windows Production PCA 2011 — expires October 2026 → replacement Windows UEFI CA 2023 (used to sign Windows boot manager).

OEM advisories sometimes list precise calendar days (for example, HP lists specific June 25/28 and October 20, 2026 entries for particular certs), so administrators should check vendor guidance for model‑level day numbers when scheduling work. Those day‑level differences do not change the operational reality: the transition window is mid‑2026 and must be handled before expiry.

---

How to check whether your PC already has the 2023 certificates (practical steps)​

For most users the simplest answer is: keep Windows Update enabled and install updates. Microsoft intends the automated rollout to reach most devices that allow OS‑driven UEFI writes and report standard update telemetry. That said, you can check and, when necessary, manually trigger processes to enroll and verify the 2023 CA entries.

• Open an elevated PowerShell (Run as Administrator).
• To check whether your firmware DB includes the Windows UEFI CA 2023, run:
  [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
  If it returns True, the DB entry exists. If it returns False, the certificate is not present yet.
• To trigger the OS‑side Secure Boot DB update task (if your device has the necessary updates), run as administrator:
  Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
  Optionally set the registry flag that indicates AvailableUpdates so the scheduled task knows which action to take:
  reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
  Reboot twice after running the task to allow the DB update to complete. Then re‑run the verification string above.
• If updates fail to apply, check OEM firmware updates and vendor guidance. Some platforms require a firmware update before the OS can write new DB/KEK entries; other platforms allow OS‑driven enrollment. The vendor support pages list affected models and minimum BIOS versions.

If you maintain images or offline media, inject the updated Safe OS dynamic update or updated installer/WinRE images into your golden images so recovery media and provisioning pipelines do not reintroduce old signatures. This is explicitly recommended for imaging teams.

---

Why gamers are watching this closely (anti‑cheat, Steam Deck, Linux)​

Secure Boot is not just a corporate security checkbox — it is being used as a gating requirement by modern anti‑cheat systems and some major PC titles. Anti‑cheat tools such as EA’s Javelin, Epic’s Easy Anti‑Cheat, Activision’s Ricochet, and Riot’s Vanguard perform pre‑boot and kernel‑level checks that rely on a platform’s boot integrity; several publishers have announced or begun requiring Secure Boot and TPM 2.0 for upcoming titles and seasons. That makes a functioning Secure Boot chain essential for players who want those titles to launch. Practical ramifications:

• Consolation for many Windows users: if you already have the 2023 CA entries, the update is transparent and you should not see any game breakage.
• For Steam Deck and many Linux setups, the move can be disruptive: a number of Linux configurations and the Steam Deck depend on shim/bootloader signing — if firmware lacks the new CAs or if bootloaders are not signed with the new 2023 CA (or dual‑signed), those systems may fail Secure Boot validation. This is a major reason some Linux users fear loss of compatibility with titles that enforce Secure Boot.
• There are real, reported user problems with anti‑cheat messages stating “This version of Vanguard requires Secure Boot” or similar errors even when users believe Secure Boot is enabled; these are often resolved by firmware updates, re‑applying Secure Boot keys, or updating the anti‑cheat/shim chain, but they demonstrate how delicate interactions at boot time can be. Riot’s own support guidance recommends switching to UEFI and enabling Secure Boot as first steps.

Game studios argue Secure Boot reduces kernel‑level attacks or cheating vectors and enables more robust anti‑cheat enforcement at boot. Opponents point to the fragility of the ecosystem, documented cases of system instability linked to anti‑cheat drivers, and the fact that hardware‑level requirements exclude alternative OS platforms and many handhelds unless compatibility engineering is done. Both positions have merit: the security improvements are real, and the transitional complexity is also real.

---

Risks, edge cases, and what can still go wrong​

This migration is large and touches firmware, OS servicing, recovery images, and third‑party boot components. These are the most credible failure modes:

• Firmware that blocks OS writes to KEK/DB: Older or locked firmware may refuse OS‑driven updates, forcing a manual OEM firmware update path; if OEM updates are unavailable for some models, those devices risk not receiving the 2023 CAs.
• Air‑gapped or telemetry‑restricted fleets: Microsoft’s automated rollout is telemetry‑gated; if telemetry is restricted (e.g., strict privacy configurations) rollout may not select those devices, requiring administrator action.
• Imaging pipelines and offline media: Recovery and installation media that were created before the CA rollover may still contain old signatures; administrators must inject updated Safe OS dynamic updates into golden images.
• Dual‑boot and custom Linux setups: If shim and bootloader binaries are not built/signed to accommodate the new CA chain, a machine may fail to boot when the vendor revokes the old PCA via DBX entries in the enforcement phase. Linux distributions and shim maintainers have been preparing dual‑signing or updated signer flows but not every custom setup will be ready.
• OEM rollout bugs and per‑model surprises: Some vendor community reports show devices where the scheduled task runs correctly but the CA 2023 is not written; when that happens, troubleshooting includes firmware updates, OEM guidance, and escalations to vendor support. One HP community thread documented CA 2023 failing to be applied on specific EliteDesk hardware despite the Secure‑Boot‑Update scheduled task running.

Sensational headlines about “millions of bricked PCs” overstate the likely outcome. The realistic failure is narrower: devices that both lack the new 2023 CAs and cannot accept the OS‑driven update (because of firmware restrictions and lack of OEM firmware) could lose the ability to receive further Secure Boot updates or trust new signatures — an operational failure that can be serious but is not the same as “instant universal bricking.” Administrators should treat the risk seriously and act; do not treat sensational reporting as an accurate technical prognosis without model‑level evidence.

---

Step‑by‑step checklist (home users and IT teams)​

Follow these prioritized steps to reduce your risk and verify your devices:

• Install Windows updates now — make sure your Windows device has the January 2026 cumulative update relevant to your build (these updates include the device‑targeting metadata and servicing logic).
• Check Secure Boot state: Open msinfo32 and confirm Secure Boot State is On and BIOS Mode is UEFI. If not, take appropriate steps to convert partitions to GPT and enable UEFI/Secure Boot according to your motherboard vendor.
• Run the PowerShell CA check (see section above) to validate presence of Windows UEFI CA 2023.
• Trigger the scheduled task if the CA is missing (Start‑ScheduledTask "\Microsoft\Windows\PI\Secure‑Boot‑Update") and set the registry flag if instructed by OEM or Microsoft guidance. Reboot twice and re‑check.
• Update firmware: consult OEM advisories and apply any BIOS/UEFI updates that list support for the 2023 CA set. Apply firmware updates before attempting the DB enrollment when OEM guidance recommends it.
• Update recovery media and images: inject the Safe OS dynamic update (catalog package) into your golden images and offline WinRE/installer images used for provisioning.
• Back up BitLocker recovery keys and store them securely before making firmware or Secure Boot changes. Reprovisioning keys is far easier with a known backup.
• Pilot and test: roll the change out to a small test ring that represents your hardware diversity (consumer laptops, desktops, VMs, devices with legacy peripherals) before broad deployment.
• Document and monitor: review the Windows event logs and the Secure‑Boot‑Update task logs for Event IDs related to DB updates; monitor helpdesk tickets closely during the rollout window.
• Plan an exception process: identify any unsupported hardware and create a remediation plan — firmware replacement, hardware refresh, or an isolated security posture for devices that cannot be updated.

---

Critical analysis — strengths, weaknesses, and recommendations​

Strengths

• Proactive hardening: Replacing exhausted cryptographic anchors before expiry is the correct, security‑first move to prevent a future in which boot components can’t be updated. The multi‑step mitigations also stop older vulnerable boot managers from being trusted.
• Phased, telemetry‑gated rollout: Microsoft’s phased enrollment reduces the blast radius and allows OEMs and admins to pilot and validate changes before mass enforcement.
• Tooling and playbooks: Microsoft and vendors published PowerShell checks, scheduled‑task controls, and an IT playbook for managed environments — useful operational artifacts for admins.

Weaknesses and risks

• Ecosystem complexity: The rollout depends on multiple independent actors (Microsoft, OEM firmware teams, anti‑cheat vendors, Linux distro maintainers). Coordination problems can leave corner cases unaddressed.
• Telemetry gating and privacy policies: Some organizations’ privacy/telemetry stances could block Microsoft’s automated path and inadvertently delay certificate enrollment, forcing manual intervention at scale.
• Game/anti‑cheat friction: Forced Secure Boot and TPM requirements for games increase the operational burden on gamers and can exclude alternative OS platforms, raising legitimate compatibility concerns. Publishers and platform owners must balance security with customer choice.

Recommendations

• For Microsoft: publish even more granular device readiness telemetry and clearer per‑model guidance that OEMs can copy into their advisories; improve tooling for offline image injection to reduce friction for imaging teams.
• For OEMs: make clear minimum BIOS revisions and utilities to help home users apply firmware safely, and flag unsupported models that will not receive updates.
• For game publishers / anti‑cheat vendors: provide fallback modes or clearer troubleshooting flows for players running alternative OSes or older firmware; dual‑signing and compatibility testing should be prioritized.

Unverifiable or fluid claims (flagged)

• The exact enforcement start date for revoking the old PCA (the step where Microsoft adds the Windows Production PCA 2011 to the DBX in firmware programmatically) is not a fixed calendar date publically committed beyond the guidance that the Enforcement Phase “will not begin before January 2026” and that Microsoft will provide at least six months’ warning. Treat any article claiming a precise enforcement start date as speculative unless it cites a Microsoft update posted within official KBs. Administrators should watch Microsoft support announcements for the definitive enforcement schedule.

---

Final takeaways​

• Action is required but manageable. For the majority of Windows users who keep Windows Update enabled and apply OEM firmware updates as recommended, the transition to 2023 CAs should be transparent.
• Check now, don’t wait. Run the PowerShell verification, apply January 2026 (or later) cumulative updates, and install OEM firmware updates where indicated. Back up BitLocker keys and test recovery workflows.
• Gamers and dual‑boot users should pay attention. Anti‑cheat requirements and shim signing changes mean some gaming and Linux workflows will need updates; publishers and distro maintainers are already working on compatibility, but not every configuration is covered by default.

This transition is a rare, deadline‑driven, platform‑level maintenance event. The technical toolkit and vendor guidance are in place; the responsibility now sits with administrators, OEMs, and users to inventory, pilot, and apply updates in an orderly way so systems remain secure and bootable as the 2011‑era certificates lapse.

---

Source: PC Gamer Windows is updating Secure Boot before certificates expire this June and break it

 

[ChatGPT]

Microsoft is quietly rolling a coordinated replacement of long‑lived Secure Boot certificates into Windows and firmware now — because several Microsoft UEFI certificates issued in 2011 begin expiring in mid‑2026 — and PC gamers should treat this as a high‑priority maintenance event that touches anti‑cheat integrity, dual‑boot setups, virtual machines, and recovery media.

Background / Overview​

Secure Boot is a UEFI firmware feature that enforces a cryptographic chain of trust at every system start. It uses on‑device stores (PK, KEK, DB and DBX) to hold X.509 certificate authorities and signature hashes that tell firmware which pre‑OS components to allow or block. Those certificates have finite validity; when a CA expires, firmware can stop accepting updates or trusting code signed under that CA. Microsoft issued several widely deployed CAs in 2011 that are scheduled to begin expiring in June 2026, with an additional Windows boot‑signing PCA expiring later in October 2026. Microsoft and OEMs have prepared a 2023 CA family to replace them. Why this matters to gamers: modern anti‑cheat systems and many publishers rely on Secure Boot and TPM guarantees to validate pre‑boot and kernel integrity. If a platform can’t trust updated, properly signed bootloaders or the Windows Boot Manager after a CA lapses, games that require anti‑cheat at boot or kernel level may refuse to launch or may cause failures in match/online services. That makes this more than a backstage security housekeeping task — it is a compatibility and availability risk for players.

---

What Microsoft and OEMs are doing now​

The technical fix (high level)​

Microsoft created a set of replacement certificates — commonly called the 2023 CA family — which include:

• Microsoft Corporation KEK 2K CA 2023 (replacement for the KEK CA 2011)
• Windows UEFI CA 2023 (replacement PCA for Windows boot manager signing)
• Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 (split roles for third‑party bootloaders and option ROMs)

The replacement flow is ordered and conservative: enroll the new DB entries, add KEK material as required (sometimes requiring OEM-signed KEK interaction), then swap the Windows Boot Manager to a binary signed under the new PCA only after device readiness checks. This ordering prevents leaving a device with an updated boot manager that the firmware does not yet trust. Microsoft packaged the certificate payloads into January 2026 cumulative/quality updates so the OS side of devices can enroll the new CAs where the firmware permits.

Telemetry‑gated, phased rollout​

Microsoft’s approach is deliberately phased and telemetry‑gated: only devices that show sufficient successful update signals and meet firmware readiness criteria are targeted for automatic enrollment. This reduces the blast radius and gives OEMs and administrators time to sequence firmware updates before OS‑side enrollment. The January 13, 2026 cumulative updates (for example, KB5073455 for Windows 11 and KB5073724 for some Windows 10 channels) include the device‑targeting metadata and servicing logic to begin the automated enrollment on eligible systems. A separate January Patch Tuesday update (for example, KB5074109) further refines device targeting and rollout behavior.

OEM coordination and per‑model guidance​

OEMs are part of the plan. Vendors such as HP have published model‑level advisories and minimum BIOS version lists that identify the specific expiry days (HP lists June 25/28, 2026 and October 20, 2026 for various certs) and whether a firmware update is required before the OS can apply the new keys. OEM guides also explain when third‑party UEFI certificates (the Microsoft UEFI CA 2023 and Option ROM CA) are enabled by default or kept disabled for secured‑core platforms. This per‑model guidance is critical for IT teams and power users who run custom or older hardware.

---

How this impacts PC gamers (specifics)​

Anti‑cheat and launch failures​

Many anti‑cheat solutions perform pre‑boot and kernel integrity checks that depend on a working, up‑to‑date Secure Boot chain. Titles and services that require Secure Boot and TPM 2.0 for anti‑cheat enforcement could fail to launch or report integrity errors if a device lacks the new CA entries when the game or anti‑cheat component is updated under the new signing chain. For most gamers on modern systems that accept Windows Update and OEM firmware updates, the transition should be transparent — but those who run older motherboards, custom firmware, blocked telemetry, or air‑gapped environments are at higher risk of encountering problems.

Dual‑boot and Linux users (including Steam Deck-style setups)​

Linux distributions often use a Microsoft-signed shim to preserve Secure Boot compatibility. If a machine’s firmware lacks the new Microsoft UEFI CA 2023 entries, newly signed shim/GRUB binaries may not be trusted, breaking boot for Linux or requiring manual intervention (dual signing, shim rework, or firmware updates). This affects enthusiasts who dual‑boot Windows and Linux or those using Steam Deck‑like Linux gaming setups on PC hardware. Virtual machines that expose virtual UEFI to guests may also require host/hypervisor updates.

Recovery media and offline images​

If you maintain custom installation ISOs, USB recovery drives, or offline images, those media can contain outdated WinRE or boot manager binaries that are signed under the old PCA. After certificate enrollment rolls forward, using old recovery media could reintroduce the old signing chain into a restored system or lead to recovery flow failures. Imaging and provisioning teams must inject the latest Safe OS Dynamic Updates or update WinRE/install wims with the new certificates before distributing media. Microsoft and enterprise KBs explicitly recommend this as part of standard rollout processes.

---

Concrete, prioritized checklist for PC gamers and home users​

Follow this condensed checklist to reduce the chance of game launch or boot problems as Microsoft and OEMs roll out the 2023 CA family.

• Keep Windows Update enabled and install the January 2026 cumulative updates (and subsequent rollups). Many devices will receive the certificate changes automatically if firmware supports it.
• Update your motherboard or system firmware (BIOS/UEFI) to the latest recommended version from your OEM. If the vendor lists a minimum BIOS to accept KEK/DB writes, apply that firmware first.
• Verify Secure Boot and certificate presence: open an elevated PowerShell and use Confirm‑SecureBootUEFI to check Secure Boot is on, and run Get‑SecureBootUEFI to inspect DB entries. Alternatively, Microsoft provides scripted checks and scheduled tasks you can run to trigger the OS‑side update task (e.g., Start‑ScheduledTask '\Microsoft\Windows\PI\Secure‑Boot‑Update') after installing the January servicing packages.
• Update anti‑cheat and game clients before major events: install updates for Steam, Epic, Origin, Riot, or any launcher you use and then reboot. Make sure anti‑cheat clients (Vanguard, Easy Anti‑Cheat, etc. are up to date and that their publishers haven’t posted special advisories.
• If you run Linux or dual‑boot, check distro and shim/GRUB guidance — some distros recommend dual‑signing or specific shim versions during certificate transitions. Test boot on a spare drive or VM before major updates.

---

Step‑by‑step commands and checks (practical)​

• Confirm Secure Boot is enabled:
• Open PowerShell as Administrator and run: Confirm‑SecureBootUEFI
• True = Secure Boot active; False = not active.
• Inspect installed DB entries quickly:
• Get‑SecureBootUEFI outputs KEK/DB/DBX content; you can search the returned certificate list for “Windows UEFI CA 2023” or “Microsoft UEFI CA 2023”.
• Trigger the OS‑side update task (if you’ve installed the January servicing package and want to prompt enrollment on a ready device):
• Run as Administrator: Start‑ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure‑Boot‑Update"
• Reboot twice to ensure the sequence completes.
• Re‑run Confirm‑SecureBootUEFI and Get‑SecureBootUEFI to verify the new DB/KEK entries appear.
• For imaging teams: download the Safe OS Dynamic Update catalog package from Microsoft Update Catalog and inject with DISM into winre.wim/install.wim to prevent old recovery media from reintroducing the legacy signing chain. Microsoft documents these steps in guidance for WinRE servicing.

---

Realistic worst‑case scenarios and who’s at risk​

• Systems with unsupported or very old firmware: OEMs may not offer BIOS updates for models older than a certain date; HP and other vendors explicitly say platforms released in 2017 and earlier may not receive BIOS updates for this change. Such devices could remain reliant on 2011 CAs.
• Air‑gapped machines and telemetry‑off environments: Microsoft’s automated, telemetry‑gated rollout helps many customers, but devices that opt out of diagnostic telemetry or are isolated may not be targeted automatically; administrators must use manual enrollment paths.
• Virtual machines and cloud images: hypervisors may present virtual UEFI that cannot be updated from inside the guest, or the host image may need updating. Some virtualization setups require host/hypervisor updates to include new CA entries.
• Dual‑boot and third‑party boot components: unsigned or differently signed Linux shims/bootloaders may be rejected by firmware with a changed DB profile; distributions and maintainers are already addressing the transition, but hobbyist setups should test carefully.

Important nuance: The most alarmist headlines about "millions of bricked PCs" are overbroad. The more likely outcomes for most consumer gamers who keep Windows Update and firmware current are transparent, seamless transitions. The real operational risks concentrate in the categories above — fleets with strict policies, unsupported devices, or nonstandard firmware flows — and demand active remediation.

---

Recommended timing and rollout plan for gamers and small teams​

• Immediate (this week)
• Ensure you have the January 2026 cumulative update installed (check Windows Update history for KB5073455 / KB5073724 or KB5074109 where applicable).
• Update firmware for your motherboard/PC using the OEM updater or UEFI flash tool from your vendor.
• Short term (2–4 weeks)
• Verify Secure Boot and that the new 2023 CA entries (when present) appear in Get‑SecureBootUEFI.
• Update game launchers and anti‑cheat clients, and run a quick test of your most‑played titles to ensure they launch cleanly.
• Medium term (1–3 months)
• If you run custom images or recovery media, refresh them with updated WinRE/install.wim content containing the certificate DU.
• If you manage multiple machines (friends/gaming LAN, small team), create an inventory by model/firmware version and prioritize updating older or unsupported systems.
• If you are unsure or run a mission‑critical competitive environment
• Pilot the change on a spare machine first, test game launches and BitLocker/TPM flows, and ensure you have a full image backup before modifying production systems.

---

Troubleshooting common failures​

• If the OS‑side task fails to enroll the 2023 certificates:
• Check Event Viewer for Secure Boot servicing events and UEFICA2023Status / UEFICA2023Error counters.
• Confirm firmware version against OEM minimum BIOS lists.
• If telemetry is disabled, temporarily enable diagnostic data only for the enrollment window or follow the manual enrollment guidance in Microsoft’s playbook.
• If a game or anti‑cheat refuses to run after the transition:
• Update the anti‑cheat client and the game to the latest build, then reboot.
• Use the game publisher’s support channels for a forced refresh or re‑registration of the anti‑cheat driver.
• If using third‑party drivers or mods, remove them and test again; legacy drivers can be a failure vector during pre‑boot transitions.
• If you can’t boot after an attempted enrollment:
• Use updated recovery media (if you refreshed it beforehand) or contact your OEM support for guidance; in extreme cases an OEM firmware recovery or signed KEK patch may be required.

---

Strengths and risks of Microsoft’s approach — critical analysis​

Strengths

• The phased, telemetry‑gated rollout is cautious and pragmatic; it reduces the chance of a single-day global regression by ensuring readiness checks before enrollment. This is sensible for firmware‑level operations where mistakes can be costly.
• Microsoft packaged the OS‑side logic into routine cumulative updates and provided management knobs (registry/GPO/WinCS/MDM) and event logging so IT and advanced users can audit and control the process. That combination supports automated remediation while preserving enterprise control.
• OEM coordination and per‑model guidance gives admins machine‑level clarity about minimum BIOS versions and required sequencing, which is essential for safe rollouts.

Risks

• Dependency on OEM firmware readiness: platforms with no vendor updates or locked firmware may not be able to accept KEK changes, leaving some devices stranded. This dependency places burden on OEM support windows and older hardware lifecycles.
• Telemetry gating leaves non‑telemetry or air‑gapped systems with manual remediation work; organizations that disabled diagnostic data without a fallback are exposed.
• Virtualized and cloud images are a complex edge case: hypervisors and cloud providers must coordinate updates to virtual UEFI images, and the guest agent cannot always remediate without host updates. This increases the management scope for multiplayer gaming hosts and community server providers.

Caveat: any claim about exact day‑level expirations should be checked against your OEM support pages and Microsoft KBs for your model. OEMs sometimes publish specific day numbers that differ by a day or two; those differences are operationally important for large fleets and imaging teams but do not change the overall June/October 2026 windows. Always verify model‑level dates before scheduling irreversible tasks.

---

Final takeaway — what every PC gamer should do today​

• Update Windows now and install January 2026 cumulative updates (check for KB5073455 / KB5073724 / KB5074109 depending on your build).
• Update your motherboard or system firmware to the latest OEM release. If your system is older than the OEM’s supported horizon (for example, many vendors exclude pre‑2017 platforms), plan for a hardware refresh if you want long‑term Secure Boot continuity.
• Verify Secure Boot is enabled and check for the new 2023 CA entries with Confirm‑SecureBootUEFI and Get‑SecureBootUEFI, or follow your OEM’s diagnostic guidance.
• Refresh recovery and provisioning media now if you maintain custom images. Inject updated WinRE/install.wim content so future restores won’t reintroduce old signing profiles.

This is a platform maintenance event with real, time‑sensitive consequences for boot security and anti‑cheat‑driven games. For most modern gamers who keep Windows Update and firmware current, it will be invisible — but for those running older hardware, custom firmware, dual‑boot Linux setups, or air‑gapped systems, the work must be done before the June–October 2026 expiry windows to avoid compatibility or serviceability problems.

---

Conclusion
Treat the 2026 Secure Boot certificate transition as a scheduled, non‑optional maintenance item: apply the January 2026 cumulative updates, update firmware, verify Secure Boot and certificate presence, refresh recovery media, and test your most important games and anti‑cheat clients. The phased rollout reduces risk for most users, but the combination of firmware diversity, virtualization edge cases, and legacy hardware means a small but significant slice of gamers must take proactive steps now to avoid launch failures or boot issues later in 2026.

---

Source: EJS Computers https://ejscomputers.com/blogs/news....com/series/best-windows-apps-this-week-185/]

 

[ChatGPT]

Microsoft is quietly replacing the Secure Boot certificates used by Windows with a new 2023 certificate family to prevent a calendar-driven failure when long-lived Microsoft UEFI certificates issued in 2011 begin to expire in mid‑2026 — a background security change that matters to PC gamers because modern anti‑cheat systems increasingly require a functioning Secure Boot chain to run.

Background / Overview​

UEFI Secure Boot enforces a cryptographic chain of trust at the earliest stage of a PC's startup. Firmware checks signatures on bootloaders, kernel loaders, and option ROMs and refuses to run code that isn’t signed by an accepted certificate authority (CA) stored in the firmware variables (PK, KEK, DB, DBX). This mechanism is a first‑line defense against bootkits and pre‑OS rootkits. Microsoft and many OEMs historically provisioned the same Microsoft‑issued CAs into platform firmware in and around 2011. Those certificates are time‑bound and begin to expire in June 2026 (with an additional Windows boot‑signing PCA expiring in October 2026). If a device still relies solely on the 2011 trust anchors when those dates arrive, it could be prevented from receiving future Secure Boot updates or validating newly signed pre‑boot components — an operational and security problem Microsoft and partners are trying to eliminate. To preserve Secure Boot continuity, Microsoft created a replacement set — the 2023 CA family — and has begun delivering those certificates via Windows servicing flows and coordinated OEM firmware updates. For most consumer devices that keep Windows Update and OEM firmware current, the transition will be automatic and invisible. But for some configurations (air‑gapped machines, firmware with restricted write access, or systems with telemetry blocked), the rollout can stall and require manual intervention or OEM firmware updates.

---

What exactly is expiring — dates and the replacement mapping​

The expiring CAs and their replacements​

Microsoft’s documentation lays out the concrete mapping of expiring certificates to their 2023 replacements:

• Microsoft Corporation KEK CA 2011 — expires June 2026 → replacement: Microsoft Corporation KEK 2K CA 2023 (stored in KEK; used to sign DB/DBX updates).
• Microsoft Corporation UEFI CA 2011 — expires June 2026 → replacements: Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 (stored in DB; splits previous responsibilities between bootloader and option ROM signing).
• Microsoft Windows Production PCA 2011 — expires October 2026 → replacement: Windows UEFI CA 2023 (stored in DB; used to sign Windows boot manager).

These are not speculative timelines — Microsoft published the expiry windows and the new certificate names, and OEMs such as Surface, HP, Dell and Lenovo have published model‑level guidance for firmware readiness where necessary. Some OEM pages list precise day numbers for specific platforms, which is why administrators should consult vendor advisories for model‑level details.

---

Why Secure Boot suddenly matters for PC gamers​

Anti‑cheat developers have increasingly incorporated platform integrity checks into their protection stacks. Several high‑profile anti‑cheat systems that operate with kernel‑level or pre‑boot checks now list Secure Boot as a gating requirement or a strongly recommended condition:

• EA’s Javelin
• Epic’s Easy Anti‑Cheat (EAC)
• Activision’s Ricochet
• Riot’s Vanguard

These tools aim to prevent cheats that load at low levels of the system, and they use Secure Boot (and often TPM 2.0) as a signal that the machine’s pre‑OS environment is untampered. If Secure Boot is disabled, misconfigured, or no longer trusted because certificates have expired, an anti‑cheat driver or service may refuse to start, blocking a game from launching or preventing access to online multiplayer. Practical user symptoms reported in community testing and vendor advisories include:

• Games failing to launch with non‑specific anti‑cheat or “security” errors.
• Online multiplayer modes refusing connections even though the rest of the system appears functional.
• Launcher prompts or in‑game messages instructing the user to “enable Secure Boot” or “update Windows” without clear diagnostics.

From a developer and publisher standpoint, Secure Boot is valuable because it raises the bar for kernel‑level persistence and tampering before Windows itself loads. From a gamer’s perspective, however, it introduces a dependency — if either the firmware trust anchors or the OS‑side rollout fails, a player could be unable to run affected titles until the certificate chain is restored.

---

How Microsoft is delivering the new certificates​

Microsoft is using a conservative, multi‑pronged approach to avoid mass disruption:

• Windows Update / OS‑side servicing: Microsoft packaged the 2023 certificate payloads into monthly cumulative updates and added device‑targeting metadata and a scheduled servicing task to enroll the certificates on eligible systems. Automatic enrollment is telemetry‑gated: Microsoft will attempt automated updates only for devices that show “sufficient successful update signals.”
• OEM firmware updates: Some platforms require a firmware revision before the OS can write new KEK/DB entries; OEMs are coordinating firmware updates and publishing lists of minimum BIOS/UEFI versions for affected models. Surface devices, for example, have been receiving updates via Windows Update and new devices shipped since 2024 often include the 2023 CA by default.
• Manual controls for administrators: Registry, Group Policy, and management tooling (WinCS, Intune MDM CSPs) let IT teams inventory and control rollout behavior across fleets. Microsoft also published a detailed playbook for IT professionals with registry flags, event‑log indicators, and recovery workflows.

The OS‑side flow is deliberately order‑sensitive: add DB entries for the Windows UEFI CA 2023, then add KEK material (often OEM‑signed) so the firmware accepts updates, and finally swap the Windows boot manager to a version signed under the new PCA — with restarts required at safe points to avoid leaving a device without a trusted bootloader. Event logs and registry state (for example UEFICA2023Status) provide per‑device diagnostics.

---

How to check your PC and prepare (practical steps for gamers)​

If you’re a PC gamer who wants to minimize the risk of being locked out of an online title, follow these prioritized steps. Each step includes the reason it matters and the minimal commands or UI paths.

1. Keep Windows Update and firmware updates enabled and applied​

Install cumulative updates and OEM firmware updates routinely. Microsoft’s rollout depends on devices accepting UEFI writes and reporting normal update telemetry; pausing updates for long periods raises the chance of missing the certificate enrollment. Surface and other OEMs have been delivering these cert updates via Windows Update to supported devices.

2. Quick PowerShell check for the 2023 certificate​

Open an elevated PowerShell (Run as Administrator) and run:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
If the result shows True, your firmware DB contains the Windows UEFI CA 2023. If it returns False, you are still on the older certificate set and should ensure Windows Update is enabled and allow the scheduled Secure Boot enrollment task to run. This command is the same check Dell and other vendors recommended in community guidance and Microsoft’s playbook.

3. Use Steam’s system information if you prefer a GUI check​

Steam’s system information view now shows whether Secure Boot is active on the machine; this is an easy check for gamers who prefer not to use PowerShell. Steam’s built‑in check only reports whether Secure Boot is enabled — it won’t tell you which CA entries are present — but it’s a useful quick verification before launching games that require Secure Boot.

4. If the PowerShell check fails, let Windows Update try to supply the certs​

Microsoft’s servicing is designed to run the update task on eligible devices automatically. You can trigger the scheduled task manually (when updates are present) using the task name Microsoft implemented, or let it run as part of the cumulative update process. If the task fails, check Event Viewer for the UEFICA2023Status and UEFICA2023Error keys and consult OEM guidance for firmware prerequisites.

5. For advanced users: firmware/BIOS settings, custom drivers, dual‑boot and Linux​

Users who deliberately disabled Secure Boot to run unsigned drivers, custom kernels, or Linux distributions need to weigh tradeoffs: re‑enabling Secure Boot or accepting the 2023 CA may break some unsigned software or require shim/grub updates on Linux. Linux distributors and shim maintainers have been tracking this transition; dual‑boot setups should check for updated shim binaries signed for the 2023 CAs or plan to use distribution guidance to maintain a working boot chain. Virtual machines using firmware‑based Secure Boot may require hypervisor‑side updates.

---

Troubleshooting scenarios and edge cases gamers may see​

• Game refuses to start after a cumulative update: This can happen if the anti‑cheat service detects missing Secure Boot trust anchors or inconsistent firmware state. Check the anti‑cheat’s support pages for explicit Secure Boot guidance, run the PowerShell DB check, and verify Windows Update history and Event Viewer for UEFICA2023Status events.
• System shows Secure Boot enabled, but anti‑cheat still blocks the game: Some anti‑cheat stacks require not only Secure Boot enabled but also the new 2023 CA entries to be present and a Windows boot manager signed under the 2023 PCA. Use the PowerShell certificate presence test above; if the 2023 entries are missing, allow the Windows servicing task additional reboots or check OEM firmware updates.
• You run Linux or Proton/Steam Play (Steam Deck users): Titles that require Secure Boot and kernel‑level anti‑cheat present compatibility issues for Linux and Proton because many anti‑cheat systems do not support non‑Windows kernels under required integrity checks. Valve and some anti‑cheat vendors are investigating mitigations, but in practice the Secure Boot + anti‑cheat requirement can block Steam Deck and other Linux Play compatibility for certain titles.
• Air‑gapped machines and privacy‑conscious setups with telemetry disabled: Microsoft’s automated enrollment is telemetry‑gated — devices that opt out of diagnostic telemetry may not be eligible for Microsoft’s “high‑confidence” automatic enrollment. In these cases, administrators must use the documented manual procedures (registry/GPO/WinCS) or request OEM firmware support to ensure the 2023 CAs are present.

---

Risk analysis — strengths, trade‑offs and where problems can still happen​

Strengths of the planned approach​

• The replacement is proactive: Microsoft and OEMs are addressing certificate expiry before calendar failure, and the staged, telemetry‑gated rollout reduces blast radius. This avoids a piledriver “expired CA breaks everything” scenario.
• The new 2023 CA family separates option ROMs from bootloader signing, allowing finer‑grained trust policies and giving OEMs and administrators more control over what is accepted at boot.
• Microsoft published an IT playbook, diagnostic registry keys, and event log hooks so administrators have tools to inventory and remediate devices at scale.

Where the risks remain​

• Firmware diversity: The Windows ecosystem is heterogeneous. Some older or vendor‑abandoned platforms may need firmware updates to accept the KEK updates required by the new CA set. If OEM support is absent for a specific model, remediation could be complex and potentially require hardware replacement.
• Edge configuration failures: Imaging pipelines, recovery media, and custom provisioning that re‑inject old WinRE/install media can reintroduce 2011 CA–signed binaries, creating confusing behavior for newly updated endpoints. Administrators must inject the new dynamic update into golden images and recovery images.
• Gaming interoperability: For gamers who run custom kernels, unsigned drivers, alternative OSes, or rely on firmware hacks, the push toward enforced Secure Boot will force tradeoffs between flexibility and compatibility with anti‑cheat‑protected titles. Some anti‑cheat solutions run at kernel level and have been associated with stability complaints, so adding Secure Boot dependencies changes the compatibility landscape.
• Virtualization and cloud images: VMs can be affected where the hypervisor exposes a virtual UEFI that cannot be updated from inside the guest. Host‑level action or vendor patches may be required.

---

Recommendations for gamers and small‑scale PC builders​

• Don’t disable Windows Update indefinitely. Keep cumulative updates and firmware updates applied. Microsoft’s automatic enrollment will handle most consumer PCs if updates are allowed.
• Run the PowerShell certificate presence check now and again. If it returns False, trigger Windows Update and reboot several times — the OS servicing flow requires reboots to complete the KEK/DB swaps.
• Check Steam’s system info for Secure Boot if you prefer a GUI check. This is a useful quick verification for titles that list Secure Boot as a requirement.
• If you deliberately disabled Secure Boot for development, modding, or multi‑boot reasons, plan for possible tradeoffs. You may need to re‑enable Secure Boot (and adjust your workflow) to play some competitive or recently released titles that enforce Secure Boot. Consider using a separate gaming installation or machine if you need unsigned drivers or custom kernels.
• If you manage many machines, pilot and inject the dynamic update into golden images. For imaging teams, ensure recovery and install media are updated with the dynamic updates to avoid re‑introducing 2011 CA artifacts.

---

What to expect in the weeks ahead​

Microsoft’s January 2026 cumulative updates embedded the device‑targeting metadata and the scheduled task to begin enrollment on eligible systems; across 2026 the ecosystem will continue a phased rollout and OEMs will publish firmware readiness lists. The calendar is firm: June 2026 for the primary 2011 CAs and October 2026 for the Windows production PCA used to sign the boot manager — treat those dates as operational deadlines. If there are unexpected large‑scale failures, the fix paths are known: OEM firmware updates, manual classroom/enterprise remediation via WinCS/GPO/registry, or, in the rarest cases where a platform simply cannot be updated, device replacement. For most consumer gamers who keep their systems updated, the experience should be seamless. For specific edge cases — heavily locked down corporate endpoints, air‑gapped systems, or abandoned firmware platforms — proactive inventory and pilot remediation is essential now.

---

Conclusion​

This is a low‑drama but high‑importance platform maintenance event. Microsoft and OEMs are replacing expiring 2011 Secure Boot certificates with a 2023 CA family and packaging the changes into the Windows servicing model so most users won’t notice anything at all. But because major anti‑cheat stacks now rely on Secure Boot as part of their integrity checks, gamers should treat this as a practical deadline: keep updates enabled, verify your firmware DB contains the Windows UEFI CA 2023, and be prepared to update firmware or adjust configurations if you intentionally run nonstandard kernels or unsigned drivers. Doing this now keeps your machine secure and reduces the chance of a frustrating “can’t play” message on an otherwise healthy gaming rig when those 2011 certificates lapse.

---

Source: EJS Computers Windows 11 Secure Boot Certificate Expiry: What PC Gamers Need To Know

 

[ChatGPT]

Microsoft is quietly rolling out replacement Secure Boot certificates to Windows devices because several Microsoft-issued UEFI certificates from 2011 begin expiring in mid‑2026, and systems that still rely on those old certificates risk losing the ability to receive security updates for pre‑boot components or to trust newly signed boot components. This is not a theoretical maintenance note — it changes the foundation of how Windows and many third‑party boot components are trusted at startup, and it requires prompt verification and, in some cases, targeted action from both home users and IT teams.

Background / Overview​

Secure Boot is a UEFI firmware feature that enforces a cryptographic chain of trust at system startup. The firmware stores certificates and signing keys in variables named PK (Platform Key), KEK (Key Exchange Key), DB (Allowed Signature Database) and DBX (Revoked Signature Database). Those certificates are real X.509 artifacts with expiration dates; Microsoft historically provisioned a set of Microsoft CA certificates in firmware across many OEM platforms starting in 2011. When those certificates expire, the platform can no longer trust or accept updates signed under that chain unless a new trust anchor is in place. Microsoft has prepared a replacement family — the 2023 CA certificates — and is distributing them via Windows updates and coordinated OEM firmware updates to avoid disruption. Why this matters: once the 2011 certificates begin to expire in June 2026, affected devices that have not been updated may stop receiving Secure Boot and Windows Boot Manager updates and could reject newly signed boot code. The result ranges from loss of future pre‑boot security fixes to compatibility problems with updated bootloaders and anti‑cheat enforcement used by some PC games. Microsoft and the ecosystem aim to avoid mass disruption by staging updates and gating deployment based on device readiness checks.

---

What exactly is expiring and when​

Microsoft’s public guidance maps three key 2011 certificates to new 2023 replacements:

• Microsoft Corporation KEK CA 2011 — expires June 2026 → Microsoft Corporation KEK 2K CA 2023 (stored in KEK; signs DB/DBX updates).
• Microsoft Corporation UEFI CA 2011 — expires June 2026 → replaced by Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 (split functions; stored in DB).
• Microsoft Windows Production PCA 2011 — expires later in October 2026 → replaced by Windows UEFI CA 2023 (used to sign the Windows boot manager).

OEMs sometimes publish day‑level expiration dates for specific firmware and product families (for example, model pages listing June 25/28 and October 20, 2026), so administrators should treat month‑level windows as the operational deadline but verify vendor advisories for exact calendar days.

---

Who is affected​

• Devices manufactured since roughly 2012 may carry the expiring 2011 certificates and are therefore potentially affected. Most devices built in 2024 or later already have the 2023 certs in firmware.
• Only systems that use Secure Boot are in scope. If Secure Boot is disabled, these certificate changes do not affect boot certificate enforcement on that device (although disabling Secure Boot reduces security).
• Enterprise fleets, air‑gapped devices, systems with blocked telemetry/diagnostic reporting, and devices with firmware that disallows OS‑initiated UEFI writes are higher risk and may require manual or OEM‑assisted remediation.
• Virtual machines and cloud images are also a consideration: hypervisor or cloud provider firmware images may need to include the new certificates or enable guest enrollment paths.

In short: if you keep Windows Update enabled and your device has recent OEM firmware, you’re likely to be updated automatically. If you run managed endpoints, air‑gapped servers, older motherboards, custom images, or specialized hardware, plan for active verification and remediation.

---

How to check if your device already has the 2023 certificates (practical steps)​

Below are concise, verifiable checks you can run locally. These steps will show whether the new Windows UEFI CA 2023 (and related 2023 family members) are already present in your firmware DB.

1) Confirm Secure Boot is enabled​

• Press Win + R, type msinfo32, press Enter. In System Information look for Secure Boot State. If it reads On, Secure Boot is enabled. If the value is Off, the certificate replacement path is not applied (but the system is not subject to the same Secure‑Boot certificate trust checks).

2) Use PowerShell to inspect firmware DB entries​

Open Windows PowerShell as Administrator and run:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
This dumps the DB variable contents in ASCII — you can scan the output for Windows UEFI CA 2023 or other 2023 certificate strings. For a direct True/False check:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
If the command returns True, the DB contains the Windows UEFI CA 2023 certificate. Microsoft’s guidance and support articles show the same commands as the recommended verification method.

3) Alternative PowerShell checks​

You can also search the KEK or DBX contents similarly:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes)

The presence of the KEK 2023 or the absence/presence of particular DBX revocations is part of the broader validation story.

4) Registry quick check (if PowerShell is inconclusive)​

Open Registry Editor and visit:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Look for WindowsUEFICA2023Capable, UEFICA2023Status, or UEFICA2023Error values. A value of 0 for WindowsUEFICA2023Capable implies the Windows UEFI CA 2023 is not present; UEFICA2023Status will transition from NotStarted → InProgress → Updated as the process runs. Microsoft documents these diagnostic keys and recommends using UEFICA2023Status for most checks.

---

If your device does not have the 2023 certs: safe, supported remediation paths​

Microsoft and OEMs provide several supported paths to get devices updated. Choose the method that matches your environment and risk tolerance.

Option A — Automatic rollout via Windows Update (consumer/default path)​

For the majority of consumer and small‑business devices that accept Microsoft‑managed updates, Microsoft is distributing the 2023 certificates gradually via cumulative updates and phased targeting. Ensure:

• Windows Update is enabled and kept current.
• Diagnostic/telemetry reporting is not disabled (Microsoft’s phased rollout uses success signals to minimize risk).
• Apply any OEM firmware/BIOS updates the vendor recommends for your model.

This is the least invasive route and the one Microsoft expects most end users to rely on.

Option B — Trigger the OS‑driven enrollment (local advance)​

If you need to force the update locally (for a pilot machine or a device that hasn’t been targeted yet), use the documented sequence:

• Set the AvailableUpdates registry bit to trigger the DB update. As an administrator run:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x40 /f

• Start the Secure Boot servicing scheduled task:

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

• Reboot twice and verify the DB contains the Windows UEFI CA 2023:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
To apply the boot manager replacement (signed by Windows UEFI CA 2023) or the SVN firmware update there are additional AvailableUpdates bitmask values (for the boot manager and SVN steps) — Microsoft documents a full set of flags and the safe sequence in their KB/playbook. Follow those KB steps exactly in production environments.

Option C — Enterprise management (WinCS, Intune, Group Policy, WSUS)​

Large organizations should use the Windows Configuration System (WinCS) CLI or domain‑scale controls to apply the Feature_AllKeysAndBootMgrByWinCS key (WinCS key F33E0C8E002) or use Group Policy/registry deployment of the AvailableUpdates bitmask 0x5944. WinCS and the updated playbook give IT teams a centrally auditable, repeatable path for mass remediation. Event IDs and registry status values provide reporting hooks for automation.

---

Imaging, recovery media, and Golden‑image guidance​

If you maintain custom installation media, WinRE images, or golden images for provisioning, ensure those images are updated to include the Secure Boot certificate changes and the updated boot manager. Microsoft explicitly warns that outdated WinRE or provisioning images can reintroduce old signatures into devices and block future Secure Boot servicing paths. For imaging teams:

• Inject the Windows DU or updated WinRE into your golden images before deploying widely.
• Pilot on representative hardware covering OEM models, BitLocker, and recovery flows.
• Test Reset/Cloud Reinstall and BitLocker pre‑boot scenarios.

---

Gaming and third‑party bootloaders: why players should care​

Modern anti‑cheat systems increasingly rely on a secure pre‑boot chain to attest system integrity. Major anti‑cheat solutions (Easy Anti‑Cheat, Vanguard, Javelin, Ricochet) may require a properly functioning Secure Boot chain; a mismatch between firmware‑enrolled certs and updated anti‑cheat expectations can prevent games from launching. For gamers, the practical advice is to keep Windows and firmware updated and confirm your system has the Windows UEFI CA 2023 entries so anti‑cheat signed components continue to validate. Microsoft and industry reporting emphasize this intersection and note that most consumer devices updated via Windows Update should transition without interruption.

---

Risks, caveats and what can go wrong​

• Firmware readiness is the single largest variable. Some OEMs require a firmware update before firmware will accept KEK or DB changes initiated by the OS. If firmware is out of date or the vendor has not published the required update, the OS‑side enrollment can fail and record event/log codes indicating firmware rejection. Check your vendor’s support pages for minimum BIOS/UEFI versions.
• Telemetry gating: Microsoft’s phased rollout uses diagnostic signals to reduce the blast radius. Devices that block telemetry or diagnostic reporting may be excluded from automated pushes and therefore need manual remediation.
• Image/installer regressions: deploying old recovery media or installers can reintroduce the old 2011 certs into a device image; this is especially relevant for provisioning servers and offline imaging processes. Update golden images first.
• Legacy hardware and drivers: some older drivers (for example, in‑box modem drivers) and legacy hardware paths might have compatibility implications. In mission‑critical environments, pilot thoroughly before mass rollout. Microsoft’s playbook explicitly warns about mixing deployment methods on the same device.
• Incomplete updates: If an update fails mid‑sequence, registry keys such as UEFICA2023Error and event log IDs (for example, Event ID 1808 for success, Event ID 1801/1795 for failures) are the primary troubleshooting indicators. Use event logs plus UEFICA2023Status to triage.

---

Practical checklists — step‑by‑step​

For home users and small businesses (minimal effort)​

• Ensure Windows Update is enabled and install all available updates.
• Apply any firmware (BIOS/UEFI) updates recommended by your PC maker.
• Run the PowerShell check:
• Start PowerShell (Admin)
• Run [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
• If True — you’re done. If False — proceed to contact OEM support or follow the local trigger steps below.

For IT teams and administrators (actionable rollout plan)​

• Inventory: collect Secure Boot status, firmware versions, and which devices report UEFICA2023Status as Updated. Scriptable checks are available using Get‑SecureBootUEFI and registry queries.
• Update firmware: apply vendor BIOS/UEFI updates on models that require them before enrollment. Maintain an OEM matrix of minimum firmware versions.
• Pilot: pick representative models (laptops, desktops, docking, WWAN) and test the whole sequence: DB update, boot manager update, SVN application, recovery flows (BitLocker/WinRE).
• Deploy: use WinCS or registry/Group Policy to set AvailableUpdates=0x5944 (or the staged bitmask your plan requires), monitor UEFICA2023Status/UEFICA2023Error and event logs.
• Report & remediate: escalate firmware‑rejection cases to OEMs; for isolated devices, schedule manual imaging or vendor assistance.

---

Troubleshooting highlights​

• If the scheduled task \Microsoft\Windows\PI\Secure-Boot-Update is missing, the device likely lacks required servicing updates — check for cumulative updates that include Secure Boot servicing logic.
• If UEFICA2023Error is nonzero, consult the System event logs under the Secure‑Boot‑Update provider for detailed error codes and possible firmware rejection reasons.
• If your VM image or cloud host refuses the change, contact the hypervisor/cloud provider to confirm their virtual firmware images include the 2023 certificates or allow guest‑driven enrollment.

---

Final analysis — why this matters for security and operations​

This Secure Boot certificate rotation is an unusual, time‑bounded, cross‑ecosystem operation. It’s not a typical monthly patch cycle: it is a renewal of cryptographic trust anchors that underpin UEFI Secure Boot across millions of devices. For devices that accept Microsoft‑managed updates and that have up‑to‑date firmware, the transition should be seamless. For others — especially enterprise, offline, or legacy fleets — this is an operational project that demands inventory, vendor coordination, pilots, and controlled rollout. Ignoring it risks losing the ability to receive pre‑boot security updates after the 2011 CA expirations in mid‑2026, which would materially impact platform security and compliance posture. Microsoft’s phased approach, telemetry gating, and the availability of management tools (WinCS, registry/GPO options, event logging) give administrators the means to handle this safely — but they do not remove the responsibility to act. OEM firmware readiness remains the most critical dependency, and device owners should verify vendor advisories for model‑specific guidance and day‑level expiry notes.

---

Quick reference commands and values (copy/paste)​

• Check Secure Boot status: open System Information (msinfo32) → Secure Boot State.
• PowerShell: check DB for Windows UEFI CA 2023

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

• Trigger DB update (local):

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

• Trigger full enterprise bitmask (apply all updates, enterprise use):

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

• WinCS key to apply centrally: F33E0C8E002 (Feature_AllKeysAndBootMgrByWinCS).

---

Conclusion
The Secure Boot certificate refresh is time‑sensitive and foundational: verify now, remediate where required, and update provisioning media so new devices and recovery flows do not reintroduce the old trust anchors. For most consumer devices receiving automatic updates and up‑to‑date firmware, the switch to the 2023 CA family will be seamless; for enterprise fleets and older hardware, treat this as a cross‑functional project involving security, endpoint management, and OEM coordination and use the registry/WinCS hooks and event logs Microsoft provides to validate success. Act sooner rather than later — the earliest expirations begin in June 2026 and the window for safe, well‑tested rollout is already open.

---

Source: PCWorld Vital Windows 11 certificates are expiring: how to check if you're affected