January Patch Tuesday: Refresh Secure Boot certificates to close pre-OS gaps

Microsoft’s January Patch Tuesday includes a high-priority update that refreshes expiring Secure Boot certificates on Windows devices — a preventative, must-install fix that closes a narrow but critical window attackers could use to install persistent bootkits before the OS loads. rview
UEFI Secure Boot is the firmware-level gatekeeper that verifies cryptographic signatures on bootloaders, option ROMs and EFI applications before Windows ever runs. When its certificate authorities (CAs) age out, the chain of trust that Secure Boot enforces weakens: devices can either refuse new, legitimately signed pre‑boot components or — worse — continue trusting legacy artifacts that adversaries can abuse. Microsoft warns the current Microsoft-supplied Secure Boot certificates issued around 2011 are set to begin expiring in mid‑2026, and has published a coordinated plan to roll replacement “2023” certificate authorities into firmware DB/KEK variables to preserve Secure Boot continuity. This week’s cumulative updates — notably KB5074109 for Windows 11 and KB5073724 for supported Windows 10 SKUs — contain the OS‑side servicing logic and device targeting telemetry that begin a cautious, phased delivery of the new CA entries and associated bootmanager changes. The updates are intentionally gated: Microsoft will automatically enroll only devices that demonstrate stable update health, while administrators retain manual controls for enterprise rollouts.

---

Why this patch matters: bootkits, persistence, and pre‑OS threats​

Bootkits and pre‑OS rootkits operate at the earliest stage of the platform trust chain. They install code on the EFI system partition or otherwise subvert the bootloader so that malicious payloads run before the operating system and anti‑malware engines initialize. That early run time gives such threats exceptional stealth and persistence; they can disable BitLocker protection or tamper with hypervisor‑based integrity features. High-profile real‑world examples — including BlackLotus — demonstrate these threats go beyond theory: security researchers and Microsoft incident response teams have documented in‑the‑wild UEFI bootkits and published mitigation guidance. CISA and other US agencies have echoed that pre‑OS compromises are among the hardest to detect and remediate. The core lesson: Secure Boot’s trust anchors must be current. If the firmware still relies on a CA that expires, Microsoft cannot deliver future revocations or signing‑chain updates needed to block or mitigate evolving threats. This update is preventive maintenance — and for that reason it belongs on the short list of “install‑now” patches for both consumers and enterprises.

---

What Microsoft shipped (technical summary)​

• The January servicing cycle introduced OS packages that include:
• Device targeting metadata and health‑gating logic used to identify systems eligible for automatic CA enrollment.
• Payloads that add the new 2023 certificates into the Secure Boot databases (DB / KEK) and, where required, replace the Windows boot manager with a binary signed under the 2023 signing CA.
• Administrative controls (registry keys, Group Policy/Intune options and enrollment tools) so IT teams can pilot, opt‑in, or opt‑out of Microsoft‑managed automatic enrollment.
• Continued reliance on OEM cooperation for KEK updates on devices that require additional firmware‑signed assistance.

Microsoft’s official guidance lays out the certificate mapping and expiry windows clearly:

• The Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 are scheduled to begin expiring in June 2026.
• The Microsoft Windows Production PCA 2011 has a later expiry window (through October 2026).
• Replacement certificates such as Microsoft Corporation KEK 2K CA 2023, Windows UEFI CA 2023, Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 will be enrolled to maintain continuity.

Independent reporting and OEM advisories corroborate Microsoft’s timeline and the deliverables in the January updates. Industry outlets flagged KB5074109 as the Windows 11 cumulative update containing the Secure Boot certificate rollout logic, and vendors such as HP and Surface published guidance for device readiness.

---

Who should install this (and when)​

Short answer: everyone running supported Windows 10 or Windows 11 builds should prioritize this update.

• Home users — Install via Windows Update as soon as practical. The rollout is designed to be safe and invisible for the majority of consumer devices that keep updates current.
• Power users and gamers — Anti‑cheat and platform integrity components increasingly rely on a functioning Secure Boot chain. Systems participating in competitive gaming or using modern anti‑cheat stacks should be updated promptly.
• Enterprises and managed fleets — Treat this as an operational priority. The rollout involves coordinated OS‑side and firmware‑side actions; inventory, pilot, and staged deployments are strongly recommended. Microsoft provides registry, GPO, and WinCS (Windows Configuration System) controls to manage enrollments for devices that cannot rely on Microsoft‑managed telemetry gating.

---

Step‑by‑step: install, verify, and prepare (consumer and admin guidance)​

• Check for the update:
• Open Settings > Windows Update and check for updates. Look for the January cumulative LCU:
• Windows 11: KB5074109 (January cumulative update).
• Windows 10 (supported SKUs/ESU): KB5073724.
• Install and reboot:
• Allow the update to install and restart the device. The update sequence is order‑sensitive; some changes (such as replacing the boot manager) require restart(s) to complete.
• Confirm Secure Boot is enabled:
• Press Start, run “System Information” and check “Secure Boot State” under System Summary; it should say On.
• For enterprise management:
• Inventory devices for firmware readiness and Secure Boot state.
• If auto‑enrollment is undesirable, use the published registry keys and Group Policy options to opt out or manage the rollout manually. Microsoft documents registry controls and event/registry status keys administrators can use for troubleshooting.

Important note: enabling Secure Boot requires UEFI mode (not legacy BIOS) and can be disrupted on multi‑boot or non‑standard setups. Administrators should pilot changes on representative hardware before broad deployment. OEM firmware updates may be required for some platforms; coordinate firmware updates and OS servicing according to the vendor guidance.

---

Enterprise deployment and troubleshooting considerations​

Microsoft’s phased, telemetry‑gated rollout​

Microsoft will not perform a blind mass update. Instead, the company uses device health signals to classify devices into “high confidence” buckets eligible for automatic enrollment. This lowers the risk of mass disruption but means administrators must be intentional when managing devices that are air‑gapped, telemetry‑restricted, or running old firmware. Manual deployment options are available and documented.

Registry and management knobs (high level)​

Microsoft published controls enabling:

• Opting out of Microsoft‑managed high‑confidence enrollment.
• Forcing enrollment via registry/GPO for piloting.
• Viewing per‑device event log and registry status keys (for example, UEFICA2023Status / UEFICA2023Error and the AvailableUpdates bitmask) to track progress and troubleshoot failures. Administrators should monitor these signals in their test rings first.

OEM firmware coordination​

Many KEK updates require OEM‑signed KEK material or firmware changes. If the device’s firmware will not accept the new KEK entries, the OS‑side process cannot complete safely — Microsoft and OEMs emphasize updating firmware where required and consulting vendor guidance for specific platform limitations. Vendor advisories (Surface, HP, Dell, Lenovo) list affected models and minimum firmware requirements.

---

Known compatibility risks and caveats​

• Firmware that cannot be updated or that lacks write access to KEK/DB variables may not receive the new CAs automatically; manual remediation will be necessary.
• Devices using legacy BIOS/CSM or running specialized boot chains (some dual‑boot Linux setups that rely on shim) may require additional steps to maintain multi‑OS compatibility.
• The January packages also remove several legacy in‑box modem drivers; organizations relying on very old hardware driven by those drivers should validate whether functionality is impacted.
• Once revocations or DB/DBX changes are applied, they are not trivially reversible; Microsoft’s model implies permanence for revocations and enrolled CA changes. Administrators should pilot carefully.

Where third‑party option ROMs or unsigned pre‑boot components are required by certain specialized hardware, site‑specific policy and firmware settings will govern whether to enroll the Microsoft Option ROM UEFI CA 2023 or keep additional third‑party CAs disabled for stricter security. HP’s guidance explicitly recommends leaving third‑party UEFI CA entries disabled unless those option ROMs are required.

---

The attack history that motivates this work (context and recent incidents)​

• BlackLotus: ESET’s in‑depth analysis and Microsoft’s incident guidance documented a UEFI bootkit (BlackLotus) that leverages a Secure Boot bypass (CVE‑2022‑21894 and related issues) to achieve pre‑OS persistence. ESET found BlackLotus was sold on underground forums and could be deployed against fully patched systems by abusing validly signed binaries that remained trusted by firmware because they were not added to revocation lists. Microsoft released guidance for investigation and recovery.
• TrickBoot/TrickBot: Research into TrickBot evolution showed modules that probe firmware for vulnerabilities and configuration weaknesses (the so‑called TrickBoot functionality), demonstrating how crimeware ecosystems can pivot toward firmware and boot‑time persistence when the opportunity exists. This trend reinforces the urgency of keeping firmware and Secure Boot trust anchors current.
• BootHole and historical fixes: Past incidents (like BootHole in GRUB2) required broad updates to DB/DBX and signing chains to prevent rollback or tampering. The present certificate refresh is analogous — preventive maintenance aimed at avoiding a scramble at expiry time.

Taken together, these incidents explain why Microsoft, OEMs, and security agencies prioritize maintaining a modern, auditable set of Secure Boot anchors and revocation lists.

---

Extra hardening steps (beyond installing the update)​

• Keep firmware updated via OEM utilities or vendor‑delivered firmware over Windows Update when available. Firmware and OS updates often must be coordinated to avoid mismatch during certificate hand‑offs.
• Enable BitLocker with TPM and secure PIN/recovery policies to protect data at rest if pre‑boot protections are circumvented.
• Use virtualization‑based security (VBS) features where supported to separate and protect critical platform processes from kernel manipulation.
• Enforce driver signing and limit installation of unsigned or unknown pre‑boot drivers. Consider device install restriction policies through Group Policy or MDM for enterprise endpoints.
• Audit Secure Boot variables and maintain a documented inventory of devices that cannot be updated automatically (air‑gapped, telemetry‑limited, or firmware‑locked platforms). Use PowerShell’s Confirm‑SecureBootUEFI and Get‑SecureBootUEFI to capture statuses at scale.

---

Critical analysis — strengths, operational risks, and unanswered questions​

Strengths

• The OS‑side, telemetry‑gated approach is prudent: Microsoft balances the security imperative against the real risk of mass‑bricking or compatibility breakage by only targeting devices that demonstrate reliable update health. This reduces blast radius compared to a blunt automatic push.
• Microsoft’s publication of enrollment controls (registry/GPO/WinCS) gives enterprises the necessary knobs to pilot at scale and avoid surprises during broad deployment.
• Vendor coordination (Surface, HP, Dell, Lenovo guidance) signals broad ecosystem alignment and lowers the single‑vendor failure risk for many modern devices.

Operational risks and caveats

• Firmware diversity remains a complicating factor. Some older or OEM‑locked platforms may be unable to accept new KEK/DB entries without explicit firmware updates, forcing manual intervention or hardware replacement in edge cases. That creates operational burden for large, heterogeneous fleets.
• The rollout depends on telemetry and health gating; environments that disable telemetry (privacy‑sensitive or compliance‑restricted systems) may not get automatic enrollment and will need carefully managed manual processes.
• The permanence of some revocation and DBX changes means mistakes or insufficient piloting could result in difficult‑to‑reverse outcomes, especially for multi‑boot or legacy scenarios. Administrators must be especially cautious.

Unanswered / cautionary points

• While Microsoft and security firms have published guidance and mitigations for BlackLotus‑style campaigns, there is never absolute certainty about the absence of active exploitation in the wild. Public reporting to date describes limited deployments and ESET telemetry; the landscape could change quickly if new tools are adopted by broader criminal groups. Flag any assertions about “no evidence of exploitation” as time‑sensitive; always assume the adversary opportunity exists until devices are updated and inventoried.

---

Practical checklist (quick reference)​

• Consumers:
• 1) Run Windows Update and install the January cumulative update (KB5074109 for Windows 11; KB5073724 for supported Windows 10 builds).
• 2) Restart and confirm Secure Boot State is On in System Information.
• 3) Update OEM firmware if the vendor has published required firmware updates.
• IT / Admins:
• 1) Inventory devices for Secure Boot status and firmware write access.
• 2) Pilot the update in a representative ring; monitor UEFICA2023Status and event logs for errors.
• 3) Coordinate firmware and OS updates per vendor guidance; use registry/GPO/WinCS controls for managed enrollment.
• 4) Document devices that require manual remediation (air‑gapped, telemetry‑off, or unsupported firmware).

---

Conclusion​

The January cumulative updates that begin delivering the 2023 Secure Boot certificate family close a critical window ahead of the 2011 CA expiry cycle in mid‑ to late‑2026. The change is preventive and necessary: keeping Secure Boot anchors current preserves the platform’s ability to receive future revocations and mitigations against boot‑time threats. Given the documented threat history — from BootHole and TrickBoot evolutions to the in‑the‑wild BlackLotus bootkit — this update is not optional for systems that rely on Secure Boot for platform integrity.
Install the update, verify Secure Boot is enabled, coordinate firmware updates from your OEM where required, and plan a careful pilot‑to‑production sequence for managed fleets. The patch reduces a subtle but high‑impact risk — attackers who can meet your machine before Windows does will always prefer a stale chain of trust. Act now to keep that door closed.

---

Source: findarticles.com Windows Issues Secure Boot Patch Against Bootkits

 

[ChatGPT]

Microsoft’s January Patch Tuesday includes a narrowly targeted but high‑impact fix that refreshes expiring Secure Boot certificates on Windows devices — a preventive update that closes a small window attackers could use to install persistent bootkits before the operating system loads. The cumulative packages (notably KB5074109 for Windows 11 and KB5073724 for supported Windows 10 builds) deliver the OS‑side logic and device targeting needed to begin enrolling new 2023 certificate authorities into UEFI Secure Boot databases; installing them should be treated as a priority for both home users and enterprise administrators.

---

Background / Overview​

Secure Boot is the firmware‑level gatekeeper that verifies cryptographic signatures on bootloaders, EFI applications and option ROMs before Windows (or any other OS) runs. When the root certificate authorities (CAs) used by Secure Boot age out, the chain of trust weakens: devices may either refuse legitimate, newly signed boot components or — worse — continue to trust outdated artifacts that attackers can abuse. Microsoft publicly warns that the Microsoft‑supplied Secure Boot certificates issued around 2011 are scheduled to begin expiring in mid‑2026, with the final Windows boot‑signing PCA expiring later in 2026. The company has prepared a replacement family of ** and is delivering them via staged Windows updates to preserve Secure Boot continuity. Why this matters now: a successful pre‑OS compromise (a bootkit or UEFI rootkit) executes before the OS and most defenses initialize, giving attackers persistence and the ability to tamper with integrity protections such as BitLocker or hypervisor‑based integrity features. Real‑world bootkits like BlackLotus have demonstrated that these threats are not just theoretical — incident responders and researchers documented in‑the‑wild UEFI bootkit activity and the need for coordinated mitigations.

---

What Microsoft shipped in January (technical summary)​

The January servicing cycle includes cumulative updates that do three things relevant to Secure Boot:

• Add device‑targeting metadata and health‑gating logic that identifies systems eligible for automatic enrollment of the 2023 certificate set.
• Deliver payloads that can add the new certificates into firmware DB/KEK variables and, where necessary, swap the Windows boot manager for a binary signed under the new PCA to complete the trust hand‑off.
• Expose administrative controls (registry keys, Group Policy/Ian pilot, opt‑in, or opt‑out of automated enrollment and troubleshoot failures.

These packages are intentionally phased and telemetry‑gated: Microsoft will attempt automatic enrollment only on devices reporting “sufficient successful update signals” to reduce the risk of applying the change on hardware that cannot accept it. Administrators still retain manual deployment options for managed fleets. Key updates to look for:

• KB5074109 — Windows 11 cumulative update containing the Secure Boot certificate rollout logic and related servicing changes.
• KB5073724 — Windows 10 servicing package that includes high‑confidence device targeting for the certificate refresh; this package also removes legacy modem drivers as an attack‑surface reduction step.

---

The certificate timeline — exact dates and replacement keys​

Microsoft’s documentation maps out the expiry windows and replacement certificates in concrete terms:

• Microsoft Corporation KEK CA 2011 — scheduled to begin expiring in June 2026; replacement: Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011 — scheduled to begin expiring in June 2026; replacements: Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.
• Microsoft Windows Production PCA 2011 — later expiry, October 2026; UEFI CA 2023*.

Those exact expiry dates and certificate mappings appear in Microsoft’s Secure Boot guidance and are echoed in OEM advisories (for example, HP and Surface documentation) that describe vendor‑specific readiness and firmware update requirements. If a device still depends on 2011 CA entries when they lapse it may be unable to accept future Secure Boot updates or validate newly signed boot components. Caveat and verification: certificate expiry is a hard deadline only for systems that continue to rely on the old CA entries in firmware. Devices manufactured since 2024 often ship with the 2023 certificates already installed; older hardware requires the staged OS‑side enrollment or a firmware (UEFI) update from the OEM. Verify your device’s firmware state and vendor guidance before you panic.

---

Threat context: bootkits, BlackLotus, and BootHole — why the refresh matters​

• Bootkits operate below the operating system and can survive OS reinstallations, masking their presence from traditional anti‑malware tools. They’re prized by attackers who want persistence and stealth.
• BlackLotus is a prominent UEFI bootkit that researchers analyzed and confirmed had been used in the wild. It leveraged CVE‑2022‑21894 (and related weaknesses) to bypass Secure Boot and install persistent pre‑OS components; Microsoft, ESET and CISA have produced guidance for detection and response. This real‑world precedent explains why maintaining an up‑to‑date certificate and revocation ecosystem matters.
• Historically, the BootHole family of vulnerabilities in GRUB2 required broad industry coordination: revocations, new shim binaries, and updates to the DB/DBX revocation store across millions of devices. BootHole demonstrates that when signed boot components turn out to be vulnerable, prompt and coordinated certificate/revocation updates are necessary to prevent attackers from re‑using older, signed binaries.

Together these incidents show the stakes: Secure Boot’s CA and revocation architecture is not mere housekeeping — it is a live security control that must be actively managed or attackers can exploit stale trust anchors.

---

Who should install this e refresh — prioritization​

Short answer: everyone running a supported Windows 10 or Windows 11 release should prioritize these updates.

• Consumers / Home users: install the January cumulative update through Windows Update (or via the Microsoft Update Catalog if you manage updates manually). Most users will receive the new certificates automatically and invisibly if their device is eligible.
• Enterprises, government and compliance‑sensitive organizations: treat this as a high‑priority change. Inventory Secure Boot state and firmware versions across your fleet, pilot the update in a small ring, and monitor the UEFICA2023Status/UEFICA2023Error event log and registry values documented by Microsoft before mass rollout. Use Intune/WSUS/ConfigMgr controls to stage the deployment.
• Specialists and multi‑boot systems: Linux distributions that rely on shim and signed GRUB2 must also be considered. The key expiry affects multi‑boot scenarios and non‑Windows OS bootloaders because they share trust anchors in firmware; coordinate with OS vendor guidance and OEM firmware updates.

Risk profile: devices that are air‑gapped, telemetry‑off, or running unsupported firmware versions may not be eligible for automatic enrollment and could require manual remediation by IT or end users. Plan ahead for those outliers.

---

How to install, verify, and troubleshoot — practical steps​

Follow this prioritized checklist to deploy and verify the Secure Boot certificate refresh.

• Install the update (consumer flow)
• Open Settings → Windows Update → Check for updates. Look for KB5074109 on Windows 11 or KB5073724 on supported Windows 10 builds. Install and restart.
• Install the update (enterprise flow)
• Ensure your Servicing Stack Update (SSU) prerequisites are present, then publish the LCU/KB to WSUS / ConfigMgr / Intune with pilot rings. Monitor event logs and the UEFICA2023Status instrumentation Microsoft documents for per‑device progress.
• Confirm Secure Boot is enabled
• 32 (System Information) and check Secure Boot State — it should read On.
• PowerShell: Run an elevated PowerShell and execute: Confirm-SecureBootUEFI — the cmdlet returns True if Secure Boot is enabled. These checks are recommended both before and after installing the update.
• Firmware updates
• If Microsoft’s OS‑side logic cannot complete enrollment because the platform needs OEM KEK updates, follow your vendor’s firmware guidance (Surface, HP, Dell, Lenovo all published readiness notes). Apply vendor firmware updates as required.
• Troubleshoot known impacts
• Legacy hardware or specialized devices that rely on removed in‑box drivers (for example, certain soft‑modems removed by KB5073724) may lose functionality; inventory those dependencies and install OEM driver replacements where required.
• Post‑deployment hardening (recommended)
• Keep firmware and device drivers up to date.
• Enable BitLocker with TPM+PIN or TPM+startup key to protect data if a device is physically compromised.
• Use virtualization‑based security (VBS / HVCI) where available to isolate critical kernel components.
• Enforce driver signing and restrict installation of unsigned pre‑boot drivers via Group Policy / endpoint controll and security trade‑offs — strengths and risks

Strengths

• Prevents a predictable failure mode: Enrolling new 2023 CAs before the 2011 CAs expire preserves the platform’s ability to accept future Secure Boot updates and to revoke vulnerable signed binaries.
• Phased, telemetry‑gated rollout reduces widespread breakage risk: Microsoft’s staged approach limits mass disruption and gives administrators controls to pilot the change.
• Industry coordination: OEM advisories and Microsoft guidance aim to synchronize firmware and OS changes to avoid a messy mid‑2026 scramble.

Risks and potential negative outcomes

• Legacy hardware and non‑standard configurations: Older systems or devices using vendor‑specific Secure Boot layouts may require firmware updates or manual interventions; in rare cases, certificate changes can render those devices unable to boot until remediated.
• False sense of safety: Certificate renewal patches do not fix bootloader bugs themselves; they preserve the revocation and signing channels that let Microsoft and vendors deliver fixes in future. Patching the certificate chain is necessary but not sufficient for complete mitigation against all bootkit techniques.
• Phased rollout complexity: Telemetry gating reduces risk but also creates uneven global coverage: a device may appear “up to date” in Windows Update yet still lack the firmware entries because it did not meet Microsoft’s automatic‑enrollment criteria. IT teams must still inventory and verify their estate.

Unverifiable or time‑sensitive claims

• Assertions that “there is no evidence of exploitation” or that “only targeted attacks exist” are inherently time‑sensitive. Threat landscape statements can change rapidly as new incidents are discovered; treat historic “no evidence” claims as provisional and rely on current telemetry and vendor advisories for your environment. Flagged claims in older reporting should be re‑checked against current advisories (Microsoft, CISA, ESET, vendor bulletins) before you act on them.

---

Enterprise checklist — deployment and audit controls​

• Inventory Secure Boot state across the estate (Confirm‑SecureBootUEFI via PowerShell, Intune compliance scripts, or firmware inventory tools).
• Identify devices that require OEM firmware updates and schedule vendor‑coordinated maintenance windows.
• Create a pilot ring: pick a healthof devices to validate enrollment, monitor UEFICA2023Status and event logs, and capture any remediation steps.
• Document a remediation plan for air‑gapped/telemetry‑off devices (likely manual enrollment or OEM firmware patching).
• Ensure backups and recovery images are tested before rolling out certificate changes at scale.

---

Final analysis and recommendations​

Microsoft’s Secure Boot certificate refresh is preventive maintenance at the firmware trust layer; it prevents a clear, predictable failure mode that would otherwise materialize when 2011‑era CAs lapse in mid‑2026. The update is small in concept but foundational in effect: it preserves the ability to deliver revocations, to sign new boot managers, and to keep Secure Boot functioning as an effective pre‑OS control. Independent research and historical incidents (BlackLotus, BootHole, MoonBounce and others) show that pre‑OS threats are real, persistent, and difficult to detect — which makes maintaining an active chain of trust critical. Recommendations (practical, in order):

• Install the January cumulative update (KB5074109 on Windows 11; KB5073724 on supported Windows 10). Restart and let the servicing tasks complete.
• Verify Secure Boot is enabled (msinfo32 or Confirm‑SecureBootUEFI) and confirm device firmware is at vendor‑recommended levels.
• For fleets, pilot then scale: use Intune/WSUS/ConfigMgr to control rollout and monitor the UEFICA2023Status telemetry.
• Apply firmware updates from your OEM where required — especially for older devices that may not accept the OS‑side enrollment.
• Maintain layered defenses: enable BitLocker, enforce driver signing, maintain endpoint EDR, and monitor firmware‑relevant logs.

The update is not optional for systems that depend on Secure Boot for platform integrity and for organizations that must meet security compliance. Installing the certificates keeps the door closed to attackers who would prefer to meet your machine before Windows does. Act now: install, verify, and document — and treat firmware trust as a routine part of your security hygiene going forward.

---

Conclusion
Secure Boot is one of the first lines of defense for modern Windows platforms, and the certificate refresh delivered in the January cumulative updates is preventive maintenance that preserves that defense. The technical details — certificate mappings, expiry dates, KB numbers and the phased servicing model — are documented by Microsoft and supported by OEM advisories and independent researchers. Deploy the update, confirm Secure Boot is on, coordinate firmware updates where needed, and incorporate Secure Boot verification into standard patching and procurement workflows to avoid a crisis when the 2011 CAs expire.

---

Source: findarticles.com Windows Issues Secure Boot Patch Against Bootkits

 

[ChatGPT]

Microsoft is holding a second Ask Microsoft Anything (AMA) focused on the Secure Boot certificate update campaign on February 5 — an event aimed squarely at IT teams, security engineers, and device managers who need to prepare Windows devices for the retirement of legacy Secure Boot certificate authorities that begin expiring in June 2026.

Background / Overview​

Secure Boot is a firmware-level trust gate built into UEFI that ensures a platform only executes boot code signed by trusted certificate authorities stored in firmware variables (the DB, DBX, KEK and PK). Those Microsoft-supplied certificate authorities issued around 2011 are scheduled to begin expiring in mid‑2026, and Microsoft — working with OEM partners — has published a coordinated plan to replace the 2011 certificates with a new family of 2023 certificates so Secure receive updates and sign new boot components without interruption. Why this matters: once the 2011 certificates expire, affected devices that still rely on them may no longer accept new Secure Boot updates or newly signed boot components, which breaks the chain of trust and prevents Microsoft from delivering future security updates and revocation lists (DBX). That can alter security posture, cause compatibility issues with newly signed firmware/bootloader components, and even trigger recovery scenarios such as BitLocker recovery prompts on some systems.

What Microsoft has published and why the AMA matters​

Microsoft has produced a practical Secure Boot playbook, technical guidance pages, and registry/GPO/WinCS tools for organisationsa manage the rollout. The company is using a mix of firmware updates from OEMs and staged Windows servicing to distribute the 2023 certificates to devices that can safely accept them. The AMA on February 5 is the follow-up forum for IT teams to ask detailed, scenario-specific questions — from inventory methodologies to handling edge-case firmware failures. Key published elements to be familiar with before the AMA:

• A Secure Boot playbook that lays out inventory, pilot, deployment, and remediation steps.
• Registry and Group Policy controls that let administrators opt‑in, opt‑out, or force updates for managed fleets.
• WinCS CLI (Windows Configuration System) and PowerShell samples for larger domain environments.
• Microsoft-managed (telemetry‑gated) rollout for devices classified as “high confidence,” plus manual methods for the rest.

Technical summary: the mechanics of the change​

Which certificates are changing and when​

Microsoft’s published table identifies three core Microsoft-provided CAs that are in scope:

• Microsoft Corporation KEK CA 2011 — expires June 2026; replaced by Microsoft Corporation KEK 2K CA 2023 (or KEK CA 2023).
• Microsoft Corporation UEFI CA 2011 (and related option-ROM CA) — expires June 2026; replaced by UEFI/Option ROM 2023 certificates.
• Microsoft Windows Production PCA 2011 — slated to expire later in 2026 (October for the PCA used to sign the Windows bootloader) and replaced by Windows UEFI CA 2023.

These entries live in firmware variables: PK (Platform Key) is typically OEM-controlled, KEK (Key Exchange Key) signs updates to DB/DBX, DB lists trusted signatures, and DBX lists revoked signatures. Refreshing the CA anchors in KEK/DB preserves the ability to sign and distribute future Secure Boot updates.

How Microsoft is delivering the update​

Microsoft is using a dual approach:

• OS-side servicing (monthly cumulative updates) that delivers the enrollment logic and payloads needed to apply certificates to firmware variables when the device is capable.
• Firmware updates from OEMs where firmware-level acceptance or KEK provisioning is required. Microsoft’s servicing may attempt to enroll new CAs automatically only on devices that report sufficient update health telemetry, while registry/GPO/WinCS options allow admins to force or control deployments in managed environments.

Notable KBs and servicing notes (deployment logic began shipping in 2025 and the enrollment behavior was added to cumulative updates, with some deployments tied to identified KB packages): administrators should treat these servicing updates as high priority because they include the logic that adds and tracks the new CAs.

Practical steps: an administrator’s checklist​

Below is a practical, prioritized checklist tailored for enterprise and SMB teams preparing a rollout. Each step is deliberately short so teams can adopt, assign, and measure progress.

• Inventory and categorize devices
• Determine which devices have Secure Boot enabled and which certificate family they currently carry (2011 vs 2023).
• Prioritize by device criticality (domain controllers, shared workstations, kiosks, cloud images), OEM model, and firmware age. Use enterprise inventory tools plus sampling via PowerShell on representative devices.
• Verify OS support and servicing channel
• Ensure devices are running a supported Windows build that can process the certificate enrollment. Windows 10 support ended for mainstream security updates on October 14, 2025 (note: some devices may be on ESU), so verify each OS version’s support status before relying on Windows Update to carry the workload. Microsoft’s guidance calls out supported Windows versions and the need for specific servicing levels.
• Patch to required baseline updates
• Install the cumulative updates that introduced the Secure Boot enrollment logic (these began appearing in 2025). On managed devices, Microsoft’s staged approach may only automatically enroll “high‑confidence” devices; for everything else use the registry/GPO or WinCS approaches. Confirm which KBs your images include before injecting into golden images.
• Firmware updates
• Contact OEMs for firmware updates for models that do not accept the new CA entries cleanly. Devices with proprietary or older firmware may require vendor-provided EFI updates before certificate enrollment is possible. Test each OEM model class during pilot.
• Pilot and validation
• Run small pilots per device model and per OS image. Validate: a) Secure Boot variables (DB/DBX/KEK), b) Windows event logs for Secure Boot events, c) BitLocker behaviour across reboots, and d) recovery media and imaging workflows using updated winre.wim/install.wim images. Microsoft supplies event IDs and registry indicators to monitor progress and errors.
• Full rollout and monitor deployment windows and track UEFICA2023Status for device-level state. Instrument event forwarding for Event IDs tied to Secure Boot DB/DBX updates and watch for UEFICA2023Error non-zero values to capture failures needing OEM or manual remediation.
• Update imaging and recovery media
• Inject the requisite cumulative updates into golden images and recovery media (WinRE) so field recovery does not rely on images signed by expired authorities. Test Reset/Refresh, offline servicing and bare-metal restores after updating golden images.

Deployment methods — what Microsoft provides and when to use them​

• Microsoft-managed (telemetry-gated) rollout: Let Microsoft’s confidence buckets apply the updates where dees success. This is lowest-effort for admins but requires diagnostic telemetry and is not intended where admins must show explicit control for compliance scenarios.
• Registry / Group Policy trigger: Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates to 0x5944 to trigger the full update path (note: the task that processes this runs every 12 hours; administrators can schedule the Secure-Boot-Update task to run immediately during testing). Track progress and UEFICA2023Error. This is the recommended controlled method for corporate rollouts. Microsoft documents the values and test commands.
• WinCS / domain-level CLI: Use WinCS in enterprise scenarios for large, domain-joined deployments where scripting or centralized control is required. The playbook includes guidance for WinCS usage.
• OEM firmware update path: For devices that refuse to accept new CA values in DB/KEK due to firmware constraints, wait for or request OEM-supplied firmware that provisions the KEK/DB updates. In these cases, firmware updates are mandatory before OS-side enrollment will succeed.

Verification and troubleshooting — the key signals​

• Registry indicators: UEFICA2023Status (NotStarted → InProgress → Updated) and UEFICA2023Error (0 for success, non-zero indicates a failure code). These keys are the canonical device-level indicators Microsoft recommends for tracking per-device state.
• Event logs: Microsoft surfaces specific Secure Boot DB/DBX update events; Event IDs highlighted in the playbook (for example, success and error event IDs such as) are useful for bulk monitoring. Correlate these events with UEFICA2023Error for root-cause.
• PowerShell verification: Use Secure Boot–related cmdlets (Confirm-SecureBootUEFI, Get-SecureBootUEFI) to inspect UEFI variables and confirm the presence of the new certificates, where supported by the platform. Note: some platforms — particularly virtual machines or BIOS-only systems — may not support all cmdlets. Test on representative hardware.
• Manual recovery test: Always validate recovery media and BitLocker recovery behavior across pilot devices. In some deployments, DBX updates or boot manager swaps can prompt BitLocker to go into recovery on systems whose recovery keys are not readily available. Keep recovery keys accessible for pilots.

Known pitfalls, incompatibilities and risks​

• BitLocker recovery prompts and locked devices: DB/DBX changes and boot manager swaps can trigger BitLocker recovery. If recovery keys are not available, this creates operational outages. Microsoft explicitly warns to validate BitLocker flows during pilot.
• OEM firmware quirks: Some OEM firmware requires a specific sequence or vendor-signed firmware before accepting KEK/DB updates. In practice this has shlder or heavily customized OEM images. Coordinate closely with vendor support for models that show UEFICA2023Error codes.
• Virtual machines and cloud images: Some hypervisor or cloud images (or older generation virtual platforms) may not expose UEFI variables in the same way as physical devices or may use vendor-specific shim keys. Validate VMs and cloud images you manage (including Windows 365 and Azure images) as part of your plan.
• Linux and non-Windows OS compatibility: Some Linux distributions rely on Microsoft’s signing (shim) and may be affected if firmware does not contain the new CA entries. Public coverage has highlighted that older signers or missing firmware updates can break Linux Secure Boot compatibility, forcing users to disable Secure Boot or seek vendor-friendly shims. Plan for dual‑boot or Linux-hosted systems.
• Imaging and recovery media: Older offline media and installation images created before the update will not contain the new certs and may fail to boot or install on updated devices. Update golden images and portable recovery media as part of the rollout.

What to ask during the AMA — high-value questions to bring​

The Tech Community AMA is a live opportunity to get clarity on operational edge cases. Bring concise, actionable questions such as:

• “For OEM model X (provide exact model and firmware version), is a vendor firmware update confirmed and what is the recommended sequencing?”
• “If UEFICA2023Error returns error code 0x800703e6 (or other non-zero), can you map the top 10 error codes to remediation steps?”
• “Will images built before KB XYZ require injection of a specific package to avoid WinRE or Reset failures?”
• “How will Microsoft manage the interaction between Microsoft-managed assists and an enterprise that uses registry/GPO-driven enrollment simultaneously?”
• “Is there an MDM CSP timeline that maps into Intune templates, and will that support bulk telemetry for rollout status?”

Strengths of Microsoft’s approach — and the tradeoffs​

Strengths

• Microsoft published a detailed playbook and many of the deployment controls (registry/GPO/WinCS), which provides multiple supported paths for different organizational sizes and compliance postures.
• Staged, telemetry-gated updates reduce the risk of widespread failures by first targeting devices with observed good update behavior. This lowers blast radius relative to a single global push.
• The approach includes eventing, registry state, and diagnostic hooks that enable automated monitoring and remediation at scale.

Tradeoffs and risks

• Dependency on OEM firmware updates introduces a vendor-coordination step that can delay or complicate rollouts, especially for older or customized hardware.
• Changes at the firmware trust layer are inherently high-impact and can induce BitLocker or imaging disruptions if not tested thoroughly. The timeline to June 2026 is fixed; this compresses the testing and remediation window for organizations with large heterogeneous estates.
• Some platforms (legacy BIOS, non-UEFI VMs, or unsupported Windows editions) cannot participate in OS-managed enrollment and require bespoke handling.

Verification of the key claims (explicit cross-checks)​

• Claim: Microsoft-supplied CAs from 2011 start expiring in June 2026 and must be replaced to maintain Secure Boot servicing. Verified against Microsoft guidance that explicitly names the 2011 CAs and schedule for 2026 expirations.
• Claim: Microsoft shipped enrollment logic in 2025 cumulative updates and uses KBs such as the January/May 2025 servicing to begin the rollout. Confirmed via Microsoft support notes and independent coverage that examined the KBs used to carry enrollment behavior.
• Claim: Administrators can trigger and track updates via AvailableUpdates = 0x5944 and follow UEFICA2023Status values. Confirmed in Microsoft’s registry key guidance and cross-referenced in the Windows IT Pro playbook materials and forum threads documenting real-world trials.

If any local firmware behaviors or KB number mappings cannot be verified publicly for a specific OEM model, treat the OEM response as the authoritative source for that hardware and record any guidance given during the AMA for your deployment notes.

Final recommendations — an operational plan you can start today​

• Week 1–2: Inventory and classify devices by model, firmware date, OS version and Secure Boot status. Ensure BitLocker recovery keys are centralized and retrievable.
• Week 3–4: Patch pilot devices to the baseline cumulative updates that include enrollment logic. Inject updates into golden images and update recovery media.
• Week 5–8: Pilot per OEM model and per image, exercise recovery workflows, and collect UEFICA2023Status/U EFICA2023Error data and Secure Boot event logs.
• Week 9–12: Coordinate firmware updates for models that failed enrollment, remediate or replace units where OEM fixes are not available, and begin phased production rollout using registry/GPO or WinCS.
• Ongoing: Monitor event telemetry, watch for post-rollout helpdesk spikes related to BitLocker, and attend the Microsoft AMA on February 5 for live answers to unresolved edge cases.

---

Secure Boot certificate replacement is operationally complex but manageable with careful inventory, firmware coordination, and methodical pilot testing. Microsoft’s playbook and the public guidance give administrators the tools and telemetry to execute a controlled migration; the AMA on February 5 is the practical forum to close gaps in your plan and get direct clarification from the engineering and product panel. Prepare precise model and KB details in advance, bring recovery and imaging results from your pilots, and treat the June 2026 certificate expiry as a hard deadline to avoid losing the ability to receive Secure Boot updates or to encounter unexpected boot-time and recovery issues.

---

Source: Microsoft - Message Center Ask Microsoft Anything: Secure Boot - February 5, 2026 - Windows Tech Community