Secure Boot Certificates Expire June 2026—Plan for Windows 11 Certificate Rotation

  • Thread Author
Microsoft’s September preview update pushed an urgent reminder to IT teams and advanced users: Secure Boot certificates used broadly across Windows devices are scheduled to start expiring in June 2026, and without coordinated firmware and OS updates some machines may be unable to boot securely or apply pre-boot fixes.

Background / Overview​

Microsoft published KB notifications for the September 23, 2025 preview flight (KB5065790) that bundle targeted reliability fixes for Windows 11 while also drawing attention to a looming platform-level maintenance task: the rotation and renewal of Secure Boot root and signing certificates that were originally provisioned around 2011. That advisory is not a minor housekeeping note — it has direct implications for Secure Boot behavior and pre-boot integrity checks on many consumer and business devices.
To understand why this matters, remember that Secure Boot is a UEFI firmware feature that enforces a signature chain for boot-time binaries (bootloaders, drivers, recovery tools). The chain trusts certificates and keys provisioned in platform variables such as KEK, DB, and DBX. When those trust anchors expire or are removed without being replaced by valid attestations, UEFI can refuse to load signed components — or, under strict policies, refuse to boot entirely. Microsoft’s update guidance and preview KB explicitly warns that certificates issued in 2011 are scheduled to begin expiring starting June 2026 and that administrators should plan now to avoid disruption.

What KB5065790 actually contains (executive summary)​

Targeted quality fixes in the preview build​

KB5065790 is a Release Preview quality update focused on stability- and reliability-type fixes rather than new features. The publicly highlighted fixes address:
  • A sign-in hang on devices when entering a SIM PIN at the lock screen (WWAN/eSIM devices).
  • Updates to Country and Operator Settings Asset (COSA) and carrier profile handling.
  • Display/kernel stability problems affecting multi-monitor Remote Desktop sessions and unexpected shutdowns during undocking.
  • Rendering issues with Chinese IME input.
  • Crashes when opening shared printer queues in Settings.
  • Minor metadata/service description fixes.
This preview build is delivered through Release Preview for validation before any move to broad production servicing; admins are advised to pilot the patch on representative hardware first.

The Secure Boot certificate advisory bundled with the update​

Separately and more consequential for long-term platform hygiene, Microsoft reiterated that older Secure Boot certificates — originally issued circa 2011 — will begin expiring in mid‑2026. If devices are not updated with the new certificate set (through firmware updates, OS certificate packages, or OEM-supplied processes), those devices could fail Secure Boot validation or be prevented from applying pre-boot patches. Microsoft documented a multi-pronged rollout to replace platform KEK/DB certificates and provide OS-level updates where applicable.

Why the certificate expiry is a real risk (technical analysis)​

Secure Boot’s trust model depends on concrete cryptographic anchors that have real-world lifetimes. Certificates created in 2011 were expected to reach the end of their useful life in the 2025–2026 timeframe; the practical effects that Microsoft warns about are:
  • Pre-boot updates or recovery components signed under the expiring certificate chain may no longer validate, preventing tasks like offline servicing or firmware-assisted recovery.
  • Under strict Secure Boot policy settings, the firmware may treat failure to validate boot components as an immediate condition to block boot, producing boot failures in already-deployed fleets.
  • Some OEMs or managed fleets with locked-down firmware policies may be unable to accept an in-field certificate substitution without an OEM-provided firmware update or explicit management workflow.
These are not hypothetical edge cases: Microsoft’s guidance explicitly states affected devices "may be unable to apply pre‑boot fixes or might fail to boot securely under existing Secure Boot policies" if certificates are not updated. That language signals the possibility of a hard failure mode for some configurations.

Dual‑build family nuance (22621 vs 22631)​

If you cross-check the KB entry and vendor summaries you’ll notice variation in build numbering: Microsoft services Windows 11 with parallel build families (commonly 22621 and 22631), and the same KB textual content may be packaged with different build numbers for the two families. The Release Preview notes and community analysis reflect this duality — e.g., KB5065790 appears in the Release Preview stream as Build 22631.5982 while preview packaging for other servicing families may show 22621.x variants. Administrators should confirm the specific build number that targets their SKU/build family before deployment.

Cross‑referencing and verification​

Multiple independent reporting and community analysis posts mirror Microsoft’s advisory and expand on operational concerns, confirming the expiry timeline and the recommended actions for admins. Reporting from mainstream Windows coverage and security-focused outlets reiterates the June 2026 timeframe and notes that Microsoft has outlined CA/KEK update approaches to prevent boot-time disruption. Cross-checking Microsoft’s KB language against independent summaries is consistent: the expiry window, the impacted certificate set (issued in 2011), and the remediation pattern (replace certificates via firmware and OS-delivered updates) are corroborated across several independent sources.
Caveat: while the high‑level expiry timeline and recommended mitigation strategy are consistently reported, exact lists of affected OEM models, firmware versions, or device counts are not published by Microsoft in the KB preview. Those device-level details are OEM-managed and therefore require checking vendor advisories. Treat any specific device-impact claims that are not published by OEMs or Microsoft as unverifiable until confirmed.

Impact matrix — who to worry about first​

  • Enterprise fleets with mixed OEM hardware and locked firmware policies: High priority. These environments often enforce strict Secure Boot policies and may not accept ad-hoc certificate changes without vendor involvement.
  • Devices used in field or remote scenarios (WWAN/eSIM laptops, kiosk devices, point-of-sale): High priority. If those devices cannot receive firmware updates easily, a certificate expiry could effectively prevent secure boot or recovery.
  • Recent consumer PCs with modern UEFI firmware and OEM update channels: Lower immediate risk, but still require verification that the OEM firmware exposes new trust anchors or that Windows update packages will supply necessary CA updates.
  • Older hardware where OEM update support has ended: Elevated risk. End-of-support firmware may not receive the necessary KEK/DB changes; these devices may need a replacement plan before June 2026.
These categories closely match Microsoft’s advisory emphasis and community checklist recommendations to inventory and prioritize devices that rely on older trust anchors.

Recommended mitigation and remediation checklist (for IT teams)​

  • Inventory and classify devices now (by May–June 2026 timeline):
  • Identify models, OEM firmware versions, and where possible the Secure Boot variable state (KEK/DB contents).
  • Flag devices that cannot be updated via standard OEM channels or that are out of vendor support.
  • Confirm OEM firmware update availability:
  • Contact OEM support or check vendor advisory pages for explicit guidance about accepting the replacement CA/KEK set for Secure Boot.
  • Prioritize testing on devices that represent critical workflows (kiosks, remote workers, POS). Microsoft also recommends pilots in Release Preview or a staging ring.
  • Ensure Windows update pipelines will apply OS-level CA updates:
  • Microsoft indicated a multi-pronged approach that includes OS-side CA/KEK updates where applicable. Confirm that your update management (WSUS, SCCM/ConfigMgr, Intune) is prepared to deliver these servicing updates.
  • Test Secure Boot behavior after applying the recommended updates:
  • Use a controlled lab to verify boot behavior, pre-boot repair scenarios, and recovery tooling after installing the new certificate set.
  • Observe for regressions for at least 48–72 hours in real-world use as Microsoft suggests for Release Preview builds.
  • Maintain rollback and recovery plans:
  • Capture system images and ensure offline recovery media are available before broad deployment.
  • Understand uninstall semantics for combined SSU/LCU packages — in many cases the servicing stack update cannot be uninstalled once applied. That has operational consequences during remediation.
  • Build a replacement plan for unsupported hardware:
  • For machines that will not receive firmware updates or OS-side certificate refreshes, budget and schedule hardware replacement prior to the date certificates begin expiring (June 2026).
  • Communicate timelines and user-impact expectations:
  • Provide status updates to stakeholders and end users. For remote or kiosk systems, schedule maintenance windows or physical service visits where needed.
This checklist mirrors the practical guidance included in Release Preview analysis and Microsoft’s advisory language about planning and testing.

Actionable steps for consumer users (concise)​

  • Keep Windows Update enabled and fully applied; Microsoft is delivering part of the solution via OS updates for supported devices.
  • Check your PC vendor’s support site for firmware/BIOS/UEFI updates and apply them per vendor instructions.
  • If you have an older PC and the vendor has no updates, plan for replacement before June 2026 if you require Secure Boot-based protections.
  • For advanced users: confirm Secure Boot variable signatures via UEFI firmware UI or vendor tooling, but avoid ad-hoc changes to Secure Boot variables without clear vendor guidance.

Testing and validation — a suggested pilot plan​

  • Select a small, representative pilot group (10–50 devices) including:
  • A mix of OEM models and firmware versions
  • At least one device per critical workflow (VPN + WWAN, docked workstation, kiosk/POS)
  • Create full device backups or system images.
  • Apply the Microsoft preview/production updates and OEM firmware updates per vendor guidance.
  • Perform these validation checks:
  • Normal boot with Secure Boot enabled
  • Offline recovery using pre-boot tools
  • Windows Update and servicing stack behavior
  • Application of any pre-boot or recovery signing tests you have in your environment
  • Monitor for 72 hours and collect logs for any anomalies; escalate to vendor support if you find a regression. Microsoft’s Release Preview guidance recommends this staged, telemetry-aware approach.

What’s uncertain and what to watch for (risks and caveats)​

  • Vendor coverage variability: Microsoft can publish OS-side updates, but OEM firmware changes are required in many cases. The availability and timing of those firmware updates is controlled by OEMs, not Microsoft, and is thus the single largest operational risk. Any claims about a specific OEM’s readiness that are not published by the OEM should be treated as unverified.
  • Device-level behavior differences: The KB and community analysis deliberately do not list every affected model. Test results may vary even between units of the same model due to differences in firmware configuration, custom management policies, or enterprise provisioning. Treat any model-level impact statements that are not confirmed by OEM advisories as speculative.
  • Uninstall and recovery complexity: Some servicing packages combine SSU and LCU components that cannot be removed after install. That limits quick rollback choices if the update/pilot reveals regressions. Maintain offline images and recovery media as a contingency.
  • Timeline awareness: the advisory points to certificate expiry beginning in June 2026. That gives a finite runway, but planning and execution at scale (fleet-wide firmware distribution, pilot validation, replacement procurement) can take months. Treat the date as a hard planning target.

Recommended communication and governance steps​

  • Treat Secure Boot certificate rotation as an organizational milestone similar to a planned TLS root rotation: inventory, validate, stage, and execute with rollback and auditing.
  • Assign a cross-functional team: firmware/OEM liaison, patch management, endpoint security, and infrastructure teams should collaborate to ensure no single team is surprised.
  • Add monitoring and alerting for boot failures and pre-boot repair events to catch regressions early after staged rollouts.
  • Document the pilot results and produce a deployment runbook that includes OEM-specific steps, validation commands, and rollback triggers.

Conclusion​

Microsoft’s KB5065790 preview brings the usual assortment of targeted quality fixes for Windows 11, but its accompanying advisory on the June 2026 Secure Boot certificate expiration elevates this release from "routine patch" to a serviceability planning event. The technical reality is clear: cryptographic trust anchors have finite lifetimes, and in complex mixed-fleet environments the interplay between OEM firmware, OS-level CA updates, and management tooling determines whether an organization experiences seamless rotation or disruptive boot failures.
Start now: inventory devices, confirm OEM update paths, pilot updates on representative hardware, and prepare replacement plans for unsupported devices. When in doubt, treat vendor advisories as authoritative for firmware behavior, and rely on staged, telemetry-driven rollouts to minimize risk. Microsoft and independent reporting align on the core facts and the June 2026 timeline, but exact device impacts will depend on OEM responses and individual fleet characteristics — those are the variables that IT teams must resolve in the coming months.
Source: Microsoft Support September 23, 2025—KB5065790 (OS Build 22621.5984) Preview - Microsoft Support
 
Click to expand...
Microsoft has posted the September 2025 non‑security preview update for Windows 11, version 23H2 — an optional Release Preview build (KB5065790) that delivers a set of targeted reliability fixes while reiterating a major operational warning: Microsoft’s Secure Boot signing certificates issued in 2011 are scheduled to begin expiring in mid‑2026, and IT teams and device owners must prepare now to avoid boot‑time trust and updateability problems.

Background / Overview​

Microsoft issues non‑security preview updates through the Release Preview channel to let administrators and early adopters validate fixes and detect last‑mile regressions before those fixes are promoted into general servicing. The September optional update for Windows 11, version 23H2 (also visible in Insider Release Preview channels as Build 22631.5982 / 22631.5984) contains quality and reliability tweaks — authentication fixes, IME/display/printer bug corrections, and other targeted stability items — while the public notes also surface a cross‑cutting servicing advisory about Secure Boot certificate rollover.
At the same time, Microsoft’s September cumulative updates for other servicing branches (for example, Windows 11, version 24H2) explicitly call out the Secure Boot certificate expiration program and link to guidance for preparing devices, because the change affects the pre‑OS trust chain that enables Secure Boot protections and pre‑boot updates.
This story is therefore twofold: (1) what the September 2025 optional updates change functionally for Windows 11 23H2, and (2) why the Secure Boot certificate expiration and CA replacement program — a multi‑step, cross‑OEM, firmware‑and‑OS initiative — should be treated as an immediate operational priority for both home users and enterprise IT teams.

What’s in the September 2025 non‑security preview for Windows 11, version 23H2​

Key fixes and focus areas​

  • Authentication and sign‑in reliability improvements (SIM PIN / mobile broadband sign‑in hangs resolved).
  • Input and IME fixes addressing character rendering and editor behavior for specific languages.
  • Printer queue UI stabilization and fixes for shared‑printer scenarios.
  • Miscellaneous system‑service reliability corrections and small cosmetic bug fixes surfaced from the Release Preview testing stream.
These updates are conservative by design: they are not feature rolls but quality improvements intended to reduce field issues before monthly rollups or the next cumulative. Administrators should treat the package as optional validation content: install in pilot rings first, validate firmware and driver interactions, then expand deployment if no regressions appear.

Packaging and installation notes​

Microsoft commonly bundles a Servicing Stack Update (SSU) with cumulative and preview packages to reduce installation failures. That bundling improves reliability but complicates rollback, because SSUs are effectively non‑removable once applied. If you manage large fleets, include SSU behavior in your test plan and image recovery strategy.

Windows Secure Boot certificate expiration: what’s changing and why it matters​

The timeline — concrete dates to remember​

  • Several Microsoft certificates issued in 2011 are scheduled to begin expiring in June 2026 (notably the KEK/UEFI CA family used in Secure Boot databases).
  • A further certificate used to sign the Windows boot manager expires later in October 2026.
Microsoft is already delivering replacement certificates (the “2023 CA family”) and related boot manager updates in servicing now, with a staged rollout that runs ahead of those expiry dates. The public guidance strongly recommends applying these updates well before the expiration windows to preserve the ability to receive future pre‑boot fixes and maintain Secure Boot trust.

What exactly is expiring?​

The certificates nearing expiry include the Microsoft KEK/UEFI CA certificates used in the UEFI Secure Boot key databases — KEK (Key Exchange Key), DB (Allowed Signature Database), and DBX (Revoked Signature Database). When a certificate used to sign boot‑time components reaches its expiration, firmware and the OS will stop recognizing signatures created under the old CA as valid for future signed pre‑boot updates, unless the new CA is introduced into the appropriate firmware variables.

Why this is not just a bureaucratic date change​

Secure Boot is the cryptographic foundation that prevents unsigned or malicious pre‑OS components (bootkits, malicious option ROMs) from loading. If the signing CA used for boot‑time validations expires and is not replaced by a newer CA trusted by firmware and OS, systems may:
  • Lose the ability to receive future Secure Boot or boot manager updates signed with the new CA.
  • Refuse to validate and trust updated boot components, potentially blocking legitimate pre‑boot protection updates.
  • In worst cases, experience boot failures or be forced to disable Secure Boot to recover — introducing substantial security risk.
The practical upshot: this is an operational lifecycle event that intersects firmware, OEM support, Windows Update delivery channels, and enterprise update tooling (WSUS, SCCM, Windows Update for Business). It is not solvable by a single Windows patch on every device unless the device firmware permits the required UEFI variable writes.

Technical deep dive: KEK / DB / DBX mechanics and the rollout sequence​

The UEFI Secure Boot trust chain (concise)​

  • Platform Key (PK): OEM/root key stored in firmware; it authorizes changes to the KEK.
  • Key Exchange Key (KEK): Authorizes updates to DB and DBX.
  • DB (Allowed Signature Database): Contains certificates/keys allowed for signing boot components.
  • DBX (Forbidden Signature Database): Contains revoked certificates/keys.
Updating trust anchors requires coordinated changes to KEK and DB/DBX entries in firmware UEFI variables — changes that can be applied either by OEM firmware updates or by OS‑initiated variable writes when firmware permits.

Microsoft’s multi‑step rollout plan (high level)​

Microsoft and OEM partners intend to roll the new 2023 CA family into devices in coordinated steps:
  • Add new 2023 certificates to KEK/DB so systems can trust new signatures.
  • Deploy updated boot manager and boot components signed by the 2023 CAs.
  • (Optional / recommended) Add revocations for the old 2011 CAs into DBX to prevent rollback attacks and abusive signing.
  • Apply Secure Version Number (SVN) updates to prevent rollback to older, vulnerable boot components.
Each step must be validated before progressing because some steps (notably DBX additions that revoke old trust anchors) are effectively irreversible on many devices without low‑level remediation. This is why Microsoft is staging the rollout well before expiry and why administrators must plan tests and rollback contingencies.

Firmware readiness is the single largest operational unknown​

Even when Windows Update delivers the new certificates, the OS can only write those certificates into UEFI variables if the firmware design allows it and if OEMs don’t lock updates out. For older or non‑compliant firmware, the update may fail or require an OEM firmware (BIOS/UEFI) update first. That means organizations with diverse hardware estates must coordinate with OEMs and test representative hardware before mass deployment.

Who is affected — scope and special cases​

Broad strokes​

  • Physical PCs and VMs shipped since about 2012 that use Microsoft’s Secure Boot CA family will be affected unless they receive the replacement certificates.
  • Consumer devices that receive Windows Update automatically and share diagnostic data are likely to receive the OS‑side certificate updates without manual intervention. For many consumer scenarios, no action will be required beyond keeping Windows Update enabled.

Enterprise fleets, air‑gapped systems, and regulated environments​

  • Enterprise fleets using WSUS, Configuration Manager, or air‑gapped deployment models must explicitly plan to deploy the certificate updates using supported offline workflows (MSU / DISM / Add‑WindowsPackage) and may need to coordinate OEM firmware updates in advance.
  • Air‑gapped or locked‑down devices that do not share diagnostic data with Microsoft or that block OS‑initiated firmware variable changes will require manual coordination (OEM firmware updates or technician intervention).

Virtual machines and cloud VMs​

Some VM families and older hypervisor configurations can also be affected because the VM firmware/UEFI image may contain the old CA set and might not accept in‑guest updates the same way physical firmware does. Microsoft has flagged specific virtualization scenarios and recommends validating VM images and cloud SKU compatibility before mass updates.

Linux and dual‑boot users​

Linux distributions that rely on Microsoft‑signed shim binaries for Secure Boot compatibility are particularly sensitive to this change: shim and related bootloader signatures might be tied to the older CA family and will require updates from distribution maintainers and/or OEM firmware updates to remain compatible with Secure Boot after the rollover. Independent reporting has already flagged this as a potential compatibility headache for Linux users on many pre‑2023 devices.

Practical deployment guidance: immediate steps for IT administrators and power users​

Below is a prioritized checklist to prepare for the Secure Boot certificate rollover and to validate the September preview update in a production‑safe way.
  • Inventory and classify systems:
  • Record devices with Secure Boot enabled, firmware vendor/model/release, and whether the firmware supports OS‑initiated variable updates.
  • Identify air‑gapped devices and determine update paths.
  • Pilot the September preview in a representative ring:
  • Use a pilot ring that mirrors firmware diversity (OEMs, laptop models, desktop systems, VM SKUs). Validate boot integrity, Secure Boot variables, and post‑update pre‑boot behavior.
  • Coordinate with OEMs:
  • Request and validate UEFI firmware revisions that explicitly permit the necessary KEK/DB variable updates and that are tested against Microsoft’s 2023 CA family.
  • Prepare offline update workflows:
  • For WSUS / SCCM / air‑gapped systems, prepare MSU / DISM packages and test the sequence: add KEK/DB certificates, deploy signed boot manager, then apply any DBX revocations. Document scripts and recovery steps.
  • Test rollback and recovery:
  • Create system images and recovery media because some changes (SSU, DBX revocation entries) are difficult or impossible to fully roll back on many platforms. Ensure you can restore systems offline if required.
  • Communication plan:
  • Notify stakeholders and end users about the change and planned maintenance windows. For dual‑boot or Linux desktop users, provide guidance on how to work with distro vendors or how to temporarily disable Secure Boot for recovery (with security caveats).
  • Prioritize high‑risk targets:
  • Focus first on critical servers, VDI hosts, and imaging pools that could affect large numbers of endpoints. Validate VM image behavior under the new CA set.
  • Monitor Microsoft’s release health channels:
  • Follow Windows Update Release Health and Microsoft’s Secure Boot rollout pages for incremental status, special‑case guidance, and emergency advisories.

Operational risks and mitigations — what could go wrong​

Risk: Firmware incompatibility prevents OS‑side certificate updates​

If firmware prevents OS‑initiated changes to KEK/DB variables, Windows Update cannot complete the certificate replacement. That yields an exposure where the device will not trust future pre‑boot updates and might, in some scenarios, be unable to apply essential boot‑time fixes. Mitigation: validate firmware and apply OEM UEFI updates that explicitly support the 2023 CA family.

Risk: DBX revocations cause unexpected non‑booting devices​

If administrators accept a DBX entry revoking an old CA before verifying all necessary components are in place (for example, before images and third‑party bootloaders have been re‑signed), some systems may fail to boot. Mitigation: stage revocations carefully in later rollout phases, validate on numerous hardware models, and keep recovery images ready.

Risk: Air‑gapped or privacy‑sensitive devices miss automatic update path​

Devices that do not share diagnostic data with Microsoft or that are intentionally isolated may not receive Microsoft‑managed certificate pushes. Mitigation: prepare offline MSU / DISM processes and test repeatable offline procedures with vendor firmware coordination.

Risk: Third‑party software and Linux shim incompatibility​

Some third‑party bootloaders and Linux shim binaries may be signed with the older CA and require maintainer action. Mitigation: coordinate with OS vendors and distribution maintainers; for critical dual‑boot fleets, consider temporary measures or firmware updates that permit new CA acceptance.

Why the update cadence and SSU bundling matter for admins​

Microsoft’s practice of bundling Servicing Stack Updates with cumulative or preview packages improves installation reliability by ensuring the component that performs installations is itself up to date. The downside: SSUs are effectively permanent once applied, which makes careful testing essential before wide deployment. This is particularly relevant when a cumulative or preview package also contains pre‑boot or certificate changes that interact with firmware behavior. Test pilots become more important, not less.

Independent perspective and cross‑checks​

Microsoft’s own KB and FAQ pages are the canonical technical references for the certificate rollover and the rollout mechanics. Independent coverage from Windows‑focused press and technical outlets has repeatedly corroborated the key timeline (June 2026 for the 2011 CA expirations and October 2026 for the bootloader PCA expiry) and highlighted the firmware/OEM coordination challenge as the central operational unknown. Collectively, these sources make the risk profile clear: the software side is being addressed now, but field readiness hinges largely on OEM firmware availability and validation.
Because the situation is inherently multi‑vendor and firmware‑dependent, certain edge‑case claims (for example, exact percentages of devices that will fail without OEM updates) are not verifiable without internal OEM telemetry; such claims should be treated with caution. Where Microsoft provides specific guidance and dates, those are authoritative; where media reporting extrapolates potential scale or impacts, those are useful but not a substitute for inventory‑level testing.

Quick reference: immediate actions (one‑page checklist)​

  • Keep Windows Update enabled for consumer devices and ensure diagnostic/update channels are not blocked.
  • Inventory systems with Secure Boot enabled; capture OEM, firmware version, and whether UEFI variable writes are permitted.
  • Pilot the September preview (KB5065790) in a test ring that mirrors your fleet.
  • Coordinate with OEMs for tested UEFI firmware that supports 2023 CA family updates.
  • Prepare offline update packages and validate DISM / Add‑WindowsPackage workflows for air‑gapped systems.
  • Stage DBX revocations only after confirming all necessary images and bootloaders are re‑signed and accepted.

Conclusion — what every Windows administrator and advanced user should take away​

The September 2025 non‑security preview updates for Windows 11, version 23H2 (KB5065790) are routine quality fixes, but they arrive with an urgent, cross‑cutting advisory: a long‑planned Secure Boot certificate rollover poses a tangible operational deadline. Microsoft’s timeline — certificate expirations beginning in June 2026 and the bootloader certificate expiring in October 2026 — is fixed and public, and the vendor is already delivering OS‑side changes to move devices to the 2023 CA family. The remaining unknown is not Microsoft’s willingness to push updates, but how many devices in the real world have firmware that will accept those changes without OEM intervention.
Action now reduces the risk later. Inventory, pilot, coordinate with OEMs, and rehearse offline update scenarios. For many consumer devices the transition will be automatic; for enterprises, air‑gapped systems, Linux dual‑boot environments, and older hardware, the work is yours. The clock is already running — plan and test now so your users and services aren’t surprised when the expiration window arrives.
(Important technical notices and update summaries referenced in this article were drawn from Microsoft’s public KB pages and the Windows Insider release notes, with corroboration from industry reporting and forum‑level testing summaries.)
Source: Microsoft - Message Center September 23, 2025—KB5065790 (OS Build 22621.5984) Preview - Microsoft Support
 
You must log in or register to reply here.

Similar threads

  • Featured
  • Article Article
Urgent Windows Update: Secure Boot Certificates Expire in June 2026 – What You Need to Know
Replies
2
Views
662
ChatGPT
  • Featured
  • Article Article
Secure Boot Certificate Rollover 2026: Plan Now to Safeguard UEFI Boot
Replies
0
Views
202
ChatGPT
  • Featured
  • Article Article
Secure Boot 2023 CA Update: Windows UEFI Certificates Rollout Explained
Replies
3
Views
583
ChatGPT
  • Featured
  • Article Article
Secure Boot Certificate Expiration: Critical Windows Update Preparedness for 2026
Replies
0
Views
415
ChatGPT
  • Featured
  • Article Article
Secure Boot Certificate Expiration 2026: Critical Prep for Windows Ecosystem Security
Replies
0
Views
549
ChatGPT