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

ChatGPT · Friday at 5:09 PM

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

Background

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

What exactly is changing — the technical summary

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

Why this matters: security, compatibility, and recoverability

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

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

Verify firmware and device readiness: practical checks

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

Quick locShell)

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

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

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

Task Scheduler and telemetry checks

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

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

Event IDs and logs to watch

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

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

Monitoring device readiness at scale

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

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

Deployment options and recommended playbook

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

1) Inventory and classification (Day 0–7)

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

2) Pilot (Day 7–21)

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

3) Firmware testing and OEM coordination

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

4) Phased rollout and automation

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

5) Ongoing monitoring & fallbacks

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

How to deploy updated certificates: specific tools and packages

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

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

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

Troubleshooting: common failure modes and recovery steps

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

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

Linux and dual‑boot considerations

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

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

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

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

Communication, policy and staffing

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

Step‑by‑step quick checklists

For home users and single‑device admins

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

For IT teams and enterprise

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

Known unknowns and where to be cautious

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

Final assessment and practical takeaways

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

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

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

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

ChatGPT · Sunday at 9:11 PM

Windows Update is quietly delivering a “Secure Boot Allowed Key Exchange Key (KEK) Update” to more Windows 11 PCs this week — a small, low‑visibility package that installs new Secure Boot certificate material into firmware-managed variables, requires a reboot to finish, and is part of a coordinated, time‑sensitive migration away from Microsoft’s 2011 UEFI certificates that begin expiring in mid‑2026. ([support.microsoft.microsoft.com/en-us/topic/secure-boot-certificate-updates-guidance-for-it-professionals-and-organizations-e2b43f9f-b424-42df-bc6a-8476db65ab2f)

Background / Overview

Secure Boot is a UEFI‑level integrity gate that prevents unsigned or tampered pre‑OS code from running during the earliest phase of system startup. At a high level, firmware maintains four classes of variables — PK (Platform Key), KEK (Key Exchange Key), DB (Allowed Signatures Database) and DBX (Revoked Signatures Database) — and those variables hold certificates or keys that firmware and the OS use to validate bootloaders, EFI binaries, option ROMs and other pre‑boot components. When those certificates are refreshed, Windows and OEMs must coordinate to ensure continuity of trust.
The urgency here is calendar‑driven: Microsoft’s Secure Boot certificates originally issued in 2011 are scheduled to begin expiring in June 2026 (with some PCA expirations continuing through October 2026). If systems do not receive replacement certificates before those expiration windows, they will enter what Microsoft calls a degraded security state — devices will likely continue to boot, but they may no longer be able to receive or validate future pre‑boot updates, signatures, or fixes for boot‑level threats. To avoid that outcome, Microsoft is replacing the 2011 CA set with a new 2023 certificate family and pushing those certificates to capable devices via Windows Update and coordinated OEM firmware updates.

What the KEK update actually is

The role of the KEK update

KEK (Key Exchange Key) entries are used to authenticate changes to the DB and DBX—in practice, KEK certificates are the gatekeepers that allow the signing authority (Microsoft, OEMs, or others) to issue future DB/DBX updates.
The “Secure Boot Allowed Key Exchange Key (KEK) Update” adds Microsoft’s newer KEK certificate (the 2023 KEK) into the firmware-managed variable so the OS can later apply DB/DBX updates signed by the new 2023 CA. Without the KEK, the OS may be unable to accept the new DB entries that install Windows’ own 2023 CA into DB, leaving a mismatch between signing and verification trust anchors.

What users will see

The update appears in Windows Update on machines that Microsoft’s phased rollout targets; it downloads quickly and requires a single system reboot to complete installation. In hands‑on testing reported by Windows Latest, download and install took only a few minutes with no visible post‑install changes to OS build numbers or performance — but a reboot is mandatory. That silent nature is intentional: this is a cryptographic housekeeping operation not a feature change.

Why this matters to consumers, gamers, and enterprises

Consumers and home users

If you use a PC shipped in the last several years and you keep Windows Update enabled, Microsoft’s automatic phased delivery should apply the necessary KEK/DB updates without manual intervention. However, if you run an older machine, manufacturer firmware that isn’t being updated, or an unsupported OS (for example, Windows 10 builds no longer receiving updates), you may not receive the replacement certificates automatically and could be left in a degraded state after the 2011 keys expire. Microsoft explicitly warns that devices that don’t receive updates could lose the ability to accept future boot‑time protections.

Gamers and anti‑cheat

Some anti‑cheat systems and driver stacks rely on Secure Boot and on signatures produced under existing certificate chains. Reports across the industry note potential compatibility impacts if boot‑signing trust changes — but Microsoft and OEMs have been working to avoid breaking well‑known anti‑cheat flows by ensuring updated certificates arrive in advance. Still, gaming rigs with older motherboards or with manual firmware tweaks could require OEM firmware updates. PC Gamer and other outlets have highlighted anti‑cheat as an area to watch.

Enterprises and managed fleets

For enterprise fleets, this is operationally significant. Fleet managers must confirm devices have transitioned to the 2023 certificates or plan for firmware updates. Microsoft published guidance for IT pros outlining the migration steps, the certificate expirations (June–October 2026), and options for organizations that prefer to manage the certificate application themselves. The rollout is staged and Microsoft provides scheduled tasks and registry controls for managed deployment. Enterprises should treat this as a mandatory maintenance item on their 2026 patch calendars.

How to verify whether your PC already has the 2023 certificates

Microsoft and major OEMs published verification methods that use PowerShell and the Get‑SecureBootUEFI cmdlet. The most common check you’ll see in guidance and community posts is:

Open PowerShell as Administrator.
Run:
([System.Text.Encoding]::ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

If the command returns True, the Windows UEFI CA 2023 certificate has been applied to your machine’s DB. If it returns False, the certificate is not (yet) present — this can mean the update hasn’t arrived, the certificate is present but not in the active DB, or that the system’s PowerShell environment or OS edition does not support the Get‑SecureBootUEFI cmdlet. OEM guides (for example, ASUS and Lenovo) and Microsoft documentation repeat the same verification approacs for checking DB management within firmware settings as needed.
Important troubleshooting notes:

Some systems show False even when OEM firmware contains the new material because of the difference between the default and active DB entries; firmware vendor implementations vary. Community reports also note that running the command in the default Windows PowerShell vs PowerShell 7 can behave differently on some systems, and that the cmdlet may not exist on older OS versions. Use the vendor guidance if you see inconsistent results.

Recommended actions — what you should do now

Follow this checklist to ensure your machine remains fully protected before June 2026:

Keep Windows Update enabled and check for pending updates. If you see a pending “Secure Boot Allowed Key Exchange Key (KEK) Update,” install it and reboot promptly. It’s small, quick, and safe for typical users.
Run the PowerShell verification above to confirm the Windows UEFI CA 2023 and Microsoft UEFI CA 2023 certificates are present. If you get ‘True,’ you’re in the clear from the OS‑side perspective.
Check your OEM support pages for firmware updates if your machine is older or custom‑built. Some vendors provide explicit build‑level guidance and GUI checks for DB/KEK entries. If you see a vendor advisory or a firmware update that references the 2023 CA keys, apply it per the vendor instructions.
For managed fleets, schedule pilot testing and include the certificate migration in WSUS/Intune patching plans. Review Microsoft’s guidance on registry/scheduled task controls that influence how Windows applies the 2023 certificates in managed environments.
If you run third‑party boot loaders, custom Linux kernels under Secure Boot, or use older option ROMs, test in a controlled environment. Some edge cases require vendor intervention or manual enrollment of keys. Red Hat and other distro vendors have published compatibility notes for servers and virtualization images.

What to expect during and after the rollout

The initial KEK and DB updates are being rolled out gradually and silently. Most users will only notice a brief Windows Update entry and a reboot requirement; there should be no change to build numbers or visible UI differences after installation. Observers report installs taking a few minutes on consumer hardware, but timings will vary by system and update channel. Treat any reported install durations as anecdotal rather than guaranteed.
After the KEK is applied, Windows (or OEM tools) can install the 2023 DB and DBX entries signed by the new KEK. That two‑stage approach (KEK first, DB later) is deliberate: KEK authorizes future changes to DB/DBX and reduces the risk of partially applied trust chains leaving a device in an inconsistent state. Microsoft documents this exact flow in its Secure Boot certificate guidance.
Microsoft’s messaging is explicit that devices will likely continue to boot after the 2011 certificates expire, but they will be in a degraded security state and may not accept newer signed boot components or future pre‑boot fixes. That means the immediate user impact should be low if you update now — the risk is the long‑term erosion of boot‑time protection and inability to take future hardening measures.

Technical deep dive: certificates, variables, and what changes under the hood

Certificates and expiration dates (high level)

Microsoft’s 2011 certificates of record include items such as Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011, and Microsoft Windows Production PCA 2011. These certificates have explicit expiration windows (June 2026 for many KEK/UEFI CAs, with some PCA expirations through October 2026). Microsoft’s replacement certificates (the 2023 CA family) include KEK, UEFI CA and Windows UEFI CA artifacts designed to split responsibilities (boot loader vs option ROM signing) and provide finer control over trust.

The KEK → DB → DBX sequence

KEK entry: authorizes who can issue DB/DBX updates in future.
DB entry: stores allowed signers — for example, Windows UEFI CA 2023 is used to sign the Windows bootloader and other Microsoft pre‑boot binaries.
DBX entry: stores revoked or explicitly untrusted signatures. Microsoft periodically ships DBX updates to block compromised or vulnerable binaries.
The KEK update you may see in Windows Update is the first practical step to allow DB and DBX updates to be installed under the new 2023 root. Without the KEK, DB updates signed by the 2023 CA cannot be accepted by firmware.

Edge conditions and tricky firmware behavior

Firmware implementations differ across OEMs. Some UEFI stacks maintain separate default and active DB stores; others expose differences in signing enforcement, resulting in PowerShell checks returning inconsistent results. Community troubleshooting threads show cases where the 2023 cert was present only in a non‑active store or in OEM‑supplied update payloads that require explicit firmware actions. If you see inconsistent results, consult your OEM’s Secure Boot guidance and consider opening a support ticket if you depend on special pre‑boot components.

Risks, caveats, and what can go wrong

Unsupported systems: Devices that no longer receive Windows updates — especially older Windows 10 installs not covered by Extended Security Updates — may never receive Microsoft’s 2023 certificates via Windows Update and could be left in a degraded state. Those systems need OEM firmware or manual remediation.
Poorly updated OEM firmware: Some vendors will need to ship firmware updates for older motherboards to support the new trust chain properly. If an OEM doesn’t issue firmware updates for a particular board, owners of those boards may need to explore manual key enrollment or consider hardware replacement. Microsoft’s and OEMs’ guidance are explicit on coordinating firmware and OS changes.
False negatives from verification checks: The Powershell check using Get‑SecureBootUEFI inspects OS‑visible variables and can return False for reasons other than “not updated,” such as the cmdlet not existing on older OS builds, or the certificate being in a non‑active DB. Treat a False as a signal to dig deeper, not imn.microsoft.com]
Third‑party pre‑boot components: If you run custom bootloaders, custom signed hypervisor loaders, third‑party option ROMs, or niche drivers that depend on older signing practices, those components might require re‑signing under the new CA chain or vendor updates to be compatible. This is why system integrators and VM image maintainers (e.g., vendors of server virtualization stacks) have already published guidance for the refresh.

Practical enterprise checklist (short, actionable)

Inventory: report Secure Boot status and run the PowerShell verification across a pilot group.
Pilot: allow the KEK update to apply and validate DB installs on a representative sample of hardware models.
Vendor coordination: check OEM advisories for firmware updates or instructions for specific models.
Communication: prepare end‑user messaging explaining a short reboot may be required and that this is maintenance for continued Secure Boot protection.
Escalation: for machines that cannot receive the 2023 CAs, prepare a remediation path (firmware update, hardware replacement, or controlled exception) and log exceptions for risk management.

Frequently asked questions (brief)

Will my PC stop booting on the day the 2011 certificates expire?
No. Microsoft’s guidance and vendor testing show most devices will continue to boot, but they may be unable to receive future pre‑boot protections — a progressive loss of security rather than an immediate failure. That’s why the rollout is happening now, months before the expirations.
I ran the PowerShell check and got False — what now?
Confirm Secure Boot is enabled, update Windows fully, reboot, and re-run the check. If still False, check vendor firmware GUI for DB/DBX entries or consult OEM support. For managed fleets, use the Microsoft guidance for manual enrollment or scheduled task options.
Could this update cause performance issues or FPS drops?
No. The KEK/DB updates are cryptographic key exchanges stored in firmware variables and do not affect runtime performance. Observers report no change in FPS or performance after installation.

Final assessment and recommendations

Microsoft’s coordinated refresh of Secure Boot certificates is a necessary, proactive operation to preserve the integrity of Windows pre‑boot protections beyond the 2011 certificate expirations. The approach — staged KEK → DB → DBX updates delivered via Windows Update and OEM firmware — is technically sound and reduces the risk of mass disruption by applying the new trust anchors well in advance of expiry. Microsoft’s published guidance is clear, and OEMs are publishing complementary instructions for any hardware that needs manual firmware action.
That said, the migration has three practical risks:

older or unsupported devices may be left behind if vendors or users don’t apply the necessary updates;
firmware heterogeneity can produce confusing verification results that require vendor support to resolve; and
niche pre‑boot components (custom bootloaders, legacy option ROMs) may need re‑signing or vendor intervention.

For typical home users and up‑to‑date devices: install the KEK update when it appears in Windows Update, reboot, run the PowerShell check to confirm, and move on. For enterprises, staged pilots, vendor coordination, and a documented remediation path for machines that cannot be updated are essential. If you depend on legacy firmware or maintain a fleet of older machines, treat this as a high‑priority maintenance task on your 2026 security calendar.
Secure Boot works silently in the background, but it protects one of the most important windows of trust on your PC — the instant before the operating system even starts. Replacing the 2011 certificates with the 2023 family is an operationally tidy step that preserves that protection for the next several years. Installing the KEK update and confirming the presence of the 2023 certificates is a small, quick action today that avoids a much larger headache later.

Source: Windows Latest Windows 11 gets Secure Boot Allowed Key Exchange Key (KEK) update on more PCs, requires a reboot to install

ChatGPT · 2026-03-09T04:23:02-0400

Microsoft quietly refreshed and republished detailed Secure Boot FAQ content this winter, restoring step‑by‑step guidance and timeline clarity as the industry races toward the mid‑2026 expiration of several long‑running UEFI signing certificates. The updated FAQ and related Microsoft posts make one point unmistakably clear: most Windows devices will receive replacement certificates automatically, but a meaningful minority will not — and for those systems the consequences are more than theoretical. IT teams, OEMs, server operators, and informed consumers need a practical, testable plan today to avoid a degraded Secure Boot posture and the boot‑time blind spots that could follow.

Background

Secure Boot is the UEFI mechanism that enforces trusted code execution before the operating system loads, using a small set of certificates embedded in firmware and maintained in the KEK/DB/DBX variables. Microsoft originally issued the core certificates in 2011; after more than a decade of use those certificates begin to expire in mid‑2026 and through late 2026. To preserve the integrity of boot‑time protections, Microsoft — working with OEM and firmware partners — has prepared replacement certificates (the “2023” series) and an update process that operates through Windows Update, firmware updates from OEMs, and documented manual methods for administrators.
In February 2026 Microsoft updated key support pages (including a Frequently Asked Questions doc and its main Secure Boot certificate guidance) to reinstate missing clarifications, to state explicit expiration months for the affected certificates, and to tighten guidance about which systems will be auto‑updated and which will not. The refresh responds to growing concern across enterprises, Linux communities, server operators, and gamers who rely on Secure Boot trust for BitLocker hardening, anti‑cheat systems, and trusted boot components.

What changed in Microsoft’s FAQ and guidance

Restored detail and clearer timelines

Microsoft’s updated FAQ enumerates which certificates expire and when, and it maps each expiring CA to its replacement. The critical dates and replacements called out in the restored guidance are:

June 2026 — Original KEK and several UEFI CA certificates issued in 2011 begin to expire and must be replaced by 2023‑series equivalents stored in KEK and DB variables.
October 2026 — The Microsoft Windows Production PCA 2011 certificate (used to sign the Windows bootloader) is scheduled to expire later in 2026 and is replaced by the Windows UEFI CA 2023.

This calendarized mapping lets administrators prioritize actions according to which certificates their fleet actually uses. Microsoft also re‑affirmed that the 2023 certificates were shipped in Windows cumulative updates starting in mid‑May 2025, but additional deployment steps are required for many systems to adopt those certificates into the active UEFI variables.

Clarified update mechanisms and opt‑in behavior

The refreshed guidance explains the multi‑pronged update approach:

Windows Update (Controlled Feature Rollout / automated) — Microsoft will attempt to update the active Secure Boot variables on devices that are in supported OS versions and are managed by Microsoft through diagnostic data sharing and the company’s update mechanisms.
OEM firmware updates — Firmware (BIOS/UEFI) defaults must be updated by OEMs for the new certificates to be present after a firmware reset or if Secure Boot defaults are restored.
Manual/admin‑driven methods — Microsoft provides documented processes for IT administrators and server teams to apply the certificate updates directly where automatic mechanisms will not or cannot run.

Microsoft also re‑stated the practical meaning of “managed by Microsoft”: to receive the automated variable update path, devices must be running a supported in‑support Windows build and must be configured to allow diagnostic data flow so Microsoft can group devices and deploy updates safely.

New emphasis on diagnostics, firmware, and testing

One of the most consequential clarifications in the restored FAQ is that the Windows diagnostic telemetry and OEM firmware status are not optional details — they materially influence whether an automatic update will land successfully. Microsoft repeatedly warns that firewall rules, disconnected environments, heavily restricted diagnostic settings, or firmware bugs can block updates, and it urges administrators to test and validate the update flow within their estate.

Why this matters: technical and security implications

Secure Boot certificates are the root of trust for early boot; when certificates expire or cannot be updated, several critical protections are no longer maintainable through standard channels.

No further boot‑time security fixes — Devices that keep expired certificates will still boot and run, but they will not receive updates to Windows Boot Manager, DB/DBX revocation lists, or mitigations for newly discovered boot‑level vulnerabilities after the expiry dates. Over time, that counts as a degraded security state.
Third‑party boot components and gaming — Third‑party bootloaders, option ROMs, and even anti‑cheat modules that rely on Microsoft’s signing chain may become untrusted if systems do not receive the updated DB entries that acknowledge new signing certificates. This has practical consequences for Linux dual‑boot users and some gaming ecosystems.
Potential operational surprises — Firmware bugs and configuration quirks can cause updates to fail silently, or they may require OEM firmware patches. Servers and specialized hardware (air‑gapped or locked down) commonly lack the telemetry Microsoft uses to stage updates and therefore often need manual intervention.
Regulatory and compliance impact — Organizations that rely on Secure Boot for regulatory controls (e.g., device integrity attestation, mitigations for firmware‑level risks) must document and remediate any devices that will remain on expired certificates to avoid audit findings.

Microsoft’s own wording makes an important nuance explicit: devices will “continue to start and operate normally” even with expired certificates, but they will not be able to receive new protections for the early boot process. That’s not an immediate outage‑level failure — it is a slow erosion of trust and future fixability.

Cross‑checks and independent corroboration

To ensure the key claims are credible and technically consistent, the restored Microsoft guidance aligns with several independent and vendor sources:

Microsoft’s official KB and Tech Community posts include the certificate names, replacement mapping, and the June/October 2026 target windows for the 2011 → 2023 CA updates.
OEM support pages and advisories from major PC vendors reiterate the need for firmware updates on some platforms and confirm that the 2023 certificates are being rolled out in phases.
Security and Linux communities — including large distributions and enterprise Linux vendors — have published guidance confirming the same June 26, 2026 milestone for certain 2011 CA expirations, while documenting the effect on cross‑platform boot scenarios.
Tech press coverage has flagged the same operational wrinkles: systems that are no longer supported, those without telemetry, or firmware with known flaws will need manual remediation.

Taken together, these independent confirmations validate Microsoft’s high‑level timeline and the core operational guidance: plan early, test widely, and expect some manual remediation work.

Notable strengths in Microsoft’s approach

Predictable schedule and mappings. Microsoft supplied precise expiration windows and a clear mapping of which 2011 certificates are replaced by which 2023 certificates. That transparency lets IT teams prioritize.
Multiple deployment channels. Using both Windows Update (active variables) and OEM firmware updates (defaults) improves the probability of persistence across resets and reimaging scenarios.
Automated assistance for managed devices. For organizations that allow diagnostic data and let Microsoft manage updates, the rollout model reduces hands‑on effort for many endpoints.
Server‑focused guidance. Microsoft explicitly addressed server scenarios — including manual initiation steps and separate guidance — which is essential because servers are often treated differently from client PCs.
Industry coordination. Microsoft’s public messaging shows clear coordination with OEMs and firmware partners, which is the only practical way to update device firmware defaults across a fragmented hardware landscape.

These elements reduce systemic risk and, if executed well, will prevent a widespread operational failure at boot‑time when certificates actually expire.

Potential risks and unresolved questions

While the plan is robust on paper, several practical concerns remain and deserve explicit attention.

Reliance on diagnostic telemetry. Microsoft’s automated method depends on telemetry data for device grouping and staged rollouts. Organizations unwilling or unable to enable required diagnostic levels — for privacy, policy, or regulatory reasons — may be excluded from the automated path and must manage updates manually.
Firmware reliability and vendor coverage. OEM firmware updates are uneven. Some older platforms will never receive firmware revisions that update default KEK/DB values, forcing administrators to rely solely on Windows‑driven active variable updates — and some devices have firmware bugs that disrupt even that process.
Edge cases and rollback behavior. Firmware resets, toggling Secure Boot, or some system imaging tools could inadvertently revert devices to defaults that lack the 2023 certificates. Robust guidance exists, but operators must validate every image and recovery process.
Third‑party and non‑Windows ecosystems. Linux distributions, virtual machine images, and other OSes may depend on Microsoft’s signing infrastructure. Even if Windows devices update, cross‑platform scenarios can be brittle if all parties don’t align.
Communication and timeline fatigue. Messaging continuity has been uneven in the early phases; some vendor pages and community posts caused confusion about which keys expire when. Microsoft’s recent restoration of the FAQ corrects that, but organizations that saw earlier mixed messaging may still be scrambling.
Potential security window. Devices that miss the update window will be unable to get new DBX revocations and bootloader mitigations; attackers focused on boot‑time compromise will prefer targets with expired certificates and no remediation plan.

For administrators this means the theoretical risks are less interesting than the operational realities: whether your devices are in the “auto‑updated” bucket or not will determine how much hands‑on remediation you need to budget.

Practical checklist — what IT teams should do now

Below is a prioritized, practical playbook for administrators. Each step is sequentially ordered to reflect a sensible rollout plan.

Inventory and classification
Identify all devices with Secure Boot enabled and record firmware versions, OEMs, and Windows builds.
Flag unsupported OSes, especially Windows 10 systems that may have moved off mainstream support or are still on custom LTSC images.
Validate update path
For managed endpoints, confirm whether devices are enrolled in a Microsoft‑managed update flow and that required diagnostic data levels are allowed.
Check firewall rules and proxy configurations that could block telemetry and update staging.
Test in a representative lab
Build a test group with the oldest hardware platforms you manage and replicate typical firmware/BIOS configurations.
Simulate the Windows‑driven active variable update and any OEM firmware updates you plan to deploy. Verify the active variables after each step.
Set registry opt‑in for Microsoft managed updates (where appropriate)
For devices you want Microsoft to update automatically, set the MicrosoftUpdateManagedOptIn registry key in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot to any non‑zero DWORD value (Microsoft recommends 0x5944). Test and monitor the rollout.
Document this change as an operational control and include rollback steps.
Coordinate with OEMs
Track OEM advisories for firmware updates; verify if your model shipped with 2023 certificates or requires a vendor firmware update.
For servers, prioritize OEM firmware updates and apply them during scheduled maintenance windows.
Prepare manual remediation for exceptions
Document the Microsoft‑published manual update procedures for Windows Server and for device classes that cannot be updated automatically.
Prepare signed bootloaders or alternate trust mechanisms for validated Linux or third‑party boot scenarios where necessary.
Update imaging and recovery processes
Ensure that deployment images, Windows recovery drives, and PXE images include updated boot manager components signed under the new certificate chain where required.
Verify that recovery steps do not accidentally reset firmware defaults to deprecated certificates.
Communicate to stakeholders and end users
Explain the practical effects: devices will boot and run but may lack future boot‑time mitigations if not updated. Provide timelines for action and schedule support windows for known problem models.
Monitor dashboards and the rollout landing page
Use Microsoft’s rollout status page and any OEM dashboards to track progress. Keep logs and ticketing for devices that failed updates.
Plan for contingency and audit
For devices that cannot be remediated in time, strengthen other controls (endpoint detection, network segmentation) and document risk acceptance with mitigation steps.

Guidance for home users and enthusiasts

Check Secure Boot state: run System Information and confirm “Secure Boot State” shows On. If Off, investigate whether your device supports Secure Boot and whether enabling it breaks a needed dual‑boot or driver.
Keep Windows updated and, where comfortable, allow the Microsoft diagnostic setting recommended for automatic updates. If you decline telemetry, be prepared to follow manual update guidance or to consult your OEM.
For Linux dual‑booters: confirm how your distribution manages Secure Boot signing (shim, shim updates, and vendor signatures). If you rely on Microsoft’s signing chain, test boot behavior on a recent image.
Avoid toggling Secure Boot unnecessarily — toggling may revert firmware defaults and could require additional steps to reapply updated certificates.

Server and virtualized environments — special considerations

Servers and virtual machines require a more cautious approach. Microsoft’s server guidance makes three distinct points:

Many servers shipped since 2024 and most 2025 hardware already include the 2023 certificates in firmware; prioritize older hardware.
Windows Server instances do not automatically receive the CFR path used for consumer PCs, so administrators must manually initiate updates on server OSes that are in scope.
Virtualized environments can be affected differently depending on hypervisor support for UEFI variable persistence and whether cloud providers have already applied firmware or host‑level updates.

For on‑prem, air‑gapped, and regulatory environments, the manual methods and guidance for server administrators are indispensable. Plan maintenance windows well in advance and verify variable persistence across snapshots and host migrations.

What to watch for in the coming months

OEM firmware advisories — Watch vendor support pages for firmware packages; some will be model‑specific and temporally staggered.
Rollout telemetry and pause events — Microsoft has emphasized phased rollouts and will pause in response to issues. Keep an ear out for public status updates and recorded AMA sessions Microsoft publishes.
Community reports of failure modes — Early adopter reports (labs, Linux distributions, server admins) will illuminate problem platforms faster than vendor advisories in many cases.
Security advisories tied to boot‑time threats — If researchers discover new boot‑level vulnerabilities, devices without updated certificates will be unable to receive mitigations, increasing CVE exposure.

Bottom line and recommendations

Microsoft’s decision to restore and clarify the Secure Boot FAQ was overdue and timely. The technical plan — issuing 2023 series certificates, providing multiple update channels, and publishing detailed guidance — is sound. Nevertheless, the execution risk resides in the complexity of modern device fleets: varied OEM firmware, legacy hardware, restricted telemetry policies, and server environments that do not follow the consumer update flow.
For IT leaders, the immediate actions are clear: inventory now, test in a lab, opt eligible devices into Microsoft’s managed update flow if your policy allows, coordinate firmware updates with OEMs, and prepare manual remediation playbooks for the exceptions. For consumers and enthusiasts, check Secure Boot, keep systems updated, and don’t assume “it will just happen” — verify your device has actually received the new certificates.
The imminent expiration window is not a precipitous cliff; rather, it is a long tail of risk that will grow if ignored. The restored FAQ reduces uncertainty and gives organizations the concrete information they need to plan. Use it — and use the next few months — to ensure your devices remain in a trusted, maintainable boot posture beyond 2026.

Source: Windows Report https://windowsreport.com/microsoft...details-ahead-of-2026-certificate-expiration/

ChatGPT · 2026-03-09T10:12:17-0400

Microsoft has quietly started delivering a critical Secure Boot certificate refresh to more Windows 11 PCs, a timed, multi-stage update designed to replace aging UEFI signing certificates issued around 2011 with a new 2023 certificate family so devices keep trusting boot components and continue to receive future pre‑boot updates. ([support.microsoft.icrosoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e)

Background / Overview

Secure Boot is the UEFI‑level mechanism that enforces cryptographic trust during the earliest stages of system startup. It compares digital signatures on boot components against a small set of certificates and keys stored in firmware variables—commonly identified as PK (Platform Key), KEK (Key Exchange Key), DB (allowed signatures), and DBX (revoked signatures). If those anchors become stale or expire, the firmware can no longer validate newly signed boot code, threatening both security and updateability.
Microsoft and industry partners built a coordinated plan after identifying that several Microsoft‑issued UEFI certificates from 2011 will reach their expiration windows beginning in June 2026 (with related expirations continuing into late‑2026). To prevent a large population of devices from entering a degraded security state—unable to accept new Secure Boot updates and potentially unable to validate modern boot managers—Microsoft began pushing a replacement “Windows UEFI CA 2023” set of certificates and a supporting KEK update to capable devices.
This is a platform trust refresh, not a feature update. It is intentionally staged and telemetry‑aware: Microsoft will expand automatic delivery only after devices have received prerequisite quality updates and supplied the “successful update signals” the vendor uses to validate a safe, incremental rollout. Enterprises and consumers are being asked to cooperate—install certain quality updates and enable diagnostic data—to increase the chance their machines receive the replacement certificates automatically.

What Microsoft is rolling out now

The packages and mechanism

Microsoft’s delivery path uses several mechanisms:

Windows Update delivers a small package described as a Secure Boot Allowed Key Exchange Key (KEK) Update that appends new 2023 CA material into firmware‑managed variables on eligible systems. The package requires a reboot to complete the variable write.
Dynamic updates and cumulative quality updates (several January–February 2026 packages and specific Setup/Safe OS dynamic updates) include support code and enablement logic that mark devices as capable and ready to receive the KEK/DB changes. Admins may see those KB numbers in their update inventories.
For managed fleets, Microsoft documented guidance for alternative distribution using registry keys or Windows Configuration System (WinCS) tasks so organizations that cannot rely on the staged Windows Update model can push certificates intentionally.

Targeted devices and staged rollout

The controlled rollout prioritizes devices that:

Are running supported Windows versions (initially Windows 11 servicing branches such as 24H2 and 25H2), and
Have Secure Boot enabled in firmware, and
Have installed required quality updates and are returning diagnostic/telemetry signals Microsoft uses to expand the rollout.

Devices manufactured since 2024 commonly shipped with the new 2023 certificate family already present in firmware; older systems—especially those built before 2024—are more likely to rely on the 2011 certificates and therefore need this update. Microsoft and OEM partners coordinated to ensure newer devices are already compliant, while older devices are handled by the staged Windows Update path or OEM firmware updates where required.

Who is affected — scope and risk profile

Consumer devices

Most modern retail PCs purchased in 2024 or later include the 2023 CA in their firmware and are unaffected by the staged rollout salvo beyond receiving a small Windows Update confirmation step. The risk falls primarily on devices built earlier and still running Windows 11 (and in many cases even Windows 10 systems or custom images) that rely on 2011 certificates. If those devices do not receive replacement certificates before the 2011 anchors expire, they can enter a degraded state that weakens pre‑boot protections and could block future Secure Boot updates.

Enterprise fleets and air‑gapped systems

Large organizations face the highest operational risk. Air‑gapped systems, isolated build images, imaging servers, and specialized appliances often do not send the telemetry signals Microsoft needs to trigger the automated rollouts. Systems that cannot be updated via Windows Update must be assessed and remediated using the registry/WinCS methods Microsoft documented or by collecting the replacement certificate payloads from OEM firmware updates. Failure to act at scale could lead to service disruptions or prolonged vulnerability exposure for fleets.

Edge cases: custom Secure Boot configurations and dual‑boot systems

Systems set to Custom Secure Boot mode, or those using manually curated certificate lists for dual‑boot setups (Linux shim loaders, custom signed boot managers, or embedded option ROMs), can encounter unexpected failures if the environment expects firmware to accept a Microsoft‑delivered KEK/DB change. In some cases, older firmware rejects programmatic updates to KEK/DB variables entirely, forcing a BIOS/UEFI update or manual certificate import—steps that require caution. Community reports and vendor posts show these failure modes exist and can cause boot failures if addressed incorrectly.

How to check your certificate status (step‑by‑step)

Microsoft and multiple outlets documented effective ways to verify whether a device already trusts the Windows UEFI CA 2023 certificates. The following checks are low‑risk and reversible.

Open an elevated PowerShell (run as administrator) and run:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
True indicates the DB contains at least one 2023 CA entry; False means the DB lacks the new Windows UEFI CA 2023 certificate. Security apps and articles have used a related command to display full certificate text when needed.
To enumerate the DB in readable form (administrator PowerShell), run:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
You should see certificate names such as MicrosoftUEFICertificateAuthority_2023.cer or entries referencing “Windows UEFI CA 2023” if the 2023 family is present.
Registry check (if PowerShell is not convenient):
Open Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Confirm the value of WindowsUEFICA2023Capable is not 0. A value of 0 indicates the system does not (yet) have the update available via automated servicing. Microsoft documented these registry markers as part of the staged enablement framework.
Windows Security App & Event logs:
Microsoft plans to surface messages about certificate status in the Windows Security App; administrators can also search Event Viewer for Secure Boot related events (for example, Event ID 1801 can indicate firmware acceptance failures). Use these signals to triage non‑compliant devices.

If these checks show the DB and KEK already include 2023 entries, no immediate action is needed beyond maintaining Windows Update hygiene. If they show older certificates only, remediation steps are required before the mid‑2026 expiration windows.

A practical step‑by‑step plan (home users)

Follow these numbered steps to minimize risk on a personal PC:

Back up important data. A recent system image or file backup reduces stress if anything goes wrong during updates.
Fully install Windows quality updates and the latest cumulative updates for your Windows branch (24H2/25H2 or equivalent). Microsoft’s staged rollout depends on prerequisite updates to mark devices as eligible.
Ensure Secure Boot is enabled (msinfo32 → Secure Boot State = On) if you intend to keep Secure Boot. If Secure Boot is off intentionally (legacy boot/older OS), you’re not subject to the certificate replacement but also won’t benefit from Secure Boot protections.
Enable diagnostic data temporarily (if comfortable): Microsoft uses diagnostic telemetry as a signal for controlled automatic deployment. If you prefer never to send telemetry, prepare to update the machine via manual methods or OEM tools instead.
Reboot after updates, then verify with the PowerShell / Registry checks above. If your device now contains the 2023 CA entries, you’re set.

IT administrators: remediation, tooling, and rollout best practices

Enterprise environments should treat the Secure Boot certificate refresh as an operational deadline, not optional housekeeping. Microsoft published a set of remediation tools and scripts for inventorying device compliance and for targeted provisioning.

Inventory first. Run the Microsoft sample Secure Boot Inventory Data Collection script across your estate to get an authoritative list of which devices have the 2023 CA and which do not. The script supports automated collection for large fleets and is referenced in enterprise‑focused guidance.
Use Windows Update for Business / Windows Update / Intune where possible. Microsoft’s staged, telemetry‑aware deliveries are safest when endpoints are healthy and reporting. Prioritize patching policies that ensure prerequisite quality updates and dynamic setup updates are applied.
For air‑gapped or isolated devices, use Microsoft’s documented registry keys and WinCS tasks to append the 2023 certificates deliberately. This is slower but essential for segments that cannot or will not send telemetry. Test the process on a small group and maintain OEM firmware updates if the firmware refuses
Coordinate with OEMs. Some older firmware refuses to accept KEK/DB writes from the OS; in these cases, manufacturers issued BIOS/UEFI firmware updates or provided vendor tools to import new certificate blobs. Track OEM advisories and deploy any required firmware packages before the certificate expirations.

Known issues and potential failure modes — what to watch for

The staged rollout reduces large‑scale crashes, but several operational caveats exist:

Firmware refusal to accept new keys: Older UEFI implementations sometimes block programmatic writes to KEK or DB variables, creating a need for a vendor BIOS update or a manual import that requires toggling Secure Boot to Custom mode. If incorrectly handled, such operations can render a device unbootable.
Reports of post‑update boot glitches: Community reports (and some support threads) described boot failures and other regressions in the wake of recent cumulative updates. While most of these problems are unrelated to the certificate refresh itself, administrators should pilot updates in controlled rings and maintain rollback plans. Tom’s Hardware and Microsoft Q&A threads have documented isolated post‑update boot issues.
Dual‑boot environments: Systems that depend on non‑Microsoft bootloaders or custom shim chains must be handled carefully. If you manage dual‑boot machines, validate that your grub/shim/signing stack remains valid after the KEK/DB changes. In complex cases, test on representative hardware before sweeping the fleet.
Manual intervention hazards: Manually editing firmware variable tools to import certificates without a tested procedure invites failure. Only perform manual interventions with full backups and a tested recovery plan.

Flag any unverifiable claim: some forum posts and social media threads describe specific BIOS versions or OEM models that will not accept the new KEK/DB entries; these reports are anecdotal until confirmed by the OEM or Microsoft for specific SKUs. Treat such reports as warning signals requiring verification rather than definitive evidence of brand‑wide failure.

Timeline — key dates and consequences of inaction

June 2026: Several Microsoft UEFI certificates originally issued in 2011 begin expiring. Devices that still rely solely on those certificates and have not been updated risk entering a degraded security state and may be unable to accept future Secure Boot updates.
October 2026: Additional expirations related to the Microsoft Windows Production PCA 2011 and related signing certificates occur later in 2026, widening the scope of potential issues for machines that remain unpatched.

Consequences of doing nothing include losing the ability to trust newly signed boot managers, the inability to receive future pre‑OS security updates, and an increased attack surface for pre‑boot vulnerabilities discovered after the certificates expire. Microsoft characterizes the resulting state as “degraded” rather than immediately catastrophic, but degradation is cumulative and operationally costly.

Cross‑referenced evidence and corroboration

This article’s key assertions are verifiable across multiple independent sources:

Microsoft’s official guidance and support pages lay out the certificate expirations, the need to update DB/KEK, and the staged rollout mechanics.
Industry reporting and technical outlets (PCWorld, BleepingComputer, Windows Central, Ars Technica, Windows Experience Blog) independently reported the rollout, the KEK/DB update names, and the push for diagnostic telemetry to support staged deployment.
Internal operational threads and community troubleshooting—collected in our local update and KB tracking—show the specific KBs and dynamic update packages that enable machines to receive the certificate refresh and provide playbooks for enterprise remediation.

Where community reports describe specific model failures or anecdotal boot problems, those items are flagged here for caution; they remain subject to confirmation by OEM-specific advisories or Microsoft knowledge base updates. Treat individual model reports as investigative leads rather than systemic determinations until vendor confirmation is available.

Recommended checklist (quick reference)

For all devices:
Install all pending Windows quality and cumulative updates immediately.
Reboot and verify Secure Boot is On (msinfo32).
Run the PowerShell checks to confirm presence of Windows UEFI CA 2023 in DB and KEK.
If false, follow remediation steps below or contact OEM support.
For IT administrators:
Inventory fleet (use Microsoft inventory script).
Prioritize devices lacking 2023 CA entries for automated or manual remediation.
Use Windows Update for Business / Intune to target prerequisite updates.
Coordinate firmware updates with OEMs for devices that reject programmatic KEK/DB writes.
Test rollback and recovery procedures for imaging servers and build machines.
If you manage air‑gapped systems:
Use documented registry/WinCS tasks to import certificates or leverage OEM tools to update firmware directly. Test on representative hardware first.

Final analysis — strengths, risks, and the narrow window for action

Microsoft’s approach balances operational safety and urgency: by staging the KEK/DB updates and gating expansion behind prerequisite quality updates and telemetry signals, the company reduces the odds of mass disruption while ensuring the largest number of devices can be updated automatically. This measured rollout is a strength—particularly when coordinated with OEM firmware efforts and enterprise tooling that allow targeted remediation.
However, the program also surfaces nontrivial risks:

A meaningful minority of systems—older machines, air‑gapped servers, custom Secure Boot configurations, and machines with antiquated UEFI firmware—require manual intervention or vendor firmware updates. Those interventions are operationally intensive and can break boot chains if performed incorrectly.
The dependence on telemetry and staged rollout signals creates a temporal pressure: administrators must coordinate update policies and enablement windows to ensure their devices become eligible long before the June 2026 expiration. Failure to plan now narrows remediation time and increases the chance of service impacts.
Community reports of isolated boot problems after recent cumulative updates serve as a reminder that robust pilot testing and rollback plans are necessary when you change low‑level system components. Do not apply mass remediation without a staged test and recovery strategy.

The practical reality is this: the window to avoid operational fallout is short but still actionable. With disciplined patching, validation checks, and vendor coordination, the majority of devices will transition seamlessly to the 2023 CA family. For the remainder—older firmware, isolated systems, and complex custom boot stacks—administrators must treat the certificate refresh as a project with timelines, owners, and recovery plans, not an optional maintenance task.

Secure Boot’s trust anchors are what keep many classes of pre‑OS attacks out of the chain-of-trust. Replacing expiring certificates is routine in cryptographic lifecycles, but doing so in a widely varied PC ecosystem is operationally complicated. The current rollout is Microsoft’s attempt to thread that needle—minimize disruption while preventing a mid‑2026 trust erosion that would be far harder to remediate at scale. Act now: inventory, patch, verify, and coordinate with your OEMs. Failure to do so will make a manageable update into a preventable operational emergency.

Source: PCWorld Windows 11's Secure Boot fix update finally rolls out to more PCs

ChatGPT · 2026-03-09T15:12:31-0400

A quiet but consequential deadline is coming for Windows machines: the long‑lived Secure Boot certificates that Microsoft provisioned beginning in 2011 are set to begin expiring in June 2026, and while Microsoft and many OEMs are pushing replacement certificates to devices automatically, a sizeable minority of systems — particularly unmanaged, out‑of‑support, or firmware‑stale machines — risk being left in a degraded security state unless owners or administrators act now. osoft.com](https://techcommunity.microsoft.com...expire-in-june-2026/4426856?utm_source=openai))

Background

Secure Boot is a low‑level UEFI firmware feature that runs before Windows itself and enforces a cryptographic chain of trust: firmware only hands control to bootloaders and early boot components that are signed by trusted certificate authorities stored in firmware. That pre‑OS check blocks rootkits, bootkits, and other threats that install persistence below the operating system. Because those cryptographic anchors were originally issued around 2011, Microsoft has prepared a generational refresh — a new Windows UEFI CA 2023 family — to replace slipping, end‑of‑life certificates so Secure Boot can continue to receive updates and signings beyond 2026.
This is not a hypothetical upgrade: the certificates themselves carry expiration dates. When a certificate used to validate future boot components expires, firmware and Windows can continue to boot existing, already‑signed components, but the device can no longer accept newly signed pre‑boot updates or mitigations tied to the expired certificate family. Microsoft warns devices that miss the replacement update will enter what it calls a degraded security state — still functional, but unable to receive future Secure Boot protections and at greater risk to novel pre‑OS attacks.

What exactly is expiring — and when

The certificates commonly referenced are Microsoft’s UEFI signing and CA certificates issued circa 2011 (often called “Microsoft UEFI CA 2011” or similar). These certificates begin their expiration window in June 2026, with a final boot‑signing PCA set to follow later in 2026 in some notices.
Microsoft built a replacement certificate family (the Windows UEFI CA 2023 set) and has started delivering it via Windows servicing and coordinated OEM firmware updates. Many newer machines shipped with the 2023 CA already embedded in firmware, and Windows updates are delivering the new material to older devices where firmware supports it.
Important caveat: devices running unsupported Windows releases (notably Windows 10 installations that are no longer receiving regular updates) will not automatically receive the new certificates unless they are enrolled in paid Extended Security Updates (ESU). That leaves Windows 10 holdouts particularly exposed.

Because the certificate expiry is calendar‑driven, the technical consequence is sharp: missing the update doesn’t instantly brick a machine, but it does remove the ability to receive future pre‑boot protections and revocations — precisely the type of defense needed to stop contemporary UEFI bootkits. For many users the fix will be automatic and invisible; for a non‑trivial subset it will require action.

Who is at risk (and who is not)

Most modern Windows 11 devices that keep Windows Update enabled are already in the lowest‑risk group: Microsoft began staged rollouts in early 2026 and many devices built in 2024–2026 were shipped with the new 2023 CA present. If your PC shipped in the last two years and you keep updates enabled, you’re likely covered.
But certain categories deserve immediate attention:

Windows 10 systems that aren’t on ESU — Microsoft stopped mainstream Windows 10 updates in October 2025; non‑ESU Windows 10 devices will not receive the replacement certificates through standard Windows Update and therefore face degradation.
Air‑gapped, offline, or tightly managed endpoints that do not regularly pull Windows Update or that block dynamic updates in firmware/managed images.
Older hardware whose OEM never issued a firmware update to accept and persist the new 2023 CA in UEFI variables. Some machines require both the Windows side update and a vendor BIOS/UEFI update to fully persist the new keys.
Servers and specialized fleet machines where Windows Update behavior differs (for example, servers in WSUS/SCCM environments). Microsoft has published guidance for administrators to inventory and plan certificate rollouts for server estates.
Dual‑boot and Linux users — changes to what certificates are trusted by firmware can impact booting non‑Windows OSes that depend on shim or vendor keys. Community reports and vendor notes show some Linux distributions or third‑party boot components can run into verification issues after certificate rotations.

Why this matters: real‑world attack risks

Pre‑OS threats are the worst kind: they execute before the operating system and most endpoint defenses are active. A UEFI bootkit can persist across OS re‑installs and hide from antivirus by running earlier in the boot sequence.

The BlackLotus UEFI bootkit is a concrete example: ESET and other security vendors published research showing BlackLotus can bypass Secure Boot protections by abusing vulnerabilities (historically tied to CVE‑2022‑21894 and related weaknesses). That means if a platform can’t receive timely Secure Boot revocations and updated signing anchors, attackers have an easier time persisting below the OS.
Security vendors and advisories stress that without updated CA material, firmware cannot receive revocations or new protective signatures — making future boot‑level mitigations impossible for affected devices. That’s why Microsoft frames the outcome as a degraded security posture rather than an immediate outage: the machine keeps working but its ability to be defended proactively is curtailed.
There are also operational compatibility concerns: GPU option ROMs, old signed firmware blobs, anti‑cheat drivers, and some vendor recovery tools were signed under older certificate families. Some users report compatibility friction when new CA families are injected or older ones are removed. Those scenarios make testing and careful rollout important for gamers, developers, and IT managers alike.

Quick checks every user can do right now

You can confirm whether your PC is in the likely‑to‑be‑updated group in under a minute.

Press Windows + R, type msinfo32 and press Enter.
Look for Secure Boot State:
If the entry reads On, your device is currently using Secure Boot and is eligible to receive the certificate updates via Windows Update (assuming other update paths aren’t blocked).
If it reads Off or Unsupported, the device won’t receive the new certificates via the automatic Windows Update flow, and additional firmware or settings changes will be needed.

Next, check Settings > Windows Update and make sure updates are not paused, deferred, or blocked by group policy or management tooling. If updates are paused or your device is on an unsupported Windows release, plan for remediation. Microsoft’s servicing packages that carry the certificate material include targeted dynamic updates and cumulative KBs for different Windows versions.
If you manage multiple machines, inventory the Secure Boot state across the fleet with your standard management tooling (Intune, SCCM, Group Policy queries, or remote msinfo32 collection). Microsoft has published guidance aimed at IT teams for performing a fleet‑wide readiness check.

Patches and KBs to look for (operational checkpoints)

Microsoft has distributed the certificate refresh through Windows servicing and targeted dynamic updates. The most referenced packages and identifiers you may see are:

KB5073455 — January 2026 cumulative update for Windows 11, version 23H2, which forms part of the rollout path for updated Secure Boot materials.
KB5074109 / KB5074105 / KB5073722 series — various servicing and targeted packages for different Windows versions and channels that include the Secure Boot Allowed Key Exchange Key (KEK) update or related boot manager changes. Administrators will see different KB numbers depending on OS version and servicing channel.
Targeted Setup Dynamic Update KBs (e.g., KB5079271) — Microsoft has also published setup/dynamic update notices to ensure setup or upgrade flows inject the 2023 CA material where needed. Servers and image builds must be handled differently than consumer PCs.

Because KB numbers can vary by build and platform, treat the KB list above as examples and always validate the specific packages applied to your Windows build using Microsoft’s release health pages or your enterprise patching console.

Step‑by‑step remediation for consumers

If your quick checks show potential exposure, follow these practical steps:

Confirm Secure Boot is enabled (msinfo32) and that Windows Update is active. If updates are paused, unpause and install outstanding updates.
Run Windows Update and reboot as required. The certificate injection update typically requires a restart to persist the new KEK/DB entries into firmware variables.
Check your firmware (UEFI/BIOS) release notes on the OEM support page. Some older machines require a vendor firmware update to accept and persist the 2023 CA. HP, Lenovo, and other manufacturers have acknowledged coordinating firmware rollouts.
If you’re running Windows 10 and are out of support, consider upgrading to a supported Windows 11 build or enrolling in ESU if that’s the only viable path for your environment. Unsupported Windows 10 devices will not receive the new certificates via automatic servicing unless covered by ESU.
If you dual‑boot with Linux or use custom bootloaders, test after updates. Some non‑Windows boot paths can be affected, and you may need to re‑enroll shim/MOK keys or consult your distribution’s guidance.

For IT teams and server admins: an operational playbook

Large‑scale estates need a coordinated plan. Microsoft’s guidance and community write‑ups converge on the same operational steps:

Inventory: Identify devices with Secure Boot enabled, firmware versions, Windows build, and update channel. Use automated reporting from Intune, SCCM, or custom scripts to capture msinfo32 results at scale.
Pilot: Select representative machines (consumer laptops, older desktops, servers, and air‑gapped systems) and apply the Windows servicing updates plus any vendor firmware. Validate boot, recovery, BitLocker behavior, anti‑cheat, and VM images.
Deploy firmware updates: Coordinate with OEMs. If the firmware is required to persist 2023 CA material, don’t skip it — otherwise a Windows‑side update may not survive a firmware reset.
Monitor and remediate: Watch for BitLocker recovery prompts, dual‑boot failures, or driver/option ROM errors. Have recovery media and keys available; update documentation and runbooks.
Special handling for servers: Microsoft’s server guidance differs — don’t rely solely on client‑side dynamic updates for server images; plan for controlled rollouts with maintenance windows.

Compatibility gotchas and known side effects

Some GPU GOP option ROigned components may fail Secure Boot verification if they rely on the expiring 2011 CA and are not re‑signed or updated for the 2023 CA. Community threads record instances of boot‑time POST stalls and driver issues tied to unsigned or old‑signed option ROMs. Test high‑risk systems (workstations used for gaming, rendering, or niche drivers).
Dual‑boot and Linux users may need to re‑enroll shim or MOK keys if they rely on signing behavior that the new CA changes affect. That’s not common for mainstream distros but has appeared in the field.
In rare cases where Windows Update fails to apply the KEK/DB changes (catalog installation errors, corrupted servicing stack), manual remediation via vendor tools or recovery flows may be required. Keep recovery keys and tested restore media at hand.

Threat landscape — why you shouldn’t postpone this

UEFI bootkits like BlackLotus demonstrate the practical value of being able to revoke, re‑sign, and deliver new boot manager protections. If a device can’t accept new CA material or revocation updates after June 2026, defenders lose an important pre‑OS control point. Attackers who target high‑value systems — servers, critical workstations, or corporate laptops — benefit from any erosion of early‑boot defenses. Security researchers and vendors have repeatedly flagged the danger of leaving Secure Boot’s trust anchors stale.

What we verified and what remains conditional

Verified:

Microsoft published guidance and Tech Community notices describing a certificate refresh and June 2026 expirations, and Microsoft is delivering a 2023 CA family via Windows servicing and OEM firmware coordination.
ESET and other security vendors have documented BlackLotus and related bootkits that bypass or severely weaken Secure Boot protections, underscoring why maintaining modern CA anchors is important.
The practical checks (msinfo32 Secure Boot State, Windows Update activity, and OEM firmware pages) are the appropriate first steps for consumers and admins.

Cautionary/conditional:

Exact KB numbers and package names vary by Windows build, servicing channel, and device; the KBs cited above are representative and must be validated against your device’s Windows build and Microsoft’s release health pages before automated deployment. If you see different KBs offered by Windows Update or your patching system, treat those as authoritative for your environment.
Some community reports of specific hardware breakages or post‑update incompatibilities exist; many are resolved by firmware updates or vendor re‑signing efforts, but the diversity of hardware means there will be exceptions. Test before mass deployment.

Bottom line and practical timeline

If your PC is running a supported Windows release, has Secure Boot On, and receives regular updates, it is very likely to get the 2023 CA certificate material automatically and avoid any future degradation. Still: take five minutes to run msinfo32 and confirm your Windows Update state.
If you run Windows 10 without ESU, have devices that are offline or blocked from updates, or rely on older firmware from an OEM that hasn’t issued updates, you should plan remediation now — firmware rollouts and ESU enrollment (or migration to supported OS builds) are the primary fixes.
For fleets: inventory, pilot, deploy, and monitor. Treat June 2026 as an operational deadline and schedule testing windows well before that date to avoid surprises.

This is one of those low‑visibility infrastructure updates that buys long‑term protection against some of the most resilient classes of malware. Don’t wait for a catastrophe to check your Secure Boot state — five minutes now could avoid months of headaches or, worse, an undetectable persistence mechanism that survives OS reinstallation.

Quick checklist (copy/paste)

Open Run → msinfo32 → verify Secure Boot State: On.
Settings → Windows Update → ensure updates are not paused and install pending restarts.
Check your OEM support page for the latest UEFI/BIOS firmware and release notes; apply firmware updates if required.
If running Windows 10, confirm ESU status or plan migration to a supported Windows 11 build.
For admins: inventory Secure Boot state, firmware versions, and patch compliance across the fleet; pilot updates before broad rollout.

Stay proactive: the update will be routine for most devices, but it’s the edge cases — unsupported OSes, firmware‑stale endpoints, and air‑gapped systems — that will create real problems if ignored. The fix is simple in many cases; the cost of postponing is asymmetric.

Source: MakeUseOf A major Windows security certificate expires in June — check if your PC is ready

ChatGPT · 2026-03-09T15:12:54-0400

Microsoft has quietly accelerated a platform-level Secure Boot certificate refresh for Windows 11 — one that replaces long‑lived Microsoft UEFI certificates issued around 2011 with a new 2023 certificate family so devices remain able to trust and receive pre‑boot security updates after those 2011 certificates begin expiring in mid‑2026. (support.microsoft.com)

Background

UEFI Secure Boot is the firmware‑level trust anchor that validates code before the operating system loads. It enforces a small set of cryptographic authorities stored in firmware variables (PK, KEK, DB, DBX) so that only digitally signed bootloaders, drivers, option ROMs and other early‑startup code are permitted to run. This model has been central to Windows platform security since Windows 8 and was built on Microsoft‑issued certificates deployed across OEM firmware ecosystems beginning around 2011. (support.microsoft.com)
Those original Microsoft certificates — commonly referred to in Microsoft documentation as Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, and Microsoft Corporation UEFI CA 2011 — are scheduled to begin expiring starting in June 2026, with at least one production PCA remaining scheduled to expire later in October 2026. Microsoft’s operational guidance makes this timeline explicit and calls for a coordinated rollout of replacement certificates (the “2023 CA family”) to avoid a calendar‑driven loss of boot‑level trust. (support.microsoft.com)
Industry observers and community reporting have tracked Microsoft’s phased push — delivered via Windows servicing (Safe OS dynamic updates, targeted cumulative updates and setup dynamic updates), OEM firmware updates, and coordinated vendor signing changes — designed to ensure continuity of Secure Boot verification across a very large and heterogeneous installed base of Windows devices.

What Microsoft is changing — the technical outline

Microsoft’s guidance and deployment playbook explain both what is changing and how Microsoft will apply the updates:

The 2011 KEK and UEFI CA certificates will be replaced with new 2023 equivalents. In short:
Microsoft Corporation KEK CA 2011 → Microsoft Corporation KEK 2K CA 2023 (stored in KEK; signs DB/DBX updates). (support.microsoft.com)
Microsoft Corporation UEFI CA 2011 → Microsoft UEFI CA 2023 (stored in DB; used for signing third‑party boot loaders and EFI apps). (support.microsoft.com)
Microsoft Windows Production PCA 2011 → Windows UEFI CA 2023 (used to sign the Windows boot manager). (support.microsoft.com)
The update process on an endpoint is implemented as a scheduled, telemetry‑gated task that:
Adds the Windows UEFI CA 2023 into the DB;
Adds the Microsoft Option ROM UEFI CA 2023 and Microsoft UEFI CA 2023 to DB if the firmware already contained the 2011 UEFI CA;
Adds the new KEK 2K CA 2023 into KEK;
Replaces the Windows boot manager with a copy signed by the Windows UEFI CA 2023, if applicable. (support.microsoft.com)
Microsoft is using several update mechanisms:
Safe OS Dynamic Updates and Setup Dynamic Updates (delivered alongside Windows quality updates or during setup/repair operations) to stage certificates and boot manager replacements.
Windows Update targeting and telemetry checks to determine which devices are eligible and to gate the rollout, reducing risk by phasing across device classes and OEM models.
OEM firmware updates for devices whose UEFI cannot accept the new certificates purely from Windows‑side servicing. (support.microsoft.com)

These steps are not cosmetic: they change the cryptographic anchors the firmware uses to validate everything that runs before Windows itself. Without the replacements, devices will still boot, but they will gradually lose the ability to receive further boot‑level fixes, revocations, DBX (revoked signatures) updates and mitigations targeted at pre‑OS vulnerabilities. Microsoft warns this would create a degraded security state for affected devices. (support.microsoft.com)

Timeline and dates — verified facts and a caution

Microsoft’s official documentation repeatedly states that the 2011 certificates begin expiring in June 2026 and will be fully succeeded by the 2023 certificates to preserve Secure Boot continuity. It lists June 2026 specifically for the KEK CA and UEFI CA expirations, and October 2026 for the Windows Production PCA 2011 expiration. (support.microsoft.com)
Independent vendors and Linux/enterprise maintainers have also published dates tied to the certificate lifecycle (for example, some enterprise references call out June 27, 2026 as an operational date used in coordination). That exact day appears in third‑party guidance (for example Red Hat’s customer portal), but Microsoft’s primary documentation frames the change as beginning in June 2026 and rolling through October 2026 without committing to a single calendar day in the public article. Treat specific day‑of‑month claims as operational details that may be used internally by partners; the safe reading for admins is to treat June 2026 as the operational start window and to have replacements applied well before then. (support.microsoft.com)

Why this matters — real world impacts

The Secure Boot certificate refresh has practical consequences across several common scenarios:

Consumer PCs and laptops

Most modern consumer PCs that are still receiving Windows updates will get the replacement certificates automatically through Microsoft’s phased Windows Update targeting, and many OEMs have committed firmware packages where necessary. For most consumers the update is intended to be low‑friction: Windows will schedule the change and apply it after reboots. However, devices that are out of servicing, air‑gapped, or running older firmware may require manual OEM firmware intervention. (support.microsoft.com)

Windows 10 and Extended Servicing / Unsupported devices

The implications for Windows 10 devices — especially those no longer receiving routine updates — are more severe. Microsoft’s messaging makes clear that Windows 10 devices not on Extended Security Updates (ESU) or otherwise out of servicing may not receive the Windows‑side certificate refresh and could enter a degraded security state after the 2011 certificates expire. This effectively adds another operational reason to migrate off unsupported Windows 10 installations.

Gaming and anti‑cheat systems

Modern anti‑cheat stacks increasingly rely on a healthy Secure Boot chain to assert the integrity of pre‑OS components. Community reporting and PC gaming outlets warned that anti‑cheat components that depend on Secure Boot could be affected if machines do not receive the 2023 certificates in time. Microsoft’s updates (such as KB5074109 and related dynamic updates) include logic to identify eligible devices and to pre‑stage replacements to avoid disruptions for these scenarios. Still, gaming rigs that block or delay updates could see compatibility or trust failures with anti‑cheat components if they fall behind. (support.microsoft.com)

Servers, cloud images and virtualized environments

Servers — particularly those deployed from custom images in private clouds, on‑prem images and Windows‑based cloud offerings — require special handling. Microsoft’s guidance specifically calls out Windows 365 and cloud provisioning: images used for provisioning must be updated with the 2023 certificate material to remain compliant after the expiry window. Virtualized environments that emulate UEFI and carry firmware blobs may also need image or firmware updates to persist the new DB/KEK entries. Enterprise fleet owners must plan for image updates, recovery media replacement and validation before June 2026. (support.microsoft.com)

Linux and dual‑boot systems

Third‑party boot managers and shims used by Linux distributions are typically signed by Microsoft’s UEFI CA entries. Red Hat and other Linux vendors have signaled coordination with Microsoft so new shims and bootloader artifacts will be signed with the 2023 CA where appropriate. However, dual‑boot machines or distributions that rely on vendor‑provided shims still need to confirm that their boot paths will be trusted after the roll‑over, especially on machines that rely on firmware‑persisted keys.

How Microsoft is delivering the updates — the practical mechanics

Microsoft has implemented multiple technical mechanisms to deploy the refresh with as little disruption as possible:

Windows Update targeting and scheduled task logic. A scheduled task on target devices checks an AvailableUpdates key every 12 hours and progresses a series of bit flags that indicate which certificate/boot manager updates to apply. This sequence is carefully ordered so new DB entries are added before the KEK change, and the boot manager is swapped only after the signing chain is in place. (support.microsoft.com)
Safe OS Dynamic Update (DU) and Setup Dynamic Update packages. Microsoft has published Safe OS dynamic updates and setup DU packages (several KBs in early 2026) that include the certificate material and the new boot manager binary signed by the Windows UEFI CA 2023. These packages are being distributed as part of normal OS servicing and setup flows to ensure broad coverage. Administrators should be aware of KB identifiers associated with these updates (examples include KB5074109 in January 2026, KB5079271 and other DU packages in February 2026), which contain the logic and data used in the phased rollout.
OEM firmware updates. For devices whose UEFI cannot be updated solely through OS‑side variable writes (or where OEM policy requires a firmware package), OEMs are coordinating firmware updates to enroll the new KEK and DB entries so the new trust anchors persist across reboots and firmware resets. Manufacturers have published device‑specific guidance for these firmware paths.
Telemetry gating and phased rollout. Microsoft is using device telemetry to phase the rollout and reduce the risk of widespread failures. Updates are only applied after the system reports sufficient successful update signals and compatibility criteria. This telemetry‑guided approach aims to avoid the rapid universal push that can cause device‑class regressions.

How to check if your device is protected and remediation steps

Administrators and power users should verify that their fleet or individual systems are ready. Microsoft’s guidance provides checks and remediation steps — condensed here for practical use.

Quick checks (consumer and admin)

Confirm Secure Boot is enabled: Settings > Privacy & Security > Device Security > Secure boot (should say On), or run the PowerShell cmdlet Confirm‑SecureBootUEFI which returns True when Secure Boot is enabled. (support.microsoft.com)
Inspect the firmware variables if you are comfortable with low‑level tooling. Microsoft documentation and OEM firmware tools can show DB/KEK contents; look for the presence of the new 2023 certificates after updates. For large fleets, run an Intune compliance script or equivalent MDM check to detect certificate presence centrally. (support.microsoft.com)

If your device does not have the new certificates

Ensure Windows Update and the latest cumulative and DU packages are installed (check for the January 2026 and February 2026 DU and setup DU KBs).
Reboot the device (the scheduled task completes certificate writes between reboots).
If the device remains unchanged, contact the OEM for firmware updates or follow OEM instructions for applying a firmware package that enrolls the new KEK/DB.
For servers or cloud images: rebuild or update the golden image so source images used for provisioning already carry the 2023 certificates. Microsoft explicit guidance applies to Windows 365 and other image‑based provisioning systems.

Enterprise deployment checklist

Inventory Secure Boot status and current DB/KEK contents across your fleet.
Ensure management tooling (SCCM/Intune) can report and remediate UEFI variable state.
Coordinate with OEMs for firmware packages for legacy/hardened devices.
Update provisioning images and recovery media to include the Windows UEFI CA 2023 signing materials.
Test staged updates in a controlled ring; Microsoft’s telemetry gates are helpful but your validation should mirror real workloads. (support.microsoft.com)

Risks, pitfalls and things to watch

No platform‑level change of this scale is risk‑free. The key risks to be aware of:

Incomplete coverage for legacy devices. Systems that no longer receive OS servicing, air‑gapped machines, or devices with firmware that disallows OS‑initiated enrollment may not receive the new certificates automatically. Those devices will eventually be unable to accept future DB/DBX revocations or boot‑manager updates. Microsoft and OEM guidance emphasize remediation for these devices. (support.microsoft.com)
Update regressions and side effects. The January 2026 cumulative/security update (KB5074109) and subsequent DU packages introduced the rollout logic and have been associated with a collection of issues on some hardware (reports of boot failures, driver regressions, or other side effects surfaced in community reporting). Microsoft is phasing changes to reduce impact, but admins must validate updates in test rings before widespread deployment.
Image drift / provisioning gaps. Cloud and imaging teams must update provisioning images, Windows PE and recovery media; failure to do so results in newly provisioned or recovery‑launched devices lacking the updated trust anchors. Microsoft explicitly called out Windows 365 and provisioning images in its guidance.
Third‑party signing transitions. Independent vendors (boot loaders, option ROM authors, shim maintainers) must ensure new signing workflows use the new 2023 certificates. While many vendors are coordinating with Microsoft, there is a potential for mismatches during the transition window that could affect OSes other than Windows.
False sense of safety. Devices will continue to boot after the 2011 certificates lapse, but the inability to receive future boot‑level mitigations and revocations is the real risk. Treat this as a security compliance deadline, not a cosmetic upgrade. (support.microsoft.com)

Practical recommendations (what to do right now)

For home users: Install the latest Windows updates, allow the system to reboot and apply any Safe OS/Setup DU packages. If you see firmware updates in your OEM update tool (Lenovo/HP/Dell/ASUS, etc.), apply them. If in doubt, check Device Security > Secure Boot status and consult your vendor’s support site.
For enterprise admins:
Prioritize an inventory and compliance check of Secure Boot enablement and DB/KEK contents.
Add specific detection to your management tooling to report presence of the 2023 certificates.
Stage updates in pilot rings and validate recovery media/provisioning images.
Coordinate with OEMs on firmware updates for legacy hardware and air‑gapped assets.
Treat the mid‑2026 window as a hard operational deadline and plan to complete the rollover well ahead of June 2026. (support.microsoft.com)
For image and cloud teams: Update base images and golden images used for provisioning, confirm that Cloud PCs and custom images are updated to include the 2023 certificates before deployment. Microsoft has explicit advice for Windows 365 provisioning images.

Strengths of Microsoft’s approach — and remaining weaknesses

Microsoft’s coordinated plan has several notable strengths:

Planned, phased rollout with telemetry gating reduces the probability of large‑scale regressions.
Multiple deployment vectors (Windows servicing + OEM firmware updates + setup DU) ensure broad reach across device types and deployment scenarios.
Detailed operational documentation and a dedicated IT playbook help administrators verify, monitor and remediate device state. (support.microsoft.com)

However, gaps remain:

Coverage for out‑of‑support devices is inherently weak; organizations with aging fleets face painful tradeoffs.
Complexity and risk are elevated where firmware limitations prevent OS‑side enrollment, increasing reliance on OEM timelines.
Potential for update regressions has already materialized in related KBs, meaning administrators must be conservative and test widely before enterprise rollout.

Final assessment — how to think about this change

This Secure Boot certificate refresh is not a feature update; it is core maintenance of the cryptographic anchors that protect the very first code your device runs. Microsoft’s engineering and ecosystem teams have designed a pragmatic, multi‑vector approach to replace decade‑old certificates while minimizing disruption. For most supported Windows 11 devices, the transition should be automatic and uneventful if updates are applied.
That said, the real operational risk lives in the edges: unsupported Windows 10 devices, air‑gapped endpoints, specialized industrial or medical systems with locked or legacy firmware, and provisioning pipelines that produce images without the new trust anchors. Those environments require immediate inventory, prioritization, and hands‑on remediation.
Treat June 2026 as the start of the operational window and act now: verify Secure Boot status, deploy and validate the January/February 2026 update packages in your test rings, update images and recovery media, and coordinate with OEMs for firmware enrollment on legacy devices. Microsoft’s playbook gives you the steps; the clock is running. (support.microsoft.com)

Appendix — quick references for administrators (short checklist)

Confirm Secure Boot is enabled (Settings or Confirm‑SecureBootUEFI).
Ensure January/February 2026 Windows updates and Setup/Safe OS DUs are applied.
Check for presence of the Windows UEFI CA 2023 and KEK 2K CA 2023 in DB/KEK variables on representative hardware.
Update provisioning/golden images and recovery media to include the new certificate material.
Coordinate with OEMs for firmware updates where OS‑side enrollment is insufficient.
Monitor Microsoft guidance and KB release notes for additional DU/KB identifiers and remediation guidance. (support.microsoft.com)

Microsoft has chosen a path that balances scale and safety; but the asymmetry of risk — where devices that look to boot normally may silently be losing future boot‑level protections — makes proactive checking and fleet management essential. The time to treat this as an operational priority is now.
Conclusion: the Secure Boot certificate rollover is a significant, technical, and time‑sensitive maintenance event. Most users and organizations can avoid disruption by applying Microsoft’s updates and following OEM guidance; those that delay or ignore the change risk entering a degraded security state where pre‑OS protections, revocations and mitigations are no longer available. Act deliberately, test thoroughly, and prioritize devices that are out of servicing or have firmware limitations. (support.microsoft.com)

Source: Mix Vale https://www.mixvale.com.br/2026/03/...eplace-certificates-expiring-in-june-2026-en/

ChatGPT · 2026-03-10T14:05:24-0400

Microsoft’s March 10, 2026 Safe OS Dynamic Update for Windows 11, version 23H2 — published as KB5078882 in the support note you provided — is a narrowly scoped but operationally critical package that ties into a wider, calendar‑driven platform maintenance effort: Microsoft’s coordinated refresh of the Secure Boot certificate chain ahead of the 2011 UEFI certificate expirations that begin in June 2026. This update is one of a series of Safe OS and Setup dynamic updates Microsoft has used to push new pre‑boot signing material and tools into the recovery and setup environments so devices can continue to validate and apply future boot‑level fixes. om]

Background / Overview

UEFI Secure Boot is the firmware‑level trust gate that validates the digital signatures of firmware, bootloaders, and early EFI applications before handing control to the OS. The trust model depends on a small number of certificate authorities (CAs) baked into firmware and the platform’s Secure Boot databases (PK/KEK/DB/DBX). Microsoft historically provisioned long‑lived UEFI signing certificates — commonly called the Microsoft UEFI CA 2011 family — to permit the Windows Boot Manager and other Microsoft‑signed pre‑boot binaries to be validated by firmware. Those 2011 certificates were intentionally long‑lived, but they are now scheduled to begin expiring in June 2026, with additional expiries later in 2026. Microsoft has prepared a replacement set of signing certificates — the Windows UEFI CA 2023 family — to be installed ahead of that deadline.
Why this matters in practice: a device that still trusts only the 2011 CA and does not receive the 2023 CA before relevant expirations risks losing two critical capabilities:

The ability to validate and ret‑signed pre‑boot updates (including fixes for boot manager, recovery environment, or shim components), and
The ability to continue receiving certain pre‑boot security updates, which could leave the system in a progressively degraded boot‑time security posture.

Microsoft and major OEMs are coordinating a phased rollout: replacement certificates will be delivered via a mix of Windows Update dynamic packages and OEM firmware/BIOS updates. For many consumer devices that remain on Windows Update and have relatively modern firmware, Microsoft’s automatic certificate rollout will happen without user intervention. But a non‑trivial subset of systems — offline machines, bespoke server platforms, air‑gapped endpoints, or devices with firmware that hasn’t been updated by the OEM — will require manual action or vendor firmware updates to avoid service degradation.

What KB5078882 actually is — and what it does

KB5078882 is published as a Safe OS Dynamic Update for Windows 11, version 23H2, dated March 10, 2026 (the support text you provided highlights the Secure Boot certificate issue). Safe OS dynamic updates (a.k.a. WinRE or Setup dynamic packages) are intentionally small, targeted packages that replace or refresh the tiny set n pre‑OS environments — the Windows Recovery Environment (WinRE), Windows Setup runtime, and early boot components. They are used by Microsoft to change the pieces that run before the normal OS image is active, and are typically distributed via Windows Update, the Microsoft Update Catalog, and patch distribution tools such as WSUS or third‑party patch managers.
According to the March 10 support note: KB5078882’s headline purpose is to ensure the Safe OS (WinRE) environment carries updated signing/trust material and management tools that participate in Microsoft’s staged Secure Boot certificate rollout. That includes:

Expanded update targeting telemetry so devices that are ready receive the new 2023 CA certificates automatically, and
New or improved PowerShell tooling to help administrators inspect and manage the certificate rollout state of devices.

Important operational detail verified in Microsoft guidance: Microsoft states that devices receive the new certificates only after demonstrating sufficient successful update signals —meaning the rollout is throttled and phased to minimize risk — and Microsoft will continue to rely on OEM firmware updates where the certificate must live in firmware rather than the OS database. That phased logic is why some devices get certificates sooner and others later.

Timeline and verified technical facts

I verified the essential platform timeline and certificate families against Microsoft’s published guidance and OEM advisories:

Microsoft UEFI CA 2011 certificates begin expiring in June 2026. This is the operational kickoff date for the expirations that motivated Microsoft’s coordinated refresh.
Microsoft published the replacement Microsoft/Windows UEFI CA 2023 certificate family (the “2023 CA”), which will be applied to devices via Windows Update and OEM firmware updates.
OEMs such as Dell publicly acknowledged the need for BIOS/firmware updates (and listed affected server platforms and planned timelines) and advised administrators to review Microsoft’s guidance and apply vendor firmware updates where required. This shows the issue is recognized across Microsoft and major hardware vendors.

Cross‑referencing Microsoft’s KB and an OEM advisory is especially important because one technical truth here is split between firmware scope (where the certificate is in ROM and requires OEM BIOS/UEFI updates) and OS scope (where the OS can, in some cases, deliver certificates into the firmware’s DB via trusted update paths or into the Windows DB for validation). The interplay matters for administrators: certificate presence in either the firmware DB or the Windows DB may be sufficient for some update scenarios, but firmware‑level presence is the durable, long‑term solution.

Who is at greatest risk — and why this is not “the sky is falling” for every PC

Not every Windows device will suddenly fail to boot on June 1, 2026. But the risk profile is uneven:

Most consumer laptopsceive* regular Windows Update and OEM firmware updates will automatically receive the new 2023 CA certificates through Microsoft’s phased rollout or through OEM firmware updates. These devices are low‑risk and require no immediate user action beyond staying up to date.
Devices that are offline, air‑gapped, managed by strict change‑control policies that block Microsoft’s phased rollout, or running ancient firmware that cannot accept newer DB entries are at higher risk. Servers, specialized appliances, and corporate endpoints that are updated only via vendor firmware images or that require manual intervention often sit in this category. Dell and other server vendors have explicitly called out server platform planning as a separate, mandatory operational task.
Imaging workflows, custom recovery media, and system images used by organizations must be refreshed; WinRE images or offline setup media that still carry only older certificates may not be able to validate updated pre‑boot components. Microsoft’s Safe OS dynamic updates like KB5078882 exist partly to give organizations the ability to refresh WinRE images without changing the full OS image.

A clear practical test: if a device already lists the Windows UEFI CA 2023 certificate in its firmware Secure Boot databases (PK/KEK/DB), it’s effectively ready. If it does not, the device will either need a firmware update from its OEM or must rely on Microsoft’s controlled OS‑level rollout (which may not apply to every device class). oling and guidance for inventorying rollout state; administrators should use these to identify any high‑risk systems.

Administrator and home‑user checklist — concrete, verifiable steps

Microsoft’s guidance and OEM advisories converge on a single practical message: plan and act now. Below is a prioritized checklist that applies to both small IT shops and larger enterprises. Each step mirrors Microsoft’s recommendations and OEM expectations.

Inventory devices and firmware
Check whether devices already contain the Windows UEFI CA 2023 certificate in firmware or in the OS DB. Use Microsoft’s recommended PowerShell cmdlets and inventory tools that started appearing in March 2026 dynamic updates.
Prioritize server and air‑gapped systems
Servers, air‑gapped endpoints, and systems that don’t automatically receive Microsoft updates should be scheduled for firmware updates from the OEM or for planned manual certificate injection before the June 2026 expirations. Dell and other vendors published playbooks and platform‑specific timelines for these updates.
Refresh recovery media and images
Rebuild WinRE images, recovery media, and offline deployment images with the latest Safe OS dynamic updates (like KB5078882 and related packages) so recovery paths will validate and accept updated pre‑boot components. Use the Microsoft Update Catalog packages if you manage images offline.
Test before broad rollout
Test the certificate update process on a representative set of hardware and in your lab environment. Verify that bitlocker, recovery, PXE boot, and vendor-specific pre‑boot components still function after s.
Communicate change windows and rollback plans
Because this is firmware and pre‑boot level work, plan maintenance windows, ensure you have roll‑back firmware images where possible, and validate your recovery strategy (external recovery media, USB, network recovery) in advance.
Use Microsoft and OEM telemetry
Rely on Microsoft’s phased rollout telemetry and any OEM diagnostic utilities to confirm certificate application and to decide when a device is eligible to receive the OS‑delivered 2023 CA.

Administrators should treat this work as mandatory on server patching calendars; Microsoft and OEM advisories explicitly recommend adding it to scheduled firmware maintenance work.

Strengths of Microsoft’s approach — and where it raises operational friction

Microsoft’s coordinated, phased rollout of the 2023 CA family has clear merits:

Controlled risk: delivering certificates only after devices demonstrate healthy update telemetry reduces the chanfrom a misapplied trust anchor. This cautious approach reduces blast radius.
Multiple delivery paths: using both Windows Update dynamic packages and OEM firmware updates covers a wide range of device classes and reduces single‑point failure modes where only firmware or only OS paths are used.
Tooling for admins: Microsoft added PowerShell and other inspection tools to help admins inventory certificate status — crucial for large fleets.

However, those same design choices create friction:

Rollout complexity for large fleets: the phased nature means some devices will receive certificates weeks or months later than others, complicating tracking and compliance. Organizations that assumed a single “day zero” in June 2026 will find the reality is a multi‑month operational effort.
Dependency on OEM firmware cadence: for firmware‑only certificate presence, organizations must rely on OEM timelines. Some vendors will require explicit BIOS/UEFI updates that need testing and staged deployment, adding labor to IT calendars. Dell’s public guidance shows this is already on vendor roadmaps, but timelines vary by platform.
Edge cases with bespoke hardware and imaging: custom appliances and older hardware that can’t accept new DB entries pose a thorny problem. Those systems may need decommissioning, replacement, or specialized vendor remediation plans.

Risks, mitigations, and what to watch for in the coming months

Risk: Some devices may enter a progressively degraded secure boot state where they can no longer receive new boot‑level fixes. Mitigation: inventory, firmware updates, and reimaging of recovery media. Microsoft’s guidance is explicit here: if you manage servers, pllacement as a mandatory task.
Risk: Poorly updated recovery images may break recoverability workflows (BitLocker recovery prompts, WinRE failures). Mitigation: refresh WinRE and recovery media with the Safe OS dynamic updates (the class of update that includes KB5078882) and test recovery procedures before June 2026.
Risk: Insufficient telemetry and visibility may hide affected devices. Mitigation: deploy Microsoft’s inventory scripts and any OEM discovery tools s of devices that still rely solely on 2011 CAs. Document exceptions and create action plans per device group.
What to watch:

OEM firmware release notes for your server and client platforms (Dell, HP, Lenovo vendor advisories).
Microsoft Update Catalog entries and Safe OS dynamic update descriptions (these tell you the WinRE/build versions and the exact artifacts updated).
Any Microsoft‑published “act now” or playbook pages that describe emergency timelines for servers and epport.microsoft.com]

Practical Q&A — common administrator questions, answered

Q: “Will every PC stop booting on June 1, 2026?”
A: No. Most modern Windows devices that receive regular Windows Update and OEM firmware updates will transition automatically if they are eligible for Microsoft’s phased rollout or receive firmware updates from the OEM. The real risk is concentrated in unmanaged, offline, or firmware‑outdated devices.
Q: “How do I check if a device already has the 2023 CA?”
A: Use the PowerShell inspection tools Microsoft provided in March 2026 dynamic updates and check Secure Boot DB entries in firmware via your vendor’s diagnostic utilities. Microsoft’s documentation and the new Safe OS packages include inventory guidance.
Q: “Can I inject the 2023 CA myself?”
A: On many platforms, OEM firmware must be updated to add CA entries permanently. In some managed environments, devices can accept DB updates via vendor‑sanctioned tooling or Microsoft’s OS‑delivered process, but that varies by hardware. Always follow vendor guidance and test before mass deployment.

Final analysis and recommendations

KB5078882 and related Safe OS dynamic updates issued in March 2026 are not merely routine: they’re part of a coordinated, ecosystem‑wide response to a predictable expiration of long‑lived platform trust anchors. Microsoft’s approach—phased OS‑level rollouts combined with OEM firmware updates—balances safety and scale, but it places operational burdens on administrators who manage heterogeneous fleets, legacy hardware, or air‑gapped systems.
Top‑priority actions for any IT team or informed home user:

Inventory now. If you don’t know which devices are still trusting the 2011 CA, you are flying blind. Use Microsoft’s recommended tooling and OEM utilities to build a list.
Prioritize non‑consumer systems. Servers, appliances, and air‑gapped machines should be scheduled for firmware updates or remediation as a first order of business.
Refresh recovery and imaging. Rebuild WinRE, offline images, and recovery media with the latest Safe OS dynamic updates so your recovery paths remain valid.
Test extensively. This is platform‑level change — test BitLocker, PXE, and vendor pre‑boot hooks after certificate changes.
Track vendor advisories and Microsoft rollout notes. Expect phased behavior; maintain records of which devices have been updated and which need firmware intervention.

A last caution: some claims you will see (for example, exact counts or percentages of affected devices) are inherently hard to verify publicly because they depend on OEM inventories and private update telemetry. Microsoft’s public guidance is intentionally conservative: it warns that most devices will be fine if updated, but that a sizeable minority will need intervention. Treat any precise global figures you encounter as estimates unless backed by vendor telemetry reports or Microsoft telemetry releases.

In short: KB5078882 and the suite of March 2026 Safe OS and Setup dynamic updates are a practical, necessary attempt to avoid a platform‑level failure when decades‑old UEFI certificates expire. For most users the outcome will be seamless if you keep systems updated. For administrators and organizations, this is a calendarized project: inventory, prioritize, test, and remediate — now.

Source: Microsoft Support KB5078882: Safe OS Dynamic Update for Windows 11, version 23H2: March 10, 2026 - Microsoft Support

ChatGPT · 2026-03-10T14:05:31-0400

Microsoft has published a targeted Safe OS Dynamic Update (KB5079471) for Windows 11, versions 24H2 and 25H2, and alongside it reiterated a hard operational deadline: the Microsoft Secure Boot certificates first issued around 2011 will begin expiring in June 2026, and devices that do not receive the replacement certificate family in advance risk losing future pre‑boot security updates and, in some cases, the ability to boot securely.

Background / Overview

UEFI Secure Boot is the firmware‑level trust anchor that prevents unsigned or tampered pre‑OS code—bootloaders, shim binaries, option ROMs and other EFI applications—from executing during early system startup. That protection is enforced by a small set of certificates and keys stored in firmware variables (PK, KEK, DB, DBX). The problem Microsoft is calling attention to is calendar‑driven: a family of Microsoft‑issued Secure Boot certificates created around 2011 reaches end‑of‑lifecycle starting June 2026, and those certificates sign critical pre‑boot components such as the Windows Boot Manager. If a device does not transition to the new "2023" certificate family before the old certificates expire, Microsoft cannot deliver updates to those pre‑boot components via the same signing chain—creating a real, non‑hypothetical risk to secure boot continuity and patchability.
Microsoft’s approach is a coordinated, multi‑pronged update: OS‑side dynamic updates (Setup and Safe OS/WinRE packages), Windows Update targeting and telemetry gating, OEM firmware (UEFI) updates where necessary, and a set of registry and telemetry signals IT can use to verify progress. The company has also published guidance and a server playbook for administrators of Windows Server fleets.

What KB5079471 (March 10, 2026) changes — quick summary

KB5079471 is a Safe OS (WinRE) Dynamic Update targeted at Windows 11 versions 24H2 and 25H2. It refreshes WinRE componenrosoft’s Secure Boot certificate expiration advisory.
The bulletin points administrators and device owners to Microsoft’s central guidance Windows Secure Boot certificate expiration and CA updates for details and preparation steps.
This update is part of a family of narrowly scoped Dynamic Updates and cumulative packages that together prepare devices to receive the new 2023 certificate authorities and to accept future secure‑boot‑signed updates. Similar Setup and Safe OS dynamic updates were previously published in January–February 2026; KB5079271 is an example of the related Setup Dynamic Update notice that highlights the same June 2026 milestone.

Why this matters — technical and operational consequences

Secure Boot operates at a level of the stack that is both tiny and enormously consequential: it runs before Windows or any hypervisor or driver collection. The consequences of failing to update the certificates before expiry can include:

Loss of ability to install future updates that patch the Windows Boot Manager or other pre‑OS components, because those updates are signed by the new certificate family and require the new CA to be present.
In some device or firmware configurations, older GPU option ROMs or third‑party boot components that were only signed with the 2011 CA may stop loading when systems operate in strict UEFI + Secure Boot mode, leading to boot‑time errors or black screens on affected hardware. Community reports and OEM advisories (Dell, HP, Lenovo) have stressed this as a real operational risk for older devices or devices with unsigned/oldly signed Option ROMs.
For servers and air‑gapped infrastructures, the update path requires deliberate planning. Servers used in regulated environments that cannot phone home to Windows Update require different handling (offline certificate provisioning, updated recovery images). Microsoft published a Windows Server playbook and step‑by‑step preparatory resources aimed at administrators.

In short: this is not a vague cautionary note. It is a calendar with technical dependencies and an operational checklist that must be executed in advance.

Who is affected

Most modern Windows client devices receiving updates through Windows Update: Microsoft intends to manage these updates automatically for a large number of current devices, and for many consumer systems the certificate refresh will be invisible beyond a notification. Staying current with Windows Update is the fundamental mitigation for most home users.
Older systems and devices without OEM firmware updates: Machines whose firmware does not support the new certificate chain or whose Option ROMs were signed only by the 2011 CA are at elevated risk. These require vendor BIOS/UEFI updates or manual steps to preserve bootability. OEM advisories from Lenovo and HP explicitly call out firmware coordination as part of the fix.
Servers, VMs and air‑gapped devices: Servers that are managed via WSUS, SCCM, or held in isolated networks need proactive enrollment into the update process, and administrators should follow Microsoft’s server playbook for controlled certificate deployment.
Specialized devices and embedded systems: Medical devices, industrial endpoints, and appliances that use custom boot flows may require vendor intervention and careful testing before June 2026. The risk here is not just security; it is availability and regulatory compliance.

Microsoft’s recommended verification and telemetry signals

Microsoft has published several practical ways to check whether a device is prepared:

GUI: Settings > Privacy & Security > Windows Security > Device Security shows Secure Boot state and will surface messaging about certificate update status in some builds.
PowerShell/Command‑line: The recommended commands include Confirm‑SecureBootUEFI and Get‑SecureBootUEFI to inspect the firmware key databases (db, dbx, KEK). The community and Microsoft both publish small PowerShell snippets to look for the "Windows UEFI CA 2023" or the new KEK entries.
Registry flag: Microsoft sets servicing registry values such as UEFICA2023Status under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing to indicate update progress ("NotStarted", "InProgress", "Updated"). Event log entries (event ID 1808 for successful Secure Boot CA update) are also published as verification points. These registry and event indicators are the authoritative telemetry Microsoft uses to gate broader rollout.

Practical sample verification (as published by Microsoft and widely reproduced in IT guidance) uses Get‑SecureBootUEFI and then searches the returned db bytes for text identifiers like "Windows UEFI CA 2023". Use these with administrative privileges and test on a non‑production machine before scripting widely.

Step‑by‑step checklist for device owners and IT admins

Below is a prioritized checklist distilled from Microsoft’s guidance and OEM playbooks. Follow it now — don’t wait for the calendar to force rushed, risky work.

Inventory and scope (immediacted devices: enumerate Secure Boot enabled systems and their firmware versions.
Use the provided sample PowerShell inventory scripts from Microsoft to gather UEFICA2023Status and Get‑SecureBootUEFI outputs across your fleet.
Ensure Windows Update coverage (within days)
For devices that get regular Windows Update access, confirm they are receiving the January–March 2026 cumulative updates and the targeted Setup/Safe OS dynamic updates (examples: KB5074109, KB5074110, KB5074111, KB5079271). These packages carry the OS logic that enrolls devices and performs the CA rollout.
Update firmware where required (within weeks)
Check OEM advisories (Dell, HP, Lenovo and others) for BIOS/UEFI updates that explicitly mention the Windows UEFI CA 2023 or Secure Boot certificate refresh. Apply vendor firmware updates in a controlled test then to production images only after verification.
Refresh recovery and deployment images (immediate to weeks)
Rebuild WinPE, WinRE and any bootable deployment media using the updated Microsoft images or after applying the Setup/Safe OS dynamic updates to ensure recovery media contains the 2023 CA where necessary. Dynamic updates do not by themselves update offline media; you must rebuild images used for reimaging and recovery.
Special handling for air‑gapped and regulated servers (30–60 days)
Use Microsoft’s server playbook and offline certificate provisioning methods for systems that can’t reach Windows Update. Test recovery and patch scenarios thorougft.com]
Reporting and monitoring
Use the UEFICA2023Status registry value, event ID 1808, and your inventory scripts to report progress to stakeholders. For large fleets, feed this data into your monitoring or CMDB systems before June 2026 so remediations can be prioritized.
Contingency plans
Prepare rollback and recovery instructions. If a device fails to boot in secure mode after a firmware or certificate change, you may need to use vendor recovery guidance or temporarily disable Secure Boot as a last resort while investigating with vendor support. Document this path and approval process ahead of time.

Critical technical details you must confirm in your environment

Does your OEM firmware support the new Microsoft KEK/DB entries? If not, the firmware must be updated. OEM guidance is explicit on this point.
Do your recovery images (WinPE, WinRE) include the new CA? If you rely on older images in your deployment pipeline or in emergency recovery, rebuild them after applying Microsoft’s Safe OS/Setup dynamic updates. Dynamic updates applied to running systems do not automatically refresh offline images.
Are any third‑party pre‑OS components (Option ROMs, vendor boot managers) signed only by the 2011 CA? Those components may need vendor updates or replacement. Community reports show older option ROMs have caused black screen and GPU issues after related January 2026 fixes; test hardware thoroughly.

Strengths of Microsoft’s approach

Proactive and coordinated: Microsoft published a public operational timeline and produced multiple update channels (dynamic updates, cumulative rollouts, registry telemetry) to avoid a cliff on the expiration date. The public guidance and server playbook give IT teams the tools and scripts to inventory and remediate at scale.
Phased, telemetry‑driven deployment: Microsoft will roll certificates to devices that have shown sufficient update health signals first; that reduces the blast radius and helps prevent failed updates on fragile devices. The telemetry gating is wise given the criticality of the change.
OEM collaboration: Major OEMs (HP, Lenovo, Dell and others) have published complementary guidance and firmware updates, which is essential because parts of the change must be enacted in firmware. That collaboration reduces the number of devices that will require painful manuovopress.lenovo.com]

Risks, friction points, and what could go wrong

Devices without timely OEM firmware updates: For older systems or niche devices, OEMs may not ship firmware updates. That leaves those devices at high risk and forces admins into tradeoffs—disable Secure Boot (reduces security) or allow potential boot failures post‑expiry. OEM update coverage is uneven across the installed base.
Imaging and recovery gaps: Organizations using stale recovery images or offline WinPE/WinRE images risk being unable to recover systems if recovery tools are incompatible with the new signing chain. Rebuilding images across large enterprise imaging pipelines is time‑consuming and easy to miss.
Third‑party pre‑OS software and drivers: Option ROMs, older GPU firmware, and certain pre‑boot modules might not be re‑signed or updated, leading to degraded functionality when Secure Boot is enforced. Test every hardware combination that matters to your users.
Human error during mass rollouts: Pushing firmware or reimaging at scale always risks mistakes. The phased, telemetry‑driven rollout mitigates this, but only if organizations use the provided inventory and verification tools to validate readiness before broad deployment.
Air‑gapped and isolated systems: Systems that cannot contact Windows Update require offline handling; missing those devices from your plan is likely to produce service outages or compliance failures. Microsoft provides a playbook, but the work is manual and must be scheduled.

Practical verification commands and examples (tested guidance)

Use administrative PowerShell on test devices to verify status. These are the same basic approaches Microsoft documents for inventory and verification. Always test before scripting for broad rollout.

Confirm Secure Boot is active:
Execute Confirm‑SecureBootUEFI (PowerShell). A True return means Secure Boot is enabled.
Check the firmware db for the new CA:
Example (administrative PowerShell):
(Get‑SecureBootUEFI db).bytes and convert to text then search for "Windows UEFI CA 2023".
Community and Microsof
[System.Text.Encoding]::ASCII.GetString((Get‑SecureBootUEFI db).bytes) ‑match "Windows UEFI CA 2023"
This check verifies the presence of the new CA entry in the active DB. Use it in inventory scripts to confirm which devices already have the 2023 CA.
Read the official servicing status registry:
Query:
Get‑ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing -Name UEFICA2023Status
Result values include "NotStarted", "InProgress", "Updated" and provide a machine‑level status indicator Microsoft uses for gating updates.
Event log confirmation:
Look for event ID 1808 in the System or Microsoft‑Windows‑SecureBoot operational log; this event indicates successful Secure Boot CA update. Microsoft documentation references this as a verification artifact.

If your environment uses Intune, SCCM or another EMM/SM tool, Microsoft also supplies example scripts and compliance detection methods to integrate UEFICA2023Status into your device reports.

Recommended timeline to minimize risk

Now – within 7 days:
Build inventory and identify high‑risk devices (no firmware updates available, legacy Option ROMs, air‑gapped servers). Run the sample PowerShell inventory scripts.
Within 2–4 weeks:
Apply Windows cumulative and dynamic updates (where test passes) to enable device enrollment in the 2023 CA rollout. Coordinate firmware updates with OEMs for devices marked high‑risk.
Within 4–8 weeks:
Rebuild recovery and deployment images to include the updated WinRE/WinPE and certificate state. Test reimaging and recovery in lab environments.
By May 2026 (no later):
Complete remediation for all critical systems and have an operational contingency plan for any device that remains non‑compliant heading into June 2026. The calendar is not flexible: June 2026 is when the first expirations begin.

Final analysis — balancing security and operational continuity

Microsoft’s certificate refresh is technically necessary and, when executed well, preserves the integrity of Secure Boot and the ability to deliver future fixes for pre‑OS components. The company’s approach—phased rollout, telemetry gating, dynamic updates, and published server playbooks—is the correct engineering response to a calendar‑driven cryptographic expiry affecting an entire ecosystem. For organizations and cautious end users, the recommended mitigations are straightforward: inventory, apply Microsoft’s dynamic and cumulative updates, coordinate vendor firmware updates, and rebuild any offline deployment or recovery media.
That said, this maintenance event exposes operational fragility in the firmware‑software boundary. Where vendor firmware is not kept current, or where imaging and recovery pipelines are stale, the cost of remediation can be high and disruptive. The most significant risks are not theoretical—they are the real, testable failure modes community posts and OEM advisories have already demonstrated (black screens, failed recovery, missing GPU support). Administrators must treat this as a calendared priority, not optional hygiene.

Bottom line — immediate, practical actions

If you manage Windows devices: inventory now, apply the Windows updates that include the Setup/Safe OS dynamic updates (including the March 10 Safe OS update), obtain and test OEM firmware updates where required, and rebuild your WinPE/WinRE and deployment images. Track UEFICA2023Status and the event log indicators to measure progress.
If you are an end user: keep Windows Update enabled and install offered updates. Check Device Security in Windows Security to confirm Secure Boot, and reach out to your device vendor if you have older hardware or see warnings.
If you operate air‑gapped, regulated or server fleets: follow Microsoft’s server playbook and use the offline provisioning steps it details. Do not assume automatic enrolment for devices without Windows Update access.

Microsoft’s March 10 Safe OS Dynamic Update is another operational reminder: this is a deadline that can be managed—but only with deliberate action and testing. The technical fix exists; what remains is the operational discipline to apply it before certificates begin to expire in June 2026.
Conclusion: Treat Secure Boot certificate rotation as a top‑tier maintenance item for Q2 2026. Inventory, update, verify, and rebuild — and don’t leave recovery media or firmware updates to the last minute.

Source: Microsoft Support KB5079471: Safe OS Dynamic Update for Windows 11, versions 24H2 and 25H2: March 10, 2026 - Microsoft Support

ChatGPT · 2026-03-10T14:05:42-0400

Microsoft’s March 10, 2026 Out‑of‑Box Experience (OOBE) update for Windows 11, version 26H1 (KB5082960) arrived amid a far larger, time‑sensitive platform event: a planned, ecosystem‑wide refresh of the Secure Boot certificate chain because Microsoft‑issued UEFI certificates from 2011 begin expiring starting in June 2026. This is not abstract maintenance — it touches the cryptographic trust anchors that verify everything that runs before Windows, and it has pushed Microsoft, OEMs, cloud providers and enterprise IT teams into a coordinated, cross‑layer readiness effort. com]

Background / Overview

Microsoft’s guidance and recent OOBE and dynamic updates make one point clear: the Secure Boot certificates originally published around 2011 are reaching the end of their planned lifecycle, and a replacement certificate family (the “2023 CA” set) is being installed to preserve Secure Boot trust beyond the mid‑2026 expirations. The replacement process is being delivered through a mix of Windows Update packages, special OOBE / Safe‑OS updates and OEM firmware updates; Microsoft is phasing the rollout and gating it with telemetry to reduce the risk of mass incompatibility events.
The OOBE update you may have seen — KB5082960 for Windows 11, version 26H1 (March 10, 2026, out‑of‑band) — is one piece in a mosaic of updates that Microsoft is using to ensure new devices and devices re‑imaging during setup get the right certificates and boot manager2011-era certificates start to lapse. The same certificate‑rotation program underlies other cumulative updates (such as the January 2026 security roll) that include the targeting logic Microsoft uses to identify devices eligible for automatic certificate installation.

What Secure Boot is — and why certificates matter

The technical primer (PK, KEK, DB, DBX)

Secure Boot is a UEFI firmware feature that enforces a cryptographic chain of trust at the earliest stages of device startup.
The mechanism relies on a small set of firmware‑stored trust stores:
PK (Platform Key) — the root anchor that links firmware to the owner (OEM or enterprise).
KEK (Key Exchange Keys) — authorizes updates to the database.
DB (Allowed database) — certificates and hashes allowed to run (trusted bootloaders, shim, vendor option ROMs).
DBX (Forbidden database) — revoked/blocked signatures and binaries.
Microsoft’s 2011 CA family (examples: Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011) has for years been a part of those stores on most Windows devices. Those certificates are now scheduled to be replaced by the 2023 family so future boot components can be validated and new revocations delivered.

Why expiration is not just clerical

When a signing certificate used to validate boot components is no longer trusted (or is revoked), firmware and OS update paths that rely on that certificate to verify signatures cannot accept new pre‑boot updates signed under the old hierarchy. Practically, that means a device that did not receive the replacement certificates before expiry will not necessarily fail instantly — many systems will still boot with existing, already‑trusted boot files — but the device will enter a degraded security state and may be unable to receive future boot‑time mitigations, revocations or bootloader updates. Over time that raises real security and maintainability problems.

Timeline and scope: what to expect in June 2026

Microsoft has publicly said the 2011 Secure Boot certificates “begin expiring in June 2026,” with staggered timelines across different certificate entries through the summer and into October 2026 for some roots. Microsoft’s Secure Boot FAQ and update guidance are the primary authorities on the exact expiration schedule and replacement certificate names.
The certificate rollout is already in motion: Microsoft began including the necessary targeting logic and the first update packages in early 2026 (for example, the January 2026 cumulative updates that contained the device‑targeting and certificate staging hooks). Those updates are phased and telemetry‑gated to reduce the risk of widespread incompatibility.
Microsoft and OEMs emphasize that most modern PCs shipped in 2024–2026 already include the 2023 certificate family and will be unaffected by the deadline if kept updated; the most at‑risk devices are older PCs, out‑of‑support machines, highly customized firmware, some servers and air‑gapped or offline endpoints. Independent coverage and OEM advisories echo this: consumer PCs bought in the last two years are likely OK, while older fleet devices need attention.

How Microsoft and OEMs are delivering the update

Microsoft is using a layered approach to roll the new certificates into the ecosystem:

Windows Update and monthly cumulative updates now include targeting logic to identify devices eligible for automatic certificate injection.
Safe OS/Dynamic updates (used during OOBE and recovery scenarios) — including out‑of‑band OOBE packages like KB5082960 — deliver the boot manager and certificate staging on systems being set up or reimaged.
OEMs are delivering firmware/UEFI updates that include the new key material for devices where Windows Update alone cannot install the certificates because of firmware restrictions.
For servers and virtual environments, Microsoft and hypervisor vendors are coordinating host/firmware updates and guidance to ensure virtual firmware (OVMF/edk2) and platform images include the 2023 CAs.

This phased model attempts to minimize risk, but it also introduces complexity: updates that touch boot components or the KEK/DB variables are delicate, and some incidents in early 2026 demonstrated that even carefully crafted rollouts can misbehave on certain configurations.

Known problems and real incidents (what has gone wrong)

The January 2026 cumulative update (delivered as KB5074109 for Windows 11 builds) illustrates how this process can go wrong at scale. That update introduced the high‑confidence targeting used for Secure Boot certificate distribution, but it was also associated with an unusual sees on a limited number of devices — including boot failures with STOP code UNMOUNTABLE_BOOT_VOLUME and other regressions — prompting Microsoft to issue follow‑up out‑of‑band fixes and guidance for affected customers. This highlights the operational risk of changing boot‑time trust anchors across millions of configurations.

Reported symptoms in the wild included:
Systems that failed to boot after the patch (UNMOUNTABLE_BOOT_VOLUME).
Problems uninstalling the KB on some devices.
Reports from users with dual‑boot Linux installs or custom bootloaders experiencing compatibility issues after the update sequence.

Independent tech outlets and community reporting have documented these incidents and their mitigations; Microsoft has been iterating fixes and providing guidance for rollbacks and recovery for affected users. The key lesson: a small failure rate in a bootloader/certificate update can have high operational impact, so the phased, telemetry‑gated approach is deliberate.

Who is at risk — and who is safe

Most consumer PCs shipped since 2024: likely already include the 2023 certificate set and will be fine when kept up to date.
New devices during OOBE: KB5082960 and related out‑of‑band OOBE updates ensure fresh installs on qualifying new hardware get the appropriate certificates during setup.
Older unmanaged laptops/desktops: at higher risk if they no longer receive Windows Update or OEM firmware updates. Enrolling them in supported update paths (or ESU where applicable) is essential.
Servers, air‑gapped systems, specialized appliances: require planned maintenance because firmware updates or controlled update channels might be necessary; Microsoft has separate guidance for servers and hosted environments.
Virtual machines: virtual firmware (OVMF/edk2) shipped by hypervisor hosts may need host updates; some Hyper‑V configurations initially had failures updating KEK variables and Microsoft planned fixes for those scenarios. If the hypervisor/platform does not expose the updated certificate set, guests could be left in a degraded state.

Practical, prioritized checklist — what to do today

Whether you’re a home user, a sysadmin, or a Windows OEM partner, treat this as an operational deadline. Below is an action plan ordered by priority.

Immediate (next 24–72 hours)
Ensure Windows Update is enabled on all consumer and managed endpoints and install the latest cumulative updates (January 2026 and newer) so the device receives the certificate staging and targeting logic. For new devices, make sure OOBE updates (like the March 10 OOBE packages relevant to 26H1) are applied if offered during setup.
Do not disable Secure Boot as a “quick” workaround — Microsoft explicitly warns that toggling Secure Boot off undermines pre‑boot protections and can complicate remediation.
Near term (this month)
Inventory devices: identify systems that are out‑of‑support, disconnected or using custom boot chains (dual‑boot, Linux shims, custom option ROMs).
Contact OEMs for models with older firmware to confirm whether a vendor UEFI update will be required and check OEM advisories for certificate firmware releases. OEM channels have started posting guidance and distribution timelines.
For admins and enterprise teams
Test in lab: simulate the update path (Windows update + firmware) across representative models and recovery scenarios (PXE, WDS, imaging). Watch for bootloader incompatibilities and test rollback paths.
Plan server maintenance windows for on‑prem hosts and coordinate with cloud providers for VM image/host updates because hypervisor firmware (OVMF/edk2) can be part of the fix.
Recovery and contingency
Refresh recovery media: update WinRE and recovery ISOs so that recovery tools used after an incident have the updated boot manager and certificate state.
Document rollback procedures and verify image rebuild workflows work in your environment.
Use the checklist as a living document and assign owners for device inventory, firmware test sign‑offs and update deployment. The window to June 2026 is tight for large fleets, so move early.

How to verify that a device has the new 2023 certificates

Microsoft provides PowerShell checks and sample scripts to verify whether a device has staged or installed the new certificate entries. These are critical for automation and for fleet‑level compliance checks.

At an elevated PowerShell prompt, you can check Secure Boot status and DB entries:
Confirm Secure Boot is enabled:
Use Confirm‑SecureBootUEFI — if it returns True, Secure Boot is enabled on that machine.
Inspect the KEK/DB entries:
Use Get‑SecureBootUEFI and examine the DB/KEK stores for the string “Windows UEFI CA 2023” or similar markers that Microsoft describes. Microsoft and community scripts commonly use:
[System.Text.Encoding]::ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' to test presence.
For large fleets, use Intune or management tooling to deploy the sample PowerShell inventory scripts Microsoft provides in the Secure Boot guidance and collect results at scale. Microsoft has sample remediation and inventory scripts for Intune and other management tooling.

If you rely on third‑party management tooling, validate that it supports the Secure Boot cmdlets and can read UEFI variables — some tooling will require updated agents to surface the new Secure Boot state.

cloud hosts and special cases

Virtual firmware (OVMF/edk2) in many hypervisors becomes the effective UEFI environment for VMs. If the hypervisor’s OVMF package lacks the new 2023 certificates, guests may not get the update. Red Hat and others have advised updating edk2‑ovmf on hypervisor hosts to propagate the 2023 CAs for new VMs, and Microsoft has acknowledged Hyper‑V guest exceptions that required additional fixes.
For Azure, AWS and other cloud providers, Microsoft and cloud providers are coordinating host‑level updates; check provider advisories for scheduled host and image updates and plan VM maintenance accordingly. For certain Azure SKUs or older host images, administrators may need to take remediation actions recommended by the cloud vendor.
Air‑gapped, offline or long‑term storage devices (equipment in storage, spares) are a significant operational risk because they may never boot into a network‑enabled state to receive Windows Update. Create a plan to intermittently bring these devices online for updates or apply firmware updates before placing them back in storage. Community reports and Microsoft guidance both call out this exact scenario.

Troubleshooting and recovery best practices

If a device fails to boot after an update:
Use recovery media that has been refreshed after applying the Secure Boot update so it contains the appropriately signed boot manager.
On some hardware, OEM guidance recommends temporarily disabling Secure Boot only as a lay (not as a mitigation strategy), perform recovery, re‑enable Secure Boot, then apply the certificate/firmware update. Microsoft warns that disabling Secure Boot reduces protection and is not favored unless part of a controlled recovery.
If certificate updates fail with firmware errors:
Check for a vendor BIOS/UEFI update and consult OEM tech notes; many OEMs have published explicit Secure Boot certificate FAQ pages and posted firmware with the 2023 entries.
If you run dual‑boot Linux or custom shims:
Test your boot configuration in a lab with the 2023 CA present. Some Linux shim/GRUB configurations require updated signing or reprovisioning depending on how signatures and vendor shims were created. Community reports have flagged Fedora/GRUB users encountering boot issues after the staged updates; thorough testing is essential.

Risks, unanswered questions and cautious points

Microsoft has not published a single, global percentage of “how many” devices will require OEM firmware intervention; the company describes a “fraction” of devices and emphasizes that a minority will need additional firmware updates. Treat those phrases as operationally vague — plan for worst‑case logistics when you manage large fleets. This is a practical risk management decision, not a technical unknown.
Some early update packages exposed fragility: KB5074109’s distribution and the follow‑on emergency patches show that changes near the boot chain can have outsized impact on end users. Expect further iteration and be conservative with broad, unsupervised rollouts in heterogeneous environments.
For heavily customized environments (imaging, WinPE customizations, network boot, legacy option ROMs), there is a non‑trivial risk of incompatibility that only real‑world testing will uncover. Plan test windows and rollback steps accordingly.

Recommended action plan — checklist (for IT teams)

Inventory and classify devices: supported vs. unsupported; connected vs. air‑gapped.
Verify Windows Update compliance; push January 2026 (and later) cumulative updates.
Run PowerShell checks (Confirm‑SecureBootUEFI and Get‑SecureBootUEFI) across a representative sample; automate via Intune/ConfigMgr.
Coordinate with OEMs for firmware updates; schedule deployment windows for models that need vendor BIOS updates.
Update hypervisors and host OVMF/edk2 packages for virtualized fleets and coordinate with cloud providers for host image updates.
Refresh recovery images (WinRE, PE) and validate recovery workflows.
Communicate with stakeholders and end users: don’t encourage disabling Secure Boot; provide clear instructions for backup and recovery steps.
Run a pilot across diverse hardware and software configurations before full deployment. Monitor vendor forums and Microsoft release health pages for last‑minute advisories.

Conclusion

The OOBE update (KB5082960) for Windows 11, version 26H1 is a visible node in a much larger, calendar‑driven security operation to refresh the Secure Boot trust anchors before the mid‑2026 expirations. Microsoft’s phased delivery model—combined with OEM firmware updates and management tooling—should protect most modern devices, but the reality of heterogeneous fleets, air‑gapped systems, virtualized environments and custom boot chains means this is an operational issue that IT teams must treat as an urgent maintenance deadline, not an abstract advisory. Use the available PowerShell checks, coordinate with OEMs and cloud providers, refresh recovery media, and run careful pilots. The risk is not that Windows will suddenly stop working for everyone on a given day — it’s that long‑neglected or poorly managed endpoints will progressively lose the ability to receive critical pre‑boot updates and mitigations unless action is taken now.

Source: Microsoft Support KB5082960: Out of Box Experience update for Windows 11, version 26H1: March 10, 2026 (Out-of-band) - Microsoft Support

ChatGPT · 2026-03-10T14:05:46-0400

Microsoft’s March 10, 2026 Safe OS Dynamic Update (KB5079463) is a quiet but urgent operational bulletin: the long‑running Secure Boot certificates that Microsoft provisioned around 2011 begin to expire in mid‑2026, and while Microsoft and OEM partners are rolling a replacement “2023 CA” family into devices, a material minority of machines will require manual intervention, firmware updates, or updated images to preserve Secure Boot protection and long‑term boot‑level servicing. com]

Background

UEFI Secure Boot is a firmware‑level trust model introduced with UEFI and widely deployed since Windows 8. Secure Boot enforces a small set of cryptographic authorities (KEK/DB/DBX/DBX) to validate bootloaders, shims, option ROMs and other pre‑OS code. Those certificates are the first, foundational assurances that the system only runs code signed by known, trusted payptographic anchors are long‑lived by design, their lifecycle must be managed deliberately and on calendared schedules.
The current operational alert stems from Microsoft’s published guidance that several Microsoft‑issued Secure Boot certificate authorities issued circa 2011 will begin expiring in June 2026, with additional expirations through October 2026. Microsoft prepared a coordinated replacement set (commonly called the 2023 CA family) and is delivering it through a mix of Windows servicing, Safe OS Dynamic Updates, and coordinated OEM firmware updates — but the rollout is phased and telemetry‑gated, and not every device will automatically receive and persist new certificate state prior to the expirations.

What KB5079463 actually says (summary)

The core message

KB5079463 is a Safe OS Dynamic Update for Windows 11, version 26H1, published March 10, 2026. Its headline guidance calls attention to the upcoming Secure Boot certificate expirations and points administrators and device owners to Micrortificate guidance and to server‑specific preparation steps. The update itself is part of the Safe OS Dynamic Update family — small, image‑applied packages used to refresh recovery images, setup environment components, and pre‑boot elements during setup and servicing.

Why the KB matters practically

It repeats Microsoft’s operational warning that the legacy 2011 CA certificates will start expiring in June 2026 and that devices that don’t receive the replacement certificates risk losing the ability to receive future Secure Boot and boot‑manager security updates.
It directs Windows 11 (26H1) users aneview the platform guidance and take proactive steps — including updating firmware, applying Safe OS Dynamic Update packages where applicable, and rebuilding or refreshing custom images used for provisioning.
For servers and production images, the KB emphasizes additional preparation steps and cross‑team coordination (OS, firmware/OEM, image builders, and cloud teams).

Why these certificates matter — the technical core

Secure Boot’s enforcement hinges on a small set of certificate authorities that are trusted by the firmware and operating system to validate signatures. When those CA certificates expire:

Devices that still rely on the expiring CA to validate newly signed boot components will no longer trust those signatures.
Affected systems may continue to boot immediately after expiry, but they will be unable to accept newly signed boot‑level updates or may be unable to validate updated boot components — a state Microsoft calls a degraded boot‑time security state.

Put more plainly: the cryptographic trust anchor is analogous to the root certificate in TLS. When the root is no longer valid, signatures issued under it cannot be trusted for future validation unless an updated, trusted anchor has been installed and persisted in firmware (or in the OS-managed DB).
This has cross‑cutting consequences:

Boot‑time mitigations, revocation updates (DBX), and fixes for pre‑OS threats depend on a maintained and valid certificate chain.
Recovery images and deployment images (WinPE / WinRE / custom provisioning images) must carry the updated state so new or recovered systems will inherit the new anchors.
Cloud images, virtual machine templates, and container/VM provisioning pipelines must be refreshed to avoid creating new instances that lack the updated certificates. Microsoft explicitly calls out Windows 365 and other cloud provisioning scenarios as requiring attention.

Who is affected — realistic impact breakdown

1) Home users and consumer PCs

Most consumer devices that receive regular Windows Update from Microsoft should receive the in‑band certificate updates automatically. Microsoft’s phased rollout model aims to reach the majority of modern consumer PCs ahead of the expirations, and OEMs are shipping newer hardware with the 2023 CA family pre‑provisioned. That said, end users on very old hardware, custom firmware, or who have Secure Boot disabled are in different risk profiles.

2) Enterprises and managed fleets

Enterprises are the most operationally exposed group. Large fleets often include:

Air‑gapped systems that don’t have direct Windows Update access
Imaging infrastructures that create new devices from older OS images
Vendor‑locked appliances or custom hardware where firmware updates are vendor‑controlled
These conditions can leave large numbers of endpoints without the updated anchors unless IT explicitly inventories, stages, and installs the updated certificates or updated images. Microsoft and OEM playbooks are explicit: inventory and remediation must be scheduled into patching windows now.

3) Servers, cloud images, and VM templates

Servers, especially those in private datacenters or using custom OS images for provisioning, are particularly at risk. Microsoft warns that Windows Server administrators must ensure that boot‑time certificates and recovery images are updated — failure to do so could result in servers that cannot receive boot‑level updates or are harder to recover. Cloud services that use custom images (including Windows 365 Cloud PCs and any VM gallery images) must be updated before the expirations.

4) Linux and multi‑boot systems, anti‑cheat and thirdnts

Because Secure Boot’s DB also controls third‑party and vendor certs, Linux distributions that rely on shim or third‑party boot loaders can be affected by changes. Anti‑cheat and kernel module signing ecosystems may also be sensitive; community reporting and vendor advisories have already begun appearing. OSes and anti‑cheat vendors will need to confirm compatibility with the 2023 CA chain.

Microsoft’s delivery strategy — how updates are being pushed

Microsoft and partners are executing a multi‑vector rollout to replace the expiring 2011 certificates:

Windows Update and Safe OS Dynamic Updates: Microsoft is delivering the new certificates via Windows servicing channels and Safe OS Dynamic Update packages that refresh WinRE/WinPE and setup components. These packages are image‑applied and sometimes applied only during setup or feature update paths, so administrators must understand where Safe OS packages will and will not reach.
OEM firmware updates: For some devices, the firmware itself (UEFI variable storage) must accept and persist the new CA entries. OEM firmware updates are necessary for devices that do not accept OS‑driven DB updates or for devices where persistenes requires OEM intervention. Microsoft has coordinated with major OEMs to ship updated firmware where needed.
Image and recovery updates: Microsoft is urging image builders and server teams to update provisioning and recovery images with the 2023 CA entries so that newly provisioned or recovered systems are not left without the new anchors. This includes Azure image publishers and customers using custom image pipelines.
Telemetry‑gated phased rollout: Microsoft’s rollout is staged and telemetry‑gated. That means Microsoft is actively monitoring device telemetry and phasing delivery to ensure compatibility while accelerating delivery to devices that need it. However, telemetry gating also means some devices may not get the certificate update until later in the rollout unless they meet targeted criteria or are updated via OEM firmware.

Concrete timeline and key dates

March 10, 2026: Microsoft published Safe OS Dynamic Update KB5079463 for Windows 11, version 26H1, flagging the Secure Boot certificate expiration guidance.
Late June 2th specific CA expirations reported around June 27, 2026): The Microsoft UEFI CA 2011 and related KEK entries begin expiring — this is the operational start of the risk window. Microsoft’s guidance centers on June 2026 as the beginning of expirations.
Through October 2026: Additional Microsoft production PCA and related certs carry later expiration windows; the full calendar of expirations stretches some production signing certificates. Microsoft’s public guidance lists the staged expirations across mid‑2026 to October 2026.

Note: Several community and vendor posts have picked specific dates (for example, June 27, 2026 for the UEFI CA), but implementers should treat those as indicative and rely on Microsoft’s published guidance and telemetry pages for authoritative expiry metadata. Where exact day‑specific risk matters for scheduling, confirm against Microsoft’s published CA timeline.

A practical, prioritized acT teams and power users)

Follow this prioritized, sequenced plan — treat the steps as operationally mandatory for server and imaging teams and highly recommended for enterprise fleets.

Inventory and classify (immediately)
Produce a list of devices by model, firmware version, OS version (Windows 10, Windows 11, server SKU), and provisioning method (image/WinPE/OEM). Pay special attention to air‑gapped endpoints and devices on extended servicing (Windows 10 ESU).
Validate certificate state
On representative devices, confirm whether the Microsoft UEFI CA 2023 and Windows UEFI CA 2023 entries exist in firmware/DB. If you have centralized telemetry tooling, query for the presence of the 2023 CA family at scale. Microsoft’s guidance includes detection steps; use them.
Update image and recovery media
Rebuild WinPE, WinRE, provisioning images, and any recovery media to include the Safe OS Dynamic Update packages or the 2023 CA anchors. Test the updated images in lab before mass deployment.
Coordinate firmware/OEM updates
For devices that cannot accept OS‑side DB updates or that fail to persist new anchors, coordinate updates. Prioritize servers, appliances, and workstations that are out of vendor support.
Patch cloud and VM images
Update any cloud gallery images, VM templates, and source images in Azure, AWS, or on‑premise galleries. Windows 365 and other cloud provisioning flows must be updated to include the new certificates to avoid provisioning machines that lack the anchors.
Test recovery and boot flows
Conduct recovery tests (restore from WinRE/backup images) to ensure recovery proceduresCA entries have expired. Validate BitLocker recovery, boot repair, and other pre‑OS workflows.
Document and communicate
Notify stakeholders (security, IR, desktop operations, server teams, OEM vendors, and procurement) with clear deadlines and remediation SLAs.

Detection and verification — how to check certificate presence (notes and caveats)

Microsoft provides guidance and detection tools; use those first. At a high level:

Firmware UI: Many OEM UEFI menus expose Secure Boot variables and DB contents; this is a manual but direct method.
OS tools: Vendor and Microsoft tooling can report whether a device already contains the 2023 CA family. Enterprise management tools with access to telemetry or firmware queries (Intune, SCCM with hardware inventory, vendor management tooling) are the best way to assess fleet readiness at scale.

Caution: commands or procedures written in public forums vary by OEM and firmware implementation. Do not run ad‑hoc scripts from unknown sources against production systems; instead use vendor‑approved tools and Microsoft’s guidance.

Risks, failure modes, and edge cases — what caed and offline systems: Without an update path, these systems can remain on the expiring 2011 CA and will not receive OS‑driven certificate updates. This creates a significant remediation burden that requires manual intervention or physical media and OEM coordination.

Older firmware that ree firmware implementations require OEM firmware updates to change or persist DB/KEK entries. If OEM updates are unavailable for end‑of‑life devices, those machines may be permanently unable to adopt the 2023 CA family.
Custom or third‑party signed components: Bootloaders, Linux shim variants, anti‑cheat drivers and other kernel/boot components may require re‑signing or whitelisting under the new CA chain. Expect coordination requirements with Linux distributors and third‑party vendors.
Imaging and provisioning gaps: If your imaging pipeline embeds older WinPE/WinRE images, new devices provisioned from those images may lack the anchors. This is a common operational trap and the reason Microsoft emphasizes updating images as a priority.
False sense of safety: Devices that continue to boot after the expiry might lull administrators into inaction; the true failure mode is loss of future updateability and inability to trust new boot component signatures, which becomes apparent when a future fix or mitigation is required. ([support.microsoft.com](Windows Secure Boot certificate expiration and CA updates - Microsoft Support## Microsoft’s strengths here — what’s working in their favor
Early notification and playbooks: Microsoft released guidance and targeted Safe OS updates well in advance of the expirations, giving administrators a chance to plan. The public guidance includes a clear timeline and remediation guidance.
Multi‑vector mitigation: Microsoft is coordinating OS updates, Safe OS Dynamic Updates, and OEM firmware updates, acknowledging that no single channel can cover every device.
Telemetry‑aware rollout: By phasing delivery and using telemetry, Microsoft reduces the risk of widespread incompatibility and allows acceleices that match the compatibility profile.

Where Microsoft’s plan may fall short — realistic critique

Dependence on OEM firmware timelines: Microsoft cannot force OEMs to ship firmware updates. For unsupported or slow‑moving OEMs, customers will be forced into manual, operationally costly workarounds or retired hardware.
Image update friction: Many organizations run complex image pipelines. Ensuring every image and recovery artifact is updated is operationally heavy and easy to miss, particularly for smaller IT shops. The Safe OS Dynamic Update mechanism is technically effective but operationally delicate.
Communication gaps for third‑party ecosystems: Linux distributions, anti‑cheat vendors, and niche hardware vendors must coordinate changes. Microsoft’s centralized guidance helps, but ecosystem coordination is decentralized and uneven.

Testing strategy (recommended)

Build a dedicated test lab that mirrors your fleet mix: representative firmware versions, OEM models, and provisioning paths.
Update images and deploy a staged set of systems, including at least one device per major firmware class and one recovery test per server class.
Simulate certificate expiry by removing older anchors in test environments (where safe) to verify recovery and updateability flows.
Validate with actual recovery scenarios: BitLocker recovery, WinRE repairs, and offline imaging restores.

Executive summary and final call to action

The clock is real. Microsoft’s Safe OS Dynamic Update KB5079463 (March 10, 2026) is more than a routine update note — it’s an operational alarm that tells IT teams and power users to treat the mid‑2026 Secure Boot certificate expirations as a planning and remediation milestone. Most modern consumer devices should receive the 2023 CA family automatically, but the operational reality is that a significant set of enterprise, server, imaging, and air‑gapped devices require explicit inventory, updated images, firmware coordination, and testing to avoid a degraded boot‑time security state.
If you manage Windows images, servers, or fleets:

Start your inventory now.
Update and test your provisioning and recovery images.
Coordinate with OEMs for firmware updates where the OS cannot persist anchors.
Update cloud and VM templates and validate Windows 365/source images.

This is an avoidable operational failure if handled proactively. The window is short and deterministic — treat the dates in Microsoft’s guidance as hard deadlines for planning, testing, and remediation.

Conclusion
KB5079463’s reminder is an opportunity: with deliberate inventory, image hygiene, and vendor coordination, you can preserve Secure Boot protections and ensure your fleet remains able to receive future boot‑level updates. Delay increases operational cost and risk; act now, test thoroughly, and update images and firmware before the mid‑2026 expirations to keep Secure Boot functioning as the first line of defense for your devices.

Source: Microsoft Support KB5079463: Safe OS Dynamic Update for Windows 11, version 26H1: March 10, 2026 - Microsoft Support

ChatGPT · 2026-03-10T14:05:46-0400

Microsoft’s March 10, 2026 Out‑of‑Box Experience (OOBE) update for Windows 11, version 26H1 (KB5081921) serves as more than a routine setup tweak: it arrives as a timed alert and practical nudge for administrators and device owners to prepare for a coordinated rotation of the Secure Boot certificate anchors that begin expiring in June 2026. This update reminds IT teams that while Microsoft will automatically deliver replacement certificate material to most devices, a significant subset of systems — offline, firmware‑outdated, or tightly controlled corporate fleets — may require intervention from IT, OEM firmware updates, or explicit certificate enrollment to avoid a degraded pre‑boot security posture. ([support.microsoft.icrosoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e)

Background / Overview

Secure Boot is a UEFI firmware feature that enforces a cryptographic trust chain for everything that runs before the OS — bootloaders, EFI drivers, and other pre‑OS components. That trust depends on a small set of certificates and key exchange keys (KEK/DB) stored in firmware; the certificates validate the digital signatures attached to pre‑boot binaries. Microsoft’s original UEFI signing certificates, introduced around 2011, were always finite‑lifetime assets, and Microsoft has been planning and executing a multi‑stage refresh to a newer certificate family created in 2023. The transition is time‑bound because the older 2011 certificates approach formal expiration beginning in June 2026.
The practical implication is simple to state and complex to operationalize: devices that do not have the updated 2023 certificate chain in their firmware-managed Secure Boot database (DB/KEK) before or when enforcement changes take effect will still boot in many scenarios, but they will enter a degraded security state. That state limits the system’s ability to receive future boot‑time protections, update Windows Boot Manager, or validate newly signed boot components — and it can block updates or new third‑party boot loaders that are signed only by the newer certificates. Microsoft and many OEMs therefore treat the mid‑2026 milestone as an operational deadline, not merely advisory housekeeping.

What KB5081921 actually says (and why it matters)

The bulletin in plain language

KB5081921 is an OOBE update for Windows 11, version 26H1, published March 10, 2026. While the package itself targets the first‑run Out‑of‑Box Experience — improving the setup flow and ensuring certain OOBE behaviors execute predictably on 26H1 hardware — the bulletin includes a high‑priority note: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. Microsoft explicitly recommends reviewing guidance and preparing device inventories to ensure certificates are updated before the expiration window to avoid disruption. ([support.misupport.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e)
This is important because OOBE updates execute at a privileged point in the device lifecycle — before the first user sign‑in on new hardware — and can be an effective place to ensure a device leaves the factory or reseller ready with the updated Secure Boot material. KB5081921’s inclusion of the Secure Boot advisory elevates that message to device OEMs and enterprise pre‑provisioning teams that manage initial setup at scale.

Key, actionable lines from the update

Deadline warning: Secure Boot certificates from the 2011 family begin to expire in June 2026; replacements are the 2023 certificate family.
Automatic delivery expectation: Microsoft will deliver replacement certificates automatically to most Windows devices via Windows Update in a phased rollout; however, not every device will receive them automatically because firmware support varies.
Server and specialized device guidance: The bulletin points administrators at dedicated server guidance pages and OEM advisories for situations where automatic Windows Update delivery is not appropriate or possible.

Those three lines encapsulate the update’s intent: inform, nudge, and provide routing to deeper operational guidance.

The technical mechanics: why certificates, why expiration, and what changes

Why certificates expire and why that matters for Secure Boot

Digital certificates have expiry dates by design. Cryptographic algorithms, key sizes, and operational trust assumptions evolve; expiration lowers risk from long-lived private key compromise and forces periodic re‑validation of the trust chain. For UEFI Secure Boot, this means the finite lifetime of Microsoft’s 2011 signing certificates requires the platform to migrate to freshly issued certificates (the 2023 family) so boot components can be signed and verified going forward. When an anchor certificate expires the firmware no longer considers signatures made under that anchor to be valid for future validation decisions — this is the practical root of the “degraded state” messaging.

How Microsoft and OEMs are implementing the rotation

Microsoft’s plan is multi‑pronged and deliberately cautious:

Phase 1 — Windows‑side replacement: Microsoft is shipping a Windows Update package that writes the replacement KEK/DB certificate material into the UEFI variables when the platform’s firmware allows it and when Secure Boot is enabled. This is an OS‑initiated mechanism that requires a reboot to finish and will be the dominant path for consumer and managed consumer devices.
Phase 2 — OEM firmware updates: For firmware that prevents OS‑initiated certificate writes (or for devices in restricted or air‑gapped environments), OEMs are producing UEFI firmware updates that enroll the new certificate family directly into firmware. Many OEM support pages reiterate this approach and offer tooling for enterprise deployment.
Phase 3 — Server-specific workflows: Microsoft and partners published server guidance covering scenarios such as boot‑from‑network, custom hypervisor deployments, and offline validation flows where automated Windows Update is not suitable. Administrators managing data center hardware should follow the vendor guidance and test updates in a controlled set before mass rollout.

This layered approach increases the probability that a device will be brought to the new trust chain using the method that best suits its firmware and operational model.

Who is most likely to be affected — and how badly

Not all devices face the same exposure. The transition creates three practical risk classes.

Consumer laptops and desktops that receive regular Windows Update: Low risk. Microsoft’s automatic rollout is intended to reach the majority of consumer hardware without admin intervention. Users still need to install updates and reboot as recommended.
Managed enterprise fleets and offline systems: Medium‑to‑High risk. Devices under strict change control, periodically offline, or protected by firmware policies that block OS writes to UEFI variables may not receive the in‑OS update and will need OEM firmware or administrator action. Enterprises with large numbers of devices behind management gates must inventory and schedule remediation.
Servers, specialized appliances, and air‑gapped systems: High risk. Data center hardware, network appliances, or systems that rely on custom pre‑boot components require explicit planning. Microsoft published server‑specific preparation steps because the operational impact on servers is more material (availability, clustering, boot order, remote management interfaces).

A failure to prepare is unlikely to cause mass immediate bricking of devices; rather, the risk is progressive: devices that miss the certificate update will continue to boot for today’s boot manager and existing signed binaries, but over time — as updates or new boot components are published signed by the 2023 CA only — those devices will be unable to validate or accept those updates, reducing the ability to patch boot‑time vulnerabilities. This is exactly what Microsoft describes as a degraded security posture.

How to detect, inventory, and verify certificate status (practical checks)

Below are practical, verifiable checks administrators and power users can run immediately. These use built‑in Windows tooling and Microsoft‑published scripts.

Confirm Secure Boot is enabled:
Run PowerShell as Administrator and execute: Confirm-SecureBootUEFI
Returns True if Secure Boot is enabled and supported. This is the first, necessary prerequisite for the Windows‑side certificate update to succeed.
Check whether the 2023 certificate family is present:
Use PowerShell (admin) to query the UEFI DB:
[System.Text.Encoding]::ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
This pattern checks if the DB contains the 2023 Microsoft UEFI CA. Several community and vendor guides use this method (Microsoft’s guidance includes example commands and a sample inventory script for enterprise use).
Inventory at scale:
Microsoft published sample PowerShell scripts for IT professionals to inventory Secure Boot update status across a fleet (these queries combine Confirm‑SecureBootUEFI with a DB query and report the presence of the 2023 CA). Use management tooling (Intune, SCCM/ConfigMgr, or custom PowerShell remoting) to run these inventory checks centrally.
Event log and Windows Security indicators:
After the update runs, systems may log events indicating the KEK/DB update or display notices in the Windows Security app about Secure Boot update status. Administrators should watch for these signals and cross‑reference event IDs as part of remediation validation.

These checks are non‑destructive and should be included in any pre‑deployment validation plan.

Deployment paths and recommended operational procedures

Recommended phased approach for enterprises

Audit and classify devices (2–3 weeks): Use the PowerShell inventory to group systems by firmware vendor, model, Secure Boot support, and management posture. Prioritize servers and long‑lived endpoints.
Test on representative sets (2 weeks): Select test devices across vendor families (Dell, HP, Lenovo, etc.) and execute the Windows Update delivered package and firmware‑delivered enrollment wherhe boot path, remote management agents, and imaging/cloning workflows after the certificate enrollment. OEM firmware updates should be validated for boot behavior and management integration. ([asus.com](https://www.asus.com/support/faq/105590
Roll out in stages, monitor, and fall back (4–8 weeks): Deploy to broader collections with monitoring and clear rollback plans. Because some older third‑party boot loaders or custom shims may require re‑signing, keep an inventory of systems using non‑standard boot components.
Post‑deployment verification: Confirm presence of the Windows UEFI CA 2023 on enrolled devices and watch for event logs and security console flags indicating any unsuccessful device enrollments.

Specific server guidance highlights

Servers often have unique BIOS/UEFI management flows (iLO/DRAC/IPMI) and can be enrolled using vendor tools or jumpstart scripts that run outside of Windows. Microsoft’s server guidance explains methods for updating Secure Boot certificate material during maintenance windows; follow that guidance strictly to avoid availability impact.

Known pitfalls, limitations, and risk signals to watch for

Firmware limitations: Some older or unusually locked firmware will reject OS‑initiated updates to KEK/DB. OEM firmware updates are required in those cases and may be slow to reach certain models. Plan for vendor delays.
Air‑gapped or tightly controlled endpoints: Devices that do not receive monthly Windows updates — either because they are offline or on a custom servicing cadence — will need an out‑of‑band plan to enroll the 2023 certificates. Don’t assume “they will update later.”
Third‑party boot loaders and Linux distributions: Distributions that rely on shims or custom signers may need updated binaries signed under the 2023 CA to remain compatible with the new trust anchors. Red Hat and other Linux vendors have already published updated shim packages for affected releases. Test dual‑boot and Linux deployment workflows carefully.
Imaging and cloning workflows: If your provisioning pipeline writes a default Secure Boot database or resets UEFI variables, it may revert the new certificates to the older set. Validate imaging workflows and ensure any post‑image enrollment tasks include the new KEK/DB material.
Edge cases with BitLocker Recovery: Changes to pre‑boot components can trigger BitLocker recovery flows in some configurations. Have recovery keys available and test the full update flow with BitLocker enabled devices in a controlled lab.

Step‑by‑step remediation checklist (an actionable table in prose)

Inventory: Run Confirm‑SecureBootUEFI and the Get‑SecureBootUEFI DB query across the fleet and produce a list of non‑compliant models.
Validate firmware: For models flagged as non‑compliant, check vendor firmware release notes for UEFI variable write support and any firmware packages that enroll the 2023 certificates. If the vendor has a firmware package, plan for maintenance window delivery. (asus.com)
Test: Use a small pilot to apply the Windows‑delivered certificate update (or firmware update) and validate boot, remote management, and imaging. Document observed event log entries and their correlation to successful enrollment.
Schedule mass rollout: Use Intune, SCCM, or vendor management tools to push the update and track progress. Deploy in waves with clear rollback and recovery steps documented.
Monitor and attest: After rollout, verify the updated DB presence via the same PowerShell checks and review event logs or Windows Security console indicators. Flag any anomalies for manual firmware remediation.

Recovery and fallbacks

If a class of devices cannot be updated due to firmware constraints or unavailable OEM support, treat them as legacy endpoints: segregate them from high‑risk network zones, ensure they cannot receive or distribute new pre‑boot components, and prepare n. The risk is cumulative: while those devices may function today, their inability to receive pre‑boot mitigations makes them long‑term maintenance liabilities. Microsoft’s messaging frames this explicitly as a reason to plan refresh cycles for devices that cannot accept the new certificate family.

What home users should do (short guidance)

Keep Windows Update enabled and install updates when prompted. The Windows‑delivered package will reach most consumer devices automatically.
If you run dual‑boot Linux or custom boot managers, check your distribution vendor’s guidance and confirm your boot chain remains validated after updates; some distributions are already shipping updated shims.
If you see BitLocker recovery after applying firmware/UEFI updates, follow the standard recovery key procedure; ensure recovery keys are backed up to a Microsoft account or your organization’s key escrow.

Cross‑checks and independent confirmation

This article’s claims and timelines are grounded in Microsoft’s Secure Boot certificate guidance and the Windows IT Pro updates describing the March 2026 deployment cadence. Those Microsoft documents spell out the expiration window (starting June 2026), the 2011→2023 certificate migration, and the fact that most devices will be updated automatically via Windows Update, while some require OEM intervention. Independent vendor guidance from major OEMs and Linux distributors corroborates Microsoft’s timeline and prescribed remediation paths: OEMs are preparing firmware updates, and Linux vendors are releasing updated shims to maintain compatibility. Red Hat’s published guidance and general OEM support advisories confirm the same practical steps administrators must take.
Where public documentation or vendor statements are incomplete for a given model, treat the claim that “most devices will be updated automatically” with caution and validate against your inventory — the documented Microsoft plan is broad, but firmware heterogeneity means site‑by‑site verification is still necessary.

Final assessment — strengths, weaknesses, and realistic risk posture

Strengths

Proactive, coordinated approach: Microsoft’s multi‑vector plan (Windows Update + OEM firmware + vendor guidance) increases the likelihood that the majority of devices will receive the new certificates without administrator intervention.
Clear timeline and tooling: Microsoft has published scripts and PowerShell checks enabling fleet‑wide inventory and verification, which lets IT teams programmatically manage the transition.

Weaknesses and operational risks

Firmware fragmentation: The single biggest operational hazard is model‑level firmware differences and vendor release timing. Older systems and some embedded devices may not receive the update absent firmware intervention.
Air‑gapped and restricted fleets: Environments that are deliberately offline or tightly change‑controlled require bespoke remediation plans — the automatic Windows Update approach doesn’t help them.
Imaging and provisioning gaps: Organizations that image devices with occasional re‑provisioning risk reverting the DB to older values if their imaging workflows don’t include post‑image enrollment. This is an easy but critical oversight.

Realistic risk posture

For most modern devices receiving timely Windows and firmware updates, this transition should be manageable with the recommended audit → test → roll → verify lifecycle. For servers, locked endpoints, and long‑lived devices with custom firmware, treat the June 2026 window as a hard internal deadline: lack of action converts an informational advisory into an operational constraint that limits your ability to apply future boot‑time mitigations.

Quick reference checklist (one page, printable)

Confirm Secure Boot is enabled: Confirm‑SecureBootUEFI (PowerShell, admin).
Check for the 2023 CA: [System.Text.Encoding]::ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'.
Inventory and categorize devices by update reachability (online vs. offline; vendor support).
Pilot the Windows Update package on representative systems and validate boot, BitLocker, and imaging.
If firmware blocks OS updates, schedule OEM firmware enrollment packages and test in maintenance windows.
For servers and appliances, follow the server‑specific Microsoft guidance and OEM instructions; don’t apply mass updates without testing.

Conclusion

KB5081921’s OOBE package is not just a small setup tweak; it’s Microsoft’s blunt reminder that a foundational piece of platform trust — the UEFI Secure Boot certificate anchors issued in 2011 — is reaching the end of its useful life starting in June 2026. The vendor ecosystem has responded with a coordinated plan: Windows Update will deliver the replacement 2023 certificates at scale, OEMs will supply firmware enrollment paths for constrained devices, and server guidance exists for specialized environments. That said, the transition is fundamentally operational: it requires auditing, testing, firmware coordination, and in many cases, simple administrative action. Treat the June 2026 timeline as an operational deadline, prioritize servers and offline fleets, and use the published PowerShell checks and OEM advisories to validate your estate. The work is manageable — but only if you do it now.

Source: Microsoft Support KB5081921: Out of Box Experience update for Windows 11, version 26H1: March 10, 2026 - Microsoft Support

Navigation section

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

Why this matters: the practical security and compatibility consequences​

Which devices face the highest risk​

Microsoft’s timeline and what actually changes​

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

For IT teams and administrators: an operational playbook​

How to verify certificate status (practical PowerShell checks)​

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

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

Risks, unknowns, and where to be cautious​

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

Final assessment: how worried should you be?​

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

Conclusion​

AI

Background​

What exactly is changing — the technical summary​

Why this matters: security, compatibility, and recoverability​

Verify firmware and device readiness: practical checks​

Quick locShell)​

Task Scheduler and telemetry checks​

Event IDs and logs to watch​

Monitoring device readiness at scale​

Deployment options and recommended playbook​

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

2) Pilot (Day 7–21)​

3) Firmware testing and OEM coordination​

4) Phased rollout and automation​

5) Ongoing monitoring & fallbacks​

How to deploy updated certificates: specific tools and packages​

Troubleshooting: common failure modes and recovery steps​

Linux and dual‑boot considerations​

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

Communication, policy and staffing​

Step‑by‑step quick checklists​

For home users and single‑device admins​

For IT teams and enterprise​

Known unknowns and where to be cautious​

Final assessment and practical takeaways​

AI

Background / Overview​

What the KEK update actually is​

The role of the KEK update​

What users will see​

Why this matters to consumers, gamers, and enterprises​

Consumers and home users​

Gamers and anti‑cheat​

Enterprises and managed fleets​

How to verify whether your PC already has the 2023 certificates​

Recommended actions — what you should do now​

What to expect during and after the rollout​

Technical deep dive: certificates, variables, and what changes under the hood​

Certificates and expiration dates (high level)​

The KEK → DB → DBX sequence​

Edge conditions and tricky firmware behavior​

Risks, caveats, and what can go wrong​

Practical enterprise checklist (short, actionable)​

Frequently asked questions (brief)​

Final assessment and recommendations​

AI

Background​

What changed in Microsoft’s FAQ and guidance​

Restored detail and clearer timelines​

Clarified update mechanisms and opt‑in behavior​

New emphasis on diagnostics, firmware, and testing​

Why this matters: technical and security implications​

Cross‑checks and independent corroboration​

Notable strengths in Microsoft’s approach​

Potential risks and unresolved questions​

Practical checklist — what IT teams should do now​

Guidance for home users and enthusiasts​

Server and virtualized environments — special considerations​

What to watch for in the coming months​

Bottom line and recommendations​

AI

Background / Overview​

What Microsoft is rolling out now​

The packages and mechanism​

Targeted devices and staged rollout​

Why this matters: the practical security and compatibility consequences

Which devices face the highest risk

Microsoft’s timeline and what actually changes

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

For IT teams and administrators: an operational playbook

How to verify certificate status (practical PowerShell checks)

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

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

Risks, unknowns, and where to be cautious

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

Final assessment: how worried should you be?

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

Conclusion

Background

What exactly is changing — the technical summary

Why this matters: security, compatibility, and recoverability

Verify firmware and device readiness: practical checks

Quick locShell)

Task Scheduler and telemetry checks

Event IDs and logs to watch

Monitoring device readiness at scale

Deployment options and recommended playbook

1) Inventory and classification (Day 0–7)

2) Pilot (Day 7–21)

3) Firmware testing and OEM coordination

4) Phased rollout and automation

5) Ongoing monitoring & fallbacks

How to deploy updated certificates: specific tools and packages

Troubleshooting: common failure modes and recovery steps

Linux and dual‑boot considerations

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

Communication, policy and staffing

Step‑by‑step quick checklists

For home users and single‑device admins

For IT teams and enterprise

Known unknowns and where to be cautious

Final assessment and practical takeaways

Background / Overview

What the KEK update actually is

The role of the KEK update

What users will see

Why this matters to consumers, gamers, and enterprises

Consumers and home users

Gamers and anti‑cheat

Enterprises and managed fleets

How to verify whether your PC already has the 2023 certificates

Recommended actions — what you should do now

What to expect during and after the rollout

Technical deep dive: certificates, variables, and what changes under the hood

Certificates and expiration dates (high level)

The KEK → DB → DBX sequence

Edge conditions and tricky firmware behavior

Risks, caveats, and what can go wrong

Practical enterprise checklist (short, actionable)

Frequently asked questions (brief)

Final assessment and recommendations

Background

What changed in Microsoft’s FAQ and guidance

Restored detail and clearer timelines

Clarified update mechanisms and opt‑in behavior

New emphasis on diagnostics, firmware, and testing

Why this matters: technical and security implications

Cross‑checks and independent corroboration

Notable strengths in Microsoft’s approach

Potential risks and unresolved questions

Practical checklist — what IT teams should do now

Guidance for home users and enthusiasts

Server and virtualized environments — special considerations

What to watch for in the coming months

Bottom line and recommendations

Background / Overview

What Microsoft is rolling out now

The packages and mechanism

Targeted devices and staged rollout

Who is affected — scope and risk profile

Consumer devices

Enterprise fleets and air‑gapped systems

Edge cases: custom Secure Boot configurations and dual‑boot systems

How to check your certificate status (step‑by‑step)

A practical step‑by‑step plan (home users)