Microsoft released KB5092765 on May 26, 2026, as a Setup Dynamic Update for Windows 11 versions 24H2 and 25H2, improving setup components while repeating its warning that Secure Boot certificates on most Windows devices begin expiring in June 2026 worldwide. The update itself is small, almost administrative, and easy to miss. The warning attached to it is not. Microsoft is using even routine servicing notes to tell customers that the Windows boot chain is entering a once-in-a-generation trust transition.
KB5092765 is not a flashy cumulative update, a feature drop, or a Patch Tuesday security bulletin. It is a Setup Dynamic Update, the kind of package Windows uses to refresh setup binaries and related files during feature updates. In practical terms, it helps Windows 11 24H2 and 25H2 installation and upgrade workflows use newer setup components.
That sounds mundane because it is. Setup Dynamic Updates are the plumbing of Windows servicing, not the furniture. They matter most when administrators are building installation media, managing in-place upgrades, or relying on Windows Update, WSUS, or the Microsoft Update Catalog to keep deployment machinery current.
But Microsoft’s decision to lead the KB article with Secure Boot certificate expiration changes the reading. The company is not saying KB5092765 alone solves the Secure Boot problem. It is using the page as another signpost in a broader campaign: if your boot trust store still depends on Microsoft’s 2011 Secure Boot certificates, the clock is running.
The update is available through Windows Update, the Microsoft Update Catalog, and WSUS. Microsoft says there are no prerequisites, no restart is required after applying it, and it replaces the earlier KB5081494. Those are the quiet details administrators expect from a setup package. The loud part is the date: June 2026.
For more than a decade, Windows devices have carried Microsoft Secure Boot certificates issued in 2011. Those certificates are now reaching the end of their planned life. Microsoft’s current guidance says the Microsoft Corporation KEK CA 2011 expires on June 24, 2026, the Microsoft UEFI CA 2011 expires on June 27, 2026, and the Microsoft Windows Production PCA 2011 expires on October 19, 2026.
That sequence matters because Secure Boot is not one certificate doing one job. The KEK signs updates to the Secure Boot databases. The Windows Production PCA is used for the Windows boot loader. The Microsoft UEFI CA has historically covered third-party bootloaders and EFI applications, a role that touches Linux dual-boot scenarios, recovery tools, expansion hardware, and vendor utilities.
Microsoft’s replacement set is built around 2023 certificates. Notably, the old UEFI CA role is being split so that third-party bootloaders and option ROMs can be trusted separately. That is a sensible security refinement, but it also means the migration is not just a date rollover. It is a reshaping of what the firmware trusts.
That is a subtle distinction, and it is exactly where many users will get confused. This is not a Y2K-style midnight failure scenario for every Windows laptop. It is a security-maintenance cliff. A machine that misses the certificate refresh can keep working while becoming increasingly unable to participate in future boot-level trust updates.
For home users, that may sound abstract until BitLocker enters the conversation. For administrators, it is immediately concrete. Microsoft’s guidance flags potential Secure Boot validation errors, BitLocker recovery prompts, startup hangs, and devices failing to boot in higher-risk environments, particularly where firmware is old or certificate updates do not apply cleanly.
The right mental model is not “my PC dies in June.” It is “my PC’s root of trust may stop evolving.” That is worse than a one-time patch failure because boot security is a long game. Revocations, mitigations, boot manager updates, and future trust decisions depend on the system being able to accept new Secure Boot database changes.
This is where the story becomes familiar to anyone who has managed Windows at scale. The operating system layer is comparatively visible. Firmware is fragmented, inconsistently updated, and often treated as a once-per-device nuisance rather than a managed software surface. The Secure Boot certificate migration drags that neglected layer back into the center of enterprise risk.
Microsoft’s own playbook tells IT teams to inventory hardware and firmware versions, test representative models, deploy OEM firmware updates where needed, and monitor event logs and registry state. That is not a casual recommendation. It is an acknowledgement that the certificate update can succeed on one model and fail on another, even inside the same nominal Windows fleet.
This is also why KB5092765 matters despite not being the Secure Boot certificate update itself. Windows setup is one of the places where old assumptions become dangerous. If organizations are refreshing devices, building images, or moving between Windows 11 releases, they need the setup stack and the boot trust transition to be aligned.
For administrators, that means the Secure Boot issue should not be treated as a one-version problem. A fleet moving from 24H2 to 25H2 does not escape the certificate calendar. A machine freshly upgraded to 25H2 can still be sitting on old firmware trust if the Secure Boot update path has not completed.
The practical implication is that OS version compliance and boot trust compliance are separate questions. A dashboard that says “Windows 11 25H2 installed” is not enough. The useful question is whether the device has accepted the 2023 Secure Boot certificates and whether Windows can move to boot components signed under the newer chain.
That separation will be uncomfortable for some shops because it exposes a blind spot in many compliance programs. Windows patch level is easy to measure. Firmware readiness and Secure Boot database state require more deliberate inventory. Microsoft is providing signals such as event IDs and status values, but organizations still have to collect and act on them.
The problem is the edge of the consumer market. Older Windows 11-capable PCs, machines upgraded across multiple Windows generations, devices with stale OEM utilities, and systems where users have paused or disabled updates are more likely to become interesting. “Interesting,” in boot security, is rarely a compliment.
There is also the Windows 10 hangover. Microsoft has said unsupported Windows versions will not receive the new Secure Boot certificates through normal servicing. Windows 10 systems enrolled in paid Extended Security Updates are a special case, but the broader message is unmistakable: the certificate transition is another pressure point pushing users away from unsupported Windows.
That does not mean every old PC instantly becomes useless. It means unsupported systems are increasingly cut off from the maintenance channels that keep the boot chain defensible. For security-minded users, that is a stronger argument than rounded corners, Copilot buttons, or Start menu redesigns ever were.
Microsoft’s guidance points administrators toward Intune, registry-based targeting, Group Policy, Windows Configuration Service Provider methods, and monitoring through event logs. The company also describes a staged process in which the Windows UEFI CA 2023, option ROM and third-party UEFI certificates, the 2023 KEK, and eventually a boot manager signed by the newer chain are applied in sequence.
That sequencing is important. It means administrators should not think of this as flipping a single switch. The process has intermediate states, restart behavior, and monitoring requirements. A device can be targeted, pending, partially updated, remediated, or failed in ways that matter operationally.
The sane enterprise playbook is boring, which is why it is likely to work. Inventory the estate. Group machines by manufacturer, model, BIOS version, and Secure Boot state. Pilot the update on representative hardware. Confirm BitLocker behavior. Push firmware before certificate migration where vendors recommend it. Then expand in waves, with help desk scripts ready for recovery prompts and boot anomalies.
Dual-boot users should pay attention. Linux distributions that rely on shim and Microsoft-signed boot components have been preparing for this ecosystem change, but users with older installation media or unusual boot chains should not assume everything will work forever without updates. The same caution applies to backup tools, rescue disks, deployment media, and hardware diagnostics.
Gaming adds another wrinkle. Kernel anti-cheat systems increasingly lean on Secure Boot and platform integrity signals. The certificate refresh is not aimed at games, but anything that depends on a trusted early boot state can be affected by how cleanly a device migrates.
This is the hidden cost of treating Secure Boot as a checkbox in firmware setup. Once enabled, it becomes part of the system’s identity. It affects operating systems, recovery workflows, encryption, driver assumptions, and some application ecosystems. Changing the trust anchors after fifteen years is necessary, but it was never going to be invisible.
That is the right move. The people who read Setup Dynamic Update articles are exactly the people who build images, run WSUS, test feature updates, and manage enterprise deployment rings. They are also the people most likely to understand that a boot-chain migration needs time.
Still, Microsoft’s challenge is tone. If the company shouts “Secure Boot certificates expire,” users may hear “my computer will not start.” If it softens the message too much, administrators may treat it as another background servicing note. The accurate version is harder to sell: most devices will probably be fine, but the devices that are not fine need to be found before June and October deadlines turn into operational incidents.
That is why this KB is more important than its payload. It is another breadcrumb in a communications campaign that Microsoft should have no interest in keeping subtle. The expiration dates are fixed. The fleet readiness is not.
For personal PCs, the prescription is simpler but still real. Install Windows updates. Check for OEM firmware updates. Avoid relying on old rescue media. If Secure Boot is off, understand why before turning it on or leaving it off. If the machine is unsupported, do not pretend the risk is theoretical just because the desktop still loads.
For enterprises, the migration belongs in the same bucket as BIOS updates, TPM readiness, BitLocker recovery validation, and Windows feature update planning. It is not glamorous work. But it is the kind of work that separates a managed Windows environment from a collection of hopeful endpoints.
Microsoft Hides the Big Story in a Setup Update
KB5092765 is not a flashy cumulative update, a feature drop, or a Patch Tuesday security bulletin. It is a Setup Dynamic Update, the kind of package Windows uses to refresh setup binaries and related files during feature updates. In practical terms, it helps Windows 11 24H2 and 25H2 installation and upgrade workflows use newer setup components.That sounds mundane because it is. Setup Dynamic Updates are the plumbing of Windows servicing, not the furniture. They matter most when administrators are building installation media, managing in-place upgrades, or relying on Windows Update, WSUS, or the Microsoft Update Catalog to keep deployment machinery current.
But Microsoft’s decision to lead the KB article with Secure Boot certificate expiration changes the reading. The company is not saying KB5092765 alone solves the Secure Boot problem. It is using the page as another signpost in a broader campaign: if your boot trust store still depends on Microsoft’s 2011 Secure Boot certificates, the clock is running.
The update is available through Windows Update, the Microsoft Update Catalog, and WSUS. Microsoft says there are no prerequisites, no restart is required after applying it, and it replaces the earlier KB5081494. Those are the quiet details administrators expect from a setup package. The loud part is the date: June 2026.
The 2011 Trust Chain Is Finally Aging Out
Secure Boot’s promise has always been simple: before Windows loads, the system checks that the boot components are trusted. That trust is anchored in certificates stored by the firmware, including keys and signature databases that decide which bootloaders, option ROMs, and early boot components are allowed to run.For more than a decade, Windows devices have carried Microsoft Secure Boot certificates issued in 2011. Those certificates are now reaching the end of their planned life. Microsoft’s current guidance says the Microsoft Corporation KEK CA 2011 expires on June 24, 2026, the Microsoft UEFI CA 2011 expires on June 27, 2026, and the Microsoft Windows Production PCA 2011 expires on October 19, 2026.
That sequence matters because Secure Boot is not one certificate doing one job. The KEK signs updates to the Secure Boot databases. The Windows Production PCA is used for the Windows boot loader. The Microsoft UEFI CA has historically covered third-party bootloaders and EFI applications, a role that touches Linux dual-boot scenarios, recovery tools, expansion hardware, and vendor utilities.
Microsoft’s replacement set is built around 2023 certificates. Notably, the old UEFI CA role is being split so that third-party bootloaders and option ROMs can be trusted separately. That is a sensible security refinement, but it also means the migration is not just a date rollover. It is a reshaping of what the firmware trusts.
The Expiration Does Not Mean Every PC Bricks Overnight
The most important corrective is also the least dramatic: an unupdated PC is not expected to stop booting the moment a certificate expires. Microsoft’s own language is more careful. Devices may continue to start and may continue receiving ordinary Windows updates, but they can lose the ability to receive future Secure Boot protections for early boot components.That is a subtle distinction, and it is exactly where many users will get confused. This is not a Y2K-style midnight failure scenario for every Windows laptop. It is a security-maintenance cliff. A machine that misses the certificate refresh can keep working while becoming increasingly unable to participate in future boot-level trust updates.
For home users, that may sound abstract until BitLocker enters the conversation. For administrators, it is immediately concrete. Microsoft’s guidance flags potential Secure Boot validation errors, BitLocker recovery prompts, startup hangs, and devices failing to boot in higher-risk environments, particularly where firmware is old or certificate updates do not apply cleanly.
The right mental model is not “my PC dies in June.” It is “my PC’s root of trust may stop evolving.” That is worse than a one-time patch failure because boot security is a long game. Revocations, mitigations, boot manager updates, and future trust decisions depend on the system being able to accept new Secure Boot database changes.
Firmware Is the Weak Link Microsoft Cannot Patch Alone
Windows Update can deliver a lot, but Secure Boot lives at the boundary between Windows and firmware. That makes this transition messier than a normal operating system update. Microsoft can publish new certificates, provide deployment controls, and update boot components, but it cannot guarantee every aging UEFI implementation will behave well.This is where the story becomes familiar to anyone who has managed Windows at scale. The operating system layer is comparatively visible. Firmware is fragmented, inconsistently updated, and often treated as a once-per-device nuisance rather than a managed software surface. The Secure Boot certificate migration drags that neglected layer back into the center of enterprise risk.
Microsoft’s own playbook tells IT teams to inventory hardware and firmware versions, test representative models, deploy OEM firmware updates where needed, and monitor event logs and registry state. That is not a casual recommendation. It is an acknowledgement that the certificate update can succeed on one model and fail on another, even inside the same nominal Windows fleet.
This is also why KB5092765 matters despite not being the Secure Boot certificate update itself. Windows setup is one of the places where old assumptions become dangerous. If organizations are refreshing devices, building images, or moving between Windows 11 releases, they need the setup stack and the boot trust transition to be aligned.
Windows 11 24H2 and 25H2 Share More Than a Servicing Branch
KB5092765 applies to both Windows 11 24H2 and 25H2. That pairing is not incidental. Microsoft has leaned into a servicing model where adjacent Windows 11 releases can share a common platform foundation, with feature enablement and servicing layered on top.For administrators, that means the Secure Boot issue should not be treated as a one-version problem. A fleet moving from 24H2 to 25H2 does not escape the certificate calendar. A machine freshly upgraded to 25H2 can still be sitting on old firmware trust if the Secure Boot update path has not completed.
The practical implication is that OS version compliance and boot trust compliance are separate questions. A dashboard that says “Windows 11 25H2 installed” is not enough. The useful question is whether the device has accepted the 2023 Secure Boot certificates and whether Windows can move to boot components signed under the newer chain.
That separation will be uncomfortable for some shops because it exposes a blind spot in many compliance programs. Windows patch level is easy to measure. Firmware readiness and Secure Boot database state require more deliberate inventory. Microsoft is providing signals such as event IDs and status values, but organizations still have to collect and act on them.
The Home User Version Is Simpler, but Not Effortless
For most consumer Windows devices, Microsoft’s message is essentially: keep Windows Update enabled, install firmware updates from the manufacturer, and do not ignore security prompts. Many supported PCs should receive the new certificates automatically. Newer devices, especially those already shipping with updated firmware and modern Windows 11 builds, are likely to have the least drama.The problem is the edge of the consumer market. Older Windows 11-capable PCs, machines upgraded across multiple Windows generations, devices with stale OEM utilities, and systems where users have paused or disabled updates are more likely to become interesting. “Interesting,” in boot security, is rarely a compliment.
There is also the Windows 10 hangover. Microsoft has said unsupported Windows versions will not receive the new Secure Boot certificates through normal servicing. Windows 10 systems enrolled in paid Extended Security Updates are a special case, but the broader message is unmistakable: the certificate transition is another pressure point pushing users away from unsupported Windows.
That does not mean every old PC instantly becomes useless. It means unsupported systems are increasingly cut off from the maintenance channels that keep the boot chain defensible. For security-minded users, that is a stronger argument than rounded corners, Copilot buttons, or Start menu redesigns ever were.
Enterprise IT Should Treat This Like a Firmware Migration, Not a Patch
The worst way to handle this transition is to wait for Windows Update to make the problem disappear. That may work for a large number of devices, but the failures are likely to cluster in exactly the places where failures hurt: older models, specialized endpoints, BitLocker-protected laptops, virtualized environments, kiosks, labs, and machines with unusual boot dependencies.Microsoft’s guidance points administrators toward Intune, registry-based targeting, Group Policy, Windows Configuration Service Provider methods, and monitoring through event logs. The company also describes a staged process in which the Windows UEFI CA 2023, option ROM and third-party UEFI certificates, the 2023 KEK, and eventually a boot manager signed by the newer chain are applied in sequence.
That sequencing is important. It means administrators should not think of this as flipping a single switch. The process has intermediate states, restart behavior, and monitoring requirements. A device can be targeted, pending, partially updated, remediated, or failed in ways that matter operationally.
The sane enterprise playbook is boring, which is why it is likely to work. Inventory the estate. Group machines by manufacturer, model, BIOS version, and Secure Boot state. Pilot the update on representative hardware. Confirm BitLocker behavior. Push firmware before certificate migration where vendors recommend it. Then expand in waves, with help desk scripts ready for recovery prompts and boot anomalies.
Linux, Recovery Media, and Anti-Cheat Sit in the Blast Radius
Secure Boot is a Windows story, but it is not only a Windows story. The Microsoft UEFI CA has long been part of the way many non-Windows bootloaders, recovery environments, and third-party pre-OS tools coexist with Secure Boot enabled. Splitting trust between third-party bootloaders and option ROMs is a cleaner design, but transitions expose assumptions.Dual-boot users should pay attention. Linux distributions that rely on shim and Microsoft-signed boot components have been preparing for this ecosystem change, but users with older installation media or unusual boot chains should not assume everything will work forever without updates. The same caution applies to backup tools, rescue disks, deployment media, and hardware diagnostics.
Gaming adds another wrinkle. Kernel anti-cheat systems increasingly lean on Secure Boot and platform integrity signals. The certificate refresh is not aimed at games, but anything that depends on a trusted early boot state can be affected by how cleanly a device migrates.
This is the hidden cost of treating Secure Boot as a checkbox in firmware setup. Once enabled, it becomes part of the system’s identity. It affects operating systems, recovery workflows, encryption, driver assumptions, and some application ecosystems. Changing the trust anchors after fifteen years is necessary, but it was never going to be invisible.
Microsoft’s Messaging Is Finally Catching Up to the Risk
Microsoft has been publishing guidance on this transition for months, including documentation for home users, IT professionals, servers, virtual environments, and OEM coordination. The KB5092765 notice shows the company has moved from publishing guidance in specialist corners to placing the warning in ordinary servicing pages.That is the right move. The people who read Setup Dynamic Update articles are exactly the people who build images, run WSUS, test feature updates, and manage enterprise deployment rings. They are also the people most likely to understand that a boot-chain migration needs time.
Still, Microsoft’s challenge is tone. If the company shouts “Secure Boot certificates expire,” users may hear “my computer will not start.” If it softens the message too much, administrators may treat it as another background servicing note. The accurate version is harder to sell: most devices will probably be fine, but the devices that are not fine need to be found before June and October deadlines turn into operational incidents.
That is why this KB is more important than its payload. It is another breadcrumb in a communications campaign that Microsoft should have no interest in keeping subtle. The expiration dates are fixed. The fleet readiness is not.
The Real Deadline Is Before the Deadline
The June 2026 expiration date is a trap if administrators treat it as the project start date. The useful deadline is earlier: before the last maintenance window, before the summer change freeze, before the next device refresh wave, before the help desk is asked to distinguish a BitLocker recovery loop from a dead SSD at scale.For personal PCs, the prescription is simpler but still real. Install Windows updates. Check for OEM firmware updates. Avoid relying on old rescue media. If Secure Boot is off, understand why before turning it on or leaving it off. If the machine is unsupported, do not pretend the risk is theoretical just because the desktop still loads.
For enterprises, the migration belongs in the same bucket as BIOS updates, TPM readiness, BitLocker recovery validation, and Windows feature update planning. It is not glamorous work. But it is the kind of work that separates a managed Windows environment from a collection of hopeful endpoints.
The Windows Boot Chain Has a Short Checklist Now
KB5092765 is a reminder that the Windows servicing calendar and the Secure Boot certificate calendar have converged. The details are technical, but the operating principle is not: devices need to be able to trust the next generation of boot components before the old generation ages out.- KB5092765 updates Windows setup components for Windows 11 versions 24H2 and 25H2, and it is available through Windows Update, the Microsoft Update Catalog, and WSUS.
- Microsoft’s 2011 Secure Boot certificates begin expiring on June 24, 2026, with another key Windows boot certificate expiring on October 19, 2026.
- Most supported Windows devices should receive the new 2023 certificates through Microsoft-managed update paths, but some systems may need OEM firmware updates first.
- An unupdated device may still boot, but it can lose access to future Secure Boot protections for early boot components and revocation updates.
- Administrators should inventory Secure Boot status, firmware versions, BitLocker behavior, event logs, and certificate update state before broad deployment.
- Unsupported Windows installations are increasingly outside the trust refresh path, making the certificate transition another practical reason to move to a supported platform.
References
- Primary source: Microsoft Support
Published: Tue, 26 May 2026 21:02:22 Z
Loading…
support.microsoft.com - Official source: learn.microsoft.com
Update Secure Boot Certificates for Windows Devices - Windows Client
Update your Windows devices to maintain Secure Boot protection with 2023 certificates before they expire in June 2026.learn.microsoft.com - Official source: microsoft.com
Prepare your servers for Secure Boot certificate updates | Microsoft Windows Server Blog
The original Secure Boot certificates introduced in 2011 are approaching the end of their planned lifecycle, with expirations beginning in late June 2026.
www.microsoft.com
- Related coverage: windowscentral.com
Microsoft warns Secure Boot certificates will expire soon — what to expect
After 15 years, the original Secure Boot certificates that keep your PC secure during boot are expiring. Here's what you need to know.
www.windowscentral.com
- Related coverage: notebookcheck.net
Microsoft sets 2026 deadline for Secure Boot certificate expiration
Microsoft has issued new guidance warning that 2011 Secure Boot certificates begin expiring in June 2026. Windows updates are rolling out 2023 replacement certificates, with some PCs requiring OEM firmware updates.
www.notebookcheck.net
- Official source: blogs.windows.com
Refreshing the root of trust: industry collaboration on Secure Boot certificate updates
Secure Boot is a foundational security feature of the Windows and Windows Server experience, providing protection from the moment a device powers on. Introduced in 2011, Secure Boot runs at startup – before Windows loads – and h
blogs.windows.com
- Related coverage: tomshardware.com
Microsoft is refreshing Secure Boot certificates to plug security holes before they happen — if you bought a PC last year, you should be set
Be sure to keep Windows 11 systems updated to get refreshed security certificates.www.tomshardware.com
- Related coverage: techradar.com
- Related coverage: pcgamer.com
- Related coverage: cisco.com
- Official source: techcommunity.microsoft.com
- Official source: cdn-dynmedia-1.microsoft.com
Loading…
cdn-dynmedia-1.microsoft.com - Related coverage: tomsguide.com