Microsoft released KB5092765 on May 26, 2026 as a Setup Dynamic Update for Windows 11 versions 24H2 and 25H2, improving setup reliability while again warning that older Secure Boot certificates used by most Windows devices begin expiring in June 2026. The update itself is not the drama; the timing is. Microsoft is using the machinery of Windows setup to push administrators toward a deadline that lives below the operating system, in firmware, where mistakes are harder to see and more expensive to unwind. For once, the most important Windows update story is not about the desktop after boot, but the chain of trust before it.
KB5092765 is, on paper, one of those unglamorous Windows servicing components that usually passes beneath the news cycle. Setup Dynamic Updates are meant to improve the Windows installation and upgrade process, refreshing setup binaries and related files so feature updates have a better chance of landing cleanly. They are plumbing, not product theater.
But the support note attached to this one carries a warning that should matter to anyone responsible for Windows devices at scale. Secure Boot certificates issued in the Windows 8 era are reaching the end of their planned life, with the first major expirations beginning in late June 2026. That puts Microsoft in the uncomfortable position of having to coordinate a trust-anchor rollover across consumer PCs, business fleets, servers, virtual machines, OEM firmware, third-party boot loaders, and long-lived devices that may not have been touched in years.
The company’s message is carefully calibrated. Microsoft is not saying that unpatched PCs will all brick the moment a certificate expires. In fact, its guidance says affected devices may continue to start and may continue receiving ordinary Windows updates. The risk is subtler and, for administrators, more worrying: systems that do not receive the newer 2023 Secure Boot certificates may lose the ability to receive future protections for early boot components.
That distinction matters. A machine that still boots can look healthy to a user and still be drifting into a weaker security state. In enterprise terms, that is the kind of failure that hides inside compliance dashboards until the day a firmware update, BitLocker event, bootloader change, or revocation update exposes the gap.
The expiring certificates are not obscure edge-case artifacts. They include Microsoft’s 2011-era Key Enrollment Key and UEFI certificate authorities, the credentials that helped establish trust for Windows boot components and third-party UEFI applications across more than a decade of PC hardware. Microsoft’s replacement set uses 2023 certificates, including separate trust paths for Windows boot loaders, third-party boot loaders, and option ROMs.
That separation is one of the more important architectural changes in the rollover. The old world leaned heavily on broad trust relationships that made sense when Secure Boot was new and the ecosystem needed to coalesce around a common implementation. The new world gives vendors and administrators finer control over what they trust before the operating system starts.
This is where the story becomes bigger than a certificate date. Microsoft is not merely swapping one expiring credential for another. It is tightening the way trust is expressed in the boot path, and doing so at a moment when firmware security is no longer a theoretical concern reserved for high-end threat models.
If a device lacks the newer certificates, it may still boot because the firmware still has enough trust material to validate what is already there. But future updates to the Secure Boot database, revocation lists, boot manager trust, and mitigations for newly discovered boot-level vulnerabilities depend on the device being able to accept and validate the new chain. Once the old chain ages out, the device is not necessarily dead; it is less adaptable.
That is a different class of risk than the one most users associate with Windows Update. A failed monthly cumulative update is visible. A missing Secure Boot trust update may not be. It lives in firmware state, event logs, registry signals, and OEM-specific behavior.
For home users, the answer is mostly boring in the best way: keep Windows and firmware updates enabled, do not defer security servicing indefinitely, and check the Windows Security app if Microsoft exposes certificate status on the device. For IT departments, boring is not enough. They need inventory, rings, firmware baselines, BitLocker recovery planning, and a way to identify machines that will not accept the new certificates automatically.
That makes sense. Feature updates are moments when Windows setup evaluates hardware, boot configuration, recovery partitions, drivers, compatibility blocks, and servicing state. If Microsoft wants to remind users and administrators that the firmware trust base needs attention, setup is one of the few places where that message has operational context.
It also reinforces how Microsoft now sees Windows servicing as a shared model across adjacent releases. Windows 11 24H2 and 25H2 are closely related from a servicing standpoint, and KB5092765 landing for both versions underscores that the Secure Boot issue is not tied to one marketing release. It is a platform maintenance event.
The timing is blunt. May 26, 2026 leaves only weeks before the first June certificate expirations. If an organization is learning about this from a Setup Dynamic Update support page, it is already behind the ideal planning curve.
The trouble is that “most devices” is not the same as all devices. Older models, stale firmware, unsupported Windows versions, unusual boot configurations, dual-boot systems, and machines that have spent months powered off can all fall outside the cleanest path. So can devices whose OEMs need to provide firmware updates before Microsoft’s certificate changes can be safely applied.
This is where Microsoft’s language becomes deliberately cautious. It recommends reviewing guidance and acting in advance, but it does not frame the update as a universal emergency patch. That balance is hard. Understate the issue and administrators procrastinate; overstate it and consumers panic.
The better interpretation is that Microsoft is trying to avoid a boot-trust cliff by stretching the work across Windows Update, OEM firmware releases, support documentation, and enterprise deployment tooling. The company knows that firmware migrations move more slowly than OS patches, especially in fleets full of mixed vendors and replacement cycles.
Many Windows 10 PCs are perfectly serviceable for daily work but cannot move to Windows 11 because of hardware requirements. Some are enrolled in Extended Security Updates. Some are not. Some live in small businesses where the “IT department” is one overworked person and a spreadsheet. The Secure Boot certificate deadline gives those environments another reason to confront the cost of staying behind.
Microsoft can argue, with some justification, that boot trust cannot be maintained forever on abandoned software stacks. Security certificates expire precisely because indefinite trust is bad practice. But users hear something different: a PC that worked yesterday may be increasingly excluded from future security plumbing because the operating system servicing contract has ended.
That is not a new tension in Windows. It is the same tension that accompanied TPM requirements, virtualization-based security, driver signing enforcement, and older CPU cutoffs. Secure Boot certificates simply move the argument lower in the stack, where user choice is more constrained and vendor coordination matters more.
That difference is easy to understand and hard to operationalize. Server estates are more conservative by design. They include clustered workloads, hypervisors, domain controllers, backup appliances, storage systems, edge boxes, lab hosts, and physical machines with firmware that may not have been updated since installation. The blast radius of a bad boot event is larger.
Virtualization complicates the picture further. A virtual machine’s Secure Boot state depends not just on the guest OS but on the hypervisor platform, VM generation, template age, and cloud or on-premises configuration. A shiny Windows Server 2025 guest is not automatically immune if the platform trust settings around it are stale.
For administrators, the practical work is not simply “install updates.” It is sequencing. Firmware first where needed, then cumulative updates, then certificate deployment, then validation, then monitoring. In environments with BitLocker or measured boot dependencies, recovery-key readiness is not optional paperwork; it is the difference between maintenance and an outage.
Microsoft’s guidance points administrators toward event logs, registry indicators, Windows Security status, Intune remediations, Group Policy, registry-key methods, and other deployment paths. That is useful, but it also reveals the problem: there is no single universal dashboard for the entire Windows ecosystem. The trust state spans Windows, firmware, OEM support, and deployment management.
The danger zone is the in-between machine. It is not brand new enough to have shipped with the 2023 certificates. It is not centrally managed enough to be inventoried cleanly. It has Secure Boot enabled, BitLocker protecting the disk, perhaps an old BIOS release, and a user who will not report a problem until the system asks for a recovery key on a Monday morning.
That is why this rollover deserves more attention than its dry KB title suggests. A certificate transition at the firmware layer is exactly the sort of project that looks like routine hygiene until it intersects with asset management debt.
This is an old Windows truth that tends to reappear during hardware-adjacent transitions. Driver updates, firmware capsules, TPM behavior, Modern Standby, BIOS settings, and recovery quirks all depend on the manufacturer. Secure Boot certificate updates sit in the same family, except the failure modes are more intimidating because they can happen before Windows is fully awake.
The best OEMs have already published guidance or delivered firmware updates. Others will follow unevenly. Some older devices may simply never receive the sort of maintenance attention administrators would prefer.
That unevenness creates a practical hierarchy of confidence. Newer devices built in 2024 and 2025 are more likely to be ready. Managed Windows 11 fleets receiving regular updates are in a better position than dusty unmanaged PCs. Servers and specialized devices require deliberate planning. Dual-boot and third-party bootloader users should assume they need to pay attention.
The 2023 certificate split matters here because Microsoft is separating trust for third-party bootloaders from trust for option ROMs. That is more precise security engineering, but it also means unusual boot paths deserve testing. A Windows-only laptop may glide through the transition unnoticed, while a dual-boot workstation or specialized imaging environment exposes assumptions nobody documented.
Gaming adds another wrinkle. Kernel anti-cheat systems increasingly lean on Secure Boot, TPM, virtualization security, and boot integrity signals as part of their trust model. The certificate rollover is not fundamentally an anti-cheat story, but any ecosystem that treats Secure Boot state as a gatekeeper will care when that state changes or becomes stale.
This is the larger lesson: Secure Boot has become infrastructure. It is no longer a Windows 8-era checkbox buried in firmware setup. It is a signal consumed by operating systems, security tools, management platforms, cloud services, game publishers, and compliance frameworks.
That is both necessary and unsettling. Necessary, because modern threats do not respect the boundary between operating system and firmware. Unsettling, because Windows users have been trained to think of updates as something that happens inside Windows, with a reboot as the price of admission. Secure Boot certificate maintenance challenges that mental model.
Microsoft’s strategy is to make as much of this automatic as possible for ordinary PCs and as scripted as possible for managed environments. The alternative would be worse: a fragmented scramble in which every OEM and administrator invents their own certificate rollover plan. Still, automation is only as strong as the population it actually reaches.
The machines that need attention most are often the hardest to reach. They are offline, unmanaged, frozen for compatibility, running older firmware, or excluded from feature updates. They are conference-room PCs, lab benches, spare laptops, point-of-sale endpoints, classroom carts, remote-office servers, and industrial-adjacent systems that Windows administrators inherit but rarely love.
But when a certificate sits in firmware across hundreds of millions of devices, expiration becomes a global maintenance event. The calendar itself becomes a security control, and every organization that postponed firmware hygiene gets a deadline it did not choose.
The first visible date is June 24, 2026, when Microsoft’s 2011 Key Enrollment Key certificate reaches expiration. The Microsoft UEFI CA 2011 follows shortly after on June 27. The Windows Production PCA 2011 runs later, into October. Those dates do not all mean the same thing operationally, but together they mark the end of the original Secure Boot trust generation.
That chronology is important because it turns vague advice into a schedule. This is not “sometime soon.” It is now. KB5092765 landed on May 26, 2026, less than a month before the first of those dates, and it sits in the path of Windows 11 24H2 and 25H2 setup precisely because Microsoft wants the warning to be unavoidable.
That work should be tied to existing management systems rather than handled as a one-off helpdesk campaign. Intune, Configuration Manager, Group Policy, PowerShell, event log collection, and endpoint security tooling can all play a role depending on the environment. What matters is not the tool brand; it is whether the organization can prove the state of the fleet.
Pilot rings are especially important because Secure Boot touches hardware diversity. Testing one vendor model does not validate another. Testing a laptop without BitLocker does not validate a field device with BitLocker, recovery partitions, third-party drivers, and an old firmware branch.
For servers, the change belongs in maintenance windows with rollback thinking and recovery material close at hand. For clients, it belongs in phased deployment with monitoring for BitLocker recovery prompts, boot failures, and certificate status anomalies. For devices in storage, it means bringing them online before they become tomorrow’s unpleasant surprise.
The details administrators should carry away are narrower and more actionable than the surrounding noise:
Microsoft Turns a Setup Update Into a Firmware Deadline
KB5092765 is, on paper, one of those unglamorous Windows servicing components that usually passes beneath the news cycle. Setup Dynamic Updates are meant to improve the Windows installation and upgrade process, refreshing setup binaries and related files so feature updates have a better chance of landing cleanly. They are plumbing, not product theater.But the support note attached to this one carries a warning that should matter to anyone responsible for Windows devices at scale. Secure Boot certificates issued in the Windows 8 era are reaching the end of their planned life, with the first major expirations beginning in late June 2026. That puts Microsoft in the uncomfortable position of having to coordinate a trust-anchor rollover across consumer PCs, business fleets, servers, virtual machines, OEM firmware, third-party boot loaders, and long-lived devices that may not have been touched in years.
The company’s message is carefully calibrated. Microsoft is not saying that unpatched PCs will all brick the moment a certificate expires. In fact, its guidance says affected devices may continue to start and may continue receiving ordinary Windows updates. The risk is subtler and, for administrators, more worrying: systems that do not receive the newer 2023 Secure Boot certificates may lose the ability to receive future protections for early boot components.
That distinction matters. A machine that still boots can look healthy to a user and still be drifting into a weaker security state. In enterprise terms, that is the kind of failure that hides inside compliance dashboards until the day a firmware update, BitLocker event, bootloader change, or revocation update exposes the gap.
The Root of Trust Is Aging Out in Public
Secure Boot was introduced to make the pre-OS environment less hospitable to bootkits and other malware that loads before Windows can defend itself. The idea is simple enough: firmware checks signatures before allowing boot components to run, and those signatures chain back to certificates stored in firmware databases. In practice, the system is a complicated handoff among UEFI firmware, OEM keys, Microsoft keys, boot managers, option ROMs, and revocation lists.The expiring certificates are not obscure edge-case artifacts. They include Microsoft’s 2011-era Key Enrollment Key and UEFI certificate authorities, the credentials that helped establish trust for Windows boot components and third-party UEFI applications across more than a decade of PC hardware. Microsoft’s replacement set uses 2023 certificates, including separate trust paths for Windows boot loaders, third-party boot loaders, and option ROMs.
That separation is one of the more important architectural changes in the rollover. The old world leaned heavily on broad trust relationships that made sense when Secure Boot was new and the ecosystem needed to coalesce around a common implementation. The new world gives vendors and administrators finer control over what they trust before the operating system starts.
This is where the story becomes bigger than a certificate date. Microsoft is not merely swapping one expiring credential for another. It is tightening the way trust is expressed in the boot path, and doing so at a moment when firmware security is no longer a theoretical concern reserved for high-end threat models.
The Expiration Date Is Not a Kill Switch, but It Is a Boundary
The most misleading reading of the June 2026 deadline is that millions of Windows PCs will suddenly refuse to boot. Microsoft has been at pains to avoid that panic, and rightly so. The more accurate reading is that June 2026 begins a staged loss of future-proofing for machines that remain on the 2011 certificate set.If a device lacks the newer certificates, it may still boot because the firmware still has enough trust material to validate what is already there. But future updates to the Secure Boot database, revocation lists, boot manager trust, and mitigations for newly discovered boot-level vulnerabilities depend on the device being able to accept and validate the new chain. Once the old chain ages out, the device is not necessarily dead; it is less adaptable.
That is a different class of risk than the one most users associate with Windows Update. A failed monthly cumulative update is visible. A missing Secure Boot trust update may not be. It lives in firmware state, event logs, registry signals, and OEM-specific behavior.
For home users, the answer is mostly boring in the best way: keep Windows and firmware updates enabled, do not defer security servicing indefinitely, and check the Windows Security app if Microsoft exposes certificate status on the device. For IT departments, boring is not enough. They need inventory, rings, firmware baselines, BitLocker recovery planning, and a way to identify machines that will not accept the new certificates automatically.
Setup Dynamic Update Is the Messenger, Not the Mechanism
KB5092765’s relevance is partly symbolic. A Setup Dynamic Update is not the same thing as the Secure Boot certificate payload itself, and administrators should not treat this one package as the magic fix for every device in their estate. Its importance is that Microsoft is threading the Secure Boot warning through the Windows 11 upgrade path for 24H2 and 25H2.That makes sense. Feature updates are moments when Windows setup evaluates hardware, boot configuration, recovery partitions, drivers, compatibility blocks, and servicing state. If Microsoft wants to remind users and administrators that the firmware trust base needs attention, setup is one of the few places where that message has operational context.
It also reinforces how Microsoft now sees Windows servicing as a shared model across adjacent releases. Windows 11 24H2 and 25H2 are closely related from a servicing standpoint, and KB5092765 landing for both versions underscores that the Secure Boot issue is not tied to one marketing release. It is a platform maintenance event.
The timing is blunt. May 26, 2026 leaves only weeks before the first June certificate expirations. If an organization is learning about this from a Setup Dynamic Update support page, it is already behind the ideal planning curve.
The Consumer Story Is Automatic Until It Isn’t
Microsoft says a significant portion of Windows devices will receive the new certificates through normal update channels. That is the message most consumers need to hear, because the last thing the ecosystem needs is users manually poking firmware settings they do not understand. Secure Boot mistakes can cascade into boot failures, BitLocker recovery prompts, or unnecessary reinstalls.The trouble is that “most devices” is not the same as all devices. Older models, stale firmware, unsupported Windows versions, unusual boot configurations, dual-boot systems, and machines that have spent months powered off can all fall outside the cleanest path. So can devices whose OEMs need to provide firmware updates before Microsoft’s certificate changes can be safely applied.
This is where Microsoft’s language becomes deliberately cautious. It recommends reviewing guidance and acting in advance, but it does not frame the update as a universal emergency patch. That balance is hard. Understate the issue and administrators procrastinate; overstate it and consumers panic.
The better interpretation is that Microsoft is trying to avoid a boot-trust cliff by stretching the work across Windows Update, OEM firmware releases, support documentation, and enterprise deployment tooling. The company knows that firmware migrations move more slowly than OS patches, especially in fleets full of mixed vendors and replacement cycles.
Windows 10 Makes the Deadline Politically Awkward
The Secure Boot rollover also arrives in the long shadow of Windows 10’s end-of-support transition. Microsoft’s broad position is that supported Windows versions receive the relevant updates, while unsupported versions do not. That is straightforward as policy and messy as reality.Many Windows 10 PCs are perfectly serviceable for daily work but cannot move to Windows 11 because of hardware requirements. Some are enrolled in Extended Security Updates. Some are not. Some live in small businesses where the “IT department” is one overworked person and a spreadsheet. The Secure Boot certificate deadline gives those environments another reason to confront the cost of staying behind.
Microsoft can argue, with some justification, that boot trust cannot be maintained forever on abandoned software stacks. Security certificates expire precisely because indefinite trust is bad practice. But users hear something different: a PC that worked yesterday may be increasingly excluded from future security plumbing because the operating system servicing contract has ended.
That is not a new tension in Windows. It is the same tension that accompanied TPM requirements, virtualization-based security, driver signing enforcement, and older CPU cutoffs. Secure Boot certificates simply move the argument lower in the stack, where user choice is more constrained and vendor coordination matters more.
Servers Are Where “Automatic” Stops Being Reassuring
The server side of this story is less forgiving. Microsoft has said Windows Server systems do not receive the 2023 Secure Boot certificates through the same Controlled Feature Rollout path used for many Windows PCs. Administrators must take explicit action on in-scope servers with Secure Boot enabled, particularly systems that did not ship with the 2023 certificates and have not otherwise been updated.That difference is easy to understand and hard to operationalize. Server estates are more conservative by design. They include clustered workloads, hypervisors, domain controllers, backup appliances, storage systems, edge boxes, lab hosts, and physical machines with firmware that may not have been updated since installation. The blast radius of a bad boot event is larger.
Virtualization complicates the picture further. A virtual machine’s Secure Boot state depends not just on the guest OS but on the hypervisor platform, VM generation, template age, and cloud or on-premises configuration. A shiny Windows Server 2025 guest is not automatically immune if the platform trust settings around it are stale.
For administrators, the practical work is not simply “install updates.” It is sequencing. Firmware first where needed, then cumulative updates, then certificate deployment, then validation, then monitoring. In environments with BitLocker or measured boot dependencies, recovery-key readiness is not optional paperwork; it is the difference between maintenance and an outage.
The Risk Is Operational Before It Is Cryptographic
Security stories often get framed as attacker-versus-defender, but the immediate risk here is operational. The hard part is not understanding that old certificates expire. The hard part is discovering which devices still depend on them, which firmware versions can accept replacements, and which systems will respond badly during the transition.Microsoft’s guidance points administrators toward event logs, registry indicators, Windows Security status, Intune remediations, Group Policy, registry-key methods, and other deployment paths. That is useful, but it also reveals the problem: there is no single universal dashboard for the entire Windows ecosystem. The trust state spans Windows, firmware, OEM support, and deployment management.
The danger zone is the in-between machine. It is not brand new enough to have shipped with the 2023 certificates. It is not centrally managed enough to be inventoried cleanly. It has Secure Boot enabled, BitLocker protecting the disk, perhaps an old BIOS release, and a user who will not report a problem until the system asks for a recovery key on a Monday morning.
That is why this rollover deserves more attention than its dry KB title suggests. A certificate transition at the firmware layer is exactly the sort of project that looks like routine hygiene until it intersects with asset management debt.
OEMs Hold More Cards Than Users Like to Admit
Microsoft owns the Windows servicing pipeline, but it does not own every part of the Secure Boot chain. OEMs own firmware implementation details, update packaging, platform keys, and the messy compatibility work that determines whether a given model handles the new certificates cleanly. That means Microsoft can coordinate the transition, but it cannot single-handedly guarantee the experience on every device.This is an old Windows truth that tends to reappear during hardware-adjacent transitions. Driver updates, firmware capsules, TPM behavior, Modern Standby, BIOS settings, and recovery quirks all depend on the manufacturer. Secure Boot certificate updates sit in the same family, except the failure modes are more intimidating because they can happen before Windows is fully awake.
The best OEMs have already published guidance or delivered firmware updates. Others will follow unevenly. Some older devices may simply never receive the sort of maintenance attention administrators would prefer.
That unevenness creates a practical hierarchy of confidence. Newer devices built in 2024 and 2025 are more likely to be ready. Managed Windows 11 fleets receiving regular updates are in a better position than dusty unmanaged PCs. Servers and specialized devices require deliberate planning. Dual-boot and third-party bootloader users should assume they need to pay attention.
Linux, Anti-Cheat, and the Third-Party Bootloader Problem
Secure Boot on Windows PCs has never been only about Windows. The Microsoft UEFI CA has long played a role in allowing third-party bootloaders and EFI applications to run on Secure Boot-enabled hardware. That includes many Linux boot scenarios, recovery tools, and niche pre-OS utilities.The 2023 certificate split matters here because Microsoft is separating trust for third-party bootloaders from trust for option ROMs. That is more precise security engineering, but it also means unusual boot paths deserve testing. A Windows-only laptop may glide through the transition unnoticed, while a dual-boot workstation or specialized imaging environment exposes assumptions nobody documented.
Gaming adds another wrinkle. Kernel anti-cheat systems increasingly lean on Secure Boot, TPM, virtualization security, and boot integrity signals as part of their trust model. The certificate rollover is not fundamentally an anti-cheat story, but any ecosystem that treats Secure Boot state as a gatekeeper will care when that state changes or becomes stale.
This is the larger lesson: Secure Boot has become infrastructure. It is no longer a Windows 8-era checkbox buried in firmware setup. It is a signal consumed by operating systems, security tools, management platforms, cloud services, game publishers, and compliance frameworks.
Microsoft’s Real Bet Is That Servicing Can Reach Firmware
The Windows servicing model has spent years expanding outward. Monthly updates no longer patch only user-mode components and kernel files. They refresh recovery environments, revocation databases, microcode delivery paths, setup components, compatibility holds, and sometimes firmware-delivered packages. KB5092765 belongs to that broader shift.That is both necessary and unsettling. Necessary, because modern threats do not respect the boundary between operating system and firmware. Unsettling, because Windows users have been trained to think of updates as something that happens inside Windows, with a reboot as the price of admission. Secure Boot certificate maintenance challenges that mental model.
Microsoft’s strategy is to make as much of this automatic as possible for ordinary PCs and as scripted as possible for managed environments. The alternative would be worse: a fragmented scramble in which every OEM and administrator invents their own certificate rollover plan. Still, automation is only as strong as the population it actually reaches.
The machines that need attention most are often the hardest to reach. They are offline, unmanaged, frozen for compatibility, running older firmware, or excluded from feature updates. They are conference-room PCs, lab benches, spare laptops, point-of-sale endpoints, classroom carts, remote-office servers, and industrial-adjacent systems that Windows administrators inherit but rarely love.
The Calendar Is Now a Security Control
There is something almost mundane about certificate expiration. Cryptographic credentials have lifetimes. They expire. They are replaced. This is how healthy trust systems are supposed to work.But when a certificate sits in firmware across hundreds of millions of devices, expiration becomes a global maintenance event. The calendar itself becomes a security control, and every organization that postponed firmware hygiene gets a deadline it did not choose.
The first visible date is June 24, 2026, when Microsoft’s 2011 Key Enrollment Key certificate reaches expiration. The Microsoft UEFI CA 2011 follows shortly after on June 27. The Windows Production PCA 2011 runs later, into October. Those dates do not all mean the same thing operationally, but together they mark the end of the original Secure Boot trust generation.
That chronology is important because it turns vague advice into a schedule. This is not “sometime soon.” It is now. KB5092765 landed on May 26, 2026, less than a month before the first of those dates, and it sits in the path of Windows 11 24H2 and 25H2 setup precisely because Microsoft wants the warning to be unavoidable.
The Work Administrators Should Have Already Started
The most useful response is not panic, and it is not passive confidence. It is inventory. Administrators need to know which devices have the 2023 certificates, which still show 2011-era trust, which have Secure Boot disabled, which require OEM firmware, and which cannot be remediated cleanly.That work should be tied to existing management systems rather than handled as a one-off helpdesk campaign. Intune, Configuration Manager, Group Policy, PowerShell, event log collection, and endpoint security tooling can all play a role depending on the environment. What matters is not the tool brand; it is whether the organization can prove the state of the fleet.
Pilot rings are especially important because Secure Boot touches hardware diversity. Testing one vendor model does not validate another. Testing a laptop without BitLocker does not validate a field device with BitLocker, recovery partitions, third-party drivers, and an old firmware branch.
For servers, the change belongs in maintenance windows with rollback thinking and recovery material close at hand. For clients, it belongs in phased deployment with monitoring for BitLocker recovery prompts, boot failures, and certificate status anomalies. For devices in storage, it means bringing them online before they become tomorrow’s unpleasant surprise.
The May 26 Update Is a Warning Shot With a KB Number
The concrete lesson of KB5092765 is that Microsoft is running out of quiet runway. The company has published broad guidance, updated support pages, hosted technical sessions, and worked with OEMs, but the Secure Boot certificate transition is now colliding with the calendar. A setup update is not the whole story; it is the latest signpost.The details administrators should carry away are narrower and more actionable than the surrounding noise:
- KB5092765 was released on May 26, 2026 for Windows 11 versions 24H2 and 25H2 as a Setup Dynamic Update, not as a standalone cure-all for every Secure Boot certificate issue.
- The original Microsoft Secure Boot certificates from 2011 begin expiring in late June 2026, with additional related expiration dates later in the year.
- Devices that miss the 2023 certificate update may still boot and receive ordinary Windows updates, but they can lose future Secure Boot protections for early boot components.
- Most consumer Windows devices should be handled through normal Windows and firmware updates, but older systems, unsupported Windows versions, and unusual boot configurations need closer attention.
- Windows Server environments require deliberate administrator action rather than relying on the same automatic rollout behavior expected on many Windows PCs.
- The safest enterprise approach is to inventory certificate state, update firmware where needed, pilot across real hardware diversity, and validate before the June and October deadlines become incident tickets.
References
- Primary source: Microsoft Support
Published: Tue, 26 May 2026 21:02:22 Z
- 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: pcworld.com
Windows 11's Secure Boot fix update finally rolls out to more PCs
Important security certificates for Windows 11 will soon expire for many users. In some cases, you will need to take action to prevent this from happening. Here's what you need to do and why.
www.pcworld.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
- Related coverage: asus.com
- Related coverage: windowsnews.ai
KB5092765 Setup Update Warns: Secure Boot Certs Expire June 2026
KB5092765, a Setup Dynamic Update for Windows 11 24H2/25H2, refines installation and warns that Secure Boot certificates expire in June 2026. Check your...windowsnews.ai
- 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
- Official source: cdn-dynmedia-1.microsoft.com
- Official source: techcommunity.microsoft.com
- Related coverage: tomsguide.com
- Related coverage: cisco.com
