Microsoft released KB5096160 on May 26, 2026, as a Setup Dynamic Update for Windows 11 version 26H1 that refreshes setup-related files for feature updates and repeats Microsoft’s warning that aging Secure Boot certificates begin expiring in June 2026. That pairing is the story: a routine-looking setup patch now sits beside one of the more consequential trust-maintenance deadlines in the Windows ecosystem. The update itself is not dramatic, but the warning attached to it is. Microsoft is telling users and administrators that the boot chain’s 2011-era foundation has reached retirement age, and the replacement cannot be treated as just another checkbox in Windows Update.
KB5096160 is, on paper, a narrowly scoped update. Microsoft describes it as improving Windows setup binaries and files used by setup during feature updates to Windows 11 version 26H1. It arrives through Windows Update automatically, can be obtained from the Microsoft Update Catalog, and syncs through WSUS when administrators enable the Windows 11 product and Update classification.
There are no prerequisites and no restart requirement. It also replaces KB5083990, the previous Setup Dynamic Update for Windows 11 version 26H1 released in March. In other words, the patch belongs to the plumbing layer: the part of Windows servicing that most users never see unless something goes wrong.
But Microsoft’s prominent Secure Boot notice changes the tone. The company is using these support pages to keep repeating the same message: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026, and some devices may lose the ability to boot securely if they are not updated in time.
That does not mean every unpatched machine suddenly becomes a brick the day the calendar flips. Microsoft’s own guidance is more nuanced: many affected devices may still boot and continue receiving ordinary Windows updates. The risk is that they may no longer receive future Secure Boot protections for early boot components, revocation lists, or related trust updates. That is a quieter failure mode, but for security teams it is the kind that matters.
Those certificates were never meant to last forever. Microsoft has now been preparing the ecosystem to move from 2011 certificate authorities to newer 2023-era authorities, including certificates used to sign Windows boot components, third-party UEFI applications, option ROMs, and Secure Boot database updates. This is the maintenance bill for a security architecture that spans Windows, OEM firmware, enterprise imaging, Linux dual-boot scenarios, hardware drivers, anticheat systems, recovery media, and server platforms.
The important distinction is that Secure Boot is not just an operating system feature. It is a handshake among firmware, Microsoft’s signing infrastructure, OEM implementation choices, and the software that runs before Windows fully loads. That is why Microsoft cannot solve the whole transition with a single cumulative update.
For many consumer Windows 11 systems, the process should be automatic. Supported devices receiving current Windows updates are expected to get the new certificates through normal servicing channels where firmware and platform readiness allow it. For some devices, though, an OEM firmware update may be required before the certificate update can be applied safely.
That is where the risk moves from theoretical to operational. A Windows Update that lands cleanly on one laptop fleet may be blocked or postponed on another because firmware behavior differs. A desktop that has never had its UEFI updated may not be in the same position as a newer Surface, Lenovo, Dell, HP, or ASUS system that has already received vendor-side preparation.
Microsoft’s staged approach reflects that reality. The company is not merely replacing certificates. It is trying to update trust anchors, preserve compatibility, coordinate with OEM firmware, support future revocations, and avoid breaking machines that enforce Secure Boot differently.
That is also why the language around this issue has been careful. Microsoft warns of degraded security, possible Secure Boot validation failures, BitLocker recovery prompts, startup hangs, and boot failures in higher-risk scenarios. Those outcomes are not the same thing as saying every unpatched PC fails in June, but they are serious enough that administrators should not wait for a visible crisis.
The timing makes the issue sharper. Windows 10 is now in its post-mainstream consumer era, with extended support arrangements and organizational exceptions carrying some environments forward. Windows 11 24H2, 25H2, and now 26H1-era servicing are the center of Microsoft’s active client strategy. The Secure Boot transition lands exactly as enterprises are already juggling hardware refreshes, Windows 11 migrations, AI PC procurement cycles, and baseline security changes.
That is the hidden cost of long-lived platform trust. The certificates worked so quietly for so long that many organizations never built an inventory habit around them. Now the expiration date turns a background assumption into an asset-management problem.
That matters for 26H1 because Microsoft’s Windows servicing story increasingly depends on a smooth setup pipeline. Feature updates, enablement-style transitions, platform-specific releases, and OEM-tuned images all require setup to be boring. Boring setup is good setup.
But the Secure Boot notice sitting inside this KB also shows how Microsoft’s support pages have become a bulletin board for platform-wide risk. The actual payload of KB5096160 is setup improvement. The message is broader: do not treat 2026 Windows servicing as separable from firmware trust.
For IT pros, that means the question is not simply whether KB5096160 is installed. The better question is whether the devices that will run 26H1 are also ready for the Secure Boot certificate transition. A successful feature update on a device with stale Secure Boot trust is not the same thing as a fully remediated device.
That is reassuring, but it is not a promise for every machine in every condition. Devices with Secure Boot disabled, unsupported hardware, outdated firmware, heavily customized boot configurations, or neglected vendor updates may not follow the happy path. Dual-boot systems and machines that rely on older third-party bootloaders deserve particular care, because Secure Boot changes can expose assumptions that have gone untouched for years.
The consumer risk is also psychological. Users have learned that “certificate expiration” usually means a website error, not a boot-chain maintenance event. Microsoft’s phrasing that devices may still boot can make the issue sound optional. But if future boot-level protections stop arriving, the machine is gradually falling behind in a place where ordinary antivirus tools have limited visibility.
That is the uncomfortable message: the absence of immediate breakage is not proof of safety. A PC can appear normal while its Secure Boot trust state becomes stale. The user experience may not change until a later boot component, revocation, firmware update, or recovery event exposes the gap.
Administrators need to identify which devices still depend on 2011-era certificates and whether they have received the 2023 replacements. Microsoft’s guidance points to signals such as event logs and registry status, including indicators that show whether UEFI CA 2023 remediation has succeeded. Those signals should be pulled into inventory systems rather than checked manually on a handful of machines.
The harder part is sequencing. Firmware updates, Secure Boot database changes, BitLocker protectors, virtualization-based security, recovery partitions, and operating system servicing can all intersect during reboot. Updating everything at once may be tempting, but it is exactly the kind of efficiency that creates ugly edge cases.
The safest enterprise pattern is familiar: pilot representative hardware, validate recovery keys, separate firmware and Secure Boot certificate changes where guidance recommends it, watch event logs, and expand deployment rings gradually. That may sound conservative, but boot failures are one of the few endpoint problems that can turn remote management into a spectator sport.
Server guidance emphasizes the same core issue: some systems may continue running if certificates are not updated, but they may lose the ability to apply future Secure Boot protections or maintain the expected trust posture. That distinction matters for compliance and incident response. A server that still boots is not necessarily a server that satisfies the organization’s security baseline.
Infrastructure operators also have more dependencies. OEM firmware packages, cluster-aware updating, maintenance windows, node draining, hardware compatibility matrices, and recovery procedures all matter. Secure Boot on a server is less about one machine’s startup and more about preserving a trusted platform across a fleet that is supposed to survive failure.
This is where Microsoft’s repeated warnings are justified. The company is not trying to manufacture urgency around a cosmetic certificate refresh. It is trying to prevent thousands of organizations from discovering in July, August, or October that their boot trust plan was “we assumed Windows Update handled it.”
If a platform trusts old boot managers forever, attackers can abuse that trust. If Microsoft revokes too aggressively before devices are ready, legitimate machines can fail to boot. The result is a staged mitigation model that feels slow to security purists and nerve-wracking to administrators.
The 2023 certificate rollout is part of that broader reset. New trust anchors allow future boot components and revocations to move forward without depending indefinitely on 2011-era authorities. That is essential if Secure Boot is to remain more than a static logo requirement in firmware setup screens.
The irony is that Secure Boot’s success made this transition harder. Because it became a default expectation across Windows hardware, its certificate lifecycle now affects a sprawling installed base. A niche security feature can be fixed with niche tooling. A platform trust anchor used by hundreds of millions of devices requires diplomacy.
But installing the Setup Dynamic Update should not be confused with completing Secure Boot certificate readiness. The KB page’s warning points administrators toward additional guidance because the certificate transition is broader than the setup patch. A device can have current setup files and still require Secure Boot remediation.
That distinction is especially important in WSUS-heavy environments. WSUS can distribute Microsoft updates, but it does not magically solve OEM firmware drift. Nor does it guarantee that every endpoint’s UEFI state matches the assumptions needed for the certificate change. The management plane can say “patched” while the firmware reality says “not ready.”
This is why Microsoft’s modern guidance leans toward inventory and status monitoring. The real compliance target is not whether a particular KB is present. It is whether the device has updated Secure Boot certificates and remains able to receive future Secure Boot database and revocation updates.
That matters because certificate updates depend on support status and servicing eligibility. In-support Windows versions are the cleanest path. Unsupported systems are more likely to become exceptions, and exceptions are where security debt accumulates.
For consumers still running Windows 10 without a supported update path, the message is blunt: this is another reason to move. Not because the desktop will necessarily stop loading in June, but because the platform’s ability to stay aligned with future boot security work is narrowing. Windows 10 nostalgia does not refresh UEFI trust anchors.
For enterprises paying for extended coverage, the job is more procedural than emotional. They need to confirm which Windows 10 devices receive the relevant updates, which require firmware intervention, and which should be accelerated into replacement or isolation. A spreadsheet that says “Windows 10 ESU” is not the same as proof that Secure Boot certificates are current.
Surface devices provide the cleanest Microsoft-controlled example, because firmware and Windows servicing sit under the same corporate roof. The broader PC market is more varied. Business-class models from major OEMs often have documented firmware channels and enterprise deployment tools. Consumer machines, white-box systems, and older hardware can be more uneven.
That variance is why some users will see nothing more than a normal update flow, while others may need to visit OEM support pages or apply firmware packages. It is also why administrators should not assume that two devices running the same Windows build have the same Secure Boot readiness. The operating system version is only one piece of the boot trust puzzle.
The industry has had years to prepare, and Microsoft has been publishing guidance well before the first expirations. Still, the final month before a certificate deadline is when neglected systems surface. That is not a Microsoft-only problem. It is the predictable result of a hardware ecosystem where firmware maintenance is still less standardized than OS patching.
That is how security baselines decay. A fleet looks current because monthly updates install. Endpoint dashboards stay mostly green. Users keep working. But the pre-OS trust chain stops receiving the same class of protection as remediated devices.
Attackers tend to like those seams. Bootkits and pre-OS tampering are difficult areas precisely because they sit below the normal operating system defenses. Secure Boot is not perfect, but weakening its update path gives defenders one less lever at a layer where levers are already scarce.
For WindowsForum readers, the practical takeaway is that this is not just a Patch Tuesday footnote. It is a rare moment when the PC’s firmware-era trust model becomes visible to ordinary Windows servicing. The correct response is neither panic nor shrugging. It is verification.
A Small Setup Patch Carries a Much Bigger Warning
KB5096160 is, on paper, a narrowly scoped update. Microsoft describes it as improving Windows setup binaries and files used by setup during feature updates to Windows 11 version 26H1. It arrives through Windows Update automatically, can be obtained from the Microsoft Update Catalog, and syncs through WSUS when administrators enable the Windows 11 product and Update classification.There are no prerequisites and no restart requirement. It also replaces KB5083990, the previous Setup Dynamic Update for Windows 11 version 26H1 released in March. In other words, the patch belongs to the plumbing layer: the part of Windows servicing that most users never see unless something goes wrong.
But Microsoft’s prominent Secure Boot notice changes the tone. The company is using these support pages to keep repeating the same message: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026, and some devices may lose the ability to boot securely if they are not updated in time.
That does not mean every unpatched machine suddenly becomes a brick the day the calendar flips. Microsoft’s own guidance is more nuanced: many affected devices may still boot and continue receiving ordinary Windows updates. The risk is that they may no longer receive future Secure Boot protections for early boot components, revocation lists, or related trust updates. That is a quieter failure mode, but for security teams it is the kind that matters.
Secure Boot’s 2011 Trust Anchor Is Finally Aging Out
Secure Boot was designed to stop untrusted code from running before the operating system takes control. It depends on firmware databases, allowed signatures, revoked signatures, and certificates that establish which bootloaders and pre-OS components are trusted. For more than a decade, much of that trust has rested on Microsoft certificates issued in 2011.Those certificates were never meant to last forever. Microsoft has now been preparing the ecosystem to move from 2011 certificate authorities to newer 2023-era authorities, including certificates used to sign Windows boot components, third-party UEFI applications, option ROMs, and Secure Boot database updates. This is the maintenance bill for a security architecture that spans Windows, OEM firmware, enterprise imaging, Linux dual-boot scenarios, hardware drivers, anticheat systems, recovery media, and server platforms.
The important distinction is that Secure Boot is not just an operating system feature. It is a handshake among firmware, Microsoft’s signing infrastructure, OEM implementation choices, and the software that runs before Windows fully loads. That is why Microsoft cannot solve the whole transition with a single cumulative update.
For many consumer Windows 11 systems, the process should be automatic. Supported devices receiving current Windows updates are expected to get the new certificates through normal servicing channels where firmware and platform readiness allow it. For some devices, though, an OEM firmware update may be required before the certificate update can be applied safely.
That is where the risk moves from theoretical to operational. A Windows Update that lands cleanly on one laptop fleet may be blocked or postponed on another because firmware behavior differs. A desktop that has never had its UEFI updated may not be in the same position as a newer Surface, Lenovo, Dell, HP, or ASUS system that has already received vendor-side preparation.
Microsoft Is Trying to Avoid a Boot-Time Y2K Moment
The obvious comparison is Y2K, but the better comparison is a slow-moving certificate rollover in a system where the recovery path is painful. If a web certificate expires, a browser throws an error and the site operator fixes it. If a boot trust certificate expires or cannot be refreshed correctly, the failure can arrive before the administrator has remote access, before endpoint tools have loaded, and before the help desk script becomes useful.Microsoft’s staged approach reflects that reality. The company is not merely replacing certificates. It is trying to update trust anchors, preserve compatibility, coordinate with OEM firmware, support future revocations, and avoid breaking machines that enforce Secure Boot differently.
That is also why the language around this issue has been careful. Microsoft warns of degraded security, possible Secure Boot validation failures, BitLocker recovery prompts, startup hangs, and boot failures in higher-risk scenarios. Those outcomes are not the same thing as saying every unpatched PC fails in June, but they are serious enough that administrators should not wait for a visible crisis.
The timing makes the issue sharper. Windows 10 is now in its post-mainstream consumer era, with extended support arrangements and organizational exceptions carrying some environments forward. Windows 11 24H2, 25H2, and now 26H1-era servicing are the center of Microsoft’s active client strategy. The Secure Boot transition lands exactly as enterprises are already juggling hardware refreshes, Windows 11 migrations, AI PC procurement cycles, and baseline security changes.
That is the hidden cost of long-lived platform trust. The certificates worked so quietly for so long that many organizations never built an inventory habit around them. Now the expiration date turns a background assumption into an asset-management problem.
The 26H1 Label Signals a Servicing Machine Already in Motion
KB5096160’s Windows 11 version 26H1 label is notable because Setup Dynamic Updates are about the installation and feature-update experience, not flashy desktop features. They refresh setup components so a feature update has the latest compatibility fixes, setup logic, and supporting files when it runs. In managed environments, these updates help reduce the chances that an upgrade fails because setup used stale components.That matters for 26H1 because Microsoft’s Windows servicing story increasingly depends on a smooth setup pipeline. Feature updates, enablement-style transitions, platform-specific releases, and OEM-tuned images all require setup to be boring. Boring setup is good setup.
But the Secure Boot notice sitting inside this KB also shows how Microsoft’s support pages have become a bulletin board for platform-wide risk. The actual payload of KB5096160 is setup improvement. The message is broader: do not treat 2026 Windows servicing as separable from firmware trust.
For IT pros, that means the question is not simply whether KB5096160 is installed. The better question is whether the devices that will run 26H1 are also ready for the Secure Boot certificate transition. A successful feature update on a device with stale Secure Boot trust is not the same thing as a fully remediated device.
The Consumer Story Is Mostly Automatic, Until It Isn’t
For home users, Microsoft’s advice is essentially to stay current. Keep Windows Update enabled, install firmware updates from the device manufacturer when offered, and do not ignore warnings from Windows Security or OEM utilities. Most supported Windows 11 PCs should receive the relevant Secure Boot certificate updates automatically.That is reassuring, but it is not a promise for every machine in every condition. Devices with Secure Boot disabled, unsupported hardware, outdated firmware, heavily customized boot configurations, or neglected vendor updates may not follow the happy path. Dual-boot systems and machines that rely on older third-party bootloaders deserve particular care, because Secure Boot changes can expose assumptions that have gone untouched for years.
The consumer risk is also psychological. Users have learned that “certificate expiration” usually means a website error, not a boot-chain maintenance event. Microsoft’s phrasing that devices may still boot can make the issue sound optional. But if future boot-level protections stop arriving, the machine is gradually falling behind in a place where ordinary antivirus tools have limited visibility.
That is the uncomfortable message: the absence of immediate breakage is not proof of safety. A PC can appear normal while its Secure Boot trust state becomes stale. The user experience may not change until a later boot component, revocation, firmware update, or recovery event exposes the gap.
Enterprise IT Has to Treat This as Firmware Change Management
In businesses, schools, and government environments, this is not a “tell users to click update” problem. Secure Boot certificate remediation touches the same operational nerves as BIOS updates, BitLocker recovery planning, endpoint compliance, and staged deployment rings. The right process looks less like a Patch Tuesday sprint and more like controlled firmware change management.Administrators need to identify which devices still depend on 2011-era certificates and whether they have received the 2023 replacements. Microsoft’s guidance points to signals such as event logs and registry status, including indicators that show whether UEFI CA 2023 remediation has succeeded. Those signals should be pulled into inventory systems rather than checked manually on a handful of machines.
The harder part is sequencing. Firmware updates, Secure Boot database changes, BitLocker protectors, virtualization-based security, recovery partitions, and operating system servicing can all intersect during reboot. Updating everything at once may be tempting, but it is exactly the kind of efficiency that creates ugly edge cases.
The safest enterprise pattern is familiar: pilot representative hardware, validate recovery keys, separate firmware and Secure Boot certificate changes where guidance recommends it, watch event logs, and expand deployment rings gradually. That may sound conservative, but boot failures are one of the few endpoint problems that can turn remote management into a spectator sport.
Servers and Clusters Raise the Stakes
Client PCs are only part of the story. Windows Server, Azure Local, Azure Stack Hub, and other infrastructure platforms have their own Secure Boot certificate guidance because the blast radius is different. A laptop that drops into BitLocker recovery is disruptive. A host cluster with boot-trust problems can become an outage.Server guidance emphasizes the same core issue: some systems may continue running if certificates are not updated, but they may lose the ability to apply future Secure Boot protections or maintain the expected trust posture. That distinction matters for compliance and incident response. A server that still boots is not necessarily a server that satisfies the organization’s security baseline.
Infrastructure operators also have more dependencies. OEM firmware packages, cluster-aware updating, maintenance windows, node draining, hardware compatibility matrices, and recovery procedures all matter. Secure Boot on a server is less about one machine’s startup and more about preserving a trusted platform across a fleet that is supposed to survive failure.
This is where Microsoft’s repeated warnings are justified. The company is not trying to manufacture urgency around a cosmetic certificate refresh. It is trying to prevent thousands of organizations from discovering in July, August, or October that their boot trust plan was “we assumed Windows Update handled it.”
The BlackLotus Lesson Still Hangs Over the Conversation
The Secure Boot certificate transition also cannot be separated from the last few years of bootkit anxiety. Vulnerabilities such as CVE-2023-24932, associated with BlackLotus-style Secure Boot bypass concerns, forced Microsoft and the industry to confront a painful truth: revoking old boot components is necessary for security, but revocation is dangerous if done carelessly.If a platform trusts old boot managers forever, attackers can abuse that trust. If Microsoft revokes too aggressively before devices are ready, legitimate machines can fail to boot. The result is a staged mitigation model that feels slow to security purists and nerve-wracking to administrators.
The 2023 certificate rollout is part of that broader reset. New trust anchors allow future boot components and revocations to move forward without depending indefinitely on 2011-era authorities. That is essential if Secure Boot is to remain more than a static logo requirement in firmware setup screens.
The irony is that Secure Boot’s success made this transition harder. Because it became a default expectation across Windows hardware, its certificate lifecycle now affects a sprawling installed base. A niche security feature can be fixed with niche tooling. A platform trust anchor used by hundreds of millions of devices requires diplomacy.
WSUS and the Catalog Are Necessary but Not Sufficient
KB5096160 is available through Windows Update, Microsoft Update Catalog, and WSUS synchronization under the Windows 11 product with Update classification. For administrators, that makes deployment straightforward in the narrow sense. The update can be approved, imported, or allowed to flow through existing servicing rings.But installing the Setup Dynamic Update should not be confused with completing Secure Boot certificate readiness. The KB page’s warning points administrators toward additional guidance because the certificate transition is broader than the setup patch. A device can have current setup files and still require Secure Boot remediation.
That distinction is especially important in WSUS-heavy environments. WSUS can distribute Microsoft updates, but it does not magically solve OEM firmware drift. Nor does it guarantee that every endpoint’s UEFI state matches the assumptions needed for the certificate change. The management plane can say “patched” while the firmware reality says “not ready.”
This is why Microsoft’s modern guidance leans toward inventory and status monitoring. The real compliance target is not whether a particular KB is present. It is whether the device has updated Secure Boot certificates and remains able to receive future Secure Boot database and revocation updates.
The Windows 10 Shadow Makes the Deadline Messier
The Secure Boot deadline arrives while Windows 10 remains present in many organizations and homes. Even after end-of-support milestones, large fleets do not disappear overnight. Some move to extended security arrangements, some become isolated legacy systems, and some simply remain unmanaged because reality is messier than lifecycle charts.That matters because certificate updates depend on support status and servicing eligibility. In-support Windows versions are the cleanest path. Unsupported systems are more likely to become exceptions, and exceptions are where security debt accumulates.
For consumers still running Windows 10 without a supported update path, the message is blunt: this is another reason to move. Not because the desktop will necessarily stop loading in June, but because the platform’s ability to stay aligned with future boot security work is narrowing. Windows 10 nostalgia does not refresh UEFI trust anchors.
For enterprises paying for extended coverage, the job is more procedural than emotional. They need to confirm which Windows 10 devices receive the relevant updates, which require firmware intervention, and which should be accelerated into replacement or isolation. A spreadsheet that says “Windows 10 ESU” is not the same as proof that Secure Boot certificates are current.
OEMs Own More of This Than Users Realize
One reason this story feels complicated is that Microsoft is both central and not fully in control. Microsoft signs important boot components and publishes guidance, but OEMs ship firmware, expose Secure Boot behavior, issue BIOS updates, and decide how quickly older models receive platform fixes. A Windows device is a partnership, whether the buyer thinks of it that way or not.Surface devices provide the cleanest Microsoft-controlled example, because firmware and Windows servicing sit under the same corporate roof. The broader PC market is more varied. Business-class models from major OEMs often have documented firmware channels and enterprise deployment tools. Consumer machines, white-box systems, and older hardware can be more uneven.
That variance is why some users will see nothing more than a normal update flow, while others may need to visit OEM support pages or apply firmware packages. It is also why administrators should not assume that two devices running the same Windows build have the same Secure Boot readiness. The operating system version is only one piece of the boot trust puzzle.
The industry has had years to prepare, and Microsoft has been publishing guidance well before the first expirations. Still, the final month before a certificate deadline is when neglected systems surface. That is not a Microsoft-only problem. It is the predictable result of a hardware ecosystem where firmware maintenance is still less standardized than OS patching.
The Real Risk Is a Slow Drift Into a Weaker Boot Chain
The scariest version of this story is not millions of PCs failing to boot on the same morning. That would be visible, measurable, and impossible to ignore. The subtler risk is worse in a different way: devices continue operating while silently missing future boot-level protections.That is how security baselines decay. A fleet looks current because monthly updates install. Endpoint dashboards stay mostly green. Users keep working. But the pre-OS trust chain stops receiving the same class of protection as remediated devices.
Attackers tend to like those seams. Bootkits and pre-OS tampering are difficult areas precisely because they sit below the normal operating system defenses. Secure Boot is not perfect, but weakening its update path gives defenders one less lever at a layer where levers are already scarce.
For WindowsForum readers, the practical takeaway is that this is not just a Patch Tuesday footnote. It is a rare moment when the PC’s firmware-era trust model becomes visible to ordinary Windows servicing. The correct response is neither panic nor shrugging. It is verification.
The Deadline Turns Trust Into an Inventory Problem
The Secure Boot certificate rollover is manageable, but only if treated as a fleet state to measure rather than a warning banner to dismiss. KB5096160 is a useful reminder because it lands inside the Windows 11 26H1 servicing stream while pointing to a deadline that affects much more than setup.- KB5096160 is a Setup Dynamic Update for Windows 11 version 26H1 that improves setup files and replaces KB5083990.
- Microsoft says Secure Boot certificates used by most Windows devices begin expiring in June 2026, with additional certificate lifecycle pressure later in 2026.
- Many supported Windows devices should receive updated certificates automatically, but some systems may require OEM firmware updates before remediation succeeds.
- Devices that miss the transition may still boot and receive ordinary Windows updates, but they may lose future Secure Boot protections for early boot components and revocation updates.
- Administrators should inventory Secure Boot certificate status, test on representative hardware, validate BitLocker recovery readiness, and separate firmware changes from Secure Boot remediation where guidance recommends it.
- Windows Server, Azure Local, Azure Stack Hub, and other infrastructure platforms need their own staged plans because boot-trust failures can become service outages rather than single-device annoyances.
References
- Primary source: Microsoft Support
Published: Tue, 26 May 2026 21:02:58 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 - 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
- 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: asus.com
- Official source: techcommunity.microsoft.com
Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog
Get tips to prepare for the rollout of updated certificates across your organization.
techcommunity.microsoft.com
- 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: cisco.com
- Related coverage: techradar.com
Microsoft's Secure Boot replacements could be bad news for Windows 10 users
Secure Boot certificate upgrades is bad news for Windows 10www.techradar.com
- Related coverage: pcgamer.com
- Official source: microsoft.com
- Official source: download.microsoft.com
- Related coverage: tomsguide.com