Microsoft released Windows 11 cumulative updates KB5089549 and KB5087420 on May 12, 2026, moving versions 25H2 and 24H2 to builds 26200.8457 and 26100.8457, and version 23H2 to build 22631.7079, across its regular Patch Tuesday servicing channels. The headline is security, but the story is bigger than another monthly patch. This release shows Microsoft trying to use Windows Update as both a repair mechanism and a control plane for the platform’s next security and AI transitions. For administrators, that makes May’s update less optional than its familiar cumulative-update packaging might suggest.
The May 2026 Windows 11 release is a useful snapshot of that new reality. KB5089549 is aimed at Windows 11 versions 25H2 and 24H2, while KB5087420 covers Windows 11 version 23H2. Both include security fixes and quality improvements, and both arrive with Microsoft’s usual Patch Tuesday urgency. But the most interesting changes sit at the boundary between ordinary maintenance and platform migration.
Microsoft is preparing Windows devices for a Secure Boot certificate rollover, tightening SmartScreen’s ability to reason about unsigned executables, correcting boot-related BitLocker recovery behavior, and updating Copilot+ PC AI components. These are not cosmetic changes. They are the kind of under-the-floorboard work that determines whether Windows remains manageable at enterprise scale.
That is why treating this as “just another cumulative update” misses the point. Microsoft is not merely shipping fixes to Windows; it is using the monthly update train to move the installed base through a security architecture transition without asking most users to understand the transition at all.
That caution is warranted. Secure Boot is one of those technologies users only notice when it breaks, and when it breaks, the failure mode can be brutal: devices that refuse to boot, recovery-key prompts, firmware confusion, and help desks scrambling to separate a security transition from a hardware failure. Microsoft has already warned that Secure Boot certificates used by most Windows devices are set to expire starting in June 2026.
The May update therefore sits on a calendar with real consequences. The company needs to move a diverse ecosystem of PCs, firmware implementations, TPM configurations, enterprise images, and management policies toward updated certificate trust before expiration becomes an operational event. The only realistic way to do that is through staged automation, and that is exactly what this update advances.
The phrase “high confidence device targeting data” sounds bureaucratic, but it matters. Microsoft is trying to identify which devices are safe candidates for automatic certificate updates and which devices need more caution. That is a compromise between two bad outcomes: moving too quickly and stranding machines, or moving too slowly and leaving organizations exposed to a looming certificate deadline.
For sysadmins, this should trigger a different mental model. Secure Boot certificate servicing is not a one-off checkbox. It is a staged fleet-readiness process, and May’s update is one of the pieces that helps Microsoft decide which machines can safely move forward.
That is the sort of bug that produces disproportionate pain in managed environments. A personal laptop asking for a BitLocker recovery key is annoying. A fleet of laptops doing it after a maintenance window can become a service desk incident, especially if recovery-key escrow, inventory accuracy, or user communications are not in good shape.
The underlying issue also exposes a long-standing enterprise tension. Security teams often want explicit controls over measured boot and TPM validation; platform vendors increasingly want sane defaults that can survive firmware diversity. When those goals collide, Windows can end up enforcing a policy that looked precise on paper but brittle in the real world.
May’s update does not mean every BitLocker-related concern disappears. Microsoft still documents a known issue for Windows 11 version 23H2 in which some devices with an unrecommended BitLocker Group Policy configuration may be required to enter a recovery key on first restart. The affected pattern is specific, involving BitLocker on the OS drive, explicit PCR7 inclusion, a PCR7 Binding status of “Not Possible,” and eligibility for the 2023-signed Windows Boot Manager.
That detail matters because it narrows the risk. This is not a broad warning that every home user should fear the update. It is a signal to managed environments that old or over-specified BitLocker policy can turn a platform security migration into a recovery-key event.
That is a meaningful shift because unsigned malware remains a common delivery pattern. Code signing is not a magic shield, and stolen certificates have long complicated the trust model, but unsigned executables remain a useful risk signal. Improving reputation checks around them gives Windows another chance to interrupt commodity malware, grayware, and opportunistic payloads before execution.
There is, however, a familiar trade-off. Reputation systems depend on telemetry, cloud evaluation, and Microsoft’s ability to classify software behavior at scale. That tends to improve protection for mainstream users, but it can create friction for independent developers, internal tools, lab utilities, and small vendors whose executables do not have established reputation.
This is where Windows’ consumer and enterprise identities collide. A home user benefits when an obscure unsigned binary gets more scrutiny. A developer shop may see more warnings around legitimate internal builds. An enterprise security team may welcome the signal while still needing allow-listing, signing discipline, and user education to prevent confusion.
Microsoft’s direction is clear. Windows is becoming less willing to treat locally launched code as a purely local decision. That may be uncomfortable for some power users, but it is consistent with the threat environment Microsoft is trying to manage.
Still, their inclusion tells us something about Windows’ future. Microsoft is folding AI component maintenance into the same servicing rhythm as security and quality fixes. The AI layer is not being treated as a novelty add-on; it is being serviced like part of the operating system.
That has practical implications. Copilot+ PCs rely on local models and platform components that will need updates for accuracy, performance, security, and compatibility. If those components drift too far from the base OS, Microsoft risks creating a fragmented Windows experience where AI features behave differently across machines. Servicing them through cumulative updates helps avoid that.
It also raises the governance bar. Enterprises that once thought of Windows Update as mainly an OS patch channel now have to consider it a delivery mechanism for local AI capability. Even if the components are limited to eligible Copilot+ hardware, procurement and endpoint management teams need to know which machines receive them, how they are inventoried, and how policy controls map onto them.
This is the quiet normalization of AI in Windows. Not through a keynote demo, but through build numbers, servicing stack updates, and Patch Tuesday metadata.
The servicing stack is the component that installs Windows updates. When it works, nobody notices. When it fails, administrators discover just how much of their patching strategy depends on a quiet layer of installation logic, package ordering, rollback behavior, and component store reliability.
Microsoft’s practice of combining the latest servicing stack update with the latest cumulative update has reduced some historical deployment friction. It means admins generally do not have to chase a separate SSU before installing the LCU. But it also means the cumulative package is not just patching Windows; it is patching the machinery that patches Windows.
That matters for offline servicing and image maintenance. KB5089549’s standalone package guidance notes that one or more MSU files may need to be installed in a specific order when using the Microsoft Update Catalog route. In managed environments that build gold images, maintain offline media, or support disconnected networks, that is not a trivial footnote.
The modern Windows update model wants to be automatic, incremental, and policy-driven. The real world still includes WSUS, Configuration Manager, Intune rings, offline images, lab validation, and machines that only occasionally phone home. Servicing stack reliability is what keeps those worlds from splitting apart.
But the contrast with KB5089549 is instructive. The 24H2 and 25H2 update carries the AI component servicing table and the boot manager reliability fix tied to the April 2026 issue. The 23H2 update still matters, especially for organizations deliberately pacing feature updates, but Microsoft’s development center of gravity has plainly moved forward.
That is normal in Windows servicing, but it has operational consequences. Organizations that hold back on feature updates often do so for good reasons: application compatibility, hardware certification, regulatory validation, or change-management conservatism. The trade-off is that the newest platform fixes and capability updates increasingly arrive first, or only, in the newer branches.
The known BitLocker issue on 23H2 also shows how support is not the same as symmetry. Microsoft is still servicing the branch, but the remediation story differs from 24H2 and 25H2. Admins managing mixed fleets should not assume that the same Patch Tuesday risk profile applies across all Windows 11 versions.
This is where inventory discipline becomes more than clerical hygiene. Knowing whether a device is on 23H2, 24H2, or 25H2 now affects not only feature availability, but boot behavior, AI component applicability, known-issue exposure, and update-package handling.
Neither sounds glamorous. Both are exactly the kind of issues that make enterprise Windows feel flaky when they go unfixed. Remote Desktop remains a daily tool for administrators, support desks, contractors, and power users. A broken security warning dialog in a mixed-DPI multi-monitor setup is not merely visual ugliness; it risks confusing the trust prompt that appears before opening an RDP connection.
SSDP, meanwhile, sits in the category of components users rarely name but networks quietly depend on. Discovery problems can look like device flakiness, printer weirdness, media-device absence, or inconsistent network behavior. Reliability work there may not produce screenshots, but it reduces the background noise administrators spend too much time chasing.
These fixes also underline a pattern in Windows servicing. Patch Tuesday does not only close vulnerabilities; it absorbs the previous month’s optional preview fixes and rolls them into the security baseline. That makes the monthly security update the moment when “optional” quality changes become broadly deployed reality.
For cautious shops, that is both blessing and burden. Preview updates can provide early warning, but many organizations avoid them outside test rings. By Patch Tuesday, the fixes arrive with security urgency attached, compressing the time available to validate quality changes against business-critical workflows.
For enterprises, the decision is more layered. The update should be prioritized, but not blindly blasted across every device at once. The BitLocker and Secure Boot context makes ring-based deployment especially important this month, with attention to machines that have nonstandard TPM validation profiles, older firmware behavior, or unclear recovery-key escrow.
The 23H2 known issue deserves particular attention. If an organization has configured “Configure TPM platform validation profile for native UEFI firmware configurations” and explicitly included PCR7, and if msinfo32 reports PCR7 Binding as “Not Possible,” the first reboot after installation can require a BitLocker recovery key. Microsoft says the recovery key should only be required once in that scenario, but “once” across enough endpoints is still a help desk surge.
This is where security policy can become self-sabotaging. A custom BitLocker profile that was created years ago to strengthen assurance may now create fragility during a boot-chain transition. The right move is not to abandon BitLocker, but to audit whether legacy policy still matches Microsoft’s current platform defaults.
Administrators should also treat the Secure Boot certificate rollout as a project, not a patch note. If Secure Boot certificate expiration begins in June 2026, then May is not early; it is the runway. Devices that fail to receive certificate updates cleanly need to be identified before the deadline becomes the incident.
That sounds obvious until a Patch Tuesday like this arrives. The difference between a smooth rollout and a bad week may come down to whether IT can answer specific questions quickly: which devices are on 23H2, which are on 24H2 or 25H2, which have PCR7 Binding marked “Not Possible,” which are eligible for the 2023-signed Windows Boot Manager, and which Copilot+ PCs are receiving AI component updates.
May’s update also rewards organizations that distinguish vendor claims from operational effect. Microsoft says the 25H2 and 24H2 update has no known issues. That is useful, but it does not replace staged deployment. “No known issues” means no currently documented issues, not no possible interaction with your VPN agent, disk encryption policy, firmware build, remote-access workflow, or device-control stack.
The right posture is neither panic nor complacency. This is a security update that should move. It is also a boot-chain and servicing update that should be observed as it moves.
Source: cyberpress.org Microsoft Rolls Out Cumulative Update for Windows 11 25H2 and 24H2
Patch Tuesday Has Become Windows’ Operating System Governance Layer
There was a time when a cumulative update could be judged mostly by whether it fixed a few bugs without creating new ones. That era is gone. Windows Update now carries security policy, hardware trust transitions, AI component servicing, mobile operator profiles, daylight saving time changes, and the plumbing that determines whether the next patch can install cleanly.The May 2026 Windows 11 release is a useful snapshot of that new reality. KB5089549 is aimed at Windows 11 versions 25H2 and 24H2, while KB5087420 covers Windows 11 version 23H2. Both include security fixes and quality improvements, and both arrive with Microsoft’s usual Patch Tuesday urgency. But the most interesting changes sit at the boundary between ordinary maintenance and platform migration.
Microsoft is preparing Windows devices for a Secure Boot certificate rollover, tightening SmartScreen’s ability to reason about unsigned executables, correcting boot-related BitLocker recovery behavior, and updating Copilot+ PC AI components. These are not cosmetic changes. They are the kind of under-the-floorboard work that determines whether Windows remains manageable at enterprise scale.
That is why treating this as “just another cumulative update” misses the point. Microsoft is not merely shipping fixes to Windows; it is using the monthly update train to move the installed base through a security architecture transition without asking most users to understand the transition at all.
Secure Boot Is the Real Clock Ticking Behind This Release
The most consequential item in May’s update may be the least visible after reboot. Microsoft says Windows quality updates now include additional high-confidence device targeting data to expand automatic delivery of new Secure Boot certificates. Devices receive those certificates only after showing enough successful update signals, which is Microsoft’s way of saying the rollout is deliberately cautious.That caution is warranted. Secure Boot is one of those technologies users only notice when it breaks, and when it breaks, the failure mode can be brutal: devices that refuse to boot, recovery-key prompts, firmware confusion, and help desks scrambling to separate a security transition from a hardware failure. Microsoft has already warned that Secure Boot certificates used by most Windows devices are set to expire starting in June 2026.
The May update therefore sits on a calendar with real consequences. The company needs to move a diverse ecosystem of PCs, firmware implementations, TPM configurations, enterprise images, and management policies toward updated certificate trust before expiration becomes an operational event. The only realistic way to do that is through staged automation, and that is exactly what this update advances.
The phrase “high confidence device targeting data” sounds bureaucratic, but it matters. Microsoft is trying to identify which devices are safe candidates for automatic certificate updates and which devices need more caution. That is a compromise between two bad outcomes: moving too quickly and stranding machines, or moving too slowly and leaving organizations exposed to a looming certificate deadline.
For sysadmins, this should trigger a different mental model. Secure Boot certificate servicing is not a one-off checkbox. It is a staged fleet-readiness process, and May’s update is one of the pieces that helps Microsoft decide which machines can safely move forward.
BitLocker Recovery Was the Warning Shot
The BitLocker-related fix in KB5089549 is a reminder that boot security is never only about boot security. Microsoft says the update improves startup reliability after boot file updates and fixes an issue where some devices could enter BitLocker Recovery after updating boot files on systems with certain TPM validation settings, including invalid PCR7 configurations. The issue could occur after the April 2026 security update for 25H2 and 24H2.That is the sort of bug that produces disproportionate pain in managed environments. A personal laptop asking for a BitLocker recovery key is annoying. A fleet of laptops doing it after a maintenance window can become a service desk incident, especially if recovery-key escrow, inventory accuracy, or user communications are not in good shape.
The underlying issue also exposes a long-standing enterprise tension. Security teams often want explicit controls over measured boot and TPM validation; platform vendors increasingly want sane defaults that can survive firmware diversity. When those goals collide, Windows can end up enforcing a policy that looked precise on paper but brittle in the real world.
May’s update does not mean every BitLocker-related concern disappears. Microsoft still documents a known issue for Windows 11 version 23H2 in which some devices with an unrecommended BitLocker Group Policy configuration may be required to enter a recovery key on first restart. The affected pattern is specific, involving BitLocker on the OS drive, explicit PCR7 inclusion, a PCR7 Binding status of “Not Possible,” and eligibility for the 2023-signed Windows Boot Manager.
That detail matters because it narrows the risk. This is not a broad warning that every home user should fear the update. It is a signal to managed environments that old or over-specified BitLocker policy can turn a platform security migration into a recovery-key event.
SmartScreen Gets More Opinionated About Unsigned Code
KB5087420 also includes a notable Microsoft Defender SmartScreen change: the Windows shell can now send file hashes for unsigned files, allowing SmartScreen to use newer reputation models and improve application reputation checks. In plain English, Windows is getting better at asking Microsoft whether an unsigned executable looks suspicious before the user runs it.That is a meaningful shift because unsigned malware remains a common delivery pattern. Code signing is not a magic shield, and stolen certificates have long complicated the trust model, but unsigned executables remain a useful risk signal. Improving reputation checks around them gives Windows another chance to interrupt commodity malware, grayware, and opportunistic payloads before execution.
There is, however, a familiar trade-off. Reputation systems depend on telemetry, cloud evaluation, and Microsoft’s ability to classify software behavior at scale. That tends to improve protection for mainstream users, but it can create friction for independent developers, internal tools, lab utilities, and small vendors whose executables do not have established reputation.
This is where Windows’ consumer and enterprise identities collide. A home user benefits when an obscure unsigned binary gets more scrutiny. A developer shop may see more warnings around legitimate internal builds. An enterprise security team may welcome the signal while still needing allow-listing, signing discipline, and user education to prevent confusion.
Microsoft’s direction is clear. Windows is becoming less willing to treat locally launched code as a purely local decision. That may be uncomfortable for some power users, but it is consistent with the threat environment Microsoft is trying to manage.
The AI Payload Is Small, but the Servicing Signal Is Large
For Windows 11 versions 25H2 and 24H2, KB5089549 updates several AI components to version 1.2604.515.0: Image Search, Content Extraction, Semantic Analysis, and Settings Model. Microsoft notes that these AI component updates apply to Copilot+ PCs and do not install on ordinary Windows PCs or Windows Server. That distinction is important, because the presence of AI component names in a cumulative update does not mean every Windows 11 machine is suddenly gaining new AI features.Still, their inclusion tells us something about Windows’ future. Microsoft is folding AI component maintenance into the same servicing rhythm as security and quality fixes. The AI layer is not being treated as a novelty add-on; it is being serviced like part of the operating system.
That has practical implications. Copilot+ PCs rely on local models and platform components that will need updates for accuracy, performance, security, and compatibility. If those components drift too far from the base OS, Microsoft risks creating a fragmented Windows experience where AI features behave differently across machines. Servicing them through cumulative updates helps avoid that.
It also raises the governance bar. Enterprises that once thought of Windows Update as mainly an OS patch channel now have to consider it a delivery mechanism for local AI capability. Even if the components are limited to eligible Copilot+ hardware, procurement and endpoint management teams need to know which machines receive them, how they are inventoried, and how policy controls map onto them.
This is the quiet normalization of AI in Windows. Not through a keynote demo, but through build numbers, servicing stack updates, and Patch Tuesday metadata.
Servicing Stack Updates Are the Boring Part That Prevents the Exciting Outage
Both releases include servicing stack updates, and they deserve more respect than they usually get. KB5092762 accompanies the 25H2 and 24H2 update with servicing stack build 26100.8456. KB5086307 accompanies the 23H2 update with servicing stack build 22621.6937.The servicing stack is the component that installs Windows updates. When it works, nobody notices. When it fails, administrators discover just how much of their patching strategy depends on a quiet layer of installation logic, package ordering, rollback behavior, and component store reliability.
Microsoft’s practice of combining the latest servicing stack update with the latest cumulative update has reduced some historical deployment friction. It means admins generally do not have to chase a separate SSU before installing the LCU. But it also means the cumulative package is not just patching Windows; it is patching the machinery that patches Windows.
That matters for offline servicing and image maintenance. KB5089549’s standalone package guidance notes that one or more MSU files may need to be installed in a specific order when using the Microsoft Update Catalog route. In managed environments that build gold images, maintain offline media, or support disconnected networks, that is not a trivial footnote.
The modern Windows update model wants to be automatic, incremental, and policy-driven. The real world still includes WSUS, Configuration Manager, Intune rings, offline images, lab validation, and machines that only occasionally phone home. Servicing stack reliability is what keeps those worlds from splitting apart.
23H2 Is Still Supported, but It Is No Longer the Center of Gravity
KB5087420 for Windows 11 version 23H2 moves the OS to build 22631.7079 and includes security fixes, quality improvements from the prior April update, Secure Boot targeting changes, SmartScreen improvements, Enterprise State Roaming management through Windows Backup for Organizations policies, COSA profile updates, Egypt daylight saving time support, and the Remote Desktop rendering fix. That is a healthy package for an older Windows 11 branch.But the contrast with KB5089549 is instructive. The 24H2 and 25H2 update carries the AI component servicing table and the boot manager reliability fix tied to the April 2026 issue. The 23H2 update still matters, especially for organizations deliberately pacing feature updates, but Microsoft’s development center of gravity has plainly moved forward.
That is normal in Windows servicing, but it has operational consequences. Organizations that hold back on feature updates often do so for good reasons: application compatibility, hardware certification, regulatory validation, or change-management conservatism. The trade-off is that the newest platform fixes and capability updates increasingly arrive first, or only, in the newer branches.
The known BitLocker issue on 23H2 also shows how support is not the same as symmetry. Microsoft is still servicing the branch, but the remediation story differs from 24H2 and 25H2. Admins managing mixed fleets should not assume that the same Patch Tuesday risk profile applies across all Windows 11 versions.
This is where inventory discipline becomes more than clerical hygiene. Knowing whether a device is on 23H2, 24H2, or 25H2 now affects not only feature availability, but boot behavior, AI component applicability, known-issue exposure, and update-package handling.
Remote Desktop and SSDP Fixes Show the Patch’s Enterprise Bias
Two smaller fixes reveal who Microsoft expects to care most about this release. The Remote Desktop fix addresses a security warning dialog that could render incorrectly in multi-monitor setups with different DPI scaling after the April 2026 update. The SSDP change improves notification reliability to help prevent the service from becoming unresponsive.Neither sounds glamorous. Both are exactly the kind of issues that make enterprise Windows feel flaky when they go unfixed. Remote Desktop remains a daily tool for administrators, support desks, contractors, and power users. A broken security warning dialog in a mixed-DPI multi-monitor setup is not merely visual ugliness; it risks confusing the trust prompt that appears before opening an RDP connection.
SSDP, meanwhile, sits in the category of components users rarely name but networks quietly depend on. Discovery problems can look like device flakiness, printer weirdness, media-device absence, or inconsistent network behavior. Reliability work there may not produce screenshots, but it reduces the background noise administrators spend too much time chasing.
These fixes also underline a pattern in Windows servicing. Patch Tuesday does not only close vulnerabilities; it absorbs the previous month’s optional preview fixes and rolls them into the security baseline. That makes the monthly security update the moment when “optional” quality changes become broadly deployed reality.
For cautious shops, that is both blessing and burden. Preview updates can provide early warning, but many organizations avoid them outside test rings. By Patch Tuesday, the fixes arrive with security urgency attached, compressing the time available to validate quality changes against business-critical workflows.
The Deployment Decision Is Easy; the Rollout Decision Is Not
For unmanaged consumer PCs, the recommendation is straightforward: install the update through Windows Update. The security fixes matter, the Secure Boot transition matters, and the known risks are narrow enough that most home users should not try to outsmart the servicing channel.For enterprises, the decision is more layered. The update should be prioritized, but not blindly blasted across every device at once. The BitLocker and Secure Boot context makes ring-based deployment especially important this month, with attention to machines that have nonstandard TPM validation profiles, older firmware behavior, or unclear recovery-key escrow.
The 23H2 known issue deserves particular attention. If an organization has configured “Configure TPM platform validation profile for native UEFI firmware configurations” and explicitly included PCR7, and if msinfo32 reports PCR7 Binding as “Not Possible,” the first reboot after installation can require a BitLocker recovery key. Microsoft says the recovery key should only be required once in that scenario, but “once” across enough endpoints is still a help desk surge.
This is where security policy can become self-sabotaging. A custom BitLocker profile that was created years ago to strengthen assurance may now create fragility during a boot-chain transition. The right move is not to abandon BitLocker, but to audit whether legacy policy still matches Microsoft’s current platform defaults.
Administrators should also treat the Secure Boot certificate rollout as a project, not a patch note. If Secure Boot certificate expiration begins in June 2026, then May is not early; it is the runway. Devices that fail to receive certificate updates cleanly need to be identified before the deadline becomes the incident.
The May Patch Rewards Shops That Already Know Their Machines
The organizations best positioned for this release are not necessarily the ones with the most expensive tools. They are the ones with accurate endpoint inventory, reliable BitLocker recovery-key escrow, test rings that include real hardware diversity, and a habit of reading known issues before approving deployment.That sounds obvious until a Patch Tuesday like this arrives. The difference between a smooth rollout and a bad week may come down to whether IT can answer specific questions quickly: which devices are on 23H2, which are on 24H2 or 25H2, which have PCR7 Binding marked “Not Possible,” which are eligible for the 2023-signed Windows Boot Manager, and which Copilot+ PCs are receiving AI component updates.
May’s update also rewards organizations that distinguish vendor claims from operational effect. Microsoft says the 25H2 and 24H2 update has no known issues. That is useful, but it does not replace staged deployment. “No known issues” means no currently documented issues, not no possible interaction with your VPN agent, disk encryption policy, firmware build, remote-access workflow, or device-control stack.
The right posture is neither panic nor complacency. This is a security update that should move. It is also a boot-chain and servicing update that should be observed as it moves.
The Practical Reading for WindowsForum Readers
This release is not a spectacle patch. It is a plumbing patch with consequences. That makes it easy to underestimate and expensive to ignore.- Windows 11 25H2 and 24H2 systems receive KB5089549 and move to builds 26200.8457 and 26100.8457.
- Windows 11 23H2 systems receive KB5087420 and move to build 22631.7079.
- The Secure Boot certificate work is preparation for a June 2026 expiration timeline, not a decorative security note.
- The 25H2 and 24H2 update fixes a BitLocker Recovery problem tied to boot file updates after the April 2026 security update.
- The 23H2 update still has a documented BitLocker recovery-key risk on devices with specific unrecommended PCR7-related policy configurations.
- Copilot+ PCs on 25H2 and 24H2 receive updated AI components, while ordinary Windows PCs and Windows Server do not install those AI pieces.
Source: cyberpress.org Microsoft Rolls Out Cumulative Update for Windows 11 25H2 and 24H2
