Microsoft released KB5089570 on May 26, 2026, as a non-security preview cumulative update for Windows 11 version 26H1, raising supported systems to OS Build 28000.2179 and bundling new PC experiences, enterprise controls, servicing-stack changes, and Copilot+ PC AI component updates. The headline is not one feature; it is Microsoft’s continued attempt to turn Windows into a faster-moving platform without admitting that monthly patching now carries product strategy inside it. This preview is optional, but it is also a rehearsal for the next security update, which makes it relevant far beyond enthusiasts who like to click “Check for updates.” For administrators, the update is a reminder that the Windows servicing train now delivers usability changes, AI plumbing, driver policy enforcement, and deployment constraints in the same carriage.
That is the new Windows cadence in miniature. The monthly non-security preview is no longer merely a bug-fix checkpoint; it is a feature staging lane. Microsoft can say, accurately, that the update is optional and gradual, while still using it to seed features that will soon become part of the baseline experience for a broad Windows 11 population.
The gradual rollout language matters. Microsoft says features may arrive in phases, with availability varying by device, and that a normal rollout follows when features reach broader availability. That sounds benign, but it creates a tricky support reality: two machines can both report the same build number while exposing different user-facing capabilities.
For home users, that means one PC may show Shared Audio or Xbox mode while another does not. For IT, it means build number alone is no longer enough to describe state. The real diagnostic question becomes not just “What build are you on?” but “Which controlled feature rollout state has this device received?”
Those additions are not trivial. Shared Audio moves Windows closer to the kind of casual device-sharing experience people expect from phones and tablets. Xbox mode is another step in Microsoft’s long-running effort to make Windows behave less like a desktop OS when it is being used as a gaming appliance.
But the more interesting story is that these features arrive alongside plumbing that has nothing to do with entertainment. File Explorer gains support for more archive formats, including uu, cpio, xar, and NuGet packages. The system improves startup app launch performance, Store download reliability, taskbar tray loading, Windows Hello behavior, Delivery Optimization memory usage, color-profile persistence, and explorer.exe reliability.
That mix is revealing. Microsoft is no longer separating “fun” Windows from “managed” Windows. The same update that helps a traveler share movie audio also changes how Windows trusts third-party drivers. The same build that adds a full-screen gaming shell also gives administrators more control over preinstalled Microsoft Store apps.
The Windows 11 user experience is being renovated from both ends: visible surface area for consumers, and deeper governance for enterprises. KB5089570 is what happens when those priorities are shipped through one servicing mechanism.
Expanded archive support is the obvious example. Adding uu, cpio, xar, and NuGet package support will not excite every user, but it matters to developers, administrators, and anyone handling cross-platform package formats. NuGet package visibility in File Explorer is especially telling because it pulls a developer ecosystem artifact into the default Windows shell.
The practical payoff is less about replacing specialized tools and more about reducing friction. If File Explorer can inspect or interact with more package types, fewer users need to install random utilities of uncertain provenance. That has security benefits, even if Microsoft does not frame it that way.
The smaller fixes may be more noticeable day to day. Preserving View and Sort preferences in folders such as Downloads and Documents when apps open Explorer directly addresses the kind of irritation that makes Windows feel inconsistent. Removing a white flash in dark mode is cosmetic, but it targets the same credibility problem: Windows 11 still occasionally feels like a modern shell sitting on top of legacy timing and rendering assumptions.
Explorer.exe reliability remains the most important item in that cluster. When File Explorer, the taskbar, and shell interactions misbehave, users do not experience it as one app crashing. They experience it as Windows itself becoming less trustworthy. Microsoft’s continued attention here suggests the company knows that shell reliability is now a reputational issue, not merely a bug count.
The limitation is hardware. Microsoft lists support for devices such as Surface Slim Pen 2, ASUS Pen 3.0, and MSI Pen 2, while saying additional compatible devices may become available as partners release updates. That means the experience will be uneven by design.
This is the blessing and curse of Windows as a hardware ecosystem. Apple can introduce a feedback pattern and know exactly which devices will support it. Microsoft has to build a capability, expose settings, court hardware partners, and then wait for firmware, drivers, and product cycles to catch up.
The voice typing change is simpler and probably more broadly useful. By removing the full-screen overlay and putting animations directly on the dictation key, Microsoft is reducing the sense that voice input is a mode switch. That matters because voice typing will never feel mainstream if invoking it makes the user feel as if they have temporarily left the normal typing experience.
The Arabic 101 Legacy keyboard addition is also worth noticing. It is not a mass-market feature in the U.S. press sense, but it is exactly the sort of regional accommodation that determines whether Windows feels respectful to multilingual users. Microsoft’s global footprint depends on thousands of such details being maintained after each round of modernization.
This is not just another notification tweak. It is an operating-system affordance for long-running AI work. Microsoft is effectively acknowledging that agents are not normal apps, not normal background tasks, and not normal notifications. They need a visible place in the shell where users can see that work is happening without staring at an app window.
The taskbar is the logical place to put that state, but it is also a contested space. Windows users already have pinned apps, running apps, system tray icons, badges, alerts, and background activity competing for attention. Adding agent progress risks turning the taskbar into yet another dashboard unless Microsoft keeps the interaction model disciplined.
For developers, the introduction of a Windows shell API for this behavior is the real signal. Microsoft wants agentic applications to integrate with Windows rather than merely exist inside browser tabs or standalone chat windows. If that model catches on, the taskbar could become a control surface for delegated work: reports, searches, renders, builds, automations, and maybe eventually administrative workflows.
There is a trust question underneath the convenience. If agents are going to live in the shell, users need confidence that the shell is accurately representing what those agents are doing. A progress indicator for AI work is only useful if it does not become a decorative spinner for opaque cloud activity.
That last caveat is classic Microsoft: the feature administrators want arrives, but the management surface they increasingly use does not yet expose it cleanly. Still, the direction is welcome. Enterprise admins have been fighting Windows inbox app sprawl for years, especially in environments where consumer apps create support noise, policy concerns, or simply unwanted clutter.
The dynamic list matters because static app-removal policies age badly. Microsoft changes app packages, renames experiences, and ships new inbox components over time. A policy that can target additional package family names gives administrators a more adaptable tool for keeping managed images lean.
There is also a philosophical shift here. Microsoft has often treated bundled apps as part of the Windows value proposition, while administrators have treated many of them as remediation tasks. This update does not settle that conflict, but it gives enterprise and education customers a more official path to say: not on this fleet.
The Intune gap is important, however. Modern management shops do not want to keep falling back to Group Policy for new Windows controls. If Microsoft wants cloud-first management to be credible, new policy features need to land in Intune quickly, not as an afterthought.
That is a mouthful, but the implication is straightforward: maintaining platform trust at Windows scale is now an exercise in telemetry-informed caution. Microsoft cannot simply push sensitive boot-trust changes everywhere at once and hope for the best. It needs evidence that a device is healthy enough to receive them.
This is where security and servicing become inseparable. Secure Boot certificate updates are not cosmetic, and mistakes at that layer can strand machines in ways that are far more painful than an app crash. The staged approach is sensible, but it also means some devices may lag behind others in receiving trust updates because they have not produced the right update-success signals.
Microsoft also adds a LimitSecureBootRequiredServiceData policy for Group Policy and MDM. When enabled, Windows limits the Secure Boot service data sent by suppressing the event normally sent to Microsoft. The policy is included in Microsoft’s restricted traffic baseline, which makes it relevant for high-control environments that minimize outbound telemetry.
That creates a delicate tradeoff. The same data that helps Microsoft target Secure Boot certificate rollout more safely may be data that some organizations prefer not to send. Microsoft is trying to give administrators a switch, but administrators must understand that limiting service data can have consequences for how confidently Microsoft can include devices in automated trust maintenance.
The broader lesson is that “turn off telemetry” is not a single-dimensional privacy decision anymore. In modern Windows, service data can influence eligibility, rollout pacing, remediation, and safety checks. Organizations need policy clarity, not slogans, when deciding what to suppress.
This is the sort of change that security teams tend to applaud and compatibility teams tend to fear. Kernel-mode drivers are a prized target because they sit at a level of privilege where a bad driver can undermine the operating system’s security model. Reducing trust in older cross-signing paths is consistent with Microsoft’s long campaign to harden the Windows driver ecosystem.
The mitigation is staged enforcement. Microsoft says Windows audits driver compatibility for at least 100 hours and three reboots before enabling enforcement. After enforcement, a small number of cross-signed drivers might be blocked.
That is more careful than flipping a switch, but it still creates a risk window for specialized environments. Industrial systems, lab hardware, medical-adjacent devices, old peripherals, niche VPN clients, and security products have historically been places where driver age and operational necessity collide. Even a “small number” of blocked drivers can mean a big incident if the affected driver belongs to a critical workflow.
For administrators, the preview channel is the warning shot. Test machines with representative hardware should get this update before the behavior becomes part of the next security baseline. The real question is not whether Microsoft is right to reduce kernel trust for legacy signing models. It is whether your organization knows which drivers still depend on them.
This sounds obscure until you remember how much enterprise automation still depends on CMD scripts. Batch files are old, plain, and easy to dismiss, but they remain embedded in deployment tasks, logon scripts, installers, remediation tools, and vendor utilities. That ubiquity makes their execution semantics a security concern.
Preventing a batch file from changing while it is running closes off a class of tampering and race-condition behavior that defenders should not have to tolerate in 2026. The challenge is compatibility. Some old scripts may rely on self-modifying behavior, temporary rewrites, or generated command sequences that assume the file can change during execution.
Microsoft is not forcing the mode on universally in this preview, which is the right call. Giving administrators a switch allows high-security environments to test and adopt it without breaking every legacy script estate overnight. But the existence of the feature is a signal: Windows is slowly dragging its oldest administrative surfaces into a more explicitly governed security model.
The irony is that the most modern Windows security story still has to account for the oldest Windows automation habits. PowerShell, Windows Terminal, Dev Home, and cloud management may get the attention, but CMD is still there. KB5089570 treats that as a fact to secure, not a relic to ignore.
That distinction matters because Windows updates are increasingly carrying payloads for hardware-defined experiences. A conventional Windows 11 PC may download an update whose contents include AI components, but the applicability logic determines whether those components install. The update package is common; the realized system state is not.
For users, this can feel arbitrary. Two machines may both be on Windows 11 version 26H1 and the same cumulative update, but only one receives the AI components because only one meets the Copilot+ PC criteria. Microsoft’s marketing wants Copilot+ to feel like a product tier; Windows servicing has to make that tier real at package-install time.
For administrators, this creates inventory and compliance questions. It is not enough to know whether KB5089570 is installed. If AI capability governance matters, you also need to know whether the device is a Copilot+ PC, whether the AI components applied, and how those components are controlled by policy.
This will become more important as AI features move from novelty to workflow infrastructure. Search, content extraction, semantic analysis, and settings models are not just flashy front ends. They are pieces of an OS-level AI substrate. Microsoft is laying that substrate through ordinary servicing, which means AI governance is becoming a Windows update management problem.
But the servicing stack is especially important in an update like this because the package does more than replace a few files. It handles a cumulative update, feature rollout state, Secure Boot targeting, optional AI components, and installation paths across Windows Update, the Microsoft Update Catalog, WSUS import, running systems, and offline media.
Microsoft says the standalone package is available from the Microsoft Update Catalog and may contain one or more MSU files requiring installation in a specific order. In the instructions shown for this update, the ARM64 MSU is the listed package, and Microsoft describes two supported approaches: place all MSU files in one folder and let DISM discover prerequisites, or install each MSU individually in order.
That guidance is more than procedural boilerplate. It reflects the increasing complexity of Windows packaging. Administrators who service offline images, maintain golden media, or import updates into WSUS cannot assume that downloading “the update” is a single-click operation with no sequencing concerns.
The Dynamic Update note is also important. When updating installation media, Microsoft tells administrators to match other Dynamic Update packages to the same month as the KB where possible, or use the most recently published SafeOS or Setup Dynamic Update if a same-month package is unavailable. That is the kind of detail that separates a clean deployment image from one that fails in a confusing corner of setup.
The update is available through Windows Update as an optional update. For Windows Update for Business, Microsoft says the changes will appear in the next security update. The Catalog path is available, and WSUS administrators can import it manually.
That channel split is the operational story. Enthusiasts and unmanaged users can choose to install it now. Organizations using Windows Update for Business generally encounter the payload when it graduates into the next security release. WSUS-heavy environments can pull it in manually if they want to validate early.
There is a strong case for testing this preview, even if there is a weak case for deploying it broadly. The driver trust change alone justifies lab evaluation. So do the Secure Boot targeting behavior, batch-file lock mode, app-removal policy, and Copilot+ component applicability.
The safest posture is selective curiosity. Install KB5089570 on test devices that represent your hardware, app, script, and management diversity. Do not treat the absence of known issues as permission to skip validation, especially if your environment includes legacy drivers or heavily customized Windows images.
Microsoft Uses the Preview Channel as a Product Launchpad
KB5089570 is labeled a preview, but the word undersells what Microsoft is doing here. Preview updates used to be easy to describe as optional quality rollups: a place where fixes could get field exposure before arriving in the next Patch Tuesday release. This one still fits that mold, but only if you stretch “quality” to include Xbox mode, Shared Audio, taskbar agent monitoring, File Explorer archive support, enterprise app-removal policy, Secure Boot certificate targeting, and new command-line behavior for batch files.That is the new Windows cadence in miniature. The monthly non-security preview is no longer merely a bug-fix checkpoint; it is a feature staging lane. Microsoft can say, accurately, that the update is optional and gradual, while still using it to seed features that will soon become part of the baseline experience for a broad Windows 11 population.
The gradual rollout language matters. Microsoft says features may arrive in phases, with availability varying by device, and that a normal rollout follows when features reach broader availability. That sounds benign, but it creates a tricky support reality: two machines can both report the same build number while exposing different user-facing capabilities.
For home users, that means one PC may show Shared Audio or Xbox mode while another does not. For IT, it means build number alone is no longer enough to describe state. The real diagnostic question becomes not just “What build are you on?” but “Which controlled feature rollout state has this device received?”
The Consumer Features Are Flashy, but the Platform Story Is Bigger
The easy read of KB5089570 is that Microsoft is giving Windows 11 some friendlier consumer polish. Shared Audio lets two people listen from one Windows 11 PC using Bluetooth LE Audio broadcast technology, assuming supported paired devices are present. Xbox mode brings a full-screen, controller-friendly interface to PCs, laptops, desktops, and tablets, with entry points through the Xbox app, Game Bar settings, or the Windows key plus F11.Those additions are not trivial. Shared Audio moves Windows closer to the kind of casual device-sharing experience people expect from phones and tablets. Xbox mode is another step in Microsoft’s long-running effort to make Windows behave less like a desktop OS when it is being used as a gaming appliance.
But the more interesting story is that these features arrive alongside plumbing that has nothing to do with entertainment. File Explorer gains support for more archive formats, including uu, cpio, xar, and NuGet packages. The system improves startup app launch performance, Store download reliability, taskbar tray loading, Windows Hello behavior, Delivery Optimization memory usage, color-profile persistence, and explorer.exe reliability.
That mix is revealing. Microsoft is no longer separating “fun” Windows from “managed” Windows. The same update that helps a traveler share movie audio also changes how Windows trusts third-party drivers. The same build that adds a full-screen gaming shell also gives administrators more control over preinstalled Microsoft Store apps.
The Windows 11 user experience is being renovated from both ends: visible surface area for consumers, and deeper governance for enterprises. KB5089570 is what happens when those priorities are shipped through one servicing mechanism.
File Explorer Keeps Becoming a Utility Belt
File Explorer’s changes in this update are modest individually, but they continue a pattern that has been building for years. Windows is absorbing more of the basic utility work that once required separate tools, shell extensions, or command-line detours.Expanded archive support is the obvious example. Adding uu, cpio, xar, and NuGet package support will not excite every user, but it matters to developers, administrators, and anyone handling cross-platform package formats. NuGet package visibility in File Explorer is especially telling because it pulls a developer ecosystem artifact into the default Windows shell.
The practical payoff is less about replacing specialized tools and more about reducing friction. If File Explorer can inspect or interact with more package types, fewer users need to install random utilities of uncertain provenance. That has security benefits, even if Microsoft does not frame it that way.
The smaller fixes may be more noticeable day to day. Preserving View and Sort preferences in folders such as Downloads and Documents when apps open Explorer directly addresses the kind of irritation that makes Windows feel inconsistent. Removing a white flash in dark mode is cosmetic, but it targets the same credibility problem: Windows 11 still occasionally feels like a modern shell sitting on top of legacy timing and rendering assumptions.
Explorer.exe reliability remains the most important item in that cluster. When File Explorer, the taskbar, and shell interactions misbehave, users do not experience it as one app crashing. They experience it as Windows itself becoming less trustworthy. Microsoft’s continued attention here suggests the company knows that shell reliability is now a reputational issue, not merely a bug count.
Input Is Becoming More Sensory, More Local, and More Fragmented
KB5089570 adds haptic feedback support for compatible input devices during actions such as aligning objects in PowerPoint or snapping and resizing windows. That sounds small, but it points toward a Windows interface that is increasingly willing to use touch, pen, and device-specific feedback as first-class signals rather than accessories.The limitation is hardware. Microsoft lists support for devices such as Surface Slim Pen 2, ASUS Pen 3.0, and MSI Pen 2, while saying additional compatible devices may become available as partners release updates. That means the experience will be uneven by design.
This is the blessing and curse of Windows as a hardware ecosystem. Apple can introduce a feedback pattern and know exactly which devices will support it. Microsoft has to build a capability, expose settings, court hardware partners, and then wait for firmware, drivers, and product cycles to catch up.
The voice typing change is simpler and probably more broadly useful. By removing the full-screen overlay and putting animations directly on the dictation key, Microsoft is reducing the sense that voice input is a mode switch. That matters because voice typing will never feel mainstream if invoking it makes the user feel as if they have temporarily left the normal typing experience.
The Arabic 101 Legacy keyboard addition is also worth noticing. It is not a mass-market feature in the U.S. press sense, but it is exactly the sort of regional accommodation that determines whether Windows feels respectful to multilingual users. Microsoft’s global footprint depends on thousands of such details being maintained after each round of modernization.
The Taskbar Becomes a Place Where Agents Report Back
One of the more futuristic additions in KB5089570 is taskbar monitoring for agents across first- and third-party apps. Microsoft names Researcher in the Microsoft 365 Copilot app as the first adopter, allowing users to watch progress from the taskbar while an agent works on a report and return to the app when results are ready.This is not just another notification tweak. It is an operating-system affordance for long-running AI work. Microsoft is effectively acknowledging that agents are not normal apps, not normal background tasks, and not normal notifications. They need a visible place in the shell where users can see that work is happening without staring at an app window.
The taskbar is the logical place to put that state, but it is also a contested space. Windows users already have pinned apps, running apps, system tray icons, badges, alerts, and background activity competing for attention. Adding agent progress risks turning the taskbar into yet another dashboard unless Microsoft keeps the interaction model disciplined.
For developers, the introduction of a Windows shell API for this behavior is the real signal. Microsoft wants agentic applications to integrate with Windows rather than merely exist inside browser tabs or standalone chat windows. If that model catches on, the taskbar could become a control surface for delegated work: reports, searches, renders, builds, automations, and maybe eventually administrative workflows.
There is a trust question underneath the convenience. If agents are going to live in the shell, users need confidence that the shell is accurately representing what those agents are doing. A progress indicator for AI work is only useful if it does not become a decorative spinner for opaque cloud activity.
Enterprise IT Gets a Quiet Win on App Removal
The update’s policy-based removal of preinstalled Microsoft apps may prove more important to managed environments than any of the consumer-facing features. KB5089570 adds support for a dynamic app removal list to the “Remove Default Microsoft Store packages” policy for Windows Enterprise and Education. Administrators can specify additional MSIX or APPX package family names through Group Policy, though Microsoft says the dynamic list is not currently available in the Intune Settings Catalog and must be validated through Group Policy or custom OMA-URI.That last caveat is classic Microsoft: the feature administrators want arrives, but the management surface they increasingly use does not yet expose it cleanly. Still, the direction is welcome. Enterprise admins have been fighting Windows inbox app sprawl for years, especially in environments where consumer apps create support noise, policy concerns, or simply unwanted clutter.
The dynamic list matters because static app-removal policies age badly. Microsoft changes app packages, renames experiences, and ships new inbox components over time. A policy that can target additional package family names gives administrators a more adaptable tool for keeping managed images lean.
There is also a philosophical shift here. Microsoft has often treated bundled apps as part of the Windows value proposition, while administrators have treated many of them as remediation tasks. This update does not settle that conflict, but it gives enterprise and education customers a more official path to say: not on this fleet.
The Intune gap is important, however. Modern management shops do not want to keep falling back to Group Policy for new Windows controls. If Microsoft wants cloud-first management to be credible, new policy features need to land in Intune quickly, not as an afterthought.
Secure Boot Changes Show How Fragile Trust Maintenance Has Become
KB5089570 includes Secure Boot changes that deserve more attention than they will probably receive. Microsoft says Windows quality updates now include additional high-confidence device targeting data to increase the coverage of devices eligible to automatically receive new Secure Boot certificates. Devices receive those certificates only after showing sufficient successful update signals, preserving a controlled and phased rollout.That is a mouthful, but the implication is straightforward: maintaining platform trust at Windows scale is now an exercise in telemetry-informed caution. Microsoft cannot simply push sensitive boot-trust changes everywhere at once and hope for the best. It needs evidence that a device is healthy enough to receive them.
This is where security and servicing become inseparable. Secure Boot certificate updates are not cosmetic, and mistakes at that layer can strand machines in ways that are far more painful than an app crash. The staged approach is sensible, but it also means some devices may lag behind others in receiving trust updates because they have not produced the right update-success signals.
Microsoft also adds a LimitSecureBootRequiredServiceData policy for Group Policy and MDM. When enabled, Windows limits the Secure Boot service data sent by suppressing the event normally sent to Microsoft. The policy is included in Microsoft’s restricted traffic baseline, which makes it relevant for high-control environments that minimize outbound telemetry.
That creates a delicate tradeoff. The same data that helps Microsoft target Secure Boot certificate rollout more safely may be data that some organizations prefer not to send. Microsoft is trying to give administrators a switch, but administrators must understand that limiting service data can have consequences for how confidently Microsoft can include devices in automated trust maintenance.
The broader lesson is that “turn off telemetry” is not a single-dimensional privacy decision anymore. In modern Windows, service data can influence eligibility, rollout pacing, remediation, and safety checks. Organizations need policy clarity, not slogans, when deciding what to suppress.
Driver Trust Tightens Around the Kernel
The Windows driver policy update is one of the most consequential security moves in KB5089570. Microsoft says the update changes how the Windows kernel trusts third-party drivers by removing default trust for cross-signed drivers, while continuing to allow drivers from the Windows Hardware Compatibility Program and an allow list of trusted legacy drivers.This is the sort of change that security teams tend to applaud and compatibility teams tend to fear. Kernel-mode drivers are a prized target because they sit at a level of privilege where a bad driver can undermine the operating system’s security model. Reducing trust in older cross-signing paths is consistent with Microsoft’s long campaign to harden the Windows driver ecosystem.
The mitigation is staged enforcement. Microsoft says Windows audits driver compatibility for at least 100 hours and three reboots before enabling enforcement. After enforcement, a small number of cross-signed drivers might be blocked.
That is more careful than flipping a switch, but it still creates a risk window for specialized environments. Industrial systems, lab hardware, medical-adjacent devices, old peripherals, niche VPN clients, and security products have historically been places where driver age and operational necessity collide. Even a “small number” of blocked drivers can mean a big incident if the affected driver belongs to a critical workflow.
For administrators, the preview channel is the warning shot. Test machines with representative hardware should get this update before the behavior becomes part of the next security baseline. The real question is not whether Microsoft is right to reduce kernel trust for legacy signing models. It is whether your organization knows which drivers still depend on them.
Batch Files Get a Security Model That Should Have Existed Years Ago
KB5089570 also introduces a more secure processing mode for batch files and Command Prompt scripts. When enabled, the mode prevents batch files from changing during execution. Administrators can turn it on with a registry value under the Command Processor key, and policy authors can enable it through an Application Control for Business manifest control.This sounds obscure until you remember how much enterprise automation still depends on CMD scripts. Batch files are old, plain, and easy to dismiss, but they remain embedded in deployment tasks, logon scripts, installers, remediation tools, and vendor utilities. That ubiquity makes their execution semantics a security concern.
Preventing a batch file from changing while it is running closes off a class of tampering and race-condition behavior that defenders should not have to tolerate in 2026. The challenge is compatibility. Some old scripts may rely on self-modifying behavior, temporary rewrites, or generated command sequences that assume the file can change during execution.
Microsoft is not forcing the mode on universally in this preview, which is the right call. Giving administrators a switch allows high-security environments to test and adopt it without breaking every legacy script estate overnight. But the existence of the feature is a signal: Windows is slowly dragging its oldest administrative surfaces into a more explicitly governed security model.
The irony is that the most modern Windows security story still has to account for the oldest Windows automation habits. PowerShell, Windows Terminal, Dev Home, and cloud management may get the attention, but CMD is still there. KB5089570 treats that as a fact to secure, not a relic to ignore.
Copilot+ PCs Get the AI Payload, Everyone Else Gets the Package
The update includes AI component versions for Image Search, Content Extraction, Semantic Analysis, and Settings Model, all listed at version 1.2604.515.0. Microsoft also makes clear that although these AI component updates are included in the cumulative update, they apply only to Windows Copilot+ PCs and will not install on other Windows PCs or Windows Server.That distinction matters because Windows updates are increasingly carrying payloads for hardware-defined experiences. A conventional Windows 11 PC may download an update whose contents include AI components, but the applicability logic determines whether those components install. The update package is common; the realized system state is not.
For users, this can feel arbitrary. Two machines may both be on Windows 11 version 26H1 and the same cumulative update, but only one receives the AI components because only one meets the Copilot+ PC criteria. Microsoft’s marketing wants Copilot+ to feel like a product tier; Windows servicing has to make that tier real at package-install time.
For administrators, this creates inventory and compliance questions. It is not enough to know whether KB5089570 is installed. If AI capability governance matters, you also need to know whether the device is a Copilot+ PC, whether the AI components applied, and how those components are controlled by policy.
This will become more important as AI features move from novelty to workflow infrastructure. Search, content extraction, semantic analysis, and settings models are not just flashy front ends. They are pieces of an OS-level AI substrate. Microsoft is laying that substrate through ordinary servicing, which means AI governance is becoming a Windows update management problem.
The Servicing Stack Is the Part You Only Notice When It Fails
KB5089570 includes a servicing stack update, KB5095676, bringing the servicing stack to version 28000.2172. Servicing stack updates are the unglamorous machinery that lets Windows receive, stage, and install future updates reliably. They rarely make headlines because their success condition is invisibility.But the servicing stack is especially important in an update like this because the package does more than replace a few files. It handles a cumulative update, feature rollout state, Secure Boot targeting, optional AI components, and installation paths across Windows Update, the Microsoft Update Catalog, WSUS import, running systems, and offline media.
Microsoft says the standalone package is available from the Microsoft Update Catalog and may contain one or more MSU files requiring installation in a specific order. In the instructions shown for this update, the ARM64 MSU is the listed package, and Microsoft describes two supported approaches: place all MSU files in one folder and let DISM discover prerequisites, or install each MSU individually in order.
That guidance is more than procedural boilerplate. It reflects the increasing complexity of Windows packaging. Administrators who service offline images, maintain golden media, or import updates into WSUS cannot assume that downloading “the update” is a single-click operation with no sequencing concerns.
The Dynamic Update note is also important. When updating installation media, Microsoft tells administrators to match other Dynamic Update packages to the same month as the KB where possible, or use the most recently published SafeOS or Setup Dynamic Update if a same-month package is unavailable. That is the kind of detail that separates a clean deployment image from one that fails in a confusing corner of setup.
Optional Does Not Mean Irrelevant
Microsoft says it is not currently aware of any issues with KB5089570. That is useful, but it should not be read as a guarantee. Preview updates are explicitly part of Microsoft’s field-validation process, and “no known issues” at publication time can change after broader exposure.The update is available through Windows Update as an optional update. For Windows Update for Business, Microsoft says the changes will appear in the next security update. The Catalog path is available, and WSUS administrators can import it manually.
That channel split is the operational story. Enthusiasts and unmanaged users can choose to install it now. Organizations using Windows Update for Business generally encounter the payload when it graduates into the next security release. WSUS-heavy environments can pull it in manually if they want to validate early.
There is a strong case for testing this preview, even if there is a weak case for deploying it broadly. The driver trust change alone justifies lab evaluation. So do the Secure Boot targeting behavior, batch-file lock mode, app-removal policy, and Copilot+ component applicability.
The safest posture is selective curiosity. Install KB5089570 on test devices that represent your hardware, app, script, and management diversity. Do not treat the absence of known issues as permission to skip validation, especially if your environment includes legacy drivers or heavily customized Windows images.
The May Preview Draws a Map for June’s Problems
KB5089570 is not a security update, but it previews the operational work that security updates will inherit. The most concrete lessons are not hidden in the longest feature descriptions; they sit at the intersection of rollout mechanics, hardware eligibility, and administrative control.- Windows 11 version 26H1 systems that install KB5089570 move to OS Build 28000.2179, but gradual rollout means identical build numbers may not expose identical features immediately.
- The update adds consumer-facing features such as Shared Audio and Xbox mode while also delivering enterprise controls for app removal, Secure Boot service data, and batch-file processing.
- The Windows driver policy change is a serious compatibility checkpoint because removing default trust for cross-signed drivers can expose old or niche kernel dependencies.
- Copilot+ PC AI components are carried in the cumulative update but only install on eligible Copilot+ hardware, making device capability inventory more important than update compliance alone.
- Catalog, DISM, offline image, Dynamic Update, and WSUS paths remain essential for administrators who need deterministic deployment rather than consumer-style optional updating.
- Microsoft’s “no known issues” statement should be treated as a starting point for testing, not as a substitute for it.
References
- Primary source: Microsoft Support
Published: Tue, 26 May 2026 21:32:32 Z
May 26, 2026—KB5089570 (OS Build 28000.2179) Preview - Microsoft Support
support.microsoft.com