Futuristic cybersecurity dashboard with protected robots, cloud controls, laptops, and a glowing global network.
Microsoft released KB5124006 on September 22, 2026. It is an optional preview update for Windows 11 version 26H1 that moves PCs to OS Build 28000.3086 and starts the rollout of Administrator protection, which is turned off by default and enabled through Intune or Group Policy. The same update adds containment and identity plumbing for AI agents, plus standalone ML-KEM post-quantum key exchange for TLS. None of these security features does anything by itself. Each one has to be turned on by policy or used by an application, so KB5124006 gives admins and developers new tools rather than changing security on every PC. The real work for IT is finding out what breaks when elevation stops sharing a profile with the signed-in user.

KB5124006 Puts Administrator Protection Back on the Table for Windows 11 26H1​

Microsoft's release notes list KB5124006 as a non-security cumulative update for all editions of Windows 11 version 26H1. It includes servicing stack update KB5124005, which brings the servicing stack to build 28000.3081. The Windows 11 26H1 update history confirms the sequence: September 22, 2026—KB5124006 (OS Build 28000.3086) Preview follows the September 14 out-of-band update and the September 8 security release KB5124012.

The build numbers need a word of explanation. Insiders saw this package first: according to the Windows Insider notes quoted on Eleven Forum, these release notes are for Windows 11 Build 28000.3079 (KB5124006) in the Release Preview Channel on Windows 11, version 26H1. That build appeared around September 11. The public release eleven days later carries the higher 28000.3086 number under the same KB identifier. If you see both numbers, one is the Release Preview build and the other is the public build. They are not conflicting reports.

The update is scoped narrowly. It applies only to 26H1, and the Microsoft Update Catalog instructions list a single Arm64 package, windows11.0-kb5124006-arm64.msu, with no checkpoint cumulative update required. PCs on Windows 11 24H2 or 25H2 get their own monthly preview under a different KB number. The features described below should not be assumed to exist on those branches until Microsoft documents them there.

Delivery is split in two. A gradual rollout turns on new experiences, including Administrator protection, in phases, so installing the update does not guarantee a feature appears right away. A normal rollout covers quality fixes, which arrive once the package is installed. Home users find it under Settings > Windows Update > Advanced options > Optional updates. Enterprises can use Windows Update for Business, the Microsoft Update Catalog, or a manual import into WSUS.

How Administrator Protection Changes Elevation on Windows 11 26H1 PCs​

Administrator protection has been a long time coming. Microsoft first described it at Build in May 2025. In a January 23, 2026 editor's note on the Windows Developer Blog, Microsoft said it had pulled the feature from retail and Insider channels after finding a reliability issue. The KB5124006 notes say the feature was previously disclosed in the October 2025 update KB5067036 and is now beginning to roll out. Neowin reports that Microsoft began seeding it again through the optional August 2026 preview update released a couple of weeks ago with KB5120998, so 26H1 is not the only branch getting it.

Microsoft's KB language is short. The feature aims to protect free-floating admin rights for administrators. It enables users to perform administrative tasks using just-in-time privileges. The notes also say it isn't classified as a formal security boundary. It hardens security against elevation-of-privilege attacks by introducing profile separation. The 2025 developer blog used stronger wording, describing a "new security boundary." The current KB drops that claim, and the KB is the record that ships with the code.

The mechanism is easiest to see against how elevation works today. Under the classic User Account Control (UAC) split-token model, an administrator signs in with two tokens: a full admin token and a filtered one. Both share a single user profile, so elevated and unelevated processes can reach the same files and the same HKCU registry hive. Microsoft's developer blog says that shared profile is what classic UAC bypasses exploit, such as registry-key manipulation and environment-variable overloading.

With Administrator protection enabled, elevation runs through a hidden, system-managed local account that Microsoft calls the System Managed Administrator Account (SMAA). It has its own security identifier and its own profile. Windows mints an admin token from that account only when an elevation is requested and throws it away when the task finishes. Microsoft also removes auto-elevation, the behaviour that lets some Windows components elevate silently, so every admin operation needs interactive approval. Microsoft recommends pairing the feature with Windows Hello.

What breaks when elevated apps get their own profile​

This design causes the compatibility problems admins need to test for. Microsoft's developer guidance says:

  • Files an elevated app saves to library folders such as Documents or Pictures go to the SMAA profile's folders by default, not the user's own folders.
  • An elevated process sees the SMAA account's HKCU hive, so per-user registry settings don't carry over.
  • App preferences such as themes and fonts don't sync between elevated and unelevated instances. Microsoft's example is dark mode set in unelevated Notepad, which does not appear in elevated Notepad.
  • Users should expect more elevation prompts, because auto-elevation is gone.

Microsoft singles out Visual Studio. Running it elevated with Administrator protection enabled is an unsupported configuration. Per-user extensions aren't visible from the elevated instance, settings differ, and default paths such as the new-project folder can point into the admin account's profile. The blog also warns that an app installed from an elevated context while the feature is on may need reinstalling if it won't launch after the feature is removed.

To confirm the feature is active, the blog gives this check: open Command Prompt as administrator and run whoami. On a protected device, the account name starts with "ADMIN_".

Administrator protection is a different tool from Intune Endpoint Privilege Management. Neowin describes the feature as giving just-in-time admin privileges to non-privileged users, but that is not how Microsoft documents it. Consultant Mert Efe Kanlikilic puts it more accurately: Administrator Protection protects the use of administrative privileges for administrator accounts, while EPM provides controlled elevation for standard users. Organizations that already run standard-user desktops with EPM still need that product.

On enablement, the KB names only an OMA-URI custom policy in Intune or Group Policy. It does not give the OMA-URI path or the name of the Group Policy setting. The 2025 blog mentioned a toggle under Account protection in Windows Security, but the KB5124006 notes don't mention one. Don't assume consumers can turn the feature on locally in this release.

Microsoft Execution Containers and Agent IDs Give Windows 11 Plumbing for AI Workloads​

KB5124006 adds two related platform features for AI-driven software. The first is Process Isolation for Microsoft Execution Containers (MXC). Microsoft describes it as a fast, lightweight boundary for responsive workloads such as coding agents and model-generated code. It uses Windows' built-in containment features to limit what a contained process can reach, including files, networking, the UI and other operating-system capabilities, according to policy.

The key words are "according to policy." The KB does not say MXC turns on automatically, and it gives no end-user setting. As documented, it is something developers and platform builders use when they want to run untrusted, model-generated code in a box. An administrator will see its effect only when an agent framework or application chooses to use it.

The second feature is a preview: tagging agentic processes. Authorized components can attach an opaque agent identifier to a process token. Windows protects that marking and passes it automatically to every child process. When a tagged process signs in through Web Account Manager (WAM), the Windows broker that handles Microsoft account and Entra ID sign-in for apps, WAM includes the agent identifier in the authentication request.

In practical terms, an agent that spawns shells, compilers and helper tools no longer loses its identity at each step. Anything downstream of WAM can tell that a sign-in came from an agent and which one. The tag labels an agent. It does not decide whether that agent is trusted or what it may access; those decisions belong to whatever consumes the identifier. Microsoft warns that the identifier format may change in future releases, so developers should not hard-code it into production logic yet.

ML-KEM Goes Standalone in the Windows 11 TLS Stack​

The cryptography change is one line in the notes. ML-KEM, the post-quantum key-encapsulation algorithm, can now be used as a standalone algorithm for TLS key exchange, in addition to the hybrid groups Windows added earlier. In a hybrid group, ML-KEM is paired with a classical key exchange, so the connection stays secure if either one holds. Standalone ML-KEM drops the classical half.

Security teams should treat this as a new option rather than an automatic upgrade. The KB does not say Windows will prefer standalone ML-KEM or that existing connections will switch to it. Whether a TLS session uses it depends on the app, the protocol stack and the server at the other end. Apps that ship their own TLS libraries won't touch the Windows implementation at all. Organizations with post-quantum policies that call for pure ML-KEM, and not only hybrid key exchange, can now start testing it on 26H1 clients.

The Quieter KB5124006 Changes: Sleep, Virtual Desktops and Store Purchases​

The rest of the security-adjacent list is mostly quality-of-life work. Switching between virtual desktops is smoother. Settings > System > Display is more reliable to navigate. Brightness now returns to its earlier level when Energy Saver turns off. Task Manager shows app-history data more reliably. Windows Setup makes it easier to skip adding a secondary keyboard, and the Get Started app gains pages for installing apps, pinning sites and choosing themes.

Two Windows Update changes deserve more attention. First, a PC that was manually put to sleep will go back to sleep after an update restart, even if automatic sleep is set to Never. Before, such a PC could stay awake after an overnight update. Second, apps that take part in the Windows Update Orchestration Platform can schedule their own updates alongside Windows Update. Only participating apps benefit, so nothing changes for software that hasn't adopted it.

For developers, the Microsoft Store now supports in-app purchases in packaged WinUI 3 apps that require elevation. This helps a specific group, packaged WinUI 3 apps sold through the Store that need admin rights. It does not change purchasing for other Win32 or Store apps.

The same release also rolls out the more visible 26H1 shell changes: a taskbar that can sit on any edge of the screen, a Small taskbar option, Start menu sizing, and a new Settings > Privacy & Security > Search control for web and Store suggestions. For enterprises, Microsoft also lists device association for Windows Autopilot device preparation as generally available. It lets organizations identify trusted devices before enrollment.


Two Known Issues Ride Along With KB5124006​

Microsoft lists two known issues that began with the September 8 security update KB5124012 and carry into this preview.

The more serious one affects domain-joined PCs. Machine accounts protected by Credential Guard can lose their secure channel with on-premises Active Directory. Users then see a message saying the trust relationship failed, although cached offline sign-in may still work. Microsoft explains that KB5124012 makes Windows start honouring existing policy settings that enforce Machine Identity Isolation. That feature is only supported with domain controllers at the Windows Server 2025 Domain Functional Level or higher.

The workaround is to disable Machine Identity Isolation the same way it was enabled:

  1. If Intune policy turned it on, turn it off in Intune. If Group Policy turned it on, turn it off in Group Policy.
  2. If it was set directly in the registry, back up the registry first. Then, under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation or HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation, change MachineIdentityIsolation from 2 to 0.
  3. Restart the device.
  4. Repair the secure channel with Test-ComputerSecureChannel -Repair -Credential (Get-Credential).

There is one discrepancy. The registry steps on the 26H1 KB page say "On the Windows 11, version 24H2 or 25H2 device," even though the page covers 26H1. The same text seems to have been copied across KB pages. Admins running 26H1 in a domain should check that those paths exist before editing. Microsoft says a future update will temporarily block Machine Identity Isolation enforcement while it improves the feature.

The second issue affects USB Audio Class 1.0 devices. They may show "This device cannot start (Code 10)" in Device Manager, produce no sound, or leave volume and sound settings unresponsive. Microsoft says it affects only USB Audio Class 1.0 hardware and has not published a workaround.

Anyone building install media should also note a deployment warning. When you apply dynamic updates to an existing image, the boot.stl file used for Secure Boot validation must be on the media and must match the image's Windows version and architecture. Without it, devices may fail to boot from the media with error 0xc0430001. Microsoft recommends its Update WinPE script. The alternative is to copy boot.stl from Windows\Boot\EFI onto the media by hand.

What this means for you​

Only people running Windows 11 26H1 need to decide anything now, and the decision for most of them is whether to pilot Administrator protection. Home users on 26H1 can install the optional update for the fixes, but unless you use USB Audio Class 1.0 hardware, there is little reason to hurry. Domain administrators should first check whether any 26H1 machines enforce Machine Identity Isolation against pre-2025 domain controllers. That problem started with KB5124012 and doesn't wait for this preview.

  • KB5124006 applies only to Windows 11 26H1 (build 28000.x). The public release is build 28000.3086, and the Release Preview build was 28000.3079.
  • Administrator protection is off by default and turned on through an Intune OMA-URI policy or Group Policy. Pilot it on a small group, then run whoami from an elevated prompt and look for an "ADMIN_" account to confirm it's active.
  • Before rolling it out widely, test installers, elevated admin tools and developer workflows. Elevated Visual Studio in particular is unsupported with the feature enabled.
  • MXC process isolation and agent process tagging only take effect when software uses them. Treat the agent-ID format as a preview that may change.
  • Standalone ML-KEM for TLS is available to test, but existing connections won't switch to it automatically.
  • If domain-joined 26H1 PCs lose domain trust, disable Machine Identity Isolation the same way it was enabled, restart, and repair the secure channel with Test-ComputerSecureChannel.

KB5124006 is the release where Administrator protection returns, and it does so cautiously: off by default, policy-only, and with a KB that no longer calls it a security boundary. Neowin expects the feature to reach Windows 11, version 26H2 later this year, provided that everything goes well this time. That makes this preview window the time for IT teams to find out which apps save files into an elevated profile before Microsoft moves closer to its stated goal of turning the feature on by default.