Windows 11 26H2 Security Baseline Enables Administrator Protection: LAPS and RDP Risks

The printer and TLS changes are useful but fairly routine. The bigger change is that the baseline now turns on Administrator protection, which changes how admins get elevated rights in Windows. If your organization deploys Microsoft's baselines without much review, read the rest of this before the next policy refresh.

What's in the 26H2 baseline​

Microsoft lists four policy changes compared with the Windows 11, version 25H2 baseline. Two are new hardening settings. Two are UAC settings that enable Administrator protection.

As in earlier releases, the package is distributed through the Microsoft Security Compliance Toolkit. Microsoft's guidance is to download it, test it, and customize it before deploying.

Section summary: There are four changes. The two UAC settings carry the most operational risk.

Administrator protection: now on by default in the baseline​

Administrator protection has had a bumpy history. Neowin reported that Microsoft disabled this feature in Windows 11 last year when it stopped rollout, then began seeding it again through the optional August 2026 preview update with KB5120998. Microsoft's post now says it is now generally available. Organizations can enable it through Microsoft Intune or Group Policy.

The baseline change isn't limited to 26H2. Microsoft says the security baselines for Windows 11, versions 24H2, 25H2, and 26H2 include settings that enable Administrator protection. The Administrator protection page on Microsoft Learn adds the timing: organizations that use Windows security baselines will see the feature enabled by default with the October 2026 Windows security update, under the new defaults in those three baselines. Fleets still on 24H2 or 25H2 are affected too.

How it works​

Microsoft Learn describes Administrator protection as a least-privilege model. Users sign in with a deprivileged token. When a task needs admin rights, Windows asks the user to authorize it, then uses a hidden, system-generated, profile-separated account to create an isolated admin token. That token goes only to the requesting process and is destroyed when the process ends. Nothing elevates automatically, and the feature is integrated with Windows Hello.

Classic UAC handed an admin a split token, and a consent click was enough to unlock the full one. Administrator protection gives you a short-lived token for one task, and once that task ends you have to authorize again. Admin365.Blog summarises it as replacing UAC elevation with just-in-time, per-task admin tokens authenticated via Windows Hello. Tokens are isolated and ephemeral — created for a single task, then destroyed.

Don't treat it as a guarantee. As Techdows notes, Microsoft does not classify Administrator protection as a formal security boundary. It hardens Windows against elevation-of-privilege attacks rather than guaranteeing they fail.

Where it can break things​

This is why Microsoft keeps telling admins to "review and test." Microsoft Learn says not to enable Administrator protection on:

• Windows 365 Cloud PCs (Enterprise, Flex and Business)
• Azure Virtual Desktop session hosts
• Devices that require Hyper-V
• Devices managed with Local Administrator Password Solution (LAPS)
• Machines running apps that access shared files across profiles

The LAPS item alone will matter to a lot of enterprises. If your baseline deployment covers LAPS-managed endpoints, you need an exclusion group before the October update arrives.

Microsoft Learn also lists behavior changes that support teams should expect:

• Settings stay in one profile. App settings don't carry over between the standard and elevated profiles. Developers who run WSL or Visual Studio elevated for some tasks may have to reinstall and configure them in the elevated profile.
• No SSO in elevated sessions. Single sign-on credentials from the standard session aren't available, so domain or cloud authentication has to be repeated in the elevated session.
• Network drives disappear. Elevated apps can't reach network drives and resources. Microsoft suggests copying installers to a local drive before elevating.
• RDP failures. Microsoft documents that non-admin RDP logons fail with error 0xC000000D on devices with Administrator protection enabled after installing KB5124010. The workaround is to turn the feature off on affected devices by resetting the Admin Approval Mode policy.
• Remote administration. Separate UAC policies control whether domain users in the local Administrators group get elevated remote logons. Remote elevation is disabled by default.

Section summary: The baseline now turns Administrator protection on for 24H2, 25H2 and 26H2. Exclude unsupported device types first, and warn the helpdesk about the RDP issue.

Configuring or opting out​

If you use Group Policy, Microsoft Learn says the two settings are under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. To enable the feature:

1. Set User Account Control: Configure type of Admin Approval Mode to Admin Approval Mode with Administrator protection.
2. Set User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection to the prompt behavior you want. The baseline uses credentials on the secure desktop.
3. Restart the device. The feature doesn't take effect until you do.

To opt out, set the Admin Approval Mode policy back to Legacy Admin Approval Mode (Default) and restart. If the setting comes from your baseline GPO, change it in the baseline itself. Otherwise the next policy refresh will turn it back on.

In Intune, Microsoft Learn says to create a Settings Catalog policy using the settings under Local Policies Security Options and assign it to a security group. The same settings are available through the LocalPoliciesSecurityOptions CSP as UserAccountControl_TypeOfAdminApprovalMode and UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection.

Monitoring elevations​

Security teams also get new telemetry. Microsoft documents two ETW events under the existing Microsoft-Windows-LUA provider:

• 15031, Elevation Approved: logged when authentication succeeds and elevation is granted.
• 15032, Elevation Denied/Fail: logged when elevation is denied, fails or times out.

According to Microsoft Learn, the logged data includes the user's SID, the app name and path, the outcome, the system-managed admin account that was used, and the authentication method. That's enough to see which apps elevate most often during a pilot, and those are the apps most likely to generate tickets after rollout.

Print driver ranking: smaller scope than it sounds​

The new Configure Windows Ready Print driver ranking setting, under Administrative Templates\Printers, tells Windows to prefer the modern inbox IPP class driver over third-party OEM drivers when it installs new printers. It's a sensible step for anyone who remembers PrintNightmare: fewer third-party drivers in the print stack means less to attack.

The scope is limited, though. Microsoft says ranking applies only when a printer is installed through a connection method that supports IPP, such as USB or network multicast discovery. In those cases, if the printer supports IPP, Windows uses the class driver even if a vendor V3 or V4 driver is available. If the printer doesn't support IPP, or you install it directly as a TCP/IP printer, nothing changes.

Before you assume this tidies up your whole printer estate, check two things: which printer models you own, and how they get installed. Also test any IPP-capable models that rely on vendor-driver features such as finishing options, secure release or custom trays. The class driver may not offer them.

TLS 1.1 is out​

The Turn off encryption support policy now allows only TLS 1.2 and TLS 1.3. Microsoft calls TLS 1.1 obsolete and says the change keeps compatibility with services that support current TLS versions.

The policy sits under the old Internet Explorer path, but it still controls WinINet's secure protocols. For verification, EndpointWeekly suggests reading the SecureProtocols value under HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings before and after deployment. If the value hasn't changed, check for a leftover old-profile assignment or a carried-over customisation. Any old internal appliance that still speaks only TLS 1.1 through WinINet-based clients will stop connecting. That's arguably the point, but find those appliances before your users do.

Packaging and availability​

Availability has been patchy. EndpointWeekly reported that Windows 11 26H2 (build 26300) arrived September 29, 2026, as a small enablement package for devices already on 24H2 or 25H2, and that the baseline wasn't in Intune at launch. The same outlet later reported that Microsoft confirmed on 6 October that the Windows 11 26H2 security baseline is live in Intune.

On the Security Compliance Toolkit side, a commenter on Microsoft's post said on October 7 that no 26H2 version appeared in the download link. The file list quoted in that comment showed Windows 11 v24H2 and v25H2 baseline packages but no v26H2. That's one user's report, not proof the package is missing for everyone. Still, check that you actually have the v2 package before scheduling a change window around it.

Intune also won't move you to the new version on its own. Microsoft's Intune documentation says existing baseline profiles don't upgrade automatically. When you update one, Intune creates a side-by-side copy without scope tags or assignments. Remove the assignments from the old profile once the new one is live, or you'll create conflicts.

Suggested rollout plan​

Based on Microsoft's own guidance:

1. Confirm the package. Make sure you have the v2 26H2 package or the updated Intune baseline version.
2. Compare policies. Use Policy Analyzer from the toolkit, or Intune's version-diff CSV, to see how the baseline differs from what you deploy today.
3. Create exclusion groups for LAPS-managed devices, Hyper-V hosts, Cloud PCs and AVD session hosts before Administrator protection reaches them.
4. Pilot with your heaviest admin users. Developers, helpdesk staff and anyone who elevates regularly. Collect events 15031 and 15032.
5. Test printers by install method. Cover IPP over USB, multicast discovery and direct TCP/IP.
6. Look for TLS 1.1 dependencies in internal web apps and appliances.
7. Roll out in stages, and clean up old baseline assignments as you go.

Bottom line​

The 26H2 baseline is short, but it's the first one to switch on a significant change to Windows privilege elevation, and the change reaches back to 24H2 and 25H2. For organizations whose standard users already lack admin rights, which is the setup Microsoft's baselines assume, most of the impact will fall on IT staff and developers. Everyone else should test it first, because the RDP issue, the LAPS conflict and the separate elevated profiles will all generate helpdesk tickets.