Intune Has Day-Zero Support for Windows 11 26H2: New…

Windows 11, version 26H2 shipped on September 29, 2026, and Microsoft Intune already has day-zero support for it in the Settings Catalog. That sounds like "everything's ready, go deploy" - it isn't, quite. The Settings Catalog itself is validated and live. The 26H2 security baseline is not, and Microsoft has said so explicitly: it's still finalizing recommendations and expects to ship the updated baseline "over the coming days." Here's what day-zero support actually covers, what's genuinely new to configure, and how to avoid deploying against a baseline that doesn't exist yet.

The short version

Windows 11 26H2 (build 26300) arrived September 29, 2026, as a small enablement package for devices already on 24H2 or 25H2 - most feature code was already sitting dormant on those builds from monthly servicing. Intune's Settings Catalog has day-zero support: every validated 26H2 policy setting is already selectable, right now. The 26H2 security baseline is a separate thing and is NOT yet available - Microsoft's own post says it's still validating recommendations. The single most concrete new control worth configuring today is Administrator protection, a just-in-time elevation feature that replaces standing local admin rights with per-action Windows Hello approval - off by default, configurable now via Settings Catalog or a custom CSP policy, with its own dedicated ETW event log. Scope any 26H2-specific policy with an applicability rule so you don't accidentally push it to your 24H2/25H2 fleet before you're ready.

The problem: "day-zero support" gets read as "everything's ready" - it isn't

Microsoft's own framing, published the same day 26H2 shipped: "Microsoft Intune provides day zero support for validated Windows policy settings in the Settings Catalog." That's a genuinely good thing - historically, admins have had to wait weeks after a Windows feature update before Intune caught up with the new CSPs. This time, the settings are already there.

But "day zero" only describes the Settings Catalog - the raw list of individual policy settings you can pick and configure one by one. It says nothing about the security baseline, which is a different, curated product: Microsoft's own opinionated bundle of "here's what we recommend for most organizations," pre-configured and versioned. Microsoft's security baselines team published their own post the same day with a very specific caveat, worth quoting directly:

Note - quoted directly from Microsoft's security baselines post. "Windows 11 version 26H2 Security Baseline will also be made available shortly in Intune... we are validating the final recommendations and plan to make the updated baseline available over the coming days following the Windows 11, version 26H2 release." The same post lists Configure NetBIOS settings as a recommendation still pending - explicitly called out as "will be added in a future update," not shipped today.

If you go looking for a "Windows 11 26H2" security baseline profile in Intune this week and don't find one, that's not a bug on your end or a delay specific to your tenant. It genuinely isn't published yet. Don't report otherwise to your team, and don't let a generic AI summary or a quick blog skim tell you it's already there - two different Microsoft teams shipped two different things on the same day, and only one of them is actually done.

Gotcha. The Settings Catalog and the security baseline are governed by different validation timelines specifically because they're different products with different risk profiles. The Settings Catalog just needs to correctly expose a CSP that already exists in the OS - low risk, fast to validate. A baseline is Microsoft making a recommendation about what value every setting should have for a "typical" enterprise, which needs broader review before Microsoft is willing to put its name on it as guidance. Expect this gap on every future annual release, not just this one.

Why it happens: what day-zero support actually validates, and what it doesn't

To understand why the Settings Catalog can move faster than the baseline, it helps to know how 26H2 itself shipped, because it's the same "staged activation" pattern Microsoft has used since 24H2.

26H2 is an enablement package, not a new install

Windows 11, versions 24H2, 25H2, and 26H2 all share the same servicing branch. New feature code ships disabled-by-default inside the regular monthly cumulative updates for months before the annual version actually "arrives." The version bump itself - what turns 25H2 into 26H2 - is a small enablement package that flips activation flags for code that's often already sitting on the device. That's why the install is one restart for most eligible 24H2/25H2 devices, not a lengthy full-OS upgrade.

This matters for Intune specifically: because the underlying CSPs for most 26H2 features were already present in Windows before the version number changed, Intune's Settings Catalog team could validate and expose them well ahead of the actual 26H2 release date - which is exactly what "day-zero" describes. The setting existed in the platform; Intune just had to confirm it behaves correctly and turn on the picker.

What's genuinely new to configure, not just newly enabled by default

Most of what Microsoft's own "what's new" documentation lists for 26H2 is features being switched on by default that already existed as opt-in via temporary commercial controls (Windows settings backup, app-specific taskbar actions, File Explorer enhancements). Those don't need a new policy - they need you to decide whether to turn them off if you don't want the new default.

The standout exception - a feature that is off by default, has real security implications, and has a dedicated new CSP you'd actually build a policy for - is Administrator protection. It shipped via KB5120998 and applies to Windows 11 24H2 and 25H2 devices too (it isn't 26H2-exclusive), but it's squarely part of the same wave of controls this post is about, and it's the one most worth your attention this week.

Note - spell it out on first use. Administrator protection replaces the old model where a local admin account carries standing elevated rights all the time. Instead, every signed-in user - even one you've made a local administrator - runs de-privileged by default. When an action genuinely needs admin rights, Windows creates a temporary, isolated admin token tied to a hidden system-managed account, asks the user to approve it via Windows Hello, and destroys that token the moment the elevated action finishes. It's Windows' own answer to "just-in-time admin," similar in spirit to Intune's Endpoint Privilege Management but built into the OS itself rather than delivered as an Intune add-on feature.

How to verify: confirming what's really there in your own tenant today

Step 1 - Confirm the Settings Catalog actually shows the new settings

Devices › Manage devices › Configuration › Create › New policy › Settings catalog

In the Intune admin center, go to Devices › Manage devices › Configuration › Create › New policy.
Choose platform Windows 10 and later, profile type Settings catalog, then Create.
Select Add settings and search for Local Policies Security Options.
Confirm you can find and add User Account Control Type Of Admin Approval Mode and User Account Control Behavior Of the Elevation Prompt for Administrator Protection. If both appear, Administrator protection's day-zero settings are live in your tenant.

Step 2 - Confirm the baseline genuinely isn't there yet (don't assume, check)

Go to Endpoint security › Security baselines.
Look at the list of available baseline types. As of the September 29, 2026 release, you'll see baselines for earlier Windows versions, but no 26H2-specific entry yet.

Gotcha. When the 26H2 baseline does land, don't assume it will look like a strict superset of the 25H2 baseline. Microsoft's own post already flags one behavior change coming with it: the TLS versions the "Turn off encryption support" recommendation targets are moving from TLS 1.1/1.2 to TLS 1.2/1.3. If you've built any custom compliance logic that assumes the old TLS pairing, re-check it once the 26H2 baseline actually ships - don't carry the assumption forward from 25H2.

Step 3 - Confirm which devices are even eligible before you plan a rollout

Administrator protection and the 26H2-specific settings only make sense on devices that can actually run them. Check your fleet's current build distribution with a quick Graph query, the same pattern used to track any Windows version rollout:

PowerShell (Microsoft.Graph module, read-only)

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All" Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'Windows'" -All | Group-Object { if ($_.OsVersion -like "10.0.26300*") { "26H2" } elseif ($_.OsVersion -like "10.0.26200*") { "25H2" } elseif ($_.OsVersion -like "10.0.26100*") { "24H2" } else { "Other" } } | Select-Object Name, Count

Anything reported as 24H2 or 25H2 is Administrator protection-eligible today via KB5120998, independent of whether it's actually moved to 26H2 yet. Anything in Other (23H2 and earlier) needs to upgrade first - Administrator protection isn't backported.

The fix: configuring Administrator protection through Settings Catalog, scoped correctly

Step 1 - Build the Settings Catalog policy

In the Intune admin center, go to Devices › Manage devices › Configuration › Create › New policy.
Platform: Windows 10 and later. Profile type: Settings catalog. Select Create.
Name it, e.g. "Administrator protection - pilot ring".
Under Configuration settings, select Add settings, search Local Policies Security Options, and add:
- User Account Control Type Of Admin Approval Mode - set to enable Administrator protection.
- User Account Control Behavior Of the Elevation Prompt for Administrator Protection - choose consent (a simple approval) or credential (re-enter Windows Hello) prompting.

The same two settings map directly to CSP nodes if you'd rather deploy them as a custom policy instead of through the Settings Catalog picker - useful if you're scripting policy deployment rather than clicking through the console:

./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/

Setting (CSP node suffix)	Configuration path	Behavior
`UserAccountControl_TypeOfAdminApprovalMode`	Settings catalog or custom OMA-URI	Turns Administrator protection on; sets the local Admin Approval Mode to the new profile-separated model instead of classic UAC
`UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection`	Settings catalog or custom OMA-URI	Chooses whether the elevation prompt asks for simple consent or a re-entered credential/Windows Hello check
`UserAccountControl_AllowRemoteLogonWithElevatedPrivilegesForDomainUsersInTheLocalAdministratorsGroupWhenAdministratorProtectionIsEnabled`	Settings catalog or custom OMA-URI	Disabled by default (no elevated remote logon); enable only if a cross-machine remote-admin workflow depends on legacy UAC-style behavior

The Group Policy equivalent is available for hybrid-managed devices that still take domain policy, and it sets the same underlying local security policy - use one management channel per device, not both:

Open gpmc.msc and edit the GPO linked to your target OU.
Navigate to Computer Configuration › Windows Settings › Security Settings › Local Policies › Security Options.
Set User Account Control: Configure type of Admin Approval Mode to Admin Approval Mode with Administrator protection.
Set User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection to your preferred prompt type.
A device restart is required for either method to take effect - it doesn't apply live like most CSP policies do.

Watch out. Administrator protection changes real workflows, not just a registry flag. Microsoft's own troubleshooting notes call out several concrete breakages: apps that expect settings to carry over between the unelevated and elevated profile won't see them; WSL or Visual Studio distros need separate setup in the elevated profile for tasks that require it; Single Sign-On credentials from the standard session are not available inside an elevated session, so domain or cloud auth has to happen again there; and network drives are frequently unreachable from an elevated app unless you install in user context first. Pilot on a small ring before touching a broad security group, and read the full troubleshooting list in the References section before you do.

Step 2 - Scope it so it never accidentally lands on a device you're not ready for

Add an applicability rule to the profile so it only applies to devices actually running 26H2 (build 26300), keeping your 24H2/25H2 pilot separate from a later 26H2-wide rollout if that's how you want to phase it:

Applicability rule - illustrative, scoping to 26H2 only

Rule: Apply this profile if OS version is: Minimum version: 10.0.26300 Maximum version: (leave blank - no upper bound) # A device on 24H2 (10.0.26100) or 25H2 (10.0.26200) is skipped entirely, # even though it's in the assigned group and Administrator protection # would technically work there too via KB5120998.

Tip. Build two separate Settings Catalog profiles instead of one: one scoped to 24H2/25H2 for your early Administrator protection pilot (since the feature already works there via KB5120998), and a second scoped to 26H2 only, for anything that's genuinely 26H2-exclusive once you find it. Keeping them apart means you can turn off the 26H2-only profile without touching your already-running pilot, and vice versa.

Proof it worked: confirming the policy landed and elevation events are logging

Confirm the policy applied on a test device

Command Prompt (Administrator) — after restart

whoami /groups | findstr /i "S-1-5-114 S-1-5-115"

Well-known SID S-1-5-114/S-1-5-115 appearing here confirms the profile-separated admin token model is active

The more reliable proof is watching a real elevation happen and checking that it's logged, not just that a setting shows as applied in the Intune console.

Watch the dedicated elevation event log

Administrator protection has its own new event surface: two Event Tracing for Windows (ETW) events under the existing Microsoft-Windows-LUA provider.

Provider: Microsoft-Windows-LUA — GUID {93c05d69-51a3-485e-877f-1806a8731346}

Event ID	Event name	Meaning
15031	Elevation Approved	User successfully authenticated with Windows Hello and elevation was granted - logs the requesting app, the SID, and the auth method used
15032	Elevation Denied/Fail	Elevation was denied, failed, or timed out - the first place to check when a user reports "the app won't let me install"

Capture a live trace on your test device and trigger one real elevation (install anything that needs admin rights) to see both event types appear:

Command Prompt (Administrator)

logman start AdminProtectionTrace -p {93c05d69-51a3-485e-877f-1806a8731346} -ets logman stop AdminProtectionTrace -ets

Analyze the resulting .etl file in Windows Performance Analyzer, or your existing SIEM pipeline if you already forward ETW traces. A healthy pilot device shows a 15031 for every legitimate install or setting change your pilot users perform, and no unexplained clusters of 15032 - a run of denials from one device usually points to an app that genuinely doesn't work with the new elevation model yet, one of the specific breakages the Watch out callout above named.

Tip. Don't wait for the 26H2 security baseline to arrive before you start this pilot. Administrator protection, its CSP nodes, and its event log are all real and documented today - the baseline is a curated recommendation layer on top, not a prerequisite for configuring the setting yourself. Waiting for the baseline just delays a control you can validate this week.

Intune Has Day-Zero Support for Windows 11 26H2: New Settings Catalog Controls Explained