Windows 11 26H2 Security Baseline Is Now Available in Intune — What Changed and How to Deploy It

On 6 October 2026, Microsoft updated its Intune Customer Success post with a one-line note: "The Windows security baseline for Windows 11, version 26H2 is now available for all customers in Microsoft Intune." Intune's own What's New page carries the same announcement under the week of 5 October.

That closes the gap flagged here on 30 September, when Windows 11 26H2 shipped with day-zero Settings Catalog support but no Intune baseline yet. The downloadable Group Policy version of the baseline had been out since 29 September. The native Intune version is now live too. Here is exactly what changed, what didn't, and how to move your existing profiles across without breaking anything.

Watch this post — YouTube walkthrough

Windows 11 26H2 Security Baseline in Intune — Migrate Safely

Endpoint Weekly

Watch on YouTube Subscribe at @EndpointWeekly

The problem: nothing in your tenant changed on its own

A new baseline version appearing in Intune does not touch a single device. Microsoft's What's New entry says it directly: "Existing security baseline profiles don't automatically update to the new version."

What does change is the status of your current profiles. The moment a newer version is published, Microsoft's documentation says the settings in profiles based on older versions become read-only. You can still rename them, edit their description, and change their assignments. You can't change a single setting inside them, and you can't create a new profile from the old version.

So if you go to tweak one value in your 25H2 baseline profile this week, you will find you can't. That is not a permissions problem on your account. It is the version lock, and the only way past it is to move that profile to 26H2.

Why it happens: how baseline versions work, and what's actually new in 26H2

A security baseline is not a live feed of Microsoft's recommendations. It is a versioned template. Each version is a frozen bundle of settings and default values. When you create a profile, you are taking a copy of that template at that version, plus whatever customisations you make.

That design is deliberate. It means Microsoft can never silently change a setting on your production fleet. The trade-off is that you have to move each profile forward yourself, and decide for each one whether to keep your own changes.

The two settings that changed

Microsoft's Security Baselines blog post for 26H2 lists exactly two changes since the 25H2 baseline. Everything else carries over unchanged.

Change 1: Windows Ready Print driver ranking

What it does, in plain English: when a new printer is installed, Windows will prefer Microsoft's own built-in driver - the Microsoft IPP Class Driver - over a third-party driver from the printer manufacturer. IPP is the Internet Printing Protocol, a standard most modern printers speak.

Why Microsoft wants it on: third-party print drivers run with high privileges inside the print stack, and they have been a long-running source of serious vulnerabilities. Microsoft's own wording is that enabling it reduces "reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface."

When it actually applies - this is the detail most summaries skip. Microsoft's post says driver ranking only kicks in when a printer is installed through a connection method that supports IPP, "such as USB or network multicast discovery." If the printer doesn't support IPP, "or is installed directly as a TCP/IP printer, there's no change in behavior." It also only affects new printer installs, not printers already on the device.

How to set it outside the baseline, if you need to:

• Intune CSP: ./Device/Vendor/MSFT/Policy/Config/Printers/ConfigureWindowsReadyPrintDriverRanking - integer, 0 = Disabled, 1 = Enabled
• Settings Catalog: Printers › Configure Windows Ready Print Driver Ranking
• Group Policy: Computer Configuration › Administrative Templates › Printers › Configure Windows Ready Print driver ranking. It is a new setting, so it only appears once your Group Policy central store has administrative templates that include it.

Change 2: Turn off encryption support (TLS 1.2 and TLS 1.3 only)

What it does, in plain English: this policy controls which versions of TLS - the encryption that protects web traffic - are allowed for connections made through Windows' old Internet Explorer networking component, called WinINet. Its internal Group Policy name, Advanced_SetWinInetProtocols, gives that away.

What changed: the 25H2 baseline allowed TLS 1.1 and TLS 1.2. The 26H2 baseline allows TLS 1.2 and TLS 1.3. Microsoft's reasoning: "TLS 1.1 is now considered obsolete and is no longer recommended for enterprise environments."

Who could notice: anything that connects through WinINet to a server that only speaks TLS 1.1. In practice that means old internal web apps, ageing appliances with built-in admin pages, and legacy line-of-business software. A modern site that supports TLS 1.2 will not notice anything.

• Intune CSP: ./Device/Vendor/MSFT/Policy/Config/InternetExplorer/DisableEncryptionSupport (a User-scope node also exists) - ADMX-backed
• Group Policy: Computer Configuration (or User Configuration) › Administrative Templates › Windows Components › Internet Explorer › Internet Control Panel › Advanced Page › Turn off encryption support
• ADMX file: inetres.admx

What's deliberately missing: Configure NetBIOS settings

Microsoft's 29 September note already flagged NetBIOS as "pending", and it did not make this release. The What's New entry explains why: the policy "is currently supported only on Windows Insider builds." Microsoft plans to add it in a future baseline update once it is available on supported, in-market Windows versions and in the Settings Catalog.

That means a further 26H2 baseline update is already expected. When it lands, your profiles will go read-only again and you will repeat the process below.

How to verify: find out which version your profiles are on

Before you change anything, get a list of every baseline profile in the tenant and the version each one uses.

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security › Security baselines.
3. Look at the Security Baseline for Windows 10 and later row. The Last Published date should now be early October 2026.
4. Select that baseline, then select Versions. This shows which versions your profiles are on and how many profiles use each one.
5. Select Profiles. Any profile on an older version shows an arrow icon telling you a newer version exists.

Here is the kind of picture you are looking for. The profile names below are examples - yours will differ:

Next, check the two changed settings in each old profile. Open the profile, go to Properties, and expand Configuration settings. Note whether you ever customised either "Turn off encryption support" or anything under Printers. This matters in the next section.

Finally, capture a "before" picture on one pilot device, so you have something to compare against later. This command, run in an elevated PowerShell window, lists what the encryption support policy has currently written to the registry:

You don't need to decode the number. You only need to see it change after the 26H2 baseline lands, which is your proof the new TLS setting arrived.

The fix: move to the 26H2 baseline safely

You have two ways forward. Microsoft's documentation supports both.

• Update the existing profile - best when you've customised your baseline and want to keep those changes.
• Create a brand-new profile - best when you never customised it, or want a clean start.

Either way, the update creates a new, side-by-side profile. Your old profile is left exactly as it was, still assigned, still applying.

Option A: update an existing profile (keeps your customisations)

1. In the Intune admin center, go to Endpoint security › Security baselines › Security Baseline for Windows 10 and later.
2. On the Profiles page, tick the checkbox next to the profile you want to move, then select Update Version.
3. On the Update Version pane, choose Accept baseline changes but keep my existing setting customizations. (The other option, Accept baseline changes and discard existing setting customizations, gives you a pure default 26H2 profile.)
4. Select Create. This opens the upgrade workflow for the new profile.
5. On Basics, give it a clear name, for example Baseline - Corporate devices - 26H2.
6. On Configuration settings, check the two changed settings by hand. Search for encryption support and driver ranking and confirm each shows the value you expect.
7. On Scope tags, re-add the same scope tags the old profile had. They are not copied.
8. On Assignments, assign it to a pilot group only for now.
9. On Review, select Create. Microsoft notes that once saved, the profile immediately deploys to its assigned groups.

Option B: create a fresh 26H2 profile

1. Go to Endpoint security › Security baselines and select Security Baseline for Windows 10 and later.
2. Select Create policy. New profiles always use the latest version, which is now 26H2.
3. On Basics, enter a name and description.
4. On Configuration settings, review the defaults and change only what your environment genuinely needs.
5. Add Scope tags, then Assignments to a pilot group.
6. On Review + create, select Create.

Then: pilot, cut over, clean up

1. Pilot for at least a few days on devices that represent your real estate. Test two things specifically: any internal web app or appliance page that might still be TLS 1.1 only, and installing a USB or auto-discovered network printer to confirm the Microsoft IPP Class Driver covers what your users need.
2. Cut over one group at a time. Add a production group to the new 26H2 profile and, in the same sitting, remove that same group from the old profile.
3. Clean up. Once the old profile has no assignments left, Microsoft says you can delete it. Keeping it unassigned for a week or two first gives you a quick reference if something needs comparing.

Proof it worked

Check three places once the pilot devices have checked in.

1. Versions view: go back to Security Baseline for Windows 10 and later › Versions. As you cut over, the profile count on 26H2 should rise and the count on older versions should fall to zero.
2. Device status: open the new profile and review its device and per-setting status. Healthy pilot devices report Succeeded. Any setting showing Conflict almost always means the same device is still assigned to the old profile as well.
3. On a pilot device: re-run the registry check from the verify section. The SecureProtocols value should now differ from the "before" number you wrote down.

For printing, install a test printer over USB or via network discovery on a pilot device. If the printer supports IPP, its driver should show as the Microsoft IPP Class Driver in the printer's properties. Remember that printers added directly by TCP/IP address are not affected, so don't use one of those as your test.

References

• Microsoft Intune Settings Catalog updated to support Windows 11, version 26H2 - Intune Customer Success blog; the 6 October update note confirming availability.
• Windows 11, version 26H2 security baseline - Microsoft Security Baselines blog (29 September); the official list of changes and the print driver ranking scope details.
• What's new in Microsoft Intune - week of 5 October 2026; no auto-update, and why NetBIOS was left out.
• Learn about Intune security baselines for Windows devices - available versions and the read-only rule for older versions.
• Configure security baseline policies in Microsoft Intune - the Update Version workflow, and what is and isn't carried over.
• Windows security baseline settings - version 26H2 - the full list of settings and defaults.
• InternetExplorer Policy CSP - the DisableEncryptionSupport node and its Group Policy mapping.

Microsoft MVP community deep-dives

Related on EndpointWeekly

• Intune's day-zero support for Windows 11 26H2 - the Settings Catalog side of 26H2, and the Administrator protection pilot.
• The Windows 11 25H2 security baseline in Intune - the previous version, if you are still migrating from 24H2 or earlier.