New Update Microsoft confirms Windows 11 26H2, urges IT admins to prepare for release

Gandalf_The_Grey

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Forum Veteran
Apr 24, 2016
7,826
6
83,079
8,389
55
The Netherlands
Windows 11 typically follows an annual update cycle, but Microsoft recently broke that tradition a bit by releasing a "26H1" version in the first half of this year as a "scoped" build for select new silicon PCs only. This version was not available for customers using 24H2 and 25H2 builds, as Microsoft is busy preparing version 26H2 for them, confirmed officially for the first time.

In a Windows IT Pro blog, Microsoft has urged IT admins to prepare for the upcoming release of Windows 11 version 26H2. The company has confirmed that this will be a small enablement package (eKB) that will simply light up certain disabled features that are already present in the operating system's code base. This means that the "refined" Windows update and deployment experience will be simpler and quicker, with minimal disruptions, as the feature update will simply toggle a few flags rather than performing a complete replacement.

Microsoft has explained that this is all possible because the standard Windows 11 releases share the same servicing branch and hence, the same source code. However, this also means that Windows 11 26H1 users won't be able to upgrade to 26H2 as that is a different branch, but this is something we have known for a while now.

Similar to previous annual feature updates, Windows 11 26H2 will offer the following support cycles:
  • 24 months of support for Home, Pro, Pro EDU, and Pro for Workstations editions
  • 36 months of support for Enterprise, Education, IoT Enterprise, and Enterprise Multi-session editions
Microsoft has not confirmed a concrete release date for Windows 11 26H2, but noted that it is "coming soon". If we go by the ongoing release cadence, we can expect it to begin rolling out in early October 2026.
 
Microsoft’s IT Pro post is basically confirming that Windows 11 26H2 will be delivered like the recent “enablement package” style releases (a small eKB that turns on features already present), rather than a full in-place feature upgrade.

What “enablement package (eKB)” means in practice
  • If you’re already on the supported baseline that shares the same servicing branch with 26H2, the update experience is typically closer to a regular cumulative update in terms of speed and disruption (smaller download, faster install, fewer migration-style steps).
  • The “new features” are often already in the OS bits, but remain disabled until the eKB flips them on. That also means some behavior changes can still appear after the switch, so testing is still important.
  • From an operational/security standpoint, the big win is predictability: fewer moving parts compared to a full feature upgrade, and usually less chance of upgrade-time failures due to drivers or app migrations.

Important catch: 26H1 vs 26H2 branch split
Microsoft is also reiterating the split you quoted: those select “26H1” builds for new silicon are on a different branch, so they don’t follow the same straightforward path to 26H2. That matters for lifecycle planning if an organization buys hardware that ships with that scoped build—admins may need a different upgrade/reimage approach for standardization.

What IT admins should do now (low-risk, practical)</B]
  • Inventory endpoints by current Windows 11 version/branch so you know which devices are likely eligible for the simple eKB path versus those that aren’t.
  • Validate your update management flow (Windows Update for Business, Intune, ConfigMgr/WSUS) for feature update targeting and rollout rings, since “small” enablement releases can still introduce UI, policy, and feature behavior changes.
  • Pilot on representative devices (especially those with security tooling like EDR, device control, smart card/VPN, and any virtualization or VBS/Memory Integrity settings) before broad deployment.
  • Confirm you’re aligned with the published support lifecycle (24/36 months by edition) so you don’t end up on an approaching end-of-support build.

Bottom line: 26H2 being an enablement package should make deployment easier for the mainstream branch, but it doesn’t eliminate the need for testing, and it makes branch/stock-keeping (especially around 26H1 “scoped” devices) more important.

Sources