Windows 11 23H2 Enterprise End of Support: Build Your Intune Upgrade Plan for 25H2

On September 15, 2026, Microsoft posted the 60-day countdown notice: Windows 11, version 23H2 Enterprise and Education editions get their last security update in November 2026, then that's it — no more patches, ever, on that version. If you still have 23H2 devices in your fleet, the clock everyone's been ignoring since October 2023 just became a real deadline. Here's how to find those devices, build the Intune upgrade path to 25H2, and actually get unstuck ones moving.

The problem: 23H2's last patch ships in November 2026, and most fleets still have stragglers

Here's Microsoft's own message, word for word, from the Windows message center on September 15, 2026:

The Microsoft Lifecycle page gives the precise cutoff behind that notice: 23H2 Enterprise and Education support ends November 11, 2026 at 6:59:59 AM Pacific Time — the moment the November Patch Tuesday servicing window officially closes for that version. After that timestamp, a 23H2 device that gets compromised through a vulnerability patched in the November update (or any update after it) has no fix coming. Ever. It's not a slow deprecation with warnings for another year — it's a hard stop.

If your organization went all-in on Windows 11 during the 23H2 wave (released October 31, 2023) and never revisited feature-update policy since, you likely have more 23H2 devices sitting around than you think — laptops that missed an upgrade window, devices with a paused or deferred feature update that auto-resumed on the wrong version, or machines that hit a safeguard hold months ago and nobody circled back to check if it cleared.

Why it happens: the Modern Lifecycle Policy, and how 25H2 actually installs

Windows 11 Enterprise and Education follow Microsoft's Modern Lifecycle Policy: each annual feature update version (23H2, 24H2, 25H2...) gets its own fixed support window, independent of the underlying product's overall lifecycle. Enterprise/Education editions get roughly 36 months per version — noticeably longer than the 24 months Home/Pro editions get on the same version, which is exactly why IT-managed fleets can safely stay a version or two behind consumer devices, but not indefinitely.

That's your real planning window if you upgrade straight to 25H2 now: just under two years of runway, versus roughly six weeks left on 23H2. It's worth understanding why upgrading to 25H2 is unusually painless compared to a normal feature update, because it changes how you should plan the rollout.

25H2 isn't a new OS install — it's a switch being flipped

Since Windows 11 24H2, Microsoft ships new feature-update code inside the regular monthly cumulative updates, sitting dormant and disabled. A 24H2 device that's kept current on its monthly updates already has almost all of 25H2's code sitting on disk — it's just switched off. The 25H2 upgrade itself is a small enablement package (commonly called an eKB) that flips the activation flag and completes the upgrade with a single restart, instead of the lengthy full-image install a traditional feature update requires. Microsoft's own prerequisite for this fast path is that the device is on 24H2 and has installed KB5064081 or later.

Where a rollout actually gets stuck: safeguard holds

A safeguard hold is Microsoft's own circuit breaker: when telemetry, partner reports, or internal validation identify a compatibility issue that would cause a specific feature update to fail, roll back, or cause serious harm (data loss, broken key functionality) on a specific hardware/driver/software combination, Windows Update silently withholds the offer from matching devices — even devices you've explicitly targeted with a feature update policy. This isn't a bug in your deployment; it's Microsoft's own protection mechanism working as designed, and it's the single most common reason a "targeted" device just never gets offered the update.

How to verify: inventory your remaining 23H2 devices and check for safeguard holds

Step 1 — Inventory devices still on 23H2 (build 22631)

Windows 11 23H2's build number is 10.0.22631; 25H2 is 10.0.26200. Rather than trusting a stale asset spreadsheet, pull this live from Intune. In the Intune admin center:

That works for a quick manual look, but for a real inventory you want something you can re-run and export. Query it directly with Microsoft Graph:

Any row returned here is a device that will stop receiving security updates on November 11, 2026 unless it moves before then. Save this list — it's your actual migration scope, not an estimate.

Step 2 — Check for safeguard holds before you assume a device is just slow

Once you've created a feature update policy (Step 1 in "The fix" below) and a device still hasn't moved after a reasonable window, check the Feature update failures report before troubleshooting anything else:

1. In the Intune admin center, go to Devices › Monitor.
2. Under Software updates, select Feature update failures.
3. Select your 25H2 feature update profile to see all active alerts for it.
4. Look specifically for the SafeguardHold alert message.

Microsoft's own guidance for this alert says to check the Deployment Error Code column of the report — that value is the specific safeguard hold ID, which you can then cross-reference against the active known issues listed on the Windows release health dashboard. This is the difference between "I don't know why this device won't update" and "I know exactly which known issue is blocking it, and whether Microsoft has already fixed it."

The Feature update failures report surfaces a documented catalog of alert messages, not just this one. Here are the ones you'll hit most often during a 23H2-to-25H2 push:

The fix: build the Intune feature update policy and deployment rings

Feature update policies are a dedicated policy type in Intune, separate from update rings, and Microsoft's current guidance is to use them as the primary mechanism for controlling which Windows version a device can install - not update-ring deferrals.

Step 1 — Create the feature update policy targeting 25H2

1. Sign in to the Intune admin center.
2. Go to Devices › Windows › Windows updates › Feature updates.
3. Select Create profile.
4. Give it a name, e.g. "25H2 - Enterprise migration from 23H2".
5. From Feature update to deploy, select Windows 11, version 25H2.
6. Choose Make available to users as a required update so the device installs it automatically once offered, rather than waiting on end users to opt in.
7. Under Rollout options, configure the staging schedule (see Step 2 below).
8. Select Next, assign the policy to the 23H2 device group you inventoried above, then Review + create.

Step 2 — Stage the rollout instead of pushing everyone at once

Under rollout options, you get three choices. For a deadline-driven migration like this one, Make update available gradually is the right call - it stages the update across time-based batches called offer groups, so a bad interaction on one device model doesn't hit your entire fleet simultaneously:

With those numbers, Windows Update automatically works out how many offer groups to create and randomly assigns roughly equal, minimum-100-device batches to each one - you don't manually pick who's in which group. Given the November 11 hard deadline, back-calculate from that date: leave yourself at least two full weeks of buffer after the final group's availability date for devices that need a retry or a safeguard-hold resolution.

Step 3 — Clean up conflicting update-ring deferrals

This step matters more than it looks. If any of your target devices are still governed by feature update deferrals in an update ring, that deferral can delay or block the exact update your new policy is trying to deliver - this is the PolicyConflictDeferral alert from the verification section, showing up before you even get there.

Don't remove the deferral blindly - follow Microsoft's documented sequencing. In the Intune admin center, go to Reports › Windows Updates › Reports tab, generate the Feature Updates report for your new policy, and confirm targeted devices show a state of OfferReady before you touch the update ring:

1. Create and assign the feature update policy (already done in Step 1). Allow several minutes for Windows Update to process it.
2. Check the Feature Updates report and confirm targeted devices report OfferReady.
3. Only after that, edit the applicable update ring policy and set Feature update deferral period (days) to 0.

Skipping straight to zeroing out the deferral before the feature update policy has finished processing is exactly the sequence that produces a device offered an unintended version - Windows Update evaluates whatever policy state exists at scan time, and a half-applied change can land on the wrong side of that evaluation.

Group Policy path, for devices not managed purely through Intune

If any of your 23H2 stragglers are hybrid-managed through Configuration Manager or still take Group Policy, the same target-version mechanism is available there - it sets the identical registry key underneath, so the two approaches don't conflict as long as you don't configure both for the same device:

1. Open gpmc.msc and edit (or create) a GPO linked to the OU containing your 23H2 devices.
2. Navigate to Computer Configuration › Administrative Templates › Windows Components › Windows Update › Manage updates offered from Windows Update.
3. Enable Select the target Feature Update version.
4. Set Which Windows product version would you like to receive feature updates for? to Windows 11.
5. Set Target Version for Feature Updates to 25H2.

Both the GPO and the Intune CSP equivalent write to the same location, so use one management channel per device, not both:

Proof it worked: confirming devices actually landed on 25H2

Don't rely on the Intune report alone - confirm it on a real device too, then confirm the fleet-wide picture.

Real output from a device that upgraded successfully. The values below are illustrative - reconstructed to show the shape of a genuine result, not copied from a production device:

OsBuildNumber: 26200 is the proof - not the marketing version string, which can lag or be cached. A device still showing 22631 here hasn't actually moved yet, regardless of what the Intune console's last-sync timestamp suggests.

For the fleet-wide picture, re-run the same Graph inventory query from "How to verify," but flip the filter:

Watch that first number trend toward zero as your rollout rings progress, and treat any device still showing up in it after your final offer group date as a real investigation - check it against the safeguard hold and alert catalog above before assuming it's simply slow.

References

• Windows message center — Microsoft Learn (23H2 Enterprise/Education end-of-updates notice, September 15, 2026)
• Windows 11 Enterprise and Education — Microsoft Lifecycle
• Configure Windows Feature Update Policies — Microsoft Intune — Microsoft Learn
• Configure Rollout Options for Feature Update Policies — Microsoft Intune — Microsoft Learn
• Reports for Windows Feature Update Policies — Microsoft Intune — Microsoft Learn
• Policy CSP - Update — Microsoft Learn
• Configure Windows Update client policies — Microsoft Learn