Windows 11 24H2 stops receiving updates a year earlier on Pro than on Enterprise, from the identical build
Windows 11 version 24H2 ends updates on 2026-10-13 for the Pro family and on 2027-10-12 for the Enterprise family, from one table row and one identical build. Count the fleet by edition, not by build, before the earlier date arrives.
Windows 11 version 24H2 on the General Availability Channel ends updates on 2026-10-13 for Home, Pro, Pro Education and Pro for Workstations, and on 2027-10-12 for Enterprise, Education, IoT Enterprise and Enterprise multi-session. Both edition groups run the same build. A managed Pro fleet has under two months of servicing left, and the build number every device reports says nothing about that.
Last verified: 2026-08-20.
What changed
The servicing policy did not move; the calendar did. Microsoft's Windows 11 release information page, read on 2026-08-20, carries one row for 24H2 with two end-of-updates columns:
| 24H2 | General Availability Channel | 2024-10-01 | 2026-10-13 | 2027-10-12 | 2026-08 B | 2026-08-11 | 26100.9168 |
The dates are told apart only by the column headers, which read End of updates: Home, Pro, Pro Education, and Pro for Workstations and End of updates: Enterprise, Education, IoT Enterprise, and Enterprise multi-session. One row, one build cell, two deadlines 364 days apart. The 23H2 row below shows what a passed deadline looks like: its Home and Pro cell now reads the literal string End of updates.
flowchart LR accTitle: Windows 11 24H2 end of updates by edition family accDescr: One availability date fans out into four end of updates dates while every lane reports the identical build 26100.9168, so the build cannot tell an administrator which date applies. O[24H2, available 2024-10-01] --> GA1[Home and Pro, build 26100.9168] O --> GA2[Enterprise, Education, IoT Enterprise, multi-session, 26100.9168] O --> LT[LTSC 2024, other product, 26100.9168] GA1 --> E1[Updates end 2026-10-13] GA2 --> E2[Updates end 2027-10-12] LT --> E3[Enterprise LTSC 2024 ends 2029-10-09] LT --> E4[IoT Enterprise LTSC 2024 ends 2034-10-10] GA1 -->|only in-place target| R[Upgrade to 25H2] R --> E5[Home and Pro end 2027-10-12] T[Today 2026-08-20] -->|under two months| E1
Who is affected
Every device on 24H2 whose edition sits in the Pro family. On a Microsoft 365 Business Premium estate or a batch of OEM business laptops that is most of the fleet, because Pro is the default edition. The Windows lifecycle FAQ records that "Home edition does not support the deferral of feature updates". Deferral is a Pro capability, so the machines still on 24H2 in October are the ones an update ring holds there.
Three readings get this wrong. The first takes the last end-of-updates date in the 24H2 row and plans against October 2027: the row looks like one product with one lifecycle, the split is stated only in long headers a reader skims, and the earlier deadline sits in the left of two date columns, where an eye scanning rightward does not stop.
The second feels better evidenced and is worse. The administrator checks Intune, sees every device reporting build 26100.9168, concludes the estate is uniform, and applies one date to all of it. The build is uniform. Edition is a separate field, and it is the field that decides.
The third looks like diligence: a page search for 24H2 also finds the Long-Term Servicing Channel table, showing 2029-10-09 and 2034-10-10 against that same build. That is a different product under a different lifecycle policy, and even there Enterprise LTSC 2024 "does not have extended support".
What the misreading costs
On 2026-10-14 a Pro device still on 24H2 is no longer offered monthly quality updates. The lifecycle FAQ states the consequence without softening it: once an operating system reaches end of support, "customers will no longer receive technical assistance, software updates, or security fixes".
The audit answer that every endpoint receives vendor security updates then cannot be given, or reconstructed for the months elapsed. The remedy is a rollout to 25H2, needing pilot rings and a maintenance window, so a decision taken on the deadline is weeks late. Moving to 26H1 is no escape route: that version "is not offered as an in-place update from 24H2 or 25H2 on existing devices".
Tenant check
Count devices by edition family. One read-only Microsoft Graph call returns both fields:
GET https://graph.microsoft.com/beta/deviceManagement/managedDevices?$select=deviceName,osVersion,skuFamily,operatingSystem
Each element carries osVersion in the form 10.0.26100.nnnn for 24H2, and skuFamily, which Microsoft documents only as "Device sku family" and for which it publishes no value set, so read the strings your own tenant returns before grouping on them. Group client-side: a Pro or Home family counts against 2026-10-13, and only Enterprise, Education and IoT Enterprise reach 2027-10-12. Identical osVersion values can fall on opposite sides of that split.
The least privileged documented permission is DeviceManagementManagedDevices.Read.All, listed first in Microsoft's List managedDevices reference, in a table headed from least to most privileged. It cannot retire, wipe, sync or update a device.
Where two Microsoft pages disagree
Release health and the lifecycle pages state the same milestone one day apart, on every row of both: release health prints ISO dates, while the Windows 11 Home and Pro lifecycle page prints 10/14/2026 6:59:59 AM for 24H2 under a heading declaring Pacific Time.
| Edition group | Release health, ISO | Lifecycle page, PT | Plan against |
|---|---|---|---|
| Home, Pro, Pro Education, Pro for Workstations | 2026-10-13 | 10/14/2026 | 2026-10-13 |
| Enterprise, Education, IoT Enterprise, Enterprise multi-session | 2027-10-12 | 10/13/2027 | 2027-10-12 |
| Enterprise LTSC 2024 | 2029-10-09 | 10/10/2029 | 2029-10-09, no extended support |
Plan against release health and the earlier date: the offset is systematic rather than a typo, and the earlier date cannot leave a device unpatched. Release health also contradicts itself, giving 36 months in prose to "Enterprise and Education editions" while its own column header names IoT Enterprise and Enterprise multi-session too. The IoT Enterprise lifecycle page settles that in favour of the header, ending 24H2 on 10/13/2027.
Limitations
The call counts devices Intune manages. Machines that are unenrolled, workgroup-joined, inventoried only by Configuration Manager or freshly imaged never appear, so the number is a floor on the exposed population rather than the estate, and the Graph API for Intune requires an active Intune licence.
skuFamily is a beta property, and Microsoft's managedDevice beta reference recommends version 1.0 where possible. There is no version 1.0 alternative: that resource carries osVersion and no edition field. Avoid a server-side filter on the version, which documents no filter operators.
The check proves which edition a device reports, not that it will get a feature update in time: hardware compatibility, update rings, deferral policy and disk space sit between the two. The dates cover the General Availability Channel only, and Windows 11 SE is named in neither release-health header; the Home and Pro lifecycle page carries SE instead, ending 24H2 for it on 10/14/2026 and noting that 24H2 was the last supported version for that edition, so an SE fleet lands on the earlier date with no 25H2 to move to.
Act now
Decision: Act now. A date 54 days out removes security updates from the default edition of a typical business fleet, and the remedy needs pilot rings first. Count the estate by edition family this week, name every Pro-family device still on 24H2, and put its 25H2 rollout in a change window closing before 2026-10-13. Schedule would fit the Enterprise date in 2027, not this one.
The Microsoft 365 management service is the internal path when that count needs an owner and a dated record rather than a screenshot.
Sources and further reading
More from Ops Log
Microsoft 365 E3 gained Defender Plan 1 in July and impersonation protection is still off by default
Microsoft 365 E3 has included Defender for Office 365 Plan 1 since 1 July 2026, but user and domain impersonation protection stays applied to nobody until an administrator configures it. This runbook gives the read-only check that settles whether anything in the tenant is actually enforcing it.
Teams call records left chat retention policies in late April 2026: the replacement policy is PowerShell only
Since late April 2026 a new Teams call data record is covered only by a retention policy for the Teams call logs location, which exists only in PowerShell and reaches nothing created before it went active. The old chat policy stays green. This note gives the read-only check and the boundary of the gap.
An empty Baseline scopes settings page proves nothing about the enforcement rollout
A Conditional Access policy targeting All resources with a resource exclusion now enforces on sign-ins requesting only baseline scopes, and the Baseline scopes settings page renders empty whether or not the rollout reached the tenant. Inventory the policy shape, the only part a read-only call can measure.