Windows 11 24H2 stops getting updates today, and your fleet is on the latest build

Today, 13 October, Windows 11 version 24H2 stops receiving updates on Home, Pro, Pro Education and Pro for Workstations. Today is also the second Tuesday of the month: the day Microsoft ships the cumulative update. Those two things land together because they are designed to land together. What does not add up is something else: the machine that falls out of support this afternoon is, technically, fully up to date. It carries the latest published revision of its version. What decides its date is the edition written in its registry, a field almost nobody has recorded anywhere.

One KB in four rows, with four different dates

Microsoft's Windows 11 release information page is a boring table that almost nobody opens in full. It is worth opening in full. This is the part that matters, exactly as it reads today:

The LTSC row carries its own footnote, and it is worth reading before getting excited about 2034: "Windows 11 Enterprise LTSC 2024 edition does not have extended support. It will reach end of updates (also known as end of servicing) on 2029-10-09. Only Windows 11 IoT Enterprise LTSC 2024 will have extended support until 2034-10-10". Two different editions inside the same channel.

The last two rows carry the same build number. Character for character: 26100.9550. The same package, with the same revision date, 22 September. One stops receiving patches today; the other keeps receiving them until 2029, and until 10 October 2034 if it is IoT Enterprise. Eight years apart, between two rows that, as far as the software is concerned, are indistinguishable.

And before anyone objects that KB5124010 was the optional fourth-week preview —it was; it is listed as 2026-09 D, not as the security update— the September security update carries both versions in the title of its own article: "KB5124008 (OS Builds 26200.9445 and 26100.9445)". One article, two versions. This is not an administrative coincidence: 24H2, 25H2 and 26H2 share a servicing branch.

That is why the fix costs one restart. And why nobody has put it in a change window

Sharing a servicing branch means the new version's features travel disabled inside the monthly cumulative updates you are already installing. The enablement package —the eKB— simply flips those switches. The one for 26H2 is KB5121794, it applies on top of "Windows 11, version 24H2 or Windows 11, version 25H2", it requires KB5124010 (the 22 September preview) or a later cumulative update, and its own article sums it up in one sentence: "You must restart your device after you apply this update".

One restart. That is the entire technical cost. Worth saying here that 26H2 is not the only destination: from 24H2 you can also go to 25H2, equally by enablement package, and that buys support until 12 October 2027. It is the conservative route and for many people it is the right one (less novelty landing on a fleet that has just moved); 26H2 buys one more year and the same mechanics. Choosing between the two is a matter of appetite, not of difficulty.

Where this goes wrong is in change governance, not in engineering. No board wakes up for a package that size: change windows open on perceived size. And a change that costs one restart moves exactly the same thing as one that costs a weekend (the version of your entire fleet), with the difference that nobody has looked at this one.

Your inventory records the one field that decides nothing

Three fields are in play, and their order of importance is exactly the inverse of the attention they get.

And then there is the footnote, which is where this gets uncomfortable. Microsoft writes that the Home edition "does not support the deferral of feature updates and will therefore typically receive a new version of Windows 11 prior to the end-of-servicing date shown". Translated: the fleet that is not late for this date is the one with no governance at all, because Windows imposes it. The one running late is the one that does have governance: managed Pro, with deferrals set by somebody who knew exactly what they were doing. It is the same mechanism we wrote about in Memory integrity turns itself on in October, and only where nobody decided anything, seen from the other side: there, the automatic change landed where nobody had decided anything; here, the only place the change does not land by itself is where somebody decided something.

The policy that gave you control is the one keeping you here

Microsoft's Intune documentation on feature update policies says, verbatim, that they let you "lock devices to a specific Windows release" or target a newer version "while preventing devices from moving beyond that version". That is exactly what you wanted in 2024, and it was not a silly thing to want: it is the difference between deciding yourself when the version changes and finding out through a ticket.

On that same page, under the Windows Autopatch heading, sits the sentence worth reading twice: "when a feature update policy no longer applies to a device, that device isn't offered any feature update until one of the following happens", followed by three exits: assign it to another profile, unenroll it from Intune, or remove it from feature update management through the Windows Autopatch Graph API. We state it with the scope the source gives it, which is devices managed by Autopatch; that said, these policies require the Autopatch entitlement and use its orchestration, so the scenario covers a lot of people. A device that drops out of the group a policy targets does not become free: it becomes stuck. And none of that machinery looks at a calendar.

Two more details from the same page that stand on their own. First: if a device is targeted by both a feature update policy and an update ring, Microsoft asks you to set the ring's Feature update deferral period (days) to 0, or the ring will delay precisely what the policy is trying to install. Two of your own controls pulling in opposite directions on the same machine. Second: the editions these policies support are Pro, Pro Education, Enterprise and Education. Home is out. And so is LTSC: "Windows Enterprise LTSC (Long Term Service Channel) isn't supported. Use update ring policies instead".

26H1 is not in this conversation, whatever the number suggests

If you bought new machines in the first half of 2026, some of them may ship with 26H1: build 28000.3086, available since 10 February 2026, with its own cumulative update (KB5124006) and its own end-of-support date (14 March 2028 on Home/Pro). Microsoft says so plainly on the same page: 26H1 "is scoped to support new devices that started coming to market in early 2026 and is not designed as a feature update for existing devices. This version is not offered as an in-place update from 24H2 or 25H2 on existing devices".

A higher-sounding name than 25H2, and a different branch: a whole other build family, 28000 against 26x00. If you sort your fleet by version number, those laptops land in the wrong row.

There is a second clock, and almost nobody has it written down

Two rows further down the same table sits 23H2. On Home and Pro it already reads simply "End of updates": that has happened. But on Enterprise, Education and IoT Enterprise it expires on 10 November 2026. Twenty-eight days from now.

If your fleet is mixed —and almost everyone's is— today is not your only date: it is the date for Pro machines on 24H2. The one for Enterprise machines on 23H2 lands in four weeks. Two fleets, two clocks, and only one of them makes headlines. October is full of these deadlines; we wrote about the other big one this month in Windows 10 and the October toll.

What we would not do

The rehearsal: one machine, one stopwatch, three numbers

It fits in half a morning and it carries over to everything that comes after.

And then the arithmetic, which is the part that turns a rehearsal into a decision: your timed number, multiplied by the number of machines, divided by how many restarts your people can handle at once. That is a window. "We will do it over the weekend" is a guess.

This is how we measure what matters to us. Our last full recovery drill took 14 minutes — an internal figure of ours, a test and not a promise. What makes that figure worth anything is that it exists, it was measured, and we take it again: the day it goes up, we will know something underneath has moved. We say it often about backups, and it holds here too: an untested backup is not a backup, it is a lucky charm.

In short

The good part about 13 October is that this deadline is cheap: a small package and one restart. In a few years, when the jump is again one of those that demands new hardware, we will look back on this date fondly.

The uncomfortable part is that cheap things do not get planned. And what does not get planned ends up happening on a Tuesday, all at once, everywhere.

Sources (checked 13 Oct 2026): the end-of-updates dates, build numbers, the latest-update column, the 26H1 note and the 23H2 and LTSC rows come from Windows 11 — release information (Microsoft Learn, page dated 29 Sep 2026). The 24- and 36-month terms by edition, the Home footnote and the purpose of the LTSC channel come from the Windows lifecycle FAQ. The 26H2 enablement package —source versions, prerequisite and restart— from KB5121794. The quotes on version locking, the behaviour when a policy stops applying, setting the ring deferral to 0 and the supported editions come from Manage Windows Feature Updates (Intune). Every quoted sentence is verbatim from those pages. On human error ranking above hardware in major outages: Oppenheimer, Ganapathi and Patterson, Why Do Internet Services Fail, and What Can Be Done About It?, USENIX 2003. The 14 minutes is an internal figure from a drill of our own: a test, not a contractual guarantee.