On 17 May and 19 June 2027 the certificates your machines use to trust Windows Update expire, and the replacement travels inside a monthly update: "Devices must contain the replacement certificates to continue connecting to Windows Update and receiving updates after the applicable expiration date", says Microsoft's MC1491763 advisory, dated 8 October. The press has covered that already. What we have not seen anywhere is the consequence that worries us: a restore brings a machine back with the update level it had on the day of the backup. The server you bring up in 2027 from a March 2026 image boots without the certificate, runs perfectly well, and cannot update itself.
Which of the two dates applies to you depends on what you have installed, and we get to that in a moment. First, what this is not: there is no bug here, no CVE, nothing to exploit. It is the ordinary rotation of a certificate authority, the kind of maintenance that usually happens without anyone in the company noticing it happened. It passes unnoticed while the machine is powered on and current. The ones that have been switched off for months are a different conversation, and that is the one this post is about.
The five families and their minimum update
This is the table to have in front of you, with the requirements exactly as Microsoft publishes them. Read it row by row rather than by intuition, because intuition fails here.
The asymmetry that does not add up at first glance
Look at the two middle rows again. Windows 11 24H2 and Windows Server 2025 require the September 2025 update; everything else requires July 2026. The newest platform carries the oldest requirement, and the veterans the most recent one. If you reason "the new stuff will be covered, it is the old stuff I worry about", you are right by accident: the bar for the new machines sits ten months lower, so almost any Server 2025 powered on in the last year clears it. The bar for the rest sits in July of this year — four months ago. A laptop that stopped updating in March 2026 is in the non-compliant group, and nothing on its screen says so.
What this is not
Three limits before we go on, because the easy headline is "millions of machines will stop getting updates" and the facts support less than that.
- It does not brick the machine. The advisory says so itself: if an in-support device arrives late, the update is obtained from the Microsoft Update Catalog or distributed through your usual management tools. The destination is the same; what changes is who does the driving. It stops being something that happens by itself overnight and becomes a task with a name, a surname and one visit per machine.
- If you patch monthly, you do not have to do anything. And it is worth saying out loud, because the noise the advisory generated suggests otherwise. Any in-support machine that has taken its July 2026 cumulative or any later one already carries what it needs.
- WSUS is out of scope. Microsoft puts it plainly: "This change does not apply to devices receiving updates from Windows Server Update Services (WSUS)". That is good news and also a map: the change affects whatever talks directly to Windows Update. In a mid-sized estate that is almost never the servers in the cabinet; it is the laptops that travel, the branch machine, the box somebody spun up "to test", and the template you clone from.
The assumption that breaks
Every patching plan is sized around an idea nobody writes into the procedure because it is taken for granted: a machine that falls behind catches up on its own the day you switch it on. It will take a while, ask for two reboots and complain, but the path is there and it needs nobody. On those two dates, for whoever arrives late, that path is cut: the certificate it needs in order to talk to Windows Update sits inside an update you download from Windows Update.
The inventory nobody has: the machines nobody switches on
The list below comes from no advisory. It comes from what we find when we walk into an estate to do the inventory properly, and over the next seven months every line on it is a candidate for falling out of the channel:
- Templates and golden images. A template sealed in spring 2026 will still be cloning, in 2028, machines born without the certificate. And the first thing a freshly cloned machine does is go looking for updates.
- Powered-off virtual machines. The one left over from a migration "just in case", the vendor appliance nobody owns any more, last fiscal year's box that gets booted twice a year for one query.
- Shop-floor and warehouse machines. The PC driving a production machine, running an LTSC version put there precisely so nothing would ever change. Note which row of the table it falls into: the 17 May one, a month before the rest.
- The laptop that comes back. From long-term leave, from a drawer, from someone who was away for two quarters. It comes back with the update level it had the day it was put away.
- And the one you bring up in a drill. We give this one its own section below, because it is the one we think is serious.
A backup returns the machine with its date inside it
This is not in Microsoft's advisory: it is our reading, and we label it as such. A restore does not return "the machine": it returns the machine as it was on the day of the backup, and that includes its update level. We treat it as obvious when we talk about data — nobody expects to recover yesterday's file from a month-old backup — and we forget it when we talk about the system.
Now add the dates. If in autumn 2027 you run a recovery drill and bring up a full server image taken in March 2026, that machine boots into a world where the certificate it knows how to speak with has already expired. It works, it serves, it does its job, and it cannot update itself. In a drill that is an anecdote you find and fix. The day it is not a drill, it is a freshly restored production machine that somebody has to go and hand-feed the missing cumulative while the phone rings.
Procedure fixes this, and it costs almost nothing: one more line in the post-restore runbook — check the update level before calling the machine good — and a pass over your templates before May. What is expensive is finding out on the day of the incident. It is the same idea we keep repeating: failure is inevitable, an outage is a design decision.
The real calendar, in order
The two 2027 dates do not stand alone. Two earlier ones shape them, and one of those falls in thirteen days:
- 10-11-2026. End of servicing for Windows 11 23H2 on Enterprise, Education and IoT Enterprise. A machine on that version needs the July 2026 update or later, and it has one monthly delivery left to pick it up the normal way: the 10 November one, which is the very day its support runs out. After that it moves to the bottom row of the table. We already wrote about the four rows of the Windows 11 calendar and their four different dates, which is the same conversation with different figures.
- 12-01-2027. End of extended support for Windows Server 2016. From then on there are no more monthly updates without paying for an extension, and its certificate cut-off is 17 May, four months later: the window to get it in order closes before the date in the advisory. If that is you, here is what you pay to keep receiving patches on a Windows Server 2016.
- 17-05-2027. The certificate expires for Windows 10 Enterprise 2019 LTSC, Windows Server 2019 and Windows Server 2016. It is the early date, and it lands on the machines that get touched least.
- 19-06-2027. The certificate expires for everything else in support.
The five things we would look at this week
- 1. Inventory by date of last cumulative. Nearly every inventory answers "which version does each machine run". The figure that decides this is a different one: when it installed its last cumulative. On a single machine you check it by comparing the build revision — the number after the dot in
winver— against the one Microsoft published for July 2026 in that version's update history. Across an estate, your management tool's update report already has the column. - 2. Pull the list of the ones that do not report. The risk is what is missing from the report, not what shows up in it. A machine that has not talked to the console in ninety days is unpatched, even if the screen files it under "no data".
- 3. Reseal your templates before May. Every template, deployment image and base disk gets an update pass and is resealed. In an estate with three or four templates that is one morning, and it saves you a whole class of future problem.
- 4. Add the line to the restore runbook. "Check the update level and apply the current cumulative before returning the machine to service." If your recovery plan already has a checklist, this is one line.
- 5. Split out the May batch. Windows Server 2016, 2019 and Windows 10 Enterprise 2019 LTSC — the ones not behind WSUS — run a month ahead of the rest, and they are almost always the machines with the smallest maintenance window in the estate. Treating them as their own batch rather than as "everything else" is what stops them being left until last. And it is worth remembering that the WSUS exclusion protects you while WSUS is there: the day a machine points back at Windows Update, it is back inside the perimeter.
In short
A certificate rotation is boring maintenance and normally nobody notices it. What makes it interesting is the order in which things happen: the replacement travels down the same channel that closes, so the date that matters is the one on your last cumulative, not the one in the advisory. Whoever knows which machines are switched on, which are not, and what date each backup carries inside it will handle this. A more expensive tool will not.
Where this fits into what we do
When we build a modern workplace, the visible part is identity and applications; the part that decides weeks like this one is underneath: an inventory that tells the truth, an update cadence that is met without heroics, and the always-awkward list of machines that do not fit the mould. The other half is compliance and continuity: a system that cannot receive patches is an audit finding before it is a technical problem, and the restore runbook is where that gets fixed, not in a new tool. If you want us to look at your estate by date of last update rather than by version, let's talk: you get a table and a list of orphans, and sometimes the list is empty and we say so.
Sources (verified on 28 October 2026): advisory MC1491763, "Prepare for Windows Update certificate rotation in 2027", published 8 October 2026 — expiry dates of 17 May and 19 June 2027, per-family requirements (none for Windows 11 25H2 and later; September 2025 for Windows 11 24H2 and Windows Server 2025; July 2026 for the rest in support, with 17 May applying to Windows 10 Enterprise 2019 LTSC, Windows Server 2019 and 2016), the sentence "Devices must contain the replacement certificates…" and the exclusion of devices served by WSUS; carried by Microsoft's Windows IT Pro Blog, Help Net Security (12 Oct 2026) and PCWorld. End of servicing for Windows 11 23H2 on Enterprise, Education and IoT Enterprise on 10 November 2026 — Microsoft lifecycle. End of extended support for Windows Server 2016 on 12 January 2027, with the January 2027 update being the last — Windows Server blog. The reading about templates, powered-off machines and restores is ours, and it is flagged as such in the text.
How many machines do you have that have not talked to anyone in ninety days?
If the answer is "I could not tell you", that is an afternoon's work and half of this problem. We pull the inventory by date of last update, split the May batch from the June one, and tell you which templates need resealing. With whatever tool you already have.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN