On November 10, 2026, two versions of Microsoft's .NET platform leave support on the same day: .NET 8, the long term release that succeeded .NET 6, and .NET 9, the shorter lived release that followed it. From that date Microsoft stops servicing both: no more monthly updates, no security fixes and no support cases. Applications built on them keep running, but any flaw discovered afterwards stays open.
That matters more for a runtime than for an ordinary application, because a bug in the runtime is a bug in every program built on it. Microsoft's own June 29 announcement put it plainly: whoever stays on an unsupported version is exposed to security holes that nobody will fix. The timing has a twist. November 10 is a Patch Tuesday, so each version may receive one final update that day if a critical issue is already known, and Microsoft's support page lists the launch of .NET 11 for the same week. One release arrives as two depart.
How two releases ended up on one date
Microsoft publishes a major .NET release every November. Even numbered versions are Long Term Support releases with three years of free patches; odd numbered versions are Standard Term Support releases, which Microsoft extended from 18 to 24 months of support. .NET 8 shipped on November 14, 2023, and its 36 months run out on November 10, 2026. .NET 9 shipped on November 12, 2024, and its 24 months end on the same day. .NET 10, released on November 11, 2025, is the LTS successor and is supported into November 2028. Only the most recent patch level of a release qualifies for support, so a server still on an early 8.0 build was already outside the policy before the deadline.
What to inventory
Finding every copy of the old runtime is harder than it sounds, because .NET does not live in one place. Framework dependent applications use the shared runtime installed on the machine, which an administrator can see and update. Self contained deployments carry their own private copy of the runtime inside the application folder, so a server can appear fully patched while an application on it quietly runs an old 8.0 runtime. Container images are the same problem in another wrapper: anything built from an 8.0 or 9.0 base image stops receiving refreshed layers once the runtime goes out of support, no matter how often the image is rebuilt.
The build side needs the same audit. Continuous integration agents often pin an SDK version through a configuration file, and a pipeline that still builds with the 8.0 SDK will keep producing unsupported binaries after November 10. Teams running on Azure App Service or Azure Functions should check which runtime stack each app is pinned to and read the platform's own retirement notices, since hosting platforms retire old stacks on their own schedules. Developer machines count too. Microsoft said in June that a future Visual Studio 2022 servicing release would flag the .NET 8 and .NET 9 components as out of support, and the installer has an option to remove such components, which can strip an SDK a team still relies on.
The migration path
For most projects the mechanical step is small: change the TargetFramework property in the project file to net10.0, then update the development and hosting environments to match. Microsoft publishes a list of breaking changes for .NET 10 and offers its Upgrade Assistant tool for the parts that do not move cleanly. The work is rarely in the project file. It is in third party packages that have no .NET 10 build yet, in behavior changes buried in the breaking changes list, and in the test runs needed to prove nothing regressed. Anyone using a .NET 8 or .NET 9 application they did not write should ask the vendor for a .NET 10 build, Microsoft advised.
Where a migration cannot finish in time, paid extended support exists. HeroDevs, which has sold patches for .NET 6 since that version left support in November 2024, offers the same for .NET 8 and .NET 9 and says its membership of the .NET Security Group gives it advance notice of vulnerabilities so that its fixes can appear on the same day as Microsoft's monthly updates. The vendor itself describes the product as a bridge rather than a destination, which is the right way to treat any such arrangement.
What staying costs
The risk of remaining on .NET 8 or .NET 9 is not abstract. Each security advisory Microsoft issues for .NET 10 after November 10 describes a flaw, and much of the code involved is shared with the older releases. Each advisory therefore doubles as a guide to an unpatched bug on every server that stayed behind, and attackers routinely work backwards from a published fix to a working exploit. Compliance frameworks that require supported software add a second cost, since an audit finding is certain even if an attack is not.
Microsoft's own list of what changes on November 10 is short: the applications keep running, the updates stop and the support line closes. The first item is exactly what makes the other two so easy to ignore.
