.NET 8 and .NET 9 are out of support today: what changes and what next

Today, 10 November 2026, .NET 8 and .NET 9 reached the end of their support, as we flagged in our earlier article. If your organisation's software runs on either, you may have seen it in the news or heard about it from a supplier.

The calm answer is that nothing has stopped working, and you have time to act. But the position has changed, and it is worth a short plan. This article explains what is different from yesterday, what is not, and what a sensible next 30 days looks like. It is written as of 10 November.

What changed today, and what did not

What changed. Microsoft's .NET support policy page lists both .NET 8 and .NET 9 as out of support, with 10 November 2026 as the end date. Microsoft's November servicing updates, 8.0.34 and 9.0.23, also came out today, and the policy page lists them as the latest patches for both versions. With support ended, a newly discovered security flaw in those versions will not get an official fix.

What did not. Your applications still run. Nothing switches off, no licence expires and no warning appears on screen. The software that was working yesterday works today.

What builds over time is exposure. Each month, flaws are found in widely used software, and for supported versions they are fixed. For .NET 8 and 9, new flaws will now stay open. Nothing is likely to break tomorrow; the gap between what is known and what is fixed widens slowly, and it matters most for systems that can be reached from the internet.

If you are staying on .NET 8 or .NET 9 for a while, install those updates now. Microsoft's servicing post lists 25 security fixes across .NET, ASP.NET Core and Visual Studio, not all of which apply to every version, and a few need an extra step beyond updating the runtime (a package update, or regenerating code from a template), so read it or ask whoever looks after your hosting to. Barring an exception from Microsoft, it is the last set of official fixes those versions will receive.

Who is affected

Only applications still running on .NET 8 or .NET 9. If yours were moved to .NET 10, you are in good shape: .NET 10 is a long-term support release, supported until 14 November 2028. Applications on the older .NET Framework are a separate question, covered below.

If you do not know which version your software uses, that is the first thing to find out. Whoever looks after your hosting, or a developer opening the project files, can tell you in minutes.

A 30-day plan

You do not need to upgrade everything this week. You do need to make deliberate choices, and write them down.

1. Take an inventory. List every application that might use .NET, including small internal tools, scheduled jobs and integrations that nobody thinks about. Record the .NET version and where each runs.
2. Rank by exposure. Put anything reachable from the internet (a customer portal, a public API, a web form) at the top. Internal-only systems come next, and tools used by one or two people last.
3. Schedule the upgrades. For each system, choose a target and a date. The usual target is .NET 10. Our practical guide to upgrading from .NET 8 to .NET 10 describes how a time-boxed upgrade usually goes, and it is made far safer by automated tests around the behaviour that matters, which we cover in adding tests to code nobody dares change.
4. Add interim controls where an upgrade will take longer. Restrict who can reach the system, keep other layers (the operating system, the database, the web server) fully patched, and make sure monitoring would show something unusual.
5. Note the decision. For any system you are not upgrading yet, record the reason, the date it will be revisited and who owns the risk.

What to tell your board, auditor or insurer

An auditor or insurer will not expect that everything is upgraded on the day support ends. They will expect that you knew, that you assessed the exposure and that you have a dated plan with a named owner. The inventory and the decision log above are exactly that evidence. Our article on what an auditor, insurer or customer will ask about your bespoke software lists the questions in more detail.

What about .NET 11?

.NET 11 was also released today. Microsoft's policy page lists it as a standard-term support release, which is a different category from long-term support, and it gives both .NET 10 and .NET 11 the same end of support date of 14 November 2028. So moving to .NET 11 buys you newer features rather than extra time, and it does not change the advice above: .NET 10 remains the sensible target for most organisations. We previewed .NET 11 on 31 October, and tomorrow we publish a technical piece for developers on what it brings and when it is worth moving.

And .NET Framework?

If your software runs on the older .NET Framework, the picture is different. Microsoft lists .NET Framework 4.6.2 as reaching end of support on 12 January 2027, and our article on still being on .NET Framework covers the dates for each version and your options.

A sensible first step

Ask whoever looks after your hosting, or your developer, one question: "Which of our applications run on .NET 8 or .NET 9, and which of those can be reached from the internet?" A written answer to that, even a short one, is the start of the inventory and the most useful thing you can have in hand.

If there is nobody to ask, or you would like an independent view, a software health audit of one system is a good starting point. We look after .NET systems under our software care service, and you can talk to an engineer at any time.