.NET 8 and .NET 9 end of support: a plan for healthcare and finance

Published 22 October 2026 · dotNew Labs

Microsoft stops supporting .NET 8 and .NET 9 on November 10, 2026. Apps on either version keep running, but they stop getting security fixes. For teams that handle patient or financial data, that turns into an audit finding sooner or later. Here is what changes and a practical way to deal with it.

Support windows for current .NET releases. .NET 8 and .NET 9 end on the same day.

What actually changes on November 10

No more security patches for the .NET 8 or .NET 9 runtime, ASP.NET Core or Entity Framework Core on those versions.
Nothing breaks that day. The risk grows each month, as new vulnerabilities are found and stay open.
Security scanners start flagging the runtime as end of life, and cloud hosts eventually retire old runtime stacks.

Why regulated teams feel it first

HIPAA's Security Rule asks you to manage reasonably expected risks. PCI DSS asks for critical patches within a month. Bank examiners ask how you handle end-of-life software. Unpatchable software sits badly with all three. You can accept the risk on paper for a while, but someone has to sign that, and it needs a dated plan behind it.

Which versions are affected

What your app runs on	Status
.NET 8, .NET 9	Support ends November 10, 2026
.NET 5, 6, 7, .NET Core 3.1	Already out of support
.NET Framework 4.6.1 and older	Already out of support
.NET Framework 4.8 / 4.8.1	Supported with Windows, but no new features and tied to Windows servers
.NET 10	Current long-term support release, supported to November 2028

Step 1: find out what you run

In each project file, look at <TargetFramework>. net8.0 and net9.0 are affected.
On each server, dotnet --list-runtimes shows the installed runtimes.
Check container base images, Azure App Service or AWS runtime settings, and build pipelines.
Don't forget the small things: scheduled jobs, internal APIs and admin tools often get missed.

Step 2: sort apps by risk, not by size

Start with apps that face the internet or touch patient, member or account data. An internal report tool with no outside access can wait a few weeks. A patient portal cannot.

Step 3: upgrade, then prove nothing changed

Moving from .NET 8 or 9 to the current version is usually modest: change the target framework, update packages, fix the breaking changes Microsoft lists.
Tools like GitHub Copilot app modernization help with the code changes.
The real work is proving behavior didn't change: business rules, reports, logins and integrations. Test old against new with real examples before go-live.
Apps still on .NET Framework, WebForms or WCF are a bigger move. Write down what the app does before you rebuild it.

Step 4: if you can't finish in time

Many teams won't finish every app by November 10. That's normal. Record the risk, put compensating controls in place (network limits, a web application firewall, closer monitoring), and set a dated plan your security officer and leadership sign. An auditor can work with a signed plan. An app nobody knew about is much harder to explain.

Not sure where your apps stand?

We offer a free 20-minute scan of one app: what it runs on, what's risky, and the shortest safe path forward. You keep a short written summary whether or not you hire us.

Book a free scan

Or email contact@dotnewlabs.ai