.NET 8 end of support on November 10, 2026: what should you do with your application?
On November 10, 2026, .NET 8 and .NET 9 stop receiving security patches. Your application keeps running, but Microsoft will no longer fix new vulnerabilities. What changes, the three options, and where to start the migration to .NET 10.
By Nicolas Cousin — Published on November 4, 2026
In short. On November 10, 2026, Microsoft stops shipping security patches for .NET 8 and .NET 9. Your application keeps running, but Microsoft will no longer fix any vulnerability found after that date. The recommended path is to migrate to .NET 10, an LTS release supported until November 14, 2028, starting with an inventory of your dependencies.
Dates verified on November 3, 2026 against Microsoft's .NET support policy.
What does .NET 8 end of support mean?
End of support is the date after which Microsoft no longer provides fixes, updates or technical assistance for a version. For .NET 8, that date is November 10, 2026.
In practice:
- your application keeps working;
- no new security updates will be released;
- Microsoft technical support ends.
Microsoft states it explicitly: using an out-of-support version may put your applications, their data and your computing environment at risk.
What about .NET 9? It ends on the same day. In September 2025, Microsoft extended support for STS releases from 18 to 24 months, which moved the end of .NET 9 from May 12 to November 10, 2026. Moving to .NET 9 therefore buys you no time.
And older versions? .NET 6 and .NET 7 have been out of support since 2024. .NET Framework 4.8, on the other hand, follows the lifecycle of the Windows version it is installed on, and no end date has been announced.
What changes for security, compliance and dependencies?
Security
The risk is not an outage. It is an exposure that grows with every vulnerability disclosed and left unpatched. Hosting is affected too:
- Microsoft's .NET 8 container images remain available to pull, but no longer receive any updates;
- on Azure App Service, the application keeps running without patches for that runtime; you will have to upgrade to get support again.
Compliance
If a security standard, a regulation or your contracts require you to manage vulnerabilities, a runtime that no longer receives fixes from its vendor becomes hard to justify in an audit.
NuGet dependencies
Microsoft's version 8 libraries, such as Entity Framework Core 8, follow the same schedule: no more fixes after November 10. Your third-party packages have their own pace: some have no version compatible with .NET 10, others are no longer maintained.
What are your options?
| Option | What it involves | When it makes sense |
|---|---|---|
| Stay on .NET 8 | No more Microsoft patches. Paid extended support offers exist from third parties. | As a temporary bridge during the migration, never as a target. |
| Migrate to .NET 10 (recommended) | New target framework, package updates, handling the changes in .NET 9 and .NET 10. | In the vast majority of cases. LTS release, supported until November 14, 2028. |
| Rewrite | New project, new architecture, highest cost and risk. | Rarely. Only if the product needs to be redesigned anyway. |
For an application already on .NET 8, Microsoft describes moving to a newer version as typically a smaller effort than modernizing from .NET Framework.
Should you target .NET 11? .NET 11 is an STS release. As of November 4, 2026, it is at the release candidate stage: RC3, released on October 25, 2026, is already supported by Microsoft for production use, according to its download page, but it is not the final release yet. For a business that values stability, .NET 10 LTS remains the safest target.
Where should you start the migration to .NET 10?
1. Take an inventory of dependencies
Before touching the code, list what the application depends on. The SDK commands give you a first picture:
dotnet list package --vulnerable --include-transitive: packages with known vulnerabilities, including indirect dependencies;dotnet list package --outdated: packages behind their latest version;dotnet list package --deprecated: packages deprecated by their authors.
Then check on nuget.org that each package has a version compatible with .NET 10.
2. Put tests in place first
A migration changes behavior in unexpected places. Without automated tests on critical paths, you will discover those differences in production. If coverage is low, start there.
3. Migrate in batches
Do not switch everything at once. Go project by project, starting with the lowest-level libraries:
- change the target framework from
net8.0tonet10.0and, if the repository has one, updateglobal.json; - move
Microsoft.*packages to version 10; - review the breaking changes of every version you cross, meaning .NET 9 and .NET 10.
.NET Upgrade Assistant is officially deprecated; Microsoft now points to its GitHub Copilot modernization agent. A tool speeds up the mechanical work. It does not replace the inventory or the tests.
Which pitfalls should you anticipate?
- Retired authentication libraries. ADAL has received no security fixes since June 30, 2023; the target is MSAL. IdentityServer4 has been out of support since December 2022. And in ASP.NET Core 10, endpoints recognized as API endpoints (
[ApiController]controllers, minimal APIs) and protected by cookie authentication now return 401 or 403 instead of redirecting to the login page. - Packages with no compatible version. A library that targets only .NET Framework may not work on .NET 10. If a vulnerable package has no fix, you have to replace it.
- BinaryFormatter. Since .NET 9, it always throws an exception, whatever the settings. Jumping straight from .NET 8 to .NET 10 does not let you skip it.
- Code tied to Windows or IIS.
System.Drawing.Commonworks only on Windows. IIS hosting ties you to Windows, and Windows Authentication needs a specific Kerberos setup outside Windows. Worth spotting early if you are targeting Linux containers. - Azure Functions in the in-process model. Its support also ends on November 10, 2026, and it only works with .NET 8. Moving to .NET 10 means migrating to the isolated worker model.
- Stricter NuGet auditing. As soon as a project targets .NET 10, restore also scans indirect dependencies. If your build treats warnings as errors, it may fail on the first attempt.
- No tests. This makes every pitfall above more expensive.
How can you assess the effort before committing?
I offer a Migration audit dedicated to moving from .NET Framework or .NET 8 to .NET 10. It includes everything in the Complete audit, plus an inventory of blocking dependencies and APIs, an effort estimate per module and a migration roadmap in batches. It represents 6 days of work, for €5,500 net, VAT not applicable.
See the Migration audit details or view a sample audit report.
Frequently asked questions
Will my .NET 8 application stop working on November 10, 2026?
No. It will keep working. It will simply no longer receive security patches or support from Microsoft.
Should I move to .NET 10 or wait for .NET 11?
Move to .NET 10. It is an LTS release supported until November 14, 2028. As of November 4, 2026, .NET 11 is an STS release that has not reached its final release, and its end-of-support date has not been published.
My application runs on .NET Framework 4.8: am I affected?
Not by this deadline. .NET Framework 4.8 follows the Windows lifecycle and has no announced end date. A migration to modern .NET remains a larger project, to plan without artificial urgency.