.NET 8 and .NET 9 Just Went End of Support. Here's What That Changes

The dates were never a surprise. .NET follows a published cadence: even-numbered releases (.NET 6, 8, 10) get three years of Long Term Support, odd-numbered releases (.NET 7, 9) get eighteen months of Standard Term Support, and Microsoft has posted the end dates on its lifecycle pages since each version shipped. .NET 8 launched in November 2023 as the "safe, boring" LTS choice; .NET 9 launched a year later as the faster-moving STS release for teams that wanted the latest features without waiting for the next LTS. Both deadlines landed on the same day this year, which means two very different adoption cohorts — the "we picked LTS to avoid churn" teams and the "we're always on the latest version" teams — hit end of support simultaneously. Microsoft's guidance is the same for both: move to .NET 10, which is itself an LTS release supported through November 2028, or arrange extended support separately.

What "End of Support" Actually Means Day One

Nothing breaks on November 11. Applications running on .NET 8 or .NET 9 keep running exactly as they did the day before. What changes is quieter and more dangerous: Microsoft stops shipping patches for any vulnerability discovered from this point forward. A newly disclosed flaw in the runtime, ASP.NET Core, or a bundled library now stays open on these versions indefinitely, because there is no supported channel to fix it. Security scanners and compliance audits start flagging the runtime version itself, independent of your own code's quality. For companies in regulated industries, "we're running an unsupported runtime" is the kind of finding that shows up in a SOC 2 gap report or a client security questionnaire, whether or not anything has actually been exploited yet.

Three Ways Teams Get Caught Here

• The upgrade was "next quarter" for three quarters running. .NET major versions ship every November, and the upgrade path from one version to the next is usually straightforward — until a dependency, a third-party package, or a quirky piece of middleware doesn't support the new target framework yet, and the migration gets deprioritized in favor of whatever's on fire that week.
• Nobody owns the runtime version. On a team with real platform ownership, someone tracks lifecycle dates the way they track certificate expirations. On a team where the original builders have moved on and the app is in maintenance mode, the runtime version is whatever it was when it shipped, and nobody notices the support window closed until a security scan says so.
• Third-party dependencies haven't moved either. Some teams are ready to upgrade their own code to .NET 10 but are blocked because a vendor SDK, an internal shared library, or a legacy NuGet package only supports up to .NET 8. That's not a one-sprint fix — it's a dependency-chain problem that needs to be scoped before the upgrade, not discovered mid-upgrade.

An unsupported runtime doesn't fail loudly. It just stops being anyone's job to keep safe, right up until a scanner or an auditor says otherwise.

The Decision This Actually Forces

For a small, actively developed service, upgrading to .NET 10 is usually a contained piece of work: bump the target framework, run the test suite, fix what breaks, ship it. The harder case is the application that's been running quietly for years on a framework version nobody wants to touch, with dependencies that haven't been upgraded in parallel and a test suite that may or may not still reflect how the system actually behaves. That's less an "upgrade the runtime" task and more a "how much of this legacy platform are we willing to re-architect while we're in here" decision, and it's exactly the kind of work that benefits from a custom software development partner who can scope the dependency chain honestly before committing to a timeline, rather than discovering the blockers three weeks into the migration. Teams that treat framework end-of-life dates as a recurring calendar item, instead of a surprise every few years, are the ones who aren't scrambling the week support actually ends.

Questions Worth Asking Before the Next EOL Date

• Which production services are still on .NET 8 or .NET 9, and who is accountable for moving them off?
• Do we know, today, which third-party dependencies would block an upgrade to .NET 10 — or will we find out mid-migration?
• Is there a standing process for tracking framework and library end-of-support dates, or does it only come up when a scanner flags it?

Frequently Asked Questions

When did .NET 8 and .NET 9 reach end of support?

Microsoft shipped the final security and quality updates for both .NET 8 and .NET 9 on November 10, 2026. .NET 8 was a Long Term Support release that launched in November 2023; .NET 9 was a Standard Term Support release that launched in November 2024.

What breaks immediately when a .NET version goes end of support?

Nothing breaks on day one. Applications keep running. What stops is Microsoft shipping patches for newly discovered vulnerabilities in the runtime, ASP.NET Core, or bundled components — so any flaw found from this point forward stays unpatched on that version indefinitely.

What should teams still on .NET 8 or .NET 9 do now?

Microsoft's recommended path is upgrading to .NET 10, an LTS release supported through November 2028. Before committing to a timeline, teams should inventory which third-party dependencies and internal libraries might block that upgrade, since those gaps are usually the real source of delay, not the framework change itself.

Does this affect compliance or security audits?

It can. Security scanners and compliance frameworks increasingly flag the runtime version itself as a finding, separate from the quality of the application code running on it, which means an unsupported .NET version can show up as a gap in a SOC 2 review or a customer security questionnaire even if nothing has been exploited.

Framework end-of-support dates are published years in advance, which makes them one of the few technical risks a team can genuinely plan around instead of reacting to. The teams who treat November's .NET deadline as routine maintenance already knew it was coming. The teams who are scrambling this week are finding out the hard way that "we'll upgrade eventually" isn't a plan.