Is Your System Running .NET 8? Security Updates Stop on November 10

Is Your System Running .NET 8? Security Updates Stop on November 10

On November 10, 2026, Microsoft stops shipping security updates for two versions of .NET on the same day: .NET 8 and .NET 9. After that date, any vulnerability discovered in the platform will not be patched on either version. If your accounting system, point of sale, or ERP is built on one of them — and in the Saudi market many are — you have under two months to decide where you are going. For most businesses the right destination is .NET 10, supported through November 14, 2028, not .NET 11, whose first release candidate landed only two days ago.

What happened on September 8

On September 8, 2026, Microsoft announced that .NET 11 had reached Release Candidate 1, carrying a go-live support license — meaning Microsoft officially supports running it in real production before the final release ships. The same day, routine servicing updates went out for .NET 10, .NET 9, and .NET 8.

That is the technical news. The news that matters to a business owner sits on an entirely different page: the official support policy page, updated the same day, which states plainly that .NET 8 and .NET 9 leave support on November 10, 2026. The glossy release announcement gets the attention; the line that costs you real money is written in a boring table.

Why a "long term support" release runs out of support

Microsoft ships a major .NET release every November. Even-numbered releases are long term support and get three years of free patches; odd-numbered releases are standard term support and get two.

.NET 8 shipped on November 14, 2023, so its three years expire in November 2026. .NET 9 shipped on November 12, 2024, so its two years expire at roughly the same moment. That is why both fall on November 10. This is where teams get caught out: "long term support" does not mean supported forever. It means three years counted from release day, and a good deal of that clock has already run while nobody was watching it.

The right target is .NET 10, not .NET 11

The reflex response to news like this is "then we will upgrade to the newest one." For most business systems that is the wrong call, and the reason is in the same support table.

.NET 10 shipped on November 11, 2025, is a long term support release, and is supported through November 14, 2028. One upgrade buys you just over two years of stability without reopening the file. .NET 11 is an odd-numbered release, so it carries only two years of standard support and will fall out of support before .NET 10 does, despite being newer. Upgrading to a newer version that expires sooner is not an upgrade — it is a deferral with an extra invoice attached.

There is a second consideration. The .NET 11 release candidate itself is supported only through October 13, 2026, because it is a transitional build you are expected to move off — to the next candidate, then to the November release. Anyone who reads "go-live" as an invitation to install a release candidate into an accounting system and leave it there has signed up for a monthly upgrade cycle rather than escaping one.

The practical rule for a company running accounting or operational software: always target the even-numbered long term support release. Leave the odd-numbered ones to product teams that upgrade continuously and want features early.

What .NET 11 actually brings

So the decision rests on knowledge rather than avoidance, here is what the release candidate carries. In C#, version 15 stabilized union types — a clearer way to express a value that can take more than one shape, such as an operation that either succeeds or fails for a specific reason. In tooling, the test command improved its handling of mobile applications and added run-level controls.

In container publishing, image generation is now reproducible and skips re-uploading layers that already exist, which shortens deployment time and makes auditing what you shipped easier. In package management, updating packages with known vulnerabilities now works even when warnings are treated as errors — an old snag that used to force teams to disable the security check just to get a build through. In ASP.NET Core, the SignalR authentication refresh APIs were finalized, and Blazor Server circuits now update their state after a refresh instead of holding a stale identity. In-process crash reporting arrived on Unix systems, which means better diagnostics when a server falls over at three in the morning.

These are genuine improvements. None of them outweighs the risk of running a financial system on a version that expires sooner than the alternative.

Why this is a compliance file, not a technical one

Running a platform that no longer receives security patches is not a matter of engineering preference. The Personal Data Protection Law obliges any organization handling customer data to apply appropriate protective measures, and any serious security review will ask which platform version you run and when its support ends. "We are on a version that went out of support eight months ago" is not an answer you can defend in front of an auditor, an enterprise client sending you a security questionnaire before signing, or a cyber insurer.

The same applies to e-invoicing systems connected to the Fatoora platform. A system that digitally signs invoices and transmits them to a government authority needs to sit on a platform that still receives cryptographic patches. This is not an internal detail — it is part of the chain of trust your invoice rests on.

An action plan between now and November

• This week — find out where you stand. Ask your vendor or technical team for an inventory of the .NET version behind every system you run, including the small internal tools and background services nobody thinks about. On a server, dotnet --list-runtimes shows it; in the project itself, it is the target framework entry in the project file.
• Next week — triage. Flag everything on .NET 8 or older and everything on .NET 9. Anything already on .NET 10 is safe until 2028. Anything on .NET 6 or 7 has been out of support for years and needs urgent handling, not a schedule.
• Within two weeks — read the breaking changes. Microsoft publishes a breaking changes list for every release. Moving from 8 to 10 is usually smooth, but reading before you start saves days.
• Within a month — upgrade the test environment first. Change the target framework, build, run the tests, then run the system against a copy of real data before anything else.
• Before November — deploy. Leave at least a two-week safety margin ahead of November 10, and do not deploy on a month-end close or during a peak sales season.
• Once, permanently. Put November 14, 2028 in the company calendar today and set a rule: every upgrade goes to the next even-numbered release. That turns this from an annual surprise into a known budget line.

If the system came from a vendor

Many companies do not own the source code; they buy a finished system from a supplier. In that case the single email you send today asks three things: which .NET version does the system run on, when will you ship a build on .NET 10, and is the upgrade covered by our support contract or billed separately. How your vendor answers tells you more about the product than any presentation will. And a vendor who does not know the answer, or stalls, is the same one you will be calling on November 11.

Sources

• Microsoft — Announcing .NET 11 Release Candidate 1, September 8, 2026: devblogs.microsoft.com
• Microsoft — official .NET support policy and end-of-support dates: dotnet.microsoft.com
• Microsoft — Breaking changes in .NET 11: learn.microsoft.com
• Saudi Data and AI Authority — Personal Data Protection Law: sdaia.gov.sa