.NET 8 and .NET 9 End of Support: The Business Risk You Need to Assess Now

An application can work perfectly, support every essential workflow, and still carry a risk that no operational dashboard makes obvious: the platform it runs on is approaching the end of its security support lifecycle.

That is the situation for organizations that still depend on .NET 8 or .NET 9. Microsoft has set November 10, 2026 as the end-of-support date for both versions. The applications will not stop running because a date passes. But after that date, those release lines will no longer receive new security fixes or technical support from Microsoft.

On October 25, 2026, the situation became more urgent. Microsoft published out-of-band security updates for .NET 8, 9, and 10, including a vulnerability related to the processing of Brotli-compressed data.

Together, those announcements deserve leadership attention. The responsible response, however, is not to authorize an immediate rewrite or require every team to move to .NET 10 without assessing the consequences.

The more important question is: which systems are actually exposed, which require immediate remediation, and how can we update the environment without interrupting the operations the business depends on?

What Ends on November 10, 2026 — and What Does Not

Microsoft follows different support policies for long-term support (LTS) and standard-term support (STS) releases. Although they fall into different categories, .NET 8 and .NET 9 reach end of support on the same date.

The dates are listed in Microsoft’s official .NET lifecycle policy. Microsoft has also published a specific notice about the end of support for .NET 8 and 9.

End of support is not an automatic shutdown. It means Microsoft will stop issuing new security fixes, servicing updates, and technical support for those release lines after the announced date. Risk can increase as new vulnerabilities are discovered.

That does not mean every application suddenly becomes exploitable the next morning. Nor does moving to .NET 10 automatically make an application secure. Actual exposure depends on application code, libraries, hosting, features in use, and the patches that have truly been deployed.

It is equally important not to confuse .NET 8/9 with .NET Framework 4.x, which has a separate lifecycle and support rules. An inventory that labels both products simply “.NET” can lead to a poor decision.

Why the October 25 Security Advisory Changes the Priorities

Microsoft’s October 2026 out-of-band security update announcement identifies these releases:

Among the issues addressed, the advisory lists:

• CVE-2026-111497: a memory corruption vulnerability involving Brotli decompression. Depending on the usage pattern and exploit conditions, it may allow an attacker to read or corrupt memory, cause denial of service, or elevate privileges. Relevant surfaces include compression APIs, ASP.NET Core request decompression, and automatic decompression of HTTP responses.
• CVE-2026-114148: unsafe ownership and permission metadata in certain Linux tarball artifacts. Its impact depends on the distribution type and source; it should not be treated as equally applicable to every .NET application hosted on Linux.

Microsoft notes that some request and response decompression mechanisms are not enabled by default. The advisory therefore does not justify claiming that every .NET service is exploitable. It does justify checking which scenarios apply and deploying the official security fixes according to the exposure identified.

The announcement also mentions additional fixes for security advisories that required re-release. Organizations that applied the regular October 13 updates should therefore not assume that those installations already contain the October 25 out-of-band fixes.

The key distinction is this: end-of-support planning and active vulnerability response are two separate activities, with different timelines.

The first calls for a modernization strategy. The second may require immediate action, including on applications that already run .NET 10.

Does Your Business Use .NET 8 or 9? Source Code Alone Cannot Tell You

A repository inventory is useful, but it does not necessarily reveal what runs in production. A project may target net10.0 while an older release continues serving customers on a server that has not been updated for months.

Likewise, finding .NET 10 installed on a host does not prove that every application on that host has been upgraded.

To establish real exposure, we must connect what was built, what was published, and what is currently executing.

1. Identify the Applications Actually in Operation

Start with the applications and services people really use: APIs, ASP.NET Core websites, desktop software, scheduled tasks, Windows services, message consumers, distributed executables, and third-party components.

Include staging and disaster-recovery environments when they contain actual business data, remain accessible, or supply artifacts that will later be promoted to production. Do not overlook old instances that still serve a particular integration.

For each system, record its business owner, technical owner, purpose, criticality, hosting location, and distribution model.

2. Distinguish the SDK, Target Framework, and Runtime

These concepts are related but are not interchangeable.

• SDK: the tools used to build, test, and publish software.
• Target framework: identified in the project by TargetFramework or TargetFrameworks; it defines the APIs against which the application is built.
• Effective runtime: the components that actually execute the deployed application in its hosting environment.

Two commands are useful on hosts where the .NET CLI is installed:

dotnet --list-runtimes
dotnet --list-sdks

The first displays runtimes installed in that environment; the second displays SDKs. Neither command on its own proves which runtime is serving each production application. Engineers must correlate processes, runtime configuration, published artifacts, and hosting infrastructure.

Microsoft’s version selection documentation also explains why installing a newer SDK does not automatically move an application to a new major runtime version.

3. Determine How Each Application Was Published

This is one of the most important distinctions in the assessment.

Framework-dependent applications: generally use a runtime installed or provided by their execution environment. Updating that runtime correctly, followed by any required process restart, can apply a security fix without recompiling the application, provided compatibility and deployment conditions are met.

Self-contained applications: package their own runtime. Installing a newer runtime on the host does not automatically patch the runtime shipped inside the application. The artifact must be rebuilt and republished with the fixed runtime.

Containers: the relevant evidence is the image actually running, not merely the image tag declared in a repository. Examine the base image, digest, build date, and deployment mechanism. Then rebuild and redeploy using patched images.

The same principle applies to desktop binaries delivered to customers: installing a newer SDK on a developer machine does not update releases already distributed.

4. Inspect Dependencies and Third-Party Systems

Exposure may involve NuGet packages, ASP.NET Core components, native libraries, workloads, managed hosting, base images, and products supplied by external vendors.

Ask vendors for verifiable statements: which version is deployed, which advisories were assessed, what patch will be applied, and how support will be handled after November 10.

Do not confuse a vendor’s commercial support contract with Microsoft’s official runtime servicing. A vendor might continue handling support requests, but that does not mean Microsoft will keep providing fixes for unsupported releases.

The Minimum Inventory Executives Should Expect

Before reporting that “we run .NET 10,” I would expect an application- and environment-level report, not just a list of repositories.

Every entry requires verifiable evidence: build manifests, artifact version, image inventory, hosting configuration, or deployment records. If evidence is missing, the status should be “not verified,” never “secure.”

This report also uncovers a governance issue: how many applications does the company have, how many does it actually control, and how many have no accountable owner?

How to Prioritize: Not Every System Presents the Same Risk

I would not treat this as a campaign to change every project file at the same time. That approach ignores operational consequences and makes teams compete for limited resources without a clear priority.

A useful assessment considers at least five dimensions:

1. Technical exposure: internet reachability, untrusted input, use of functionality affected by the CVEs, and existing security controls.
2. Business impact: risk to billing, customer service, personal data, contractual obligations, and continuity.
3. Verified patch gap: the runtime and patch actually deployed, taking the publication model into account.
4. Dependencies: vendors, unsupported components, integrated systems, and infrastructure limitations.
5. Ability to respond: available tests, deployment automation, rollback mechanisms, and knowledge of the system.

The outcome can be presented in action tiers:

A CVE’s severity is an input, not an automatic priority formula. A non-public application may still process third-party files; a public API may have controls that materially reduce exposure. The right classification depends on the actual attack path and its consequences for the business.

Two Workstreams: Remediate Now, Modernize with Control

Organizations facing this situation need two coordinated workstreams.

Workstream A: Apply the Security Fixes

The first workstream responds to the vulnerabilities already disclosed and addressed by the vendor.

• Confirm which release lines and features are in use and which advisories apply.
• For framework-dependent applications, update the correct runtime in the correct environment and restart processes where required.
• For self-contained deployments, rebuild and republish applications with the corrected runtime.
• For containers, update the base image, rebuild the artifact, and deploy a corrected image, verifying the image digest in production.
• Exercise critical business flows and monitor logs, metrics, error rates, and behavior after deployment.
• Capture version and patch evidence from the application environment that is actually serving the business.

This workstream includes .NET 10 applications, since the out-of-band releases also affected that line.

Applying the patch is necessary, but it does not solve the future end of support for .NET 8/9. Similarly, retargeting a project to net10.0 does not replace verification that the required patch has been deployed.

Workstream B: Prepare a Move to .NET 10 LTS

The second workstream reduces the organization’s dependency on release lines that are about to become unsupported.

It starts with Microsoft’s list of .NET 10 breaking changes and an assessment of the dependencies used by each application. Review ASP.NET Core, Entity Framework Core, NuGet packages, serialization, authentication, native libraries, workloads, and operational behavior.

Changing TargetFramework from net8.0 or net9.0 to net10.0 is one part of the process, not proof that migration is complete.

The plan must include development and hosting environments, build tools and CI/CD pipelines, testing and acceptance, operating system requirements, and revised distribution images.

This is where an architecture assessment creates business value: it separates applications with straightforward upgrades from those that need dependency remediation, integration changes, or more extensive technical-debt work.

What a Controlled Migration Must Test

Successful compilation does not guarantee that business processes still behave correctly. For critical systems, unit tests are necessary but not sufficient.

Integration contracts: APIs, messages, queues, callbacks, file exchanges, authentication, and external systems need to preserve behavior expected by their consumers.

Persistence and data: validate queries, mappings, serialization, conversions, transactions, schema migrations, and backward compatibility with other service versions.

Security: check TLS configuration, authentication, authorization, secrets, permissions, and data handling. An upgrade should not reintroduce excessive privileges or disable controls simply to “make it work.”

Load and resilience: compare response times, memory usage, CPU consumption, queue backlogs, timeouts, restarts, and behavior under failure.

Operational experience: validate full business journeys: order to invoicing, appointment to service delivery, document issuance, financial closing, overnight processing, and incident recovery.

Measure the baseline before migration. Otherwise, a moderate regression may remain invisible until production traffic increases.

Rollback Must Be Proven, Not Promised

Migration plans often say: “If anything goes wrong, we’ll roll back.” That promise is only meaningful when someone has demonstrated that the previous release can operate with the data and integrations that exist after the change.

A code rollback can fail when an update introduces incompatible database changes. An old container may depend on libraries that are no longer available. Two services deployed at different times may rely on incompatible contracts.

For a credible recovery strategy, I would require:

• Previous artifacts that can be identified and recovered, including preserved dependencies and images.
• Database changes designed for compatibility across versions, or an explicit data recovery strategy.
• Tests showing that old and new components can coexist during rollout.
• Objective stop conditions: error rates, failed transactions, latency, data integrity, and business indicators.
• Named owners, communication channels, and authority to make the rollback decision.
• A rehearsal in a representative environment, with documented evidence.

There is an important tension: restoring a vulnerable artifact may recover availability while reopening a security exposure. Prefer a previously patched artifact, an additional corrective release (roll-forward), or a temporary containment measure where feasible. The choice requires an explicit assessment of risk.

In environments with many services, progressive rollout, observability, and version compatibility matter more than simply labeling the deployment “zero downtime.”

The Deadline Is Near: What Should Happen Before November 10?

The approaching date is not a license to improvise. It is a reason for leadership to distinguish immediate decisions from changes that require careful validation.

Immediately: review the October 25 advisory, identify potentially affected systems, apply appropriate security patches, and document exceptions with accountable owners and temporary safeguards.

Next: complete the inventory of deployed .NET 8/9 applications, prioritize critical business processes, and identify actual migration blockers.

Before support ends, wherever feasible: migrate and validate priority applications, with rollback tests, monitoring, and approval from the relevant business owner.

When migration cannot be completed in time: formally document residual exposure, temporary restrictions, ownership, budget, and a verifiable exit schedule. A documented exception does not extend Microsoft’s support lifecycle or make an unavailable security fix available.

It would be a mistake to promise that an unknown portfolio can be migrated in a few days. It would be an equally serious mistake to ignore the deadline because “everything has always worked.”

Who Owns This Decision — and What Investment Is Justified?

The security function may discover vulnerabilities; engineering can estimate the work; infrastructure can verify deployed versions. But accepting the risk of a business-critical system requires the involvement of business leaders who are accountable for its consequences.

The CTO and CIO should assemble a consolidated view showing which applications require updates, how much remediation is needed, which dependencies prevent changes, and how operations will be protected.

Budgeting must include not only code changes but also tests, environments, dependency upgrades, controlled deployment, support, documentation, and any temporary coexistence between releases.

At the same time, do not use the deadline as an automatic justification to replace entire platforms. Sometimes the correction is straightforward; sometimes it reveals a structural dependency. A sound technical assessment prevents both dangerous underinvestment and disproportionate modernization.

The intended outcome is a prioritized decision roadmap: patch, migrate, reduce exposure, replace unviable components, or retire applications that no longer justify their continued operation.

Frequently Asked Questions

Will .NET 8 Stop Running on November 10, 2026?

No. End of support does not disable existing applications. It ends normal provision of new security updates, servicing, and technical support for .NET 8 and .NET 9. That increases the risk of continuing to run those versions in production.

If We Install the .NET 10 SDK, Are Our .NET 8 and 9 Applications Upgraded?

No. The development SDK, target framework, and runtime used by an application are distinct. Verification must focus on the application that is actually deployed and its publication model.

Does Applying the October 25 Patch Remove the Need to Migrate?

No. The patches address specific vulnerabilities during the supported lifecycle. They do not change the .NET 8/9 end-of-support date.

Does a Self-Contained Application Receive the Patch When We Update the Server?

Not necessarily. Self-contained applications ship with a runtime that must be updated through a new publish. For containers, patched images must be rebuilt and deployed.

Does This Also Mean .NET Framework 4.8 Is Reaching End of Support?

No. .NET Framework 4.x is a separate product with its own support lifecycle. It deserves an appropriate assessment, but it should not automatically be assigned the .NET 8/9 deadline.

Must Every Application Move Directly to .NET 10?

.NET 10 is the stable LTS destination Microsoft recommends for these applications. The detailed strategy depends on compatibility, vendors, operating systems, transition costs, and business requirements. Support deadlines should shape the decision, but they do not eliminate testing and planning.

Conclusion: The Real Problem Is Not Just the Version — It Is the Lack of Visibility

The end of support for .NET 8 and 9 has a firm date. October’s out-of-band fixes demonstrate that vulnerabilities can require action even before a major-version migration.

The business challenge is not counting repositories that contain net8.0. It is knowing which applications actually execute affected versions, where they run, what data they process, which dependencies they rely on, and how they can be patched without interrupting the business.

A mature organization does not choose between security and continuity. It creates the conditions to preserve both: a trustworthy inventory, risk-based prioritization, security updates, tests, a migration strategy, and a realistic recovery plan.

Does your business need to assess .NET applications before an upgrade? We can help identify risks and define a modernization roadmap.

Through software architecture and engineering consulting, I help organizations assess architecture, uncover dependencies, and plan controlled modernization. Commercial engagements are delivered by IVATEC.

Official Sources and Further Reading

• Microsoft — .NET 8 and .NET 9 will reach End of Support on November 10, 2026
• Microsoft — .NET October 2026 Out-of-Band Security Updates
• Microsoft — Official .NET Support Policy
• Microsoft Learn — Select which .NET version to use
• Microsoft Learn — Breaking changes in .NET 10

Version and patch information was checked against official communications available as of October 26, 2026. Always consult the most recent vendor advisories before changing production systems.