On November 10, 2026, Microsoft stops shipping free security patches for .NET 8 and .NET 9. Both versions keep running after that, but newly discovered platform vulnerabilities no longer receive fixes from Microsoft. The work has to be scheduled rather than deferred. The recommended target is .NET 10, the current long-term support release, which is patched through November 2028.
First, Check Which .NET You Actually Run
The word .NET covers two different products, and mixing them up causes both false panic and missed risk. The deadline is about modern .NET, the cross-platform product that ships every November as .NET 8, 9, and 10. The older .NET Framework, the Windows-only 4.x line, is a separate product on a much longer lifecycle tied to Windows itself, and this date does not touch it.
You do not have to guess which one a system uses. Open its project file and read the target framework: net8.0 or net9.0 means the November date applies; net48 and similar is .NET Framework and is out of scope here. Do that check for each system before anything else, because it decides which systems are even in scope.
Check Dependencies Before Setting A Date
Raising the target framework to net10.0 is only the first edit. Rebuild the application and work through what the compiler and tests expose.
Every third-party NuGet package in the application has to be checked for .NET 10 compatibility. A package does not need a release badged specifically for .NET 10 to work: one built for an older target framework, or for .NET Standard, may be compatible and run unchanged. The problem is a package that is abandoned or incompatible, because one can block the move whether you reference it directly or it arrives transitively through another package. Transitive packages are harder to spot since nothing in your own project file names them. List direct and transitive dependencies, then confirm the compatible version of each before committing to an upgrade date.
The same check applies to software a vendor controls. Ask for the plan and delivery date for moving off .NET 8 or .NET 9 before November 10, 2026. Record the answer. If the vendor has not committed, the application schedule has an external dependency that needs an owner and a fallback.
Make the List, and Give Each Item an Owner
Write down everything that runs on .NET 8 or .NET 9, including internal tools, APIs, worker services, scheduled jobs, desktop applications, and vendor-managed systems. For each one, note the target version, hosting location, deployment method, business criticality, and the person responsible for the upgrade decision.
Orphaned tools are easy to miss because nobody is responsible for deciding, testing, and approving the change. Treat an empty owner field as a problem to resolve, not a placeholder.
Do Not Stop at the Application
Three things around the application have to move with it. The first is the runtime, and how you handle it depends on how you deploy. A framework-dependent deployment relies on a .NET runtime already present on the server or in the container image, so that environment needs a compatible .NET 10 runtime available to it. A self-contained deployment carries its own runtime inside the published output, so there is nothing to install on the server, but the application has to be republished on .NET 10 to pick up the newer runtime. The second is the hosting platform underneath, whether a cloud app service, a functions host, a container platform, or a plain virtual machine, each of which has its own supported-runtime setting to update. The third is the build agents that compile and publish the code: once a project targets net10.0, an agent without the .NET 10 SDK cannot build it. Install the .NET 10 SDK on the agents before expecting the pipeline to pass.
If a repository pins its SDK version with a global.json file, update that pin to a suitable .NET 10 SDK. Otherwise the requested SDK and the net10.0 target do not line up, and the build cannot proceed with the intended toolchain.
Prove It, Then Ship It
An upgrade is finished when it is proven in something close to production, not when it compiles. Run the automated tests, then exercise the application in a staging environment that resembles the real one. Systems with thin test coverage need more manual checking because the automated suite proves less.
Decide how you will roll back before you deploy, not during an incident: how to reinstate the previous version, which window is low-risk, and whether your logging will show a problem in the first hour. The deployment model matters here too. A framework-dependent app built for .NET 10 automatically runs on the latest .NET 10 patch installed on the host, so keeping it current is mostly a matter of applying runtime updates; a self-contained app stays on the runtime it shipped with and only moves when you republish it.
Until You Move, Keep 8 and 9 Patched
A system still on .NET 8 or .NET 9 should use the latest patch available for that version. Microsoft ships security and reliability fixes monthly, and they keep coming through November 10, 2026. Freezing on an older patch gives up fixes that are still available.
A Rough Order of Work
Use the fixed November 10, 2026 deadline to sequence the work:
- Identify affected systems and assign an owner.
- Check package compatibility, vendor commitments, deployment type, runtime, hosting, build agents, and any global.json pin.
- Upgrade lower-risk systems first to test the process before scheduling business-critical applications.
- Keep each system patched until it moves, then confirm the upgraded application in production.
Where IKRC Fits
IKRC can inventory the affected applications, check package and hosting constraints, coordinate with software vendors, and carry out upgrades to .NET 10 with test and rollback plans. The work may involve our .NET development, application modernization, and software integration services.
If you are not sure which systems are affected, call IKRC at 646-783-1441 or email info@ikrc.co.
Related Reading
For a wider view of upgrading older systems safely, read the Legacy Application Modernization Guide. For what to look for in a long-term .NET partner, read Choosing a C# Development Company.
Need this solved in your software?
IKRC builds the custom systems, integrations, and modernization work discussed in this article.