Companies complaining .NET moves too fast should just pay for post-EOL support

The article argues that companies concerned about .NET's rapid release cycle and short support periods (2-3 years per version) should consider paying for post-End of Life (EOL) support rather than expecting Microsoft to slow development or extend free support. It explains that Microsoft provides active support (bug fixes and security patches) and maintenance support (security-only fixes for the final six months), after which versions become unsupported. The post, sponsored by HeroDevs, promotes their "Never Ending Support for .NET" as a paid alternative to keep EOL versions like .NET 6 secure, such as by patching critical vulnerabilities.

In this post I make a potentially spicy assertion: if you're worried about the speed that .NET is moving, and more specifically the fact that Microsoft only gives 2 or 3 years of support to new versions of .NET, maybe the answer isn't that .NET should slow down .NET. Maybe it isn't even that Microsoft should shoulder the burden of supporting more versions of .NET. Maybe the answer is that you should just pay for post-EOL support like other ecosystems do. This post is sponsored by HeroDevs, and is the result of chatting with Hayden Barnes in the fallout on my post about the worst .NET vulnerability ever. That said, all the opinions expressed in this post are entirely my own—I just think HeroDevs' Never Ending Support for .NET could be a great option for many companies. In this post I describe the official support for .NET provided by Microsoft and what "support" actually means. I discuss the advantages and disadvantages of updating to a new major version and then provide an alternative: pay for EOL support instead. Finally I show how you can easily fix your EOL .NET 6 applications by using HeroDevs' Never Ending Support for .NET 6, demonstrating how it protects you from the recent 9.9 severity CVE. .NET, support lifecycles, and managing vulnerabilities .NET 10 has just been released, and while some people are excited to see the performance improvements and to use the new features, others will no doubt be worrying about the inevitable march of time before the current version of .NET they're using is out of support. A new version of .NET is released every November, and is either a Long Term Support LTS release or Standard Term Support STS release: - Odd number releases are Standard Term Support STS , and receive 2 years of support from Microsoft. - Even number releases are Long Term Support LTS , and receive 3 years of support from Microsoft. The following image shows how this works adapted from the official .NET support policy page There's no difference in the quality bar between LTS and STS releases, the only difference is how long the release is supported by Microsoft until it becomes End of Life EOL . But what do "supported" and "EOL" even mean? 🤔 What does "supported" mean? Most people have an intrinsic feel for what "supported" means and it's typically something like "if there's a bug, it'll get fixed". But Microsoft is very specific about exactly what supported means in their policy. There are two "phases" to support for both LTS and STS releases: - Active support: During the active support period, .NET releases are updated to improve functional capabilities and mitigate security vulnerabilities. - Maintenance support: During the maintenance support period, .NET releases are updated to mitigate security vulnerabilities, only. The maintenance support period is the final 6 months of support for any release. So for the majority of the support timeline, you can expect to see fixes for security vulnerabilities, and "updates to improve functional capabilities". What counts as an "improvement to functional capability" is actually pretty broad: - Resolve reported crashes. - Resolve severe performance issues. - Resolve functional bugs in common scenarios. - Add support for a new operating system version or new hardware platform. Given how the first three points are all about fixing relatively severe issues, I was somewhat surprised to see "supporting a whole new OS version" on the list, but that somewhat makes sense. For example, if Debian releases a new version, it's likely the .NET team are going to want to make sure the latest released version of .NET works on it 6 months before a release goes EOL and stops receiving official support entirely, it enters "maintenance", in which only security vulnerabilities will be addressed: Whatever your issue, you should be able to contact a Microsoft Support Professional to ask for support. This is particularly appealing to larger companies that like to have a single person they can shout at if things aren't working, and typically have an ongoing relationship with Microsoft anyway. Of course, you can also interact with the various teams on GitHub in the dotnet org too. If you do file an issue on GitHub, and assuming that you provide sufficient information that the issue can be reproduced, then I've found the team to be very receptive to resolving issues: Where you might struggle is where your issue is considered minor. If you find a security issue, or a common crashing bug, then sure, it'll probably be fixed in all supported versions of .NET. But if your issue is rare, or if it's risky because it could have adverse impacts, for example then you might have a harder time getting the fix implemented in all versions of .NET, even if they're technically still supported. This is particularly true in the last 6 months of support, when the release enters "maintenance" support. In this stage, you'll likely only get security vulnerability fixes. Another aspect to consider is that whenever you raise an issue, you'll be asked what version of .NET you're using. Which brings us to the next very important point: only the latest patch version of a .NET major version is supported. You patch every month, right? .NET 10 was released on 11th November, but in a month's time I'm sure there will be patches released for the runtime, for ASP.NET Core, for the .NET SDK, and for a variety of other packages that make up the base .NET ecosystem as provided by Microsoft. Even if you're using a .NET release which is actively supported, you're only supported if you're using the latest patched version. To make this concrete, the latest released versions of .NET 9 at the time of writing are: - .NET 9 SDK 9.0.307 - .NET Runtime 9.0.11 If you have an application today that's using .NET 9, and you're not running on the latest .NET 9 patch version 9.0.11 , then you're using an unsupported version of .NET. And next month there will likely be a 9.0.12 version, which will supplant 9.0.11 Only the latest patch versions of all the .NET components are supported. As of today, that means the latest patches for .NET 8, .NET 9, and .NET 10 respectively. Putting that all together, if you want to stick to using only Microsoft supported versions of .NET, that means that every month, you need to, at a minimum: - Update the .NET SDKs used to build .NET applications. - Update the .NET runtime used to deploy and run your applications. If you can't update these versions every month, then you won't be using a Microsoft supported version of .NET. The good news is that patch updates for .NET are typically very easy to apply. They rarely contain breaking issues or require significant effort. But eventually there won't be any more patch versions, the version of .NET you're using will go out of support, and then what? Running an unsupported version of .NET is playing with fire Fundamentally, nothing happens from a technical point of view when a .NET version goes out of official support. Everything keeps working, just as it did before. Nevertheless, depending on your regulatory environment, you may find you're no longer compliant, with all the potential associated financial or legal implications. Even if you're not in a regulated environment, you still have the potential for a big problem to hit at any point: when you or someone else discovers an issue in your out-of-support version of .NET. This is the exact scenario many people found themselves in recently, when the request-smuggling security vulnerability CVE-2025-55315 was announced. This vulnerability is Very Bad™️ a 9.9 severity , because it allows attackers to potentially bypass security controls, exfiltrate data, login as other users, perform injection attacks and more, all by relying on request smuggling. Hopefully, you get the picture…Not Good. I wrote an extensive blog post looking at this vulnerability, explaining how request smuggling works in general, walking through the specific vulnerability in CVE-2025-55315, describing how to test if you're vulnerable and what to do to protect yourself. Patches were released for the vulnerability for .NET 8, .NET 9, and .NET 10, as these were in support. But basically all versions of .NET are vulnerable; at least .NET Core 3.1. NET 5, .NET 6, and .NET 7. All of which leaves those organisations running an unsupported version of .NET in a sticky situation. If you keep running an unsupported version of .NET, then your application has a known 9.9 severity vulnerability. The alternative is to perform a major version update of your applications to use a supported version of .NET, but that might also be easier said than done… If you're using .NET 6, then there's another option, HeroDevs, which we're going to come to shortly 😅 The difficulties of a major version update Many developers look forward to new major versions of .NET. A new major version of .NET typically means: - Performance improvements. Incredibly, each new version of .NET is faster than the previous version. - New features. A major version typically means new features. Whether that's incremental improvements or entirely new features, most releases touch all parts of the .NET stack. - Support for new platforms. Some major releases include support for new operating systems and CPU architectures. But a major upgrade isn't always for the feint of heart. We've come a long way from the huge shifts between .NET Core 1.0, .NET Core 2.0, and .NET Core 3.1, but there are still many potential risks associated with performing major version updates, particularly when viewed from an organisation's point of view. For example: - Breaking changes. Major version updates inevitably come with a variety of breaking changes. How severely you're affected by these issues will depend on your specific application, but you should always review this list to establish which, if any, would impact you, and plan work to mitigate them as part of an upgrade. - Behavioural changes. Even if the changes in an update aren't considered breaking, they may still result in a difference in behaviour, which could cause your application to behave in a way you don't expect. Often the only way to identify these issues if they're not marked as breaking changes is to test your updated application extensively. - Tooling upgrades. Building a new version of .NET may require that you update various tooling, whether that's the SDK you use to build your application, the continuous integration CI runners you use to build your app, or the machines you deploy your application to. This work often takes a large proportion of the overall migration time, and is commonly overlooked. - Regulatory compliance. Depending on your environment, you may need to re-certify all the applications that you update to a new major version, to ensure they're compliant with any regulations. That can cost time and money. - Internal support. If you have a "platform" team which supports other teams, then there's a degree of experience and learning developers need to undertake to learn about what's available. - Opportunity cost. Time spent migrating to newer versions of .NET is time spent not implementing new features or addressing customer needs. Updating to a new major version clearly has a number of advantages, but for some organisations and applications, the benefits of performance improvements and new features simply aren't enough to offset the risk and costs associated with performing a migration. But those same organizations also can't afford to be stuck on unsupported versions that will cause them regulatory problems, or be at risk of handling unpatched CVEs like CVE-2025-55315. So what's a poor .NET-using org to do? Why not just pay for support? And now we get to my pitch: delay the major-version update if it's too painful, and just pay for support for old .NET versions. As I discussed in the previous section, organizations often don't want to do major version updates, due to the difficult