--- title: "S09E04 - .NET 8 and .NET 9 End of Support: What Stops, and What Does Not" url: https://dotnetcore.show/season-9/net-8-and-net-9-end-of-support-what-stops-and-what-does-not/ date: 2026-10-23 author: "Jamie Taylor" summary: "Jamie marks the two hundredth episode of the show with a public service announcement rather than a retrospective. Microsoft stops supporting .NET 8 and .NET 9 on 10 November 2026, eighteen days after this episode goes out. Applications keep running. Security fixes stop. The episode covers what else shares that date. The list includes ASP.NET Core, Entity Framework Core, PowerShell 7.4 and the Azure Functions in-process model. Two other things went out of support before the runtime they target. The episode also covers what a security advisory does when a version is already out of support. The worked example is the highest scoring ASP.NET advisory Microsoft has published. One Azure hosting plan cannot run .NET 10 at all, which turns the date into an infrastructure change for the teams on it. The episode ends with a rule for telling which of two similarly named things has a deadline." audio: "https://traffic.libsyn.com/thedotnetcorepodcast/S09E04_End_of_Support.mp3" episode_id: 200 duration: "PT45M6S" --- # S09E04 - .NET 8 and .NET 9 End of Support: What Stops, and What Does Not ## Episode Summary Jamie marks the two hundredth episode of the show with a public service announcement rather than a retrospective. Microsoft stops supporting .NET 8 and .NET 9 on 10 November 2026, eighteen days after this episode goes out. Applications keep running. Security fixes stop. Topics covered in this episode include: - What Microsoft actually stops doing on 10 November 2026, and what carries on unchanged - The other things that share the date, including ASP.NET Core, Entity Framework Core, PowerShell 7.4 and the Azure Functions in-process model - Why one Azure hosting plan turns the runtime date into an infrastructure change rather than a version change - Two things that already went out of support before the runtime they target - What a security advisory does when a version is already out of support - A rule for telling which of two similarly named things has a deadline on it > **A note on dates.** Every support date in this episode was correct at the time of writing, which was 15th September 2026. These dates move, and one of the dates in this episode has moved already. Microsoft's published lifecycle pages are the authority and are linked at the end of these notes. Check them before you act on anything here. ## Dates in This Episode | What | End of support | Source | | --- | --- | --- | | .NET 8 (LTS) | 10 November 2026 | [Microsoft lifecycle](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core) | | .NET 9 (STS) | 10 November 2026 | [Microsoft lifecycle](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core) | | .NET 10 (LTS) | 14 November 2028 | [Microsoft lifecycle](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core) | | .NET 11 (STS) | 9 November 2028 | [Microsoft lifecycle](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core) | | ASP.NET Core 8 and 9 | 10 November 2026 | [ASP.NET policy](https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet) | | Entity Framework Core 8 and 9 | 10 November 2026 | [EF Core releases](https://learn.microsoft.com/en-us/ef/core/what-is-new/) | | PowerShell 7.4 (LTS) | 10 November 2026 | [PowerShell lifecycle](https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle) | | Azure Functions in-process model | 10 November 2026 | [Migration guide](https://learn.microsoft.com/en-us/azure/azure-functions/migrate-dotnet-to-isolated-model) | | Azure Functions on the **Linux Consumption** plan | **Not a date.** .NET 9 is the last .NET version the plan accepts | [Functions versions](https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions) | | The Azure Functions **Linux Consumption** plan itself | 30 September 2028, when the plan retires | [Migrate to Flex Consumption](https://learn.microsoft.com/en-us/azure/azure-functions/migration/migrate-plan-consumption-to-flex) | | `mcr.microsoft.com/dotnet` tags 8.0 and 9.0 | 10 November 2026, or earlier if the base image goes first | [Tag lifecycle](https://github.com/dotnet/dotnet-docker/blob/main/documentation/supported-tags.md) | | .NET MAUI 8 | **14 May 2025 (already passed)** | [MAUI policy](https://dotnet.microsoft.com/en-us/platform/support/policy/maui) | | .NET MAUI 9 | **12 May 2026 (already passed)** | [MAUI policy](https://dotnet.microsoft.com/en-us/platform/support/policy/maui) | | .NET MAUI 10 | 11 May 2027 | [MAUI policy](https://dotnet.microsoft.com/en-us/platform/support/policy/maui) | | ASP.NET Core 2.3 (on .NET Framework only) | 13 April 2027 | [Microsoft announcement](https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of-support/) | | Umbraco 13 | 14 December 2026 | [Umbraco LTS](https://umbraco.com/products/knowledge-center/long-term-support-and-end-of-life/) | | **.NET Framework 4.8** | **None of its own.** Follows the Windows version it is installed on | [Framework policy](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework) | | **Windows PowerShell 5.1** | **None of its own.** A component of Windows | [PowerShell lifecycle](https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle) | ## Before 10 November 2026 If you are forwarding this to somebody who does not write the code, this section is the one to send. On 10 November 2026, Microsoft stops publishing security fixes for .NET 8 and .NET 9. Applications built on those versions keep running. Nothing switches off, nothing expires, and no licence lapses. What stops is the supply of patches for problems found after that date. Two versions going out of support on the same day is unusual. It has happened because .NET 9 had its support window extended from eighteen months to twenty-four, which moved its end date from May 2026 onto the same day as .NET 8. The move most teams will make is to .NET 10, which Microsoft supports until 14 November 2028. For a straightforward application that is a configuration change and a test pass rather than a rewrite. For a complicated one it is a project, and projects need planning time, which is why this is worth reading in October rather than in November. There is a decision to make even if the answer is to stay. [Kentico](https://www.kentico.com/customers/supportcenter/support-lifecycle), who make a content management system built on .NET, write the consequence into their own end of support terms more plainly than most. From the day their version 13 goes out of support, customers "assume full liability for any claims, damages, losses, costs, or expenses, including those arising from security incidents", and Kentico's own liability "will terminate" on that date. Not every supplier says it that directly. It is worth finding out whether yours does, because that sentence is the real shape of an end of support date for anybody who signs contracts. Three questions worth answering before 10 November 2026: 1. Which versions of .NET are actually running in production, including the ones nobody has looked at for a while? 2. For each of them, which supplier is responsible for security fixes after that date, and what have they committed to in writing? 3. If the decision is to stay on an unsupported version for now, who has signed that decision, and when will it be reviewed? **One wrinkle worth knowing about in advance.** Some applications run on a specific Azure hosting arrangement called the Linux Consumption plan. That arrangement does not accept .NET 10, and Microsoft has said that newer .NET versions are not added to it. The most recent version it accepts is .NET 9, which reaches its end of support on the same day as .NET 8. For an application in that position, the move is not a small configuration change. It needs a new hosting setup, which usually means a change that somebody has to approve and schedule. The episode covers the detail, and the table above links the sources. If your teams run anything on Azure Functions, question one is worth extending to ask which hosting plan each application uses. ## Episode Transcription Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I'm your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem. Today's episode is a little different from the norm. There's no guest; it's just me. And there's a date coming that I'd rather tell you about early than late. So let's sit back, open up a terminal, type in `dotnet new podcast` and we'll dive into the core of Modern .NET. ### Two Hundred This is episode two hundred. I had something planned for that, and then I looked at the calendar. There's a date coming in November that I think is worth more of your time than a look back at mine, so the retrospective can wait. It'll keep. There'll still be a special episode whenever I get round to it. And before anybody's shoulders go up: nothing is on fire. Your application will not stop working. I'd simply rather tell you about this now, with a couple of weeks in hand, than in three weeks' time with none. ### Housekeeping Three bits of housekeeping first, because this episode names some companies, and one of them is mine. This show is produced by RJJ Software. RJJ is who I work for, and some of what RJJ does is application modernisation. So I have a commercial interest in you deciding to modernise. I want to be straight about which way that points today. In a previous episode I told you that plenty of you should stay where you are, which was easy to say, because it cost me money. This one is about a deadline, and a deadline is the best sales tool anybody in my line of work has ever been handed. So check the dates yourself. They're Microsoft's, not mine, and every one of them is linked in the show notes. HeroDevs have never paid this show a penny. Nobody briefed me for this episode and nobody has seen it. Hayden came to us about a vulnerability with .NET last year: he asked whether he could talk about it on the show, and that's why season eight, episode seven B exists. I've also known him for years, from back when I was a Microsoft MVP. And Umbraco flew me to Codegarden this summer and paid for my hotel, so that I could record the episode that went out four weeks ago. I'm going to mention Umbraco today, because their support dates make a point I need. I'm not going to recommend anything they sell in this episode. Right. That's the housekeeping. Weigh what I tell you accordingly, and go and check it. ### One More Thing Before the Dates Last thing before I start, and I'd like you to hold on to it for the next forty minutes. Everything I'm about to tell you about support dates was correct at the time of writing, which was the fifteenth of September, 2026. These dates move. One of them in this episode has already moved once, and I'll come to that. Microsoft's lifecycle pages are the authority here, not me, and they're linked in the show notes. If you're listening to this a year from now, go and check them rather than trusting a recording. ### Is This About You? Let me sort you into groups, because this episode isn't equally about all of you. If you're running .NET 8 or .NET 9 in production, this is your episode. Both of those versions stop being supported by Microsoft on the tenth of November, 2026, which is eighteen days after this episode goes out. Stay with me for the whole thing. If you're running .NET Framework, and I know a lot of you are, because I've spent two episodes of this season talking to you specifically, then most of the next half hour is not about you. .NET Framework 4.8 has no end of support date of its own. It follows the Windows version it's installed on, and that has not changed. You do not have a November deadline, and nothing I say today creates one. There is one date later on that catches a particular group of you, and it is not in November. I will flag it clearly when I get there, and I will tell you first whether it is yours. I'd still like you to stay, though, and I want to be straight about why rather than just asking nicely. The last section of this episode is a rule for working out which of two similarly named things has a deadline on it, and you are the single group most likely to be handed the wrong answer by somebody who has only read a headline. I've had that conversation. Somebody sees ".NET goes out of support in November", looks at a Framework application, and panics a team that had nothing to worry about. So stay for that bit, because it's the part that arms you. And if you don't write the code, if you're listening because you run a .NET application that somebody else built and you've never once thought about what it's made of, there's one instruction for you, and I'll give it to you in about ten minutes. You can skip everything in between. One more group, and I nearly left them out. If you're on .NET 6 or .NET 7, or something older than that, you went out of support a while ago and you already know. This episode is still worth your time, because the section on security advisories is about you more than anybody. Now, the reassuring part, and I want it out of the way before anything else. Here's Microsoft, in their own end of support announcement: > Applications built on .NET 8 or .NET 9 will continue to run. > > — Microsoft, *[.NET 8 and .NET 9 will reach End of Support on November 10, 2026](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/)* That's it. That's the whole of what happens to your running application on the eleventh of November. Nothing switches off. Nothing phones home and refuses. There's no licence check, no kill switch, and no expiry. If you do nothing at all, your application will be doing exactly the same thing on the eleventh that it was doing on the ninth. So whatever else I say in the next half hour, that sentence stays true. Hold on to it. ### What Actually Stops Right. So if nothing breaks, what actually happens? This, and again it's Microsoft's own wording, from the same post: > After that date, Microsoft will no longer provide servicing updates, security fixes, or technical support for these versions. > > — Microsoft, *[.NET 8 and .NET 9 will reach End of Support on November 10, 2026](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/)* There are two words sitting in the middle of that sentence which are doing most of the work, and they are very easy to read straight past. *Microsoft will* no longer provide. That's a statement about what Microsoft does. It isn't a statement about what happens to you, and those are genuinely different claims. There are people listening to this who have a support arrangement with somebody other than Microsoft, and for them that sentence is not the whole story. I'll come back to that. But for most of you, most of the time, it amounts to this: a vulnerability found in .NET 8 on the twelfth of November does not get a patch from Microsoft. Not a slow patch. Not a patch you have to ask for. No patch. There's one more detail on the day itself that I like, because it's oddly human. The tenth of November is a Tuesday, and it's the second Tuesday of the month, which makes it a Patch Tuesday. Microsoft's own announcement says this: > November 10th is a Patch Tuesday release day. .NET 8 and .NET 9 may each receive one final update on that day if there is a known critical issue. > > — Microsoft, *[.NET 8 and .NET 9 will reach End of Support on November 10, 2026](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/)* *May* receive. *If* there's a known critical issue. That's not a promise of a farewell patch. Support doesn't end with a tidy full stop and a final release. It ends on a day that happens to be a release day, and whether anything actually ships depends entirely on whether something needed fixing that fortnight. I find that a much more honest picture of what end of support is than a countdown clock would be. And while we're on the dates: I said one of them had already moved. Here it is. .NET 9 was originally going to go out of support on the twelfth of May, 2026. It's a Standard Term Support release, and Standard Term Support used to mean eighteen months. In 2025 Microsoft changed that to twenty-four months, starting with .NET 9, and that pushed .NET 9's end date from May onto the same day as .NET 8's. You can watch this happen in Microsoft's own documentation. The [Azure Functions migration guide](https://learn.microsoft.com/en-us/azure/azure-functions/migrate-dotnet-to-isolated-model) carries a footnote explaining that the date used to be May and now is not, and why it changed. I'm not telling you that as trivia. I'm telling you because a support window moved by six months while people were already running on it, and that's the best argument I can make for going and checking these dates yourself rather than trusting a recording of me. ### What to Do About It So. Options, and I'm going to put the free ones first, because I think that's the honest order. **Move to .NET 10.** It's the current Long Term Support release, and Microsoft supports it until the fourteenth of November, 2028. That's just over two years of runway from the November date. For a lot of applications this is genuinely small: you change the target framework in your project file from `net8.0` to `net10.0`, you update your build and hosting environments, and you run your tests. Microsoft's own upgrade instruction really is one line of XML. Whether it's a morning or a quarter depends entirely on how much of your application is yours and how much is other people's code, which I'll come to. One flag on that middle step, though, and I'll come back to it later with a real example. Updating your hosting environment is doing rather more work in that sentence than it looks like. For most of you it's a version number in a config file. For a few of you, it's the entire job. Worth saying: if you're on .NET 8, the move to .NET 10 is one Long Term Support release to the next, which is the path Microsoft designs for and documents best. If you're on .NET 9, you're making a single version step, and there are fewer breaking changes in your way. Neither of those is a promise that it'll be easy. Both of them mean you're on a route somebody has signposted. **Move to .NET 11 instead.** You can, and I'd think carefully about it. I went through this in detail a fortnight ago, so I'll keep it short: .NET 11 is a Standard Term Support release, and its support ends on the ninth of November, 2028. .NET 10's ends on the fourteenth. Moving to the newer version buys you five days *less* support than moving to the older one. That's not a trick and it's not a scandal. It's just what happens when you have two release cadences running next to each other, and it's worth knowing before somebody on your team argues for the higher number on principle. **Stay, deliberately, and write it down.** This is a real option and I spent a whole episode on it two weeks ago, so I won't re-teach it. The short version: a decision to stay is defensible, and a decision to stay that nobody has written down is indistinguishable from not having decided. Write down what you're on, what you looked at, what moving would cost, what it would buy, and when you'll look again. Get somebody above you to sign it. **And if you genuinely cannot move.** There's a market in commercial support for versions of .NET that Microsoft has stopped supporting. It exists, it's a real thing you can buy, and I want you to know it's there so you can go and ask about it rather than assuming you're stuck. I'll do the old BBC thing here, which I've done before on this show. Other options are available. Last time I said that I admitted I didn't actually know of a second supplier. I've checked since, and there are at least two, HeroDevs and TuxCare, and there may well be more I haven't found. One thing about that market matters specifically to this episode, so I'll say it and then stop. The two I checked don't cover the same versions. Between them, .NET 8 is covered by both. **.NET 9 is covered by one of the two.** This is an episode about .NET 8 *and* .NET 9, and it would be a bit rich of me to tell you commercial support exists without telling you that half the market I looked at doesn't sell it for one of the two versions I'm talking about. Go and ask. Don't assume. And that's as far as I'm going on that, because there's a whole episode in it and this isn't it. Whichever of those you pick, do one thing first, and it's the cheapest thing in this episode. **Find out what you are actually running.** Not what the architecture diagram says, not what the readme says, and not what somebody remembers deciding in 2023. The actual versions, in production, including the scheduled job nobody has opened since the person who wrote it left. I'm labouring this because every other decision depends on it, and because in my experience it is the step teams skip. It is genuinely common to find a .NET 6 service in an estate that everybody would have sworn was entirely on 8. That's not incompetence, it's just what happens to any system that more than four people have touched over three years. **Finally, the instruction I promised.** If you're listening because you *use* a .NET application rather than build one, you bought it, somebody installed it, it does something useful and you've never thought about what it's written in, then your job here is one email. Ask whoever makes it what version of .NET it runs on, and what they're doing about November. That's it. You can't fix this one yourself and you shouldn't have to. ### It Is Not Only the Runtime Now the part I think is actually new, and the reason I wanted a whole episode rather than a paragraph. When people say ".NET 8 goes out of support", they usually picture the runtime. One thing, one date. But there's a whole stack of things sitting on top of that runtime, and they've all got their own lifecycles, and they do *not* all end on the same day. Let me start with the one that surprised me most. **.NET MAUI.** If you're building mobile and desktop applications with .NET MAUI, your version probably went out of support a while ago and you may not have noticed. MAUI doesn't follow the .NET support policy. It has [its own](https://dotnet.microsoft.com/en-us/platform/support/policy/maui), and that policy says a major version gets supported for "a minimum of 6 months after a successor ships". That's because MAUI has to keep pace with Xcode and the Android SDK, which move on their own schedule. That's a reason, not an excuse, and I think it's a fair one. But look at what it produces. **.NET MAUI 8 went out of support on the fourteenth of May, 2025.** That's eighteen months before the runtime it targets. MAUI 9 went on the twelfth of May this year. Both of them are already gone. And if you're a MAUI developer who did everything right and moved to .NET 10, MAUI 10 is supported until the eleventh of May, 2027, which is a year and a half before .NET 10's runtime ends. So there's somebody listening to this who has been out of support since May of last year, has had no reason whatsoever to think so, and would have told you with total confidence that they were fine until November, because `net8.0` is a Long Term Support release and it runs until November. And they'd have been right about the runtime and wrong about the thing they actually build with. **Visual Studio.** This one you'll see on your own machine. Microsoft have said that in [a future servicing update](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/), Visual Studio 2022 will mark the .NET 8 and .NET 9 components as out of support. To be completely clear, because I don't want anybody panicking about their development machine: existing installations aren't affected, nothing is deleted, and there's no date attached to it. The component gets labelled, not removed. There's even a "remove out of support components" option if you want to tidy up. But it's the one consequence of this date that a developer is going to *see*, without reading a single lifecycle page. **Azure Functions.** If you're running .NET Azure Functions on the in-process model, the in-process model itself goes out of support on the tenth of November, 2026. Same day. And I want to be precise about why that's worse than it sounds: that's not a runtime version, it's a hosting model, and moving off it is a code change rather than a version bump. Microsoft's own [migration guide](https://learn.microsoft.com/en-us/azure/azure-functions/migrate-dotnet-to-isolated-model) is blunt about the trap, too. It notes that support for .NET 8 and .NET 9 ends the same day as the in-process model, and says that if you target either version during your migration, you'd "have to upgrade again immediately to stay in support". Two deadlines, one day, and the fix for one of them isn't the fix for the other. And there's a third deadline hiding behind those two, for some of you. I want to be careful about who, because this next part is only about one particular way of hosting Functions, and Azure has two things with nearly the same name. If your Functions app runs on the Consumption plan on Linux, this is about you. If it runs on the Consumption plan on Windows, Microsoft say those apps aren't currently affected, and you can relax for the next couple of minutes. Here's what Microsoft say about the Linux one, and I'm going to read it rather than paraphrase it, because the wording is the whole thing. > .NET 9 is the last .NET version supported for Linux Consumption plan apps. Newer .NET versions aren't added to Linux Consumption. > > — Microsoft, *[Azure Functions runtime and language versions](https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions)* So .NET 9 is the ceiling. And .NET 9, as I've been saying for the last half hour, goes out of support on the tenth of November, 2026. The same day as .NET 8. Work through what that actually means, because I had to do it twice before I believed it. Everywhere else in this episode, the answer to "what do I move to" is .NET 10. It's the Long Term Support release, it has two years on it, and it's one line of XML. On this plan, that answer isn't available, and it isn't going to become available. So what's the supported version to move to? There isn't one. After the tenth of November, there is no in-support version of .NET that will run on the Linux Consumption plan at all. Which means the move isn't up a version. It's off the plan. The place Microsoft point you at is Flex Consumption, which does take .NET 8, 9 and 10. And here's the part I'd want to know before I promised anybody a date. You can't move an existing app between those two plans. I'll let Microsoft say it, because I don't want this one coming from me. > In-place migration of an existing function app from another hosting plan to the Flex Consumption plan isn't supported. You also can't migrate your app from Flex Consumption to another plan. To move to Flex Consumption, you must create a new function app in a Flex Consumption plan and redeploy your code. > > — Microsoft, *[Azure Functions Flex Consumption plan hosting](https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan)* So that's a new app, a new storage account, a managed identity created again with its role assignments granted again, your custom domains and certificates re-pointed, and your access restrictions rebuilt. And if your release process uses deployment slots, Flex Consumption doesn't have them. That is not a setting you change on a Friday afternoon. That's a change to your infrastructure, and depending on where you work, it might be a change that somebody other than you has to approve. One more thing, and it's the part that tells you what this really is. It isn't a .NET problem. The same note sits on that page against Java 21, against Node.js 22, against Python 3.12, and against PowerShell 7.4. In every case, that's the last version of that language the plan will take. And you'll recognise that last one, because I gave you its date earlier: PowerShell 7.4 goes out of support on the tenth of November, 2026, so a PowerShell Functions app on Linux Consumption is in exactly the same bind as a C# one, on exactly the same day. What that pattern tells you is that nothing new is being added to this plan in any language. Which also means there's no point waiting for .NET 11 to rescue it, because .NET 11 isn't coming there either. Now, I've spent this episode telling you that nothing is on fire, and I meant it, and it's still true here. Nothing switches off on the eleventh of November. Your functions keep running, keep serving traffic, and keep doing their job, exactly like every other application I've talked about today. But I've also been telling you that eighteen days is plenty of time to find out what you're running and get a decision written down, and for this particular group I don't think that's honest, so I'll say so. If this is you, the thing in front of you isn't a decision, it's a project. It needs a change to your infrastructure, it probably needs somebody's approval, and it very likely needs a slot in a delivery plan that was written before either of us knew about any of this. That's exactly why I'm telling you in October rather than in November. Not because it's urgent, but because it has a lead time, and lead time is the one thing you can't buy back later. So the thing to go and do is genuinely one thing: find out which plan that Functions app is on, and whether it's Linux or Windows. That's the entire check. And if your infrastructure is described in code, in Bicep or Terraform or whatever your team uses, the answer is already sat in your repository and you don't need to open a console at all. One caveat before I move on, because this is the only place today where I'd otherwise be overstating my case. I've said all episode that nothing switches off, and for every .NET date in this episode that is true. There is one Azure retirement running on its own clock that genuinely does stop applications, and I'd rather you heard it in Microsoft's words than mine. > Function apps still running the end-of-life v3 runtime on Linux in a Consumption plan stop running after September 30, 2026. > > — Microsoft, *[Azure Functions runtime and language versions](https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions)* That's not a .NET version date, it's a Functions runtime date, so it isn't this episode's subject and I'm not going to teach it here. But I'm not going to stand here telling you nothing stops when something does. If that sentence describes anything you own, go and read Microsoft's page on it rather than taking this one as your answer. **Azure App Service** doesn't have a date of its own. It follows whatever the runtime does. But there's a consequence in [their policy](https://learn.microsoft.com/en-us/azure/app-service/language-support-policy) that I'd never joined up, and it's this: if your application uses an unsupported language version, you have to upgrade it to a supported one *before you can get App Service support*. So the runtime date quietly withdraws a commercial entitlement you're still paying for. You can still raise a ticket. They just won't help you with that application until you've moved it. **ASP.NET Core and Entity Framework Core**, versions 8 and 9. Same date, tenth of November. No surprises there, and that's rather the point: they follow the runtime exactly, so if you were hoping the web framework had its own longer window, it doesn't. **Container images.** If you're pulling `mcr.microsoft.com/dotnet` tags for 8.0 or 9.0, here's what the .NET container team say happens: > Unsupported tags and images can still be pulled, but they will no longer receive updates for any reason. > > — The .NET container images team, *[Tag lifecycle, dotnet/dotnet-docker](https://github.com/dotnet/dotnet-docker/blob/main/documentation/supported-tags.md)* Nothing is deleted. Your build doesn't break. The image is still there, it still pulls, and it simply stops changing, quietly, forever. Which I find slightly more unsettling than removal would be, because there's no error for anybody to notice. And the tag's support ends when the .NET version *or* the base operating system image stops getting updates, "whichever happens first", so the operating system underneath can shorten it further. **Your Linux distribution.** I went looking for good news here, and I want to report honestly that I didn't find any. I had assumed that one of the big distributions might support .NET 8 on its own timeline, past Microsoft's date, the way they do with lots of packages. [Red Hat's .NET lifecycle policy](https://access.redhat.com/support/policy/updates/net-core) answers that in one sentence: "Microsoft establishes and maintains the life-cycle support policy for .NET on Red Hat Enterprise Linux." Their dates are Microsoft's dates, to the day. And it can go the other way, too: .NET 6 on Red Hat Enterprise Linux 7 ended in June of 2024, four and a half months *before* Microsoft ended .NET 6, because the operating system went first. So the instruction here is worth having, and it's free: **go and check what your distribution actually does, because it may give you less than you think, and it will not give you more.** And I'd extend that past Linux, because it's the same question wherever your runtime comes from. If somebody else packages, hosts or installs .NET on your behalf, then their support window is a separate fact from Microsoft's, and it is theirs to publish rather than yours to assume. Sometimes it matches. Sometimes, as with that Red Hat Enterprise Linux 7 example, it stops sooner. I have not found a single case anywhere in the research for this episode where it runs longer. **And one more, because it's close to home for a lot of you.** Umbraco 13 is built on .NET 8. The package targets `net8.0` and nothing else. [Umbraco support Umbraco 13](https://umbraco.com/products/knowledge-center/long-term-support-and-end-of-life/) until the fourteenth of December, 2026. The runtime underneath it loses Microsoft's support on the tenth of November. Those are two different dates, thirty-four days apart, and I'm not going to tell you what to conclude from that, because Umbraco don't comment on it and I'm not going to put words in their mouth. I'm telling you the two dates exist and they're not the same one. That's the pattern I want you to be able to spot, and it's what the rest of this episode is about. ### The Part Where Your Scanner Lies to You by Omission Right. This next bit is the one I'd most like you to take away, and it's the one I've been most careful with. Here's the setup. You run a vulnerability scanner. Maybe it's in your build pipeline, maybe it's your endpoint management tooling. It checks what you've got installed against the list of affected versions published with each security advisory. Green tick, no findings, everybody goes home. Now think about what that scanner does when a version is out of support. I don't have to speculate about this, because it's already happened, and it happened in the highest scoring advisory Microsoft has ever published against ASP.NET. So let me show you rather than tell you, and I'd genuinely like you to go and look at this one yourself. It's four bullet points long and it's linked in the show notes. On the fourteenth of October, 2025, Microsoft published CVE-2025-55315. A CVE, if you have not had to care about one before, is a Common Vulnerabilities and Exposures record. It is just a shared number for one specific flaw, so that everybody talking about it knows they are talking about the same thing. It's a request smuggling flaw in Kestrel, and [Microsoft scored it 9.9 out of 10](https://www.microsoft.com/en-us/msrc/blog/2025/10/understanding-cve-2025-55315). The affected software list has four entries on it: ASP.NET Core 10, ASP.NET Core 9, ASP.NET Core 8, and the ASP.NET Core 2.x Kestrel package. Notice what isn't on that list. .NET 7 isn't on it. .NET 6 isn't on it. .NET 5, .NET Core 3.1 and .NET Core 3.0 aren't on it either. And .NET 6 is the one I'd point at, because .NET 6 was a Long Term Support release and it had only been out of support for eleven months when that advisory was published. Now, the obvious question: were those versions actually vulnerable, or were they just fine? Because "not listed" and "not affected" would be very different things. They were vulnerable. The people at HeroDevs built a small console application out of the functional tests from Microsoft's own patch, so that you could run it against versions that never got one. And Andrew Lock, who's a .NET blogger with nothing at all to sell you, and who went and did this himself, wrote this: > I've personally tested down to .NET Core 3.0 and I can confirm that the vulnerability is there and there are no patches coming for you. > > — Andrew Lock, *[Understanding the worst .NET vulnerability ever: request smuggling and CVE-2025-55315](https://andrewlock.net/understanding-the-worst-dotnet-vulnerability-request-smuggling-and-cve-2025-55315/)* So the vulnerability was in those versions, and the advisory didn't name them. Hayden Barnes put the consequence in one sentence, on this show, last November: > Your scanner is not going to report the CVE in .NET 6 because the CVE doesn't have 6 listed in the affected versions. > > — Hayden Barnes, *[S08E07b - Hayden Barnes and CVE-2025-55315](https://dotnetcore.show/season-8/hayden-barnes-and-cve-2025-55315/)* And [in writing, a few weeks earlier](https://www.herodevs.com/blog-posts/reproducing-cve-2025-55315-the-cvss-9-9-cve-in-asp-net), he put it more carefully, which is the version I'd rather you carried away. Security tooling, he wrote, "may not detect this vulnerability on your systems. However, the absence of a CVE detection does not mean the vulnerability is not present." Now, I said I'd be careful, so here's the careful part. I am not telling you that this will happen to .NET 8 and .NET 9 after the tenth of November. I can't tell you that, because it hasn't happened yet. What I can tell you is that this is what happened last time, to a Long Term Support release, eleven months after its end of support, in this exact product. It is [CVE-2025-55315](https://github.com/dotnet/announcements/issues/371), and every word of what I have just told you is checkable from that one page. And here's the bit that convinced me it was worth a segment rather than a sentence. This isn't only a problem for a scanner in somebody's build pipeline. Look at what it did to Canonical, a distribution vendor, with a paid security subscription and advance access to Microsoft's embargoed patches. On [their own public tracker](https://ubuntu.com/security/CVE-2025-55315), .NET 6 on Ubuntu 22.04 is marked "vulnerable, fix deferred" for this CVE. And the note from their security engineer explains why, in eleven words: > Marking .NET 6 as deferred until information is available to determine if it is impacted. > > — Canonical's security team, *[CVE-2025-55315 on the Ubuntu security tracker](https://ubuntu.com/security/CVE-2025-55315)* They couldn't tell. Not because they weren't looking, and not because they didn't care, but because the list that tells you whether you're affected didn't have their version on it. That's a professional distribution security team, doing this for a living, reduced to "we can't tell". And that, for me, is the whole argument for knowing precisely which versions of .NET you've actually got running, rather than trusting something else to tell you. ### The Rule So let me give you the thing I actually want you to keep, because I think it's more useful than any single date I've said today. Three times in this episode there's been a pair of similarly named things, where one of them has a deadline and the other one doesn't. I want to run through all three, because once you've seen it three times you can apply it to things I've never mentioned. Before each one, I'm going to tell you who it's *not* about. Please listen to that part, because getting these the wrong way round is the only way this episode does any damage. **One.** If you are on .NET Framework, whether that's Web Forms, MVC 5, Windows Forms or WPF, this one is not about you. .NET Framework 4.8 has no end of support date of its own. It's a component of Windows and it follows the operating system. Everybody else: .NET 8 and .NET 9 go out of support on the tenth of November. **Two.** If your web application is Web Forms, MVC 5 or Web API 2, which is to say it uses `System.Web`, then this next one is not about you either, and you have no deadline from it. Genuinely none. Now, for everybody else: ASP.NET *Core* 2.3, which is the version of ASP.NET Core that runs on .NET Framework, goes out of support on the thirteenth of April, 2027. I mentioned this a fortnight ago so I won't labour it, but it's a legitimate way to host an application and the people running it deserve their own date. **Three.** If you type `powershell` and get version 5.1 back, this one is not about you. Windows PowerShell 5.1 is a component of Windows and it follows the operating system, exactly like Framework does. But PowerShell 7.4, the Long Term Support release, is built on .NET 8, and it goes out of support on the tenth of November, 2026, with everything else. Now look at the shape of those three. .NET Framework carries on. .NET 8 has a date. `System.Web` carries on. ASP.NET Core has a date. Windows PowerShell carries on. PowerShell 7 has a date. **Every single time, the thing with "Core" in its name, or the higher version number, is the thing with the clock on it.** And the older-sounding thing, the one somebody on your team probably describes as legacy, is the one with no deadline at all, because it's tied to an operating system instead of a release cadence. I'd like you to sit with that for a second, because it's the opposite of what everybody's instincts say. The newer thing is not automatically the safer thing. Sometimes the newer thing is the thing with eighteen days left. ### The Treadmill I want to be honest about something before I finish, because otherwise this episode is a sales pitch for a thing I'd be doing again in two years. Moving to .NET 10 does not solve this. It moves it. .NET 10 goes out of support on the fourteenth of November, 2028, and I will, presumably, be making an episode that sounds quite a lot like this one in about two years' time. Upgrading isn't a destination and there isn't a version where this stops. There's a cadence now, and the cadence doesn't care what your release schedule looks like, or what your regulator thinks, or whether you've got the people. That's a genuine, ongoing cost of being on modern .NET, and anybody who tells you otherwise is selling you something. Possibly me. Check. So the useful move isn't to do this upgrade. It's to do this upgrade *and* work out what makes the next one cheaper. That's usually not a technical question. It's how much of your dependency list you control, how good your test coverage is, how much of your deployment is automated, and whether you have any capacity reserved for work that doesn't ship a feature. Every one of those makes the two-year cycle survivable, and none of them are things you can start in the third week of October. Let me be concrete about that, because "invest in fundamentals" is the sort of advice that sounds true and tells you nothing. The thing that makes an upgrade expensive is almost never the runtime. Changing `net8.0` to `net10.0` takes seconds. What takes months is everything that answers back: a package that has no version targeting the framework you're moving to, a test suite thin enough that nobody trusts a green build, a deployment that one person does by hand on a Thursday, and a release process with no slot in it for work that doesn't ship a feature. Every one of those is fixable between upgrades rather than during one. And every one of them gets cheaper the earlier you look at it, because the alternative is discovering all four in the same fortnight, under a date somebody else chose. So if you take one piece of planning out of this episode, I'd make it this. When you do the move to .NET 10, keep a list of everything that fought you. Not to complain about, and not for a retrospective nobody reads. Keep it because that list is the specification for what to fix before 2028, and it is the only version of that list that will ever be accurate, because you will have just lived it. The teams I've watched cope with this well aren't the ones who upgraded fastest. They're the ones for whom the next upgrade is boring. ### Taking This Upstairs Right, and this is the bit to forward. There's a section in the show notes called "Before 10 November 2026". It's written in business language, it's short, and it's meant to be sent to somebody who doesn't write code. There's also a table above it with every date I've said today and a link to the source for each one, so nobody has to take my word for any of it. Here's why I think the table matters more than the episode. Fifteen dates delivered by voice is useless. Nobody retains that, I don't expect you to, and you shouldn't be taking notes while driving. The table is the actual deliverable. The episode is just me explaining what it means. And the thing I'd put at the top of the conversation upstairs isn't a date at all. It's [Kentico's wording](https://www.kentico.com/customers/supportcenter/support-lifecycle). When their version 13 goes out of support, their customers "assume full liability for any claims, damages, losses, costs, or expenses, including those arising from security incidents", and Kentico's own liability terminates on that day. Now, that's one company's contract, about one company's product, and I'm not making a claim about the law. But it reframes what end of support actually is, and it reframes it in the only language that reliably travels upstairs. This isn't a patch supply question. It's a question about who carries the risk after a specific date, and whether anybody in your organisation has agreed to carry it on purpose. That's a conversation you can have in five minutes with somebody who has never heard of a target framework. And it changes what you're asking for, which I think is the practical point. "We need to upgrade to .NET 10" is a request for budget, and it competes with every other request for budget, and it usually loses, because nothing visibly improves when it succeeds. "Here is a date after which nobody is contractually responsible for security fixes in this system, and here are the three options, and I'd like a decision recorded against one of them" is not a budget request at all. It's a governance question, and organisations are much better at answering those. Notice that it also survives the answer being no. If the decision is to stay on .NET 8 into next year, that is a legitimate answer, and I said so at length a fortnight ago. But it needs to be a decision somebody made, with a name against it and a date to look again, rather than a thing that happened because nobody raised it. The difference between those two is entirely invisible from the outside until something goes wrong, at which point it is the only thing anybody cares about. So the ask is small. You are not asking permission to spend three months. You are asking for an hour, a written answer, and a review date. One caution, and I'd rather say it than have you find out the hard way. If you run this exercise honestly, it might come back the other way. You might do the arithmetic, look at what you actually run, and conclude that you should move, on a timeline you'd rather not. You have to live with that too. If you only want the exercise when it agrees with you, it isn't a decision procedure, it's a search for permission. ### Before You Go So that's the tenth of November. Let me leave you with the short version. Your application will keep running. Microsoft stop shipping security fixes for .NET 8 and .NET 9 that day. Several things you might not have connected to it share the date, a couple of things died before it, and the affected versions list on a future advisory may not mention you at all. Go and find out what you're actually running, check what your suppliers have committed to, and if you decide to stay put, write it down and get it signed. And that is episode two hundred. Not the one I'd planned, but I think it was the more useful one, and there'll be time for the other. I said at the start that nothing is on fire, and I'll finish on the same note, because I'd rather you acted out of planning than out of worry. Eighteen days is not very long to run a project. It is plenty of time to find out what you're running, ask two suppliers a question, and put a decision in writing. That's the whole ask. Everything past that can happen on a timeline somebody in your organisation chooses, which is a much better position than the one this episode would have put you in if I'd left it until November. If this was any use to you, the best thing you can do is share it with whoever on your team is going to be asked about November. That's how this show grows, and it's the only marketing it has. One last thing, and it's a genuine ask. I'm still looking for people to come on this show later in the season and talk about what a migration actually took. Not a conference talk version. The real one, with the bits that went wrong. Anonymised if your employer needs it. If that's you, or if you know who it should be, the contact page is in the show notes. Be kind to yourselves, be kind to each other. ## Wrapping Up Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. Let me know if you found this monologue interesting or useful. I'd love to know if you did, and whether you'd like me to create more of them. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at [the podcast's website](https://dotnetcore.show/), and there will be a link directly to them in your podcatcher. And don't forget to spread the word, leave a rating or review on your podcatcher of choice—head over to [dotnetcore.show/review](https://dotnetcore.show/review) for ways to do that—reach out via our [contact page](https://dotnetcore.show/contact), or join our discord server at [dotnetcore.show/discord](https://dotnetcore.show/discord)—all of which are linked in the show notes. But above all, I hope you have a fantastic rest of your day, and I hope that I'll see you again, next time for more .NET goodness. I will see you again real soon. See you later folks. ## Useful Links - Microsoft lifecycle pages, which are the authority for every date in this episode - [.NET and .NET Core official support policy](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core) - [.NET 8 and .NET 9 will reach End of Support on November 10, 2026](https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/) - [ASP.NET and ASP.NET Core official support policy](https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet) - [Entity Framework Core releases and planning](https://learn.microsoft.com/en-us/ef/core/what-is-new/) - [PowerShell support lifecycle](https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-support-lifecycle) - [.NET MAUI support policy](https://dotnet.microsoft.com/en-us/platform/support/policy/maui) - [ASP.NET Core 2.3 end of support](https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of-support/) - Hosting and packaging - [Migrate .NET Azure Functions to the isolated worker model](https://learn.microsoft.com/en-us/azure/azure-functions/migrate-dotnet-to-isolated-model) - [Azure Functions runtime and language versions](https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions) - [Migrate Consumption plan apps to the Flex Consumption plan](https://learn.microsoft.com/en-us/azure/azure-functions/migration/migrate-plan-consumption-to-flex) - [Azure App Service language runtime support policy](https://learn.microsoft.com/en-us/azure/app-service/language-support-policy) - [.NET container image tag lifecycle](https://github.com/dotnet/dotnet-docker/blob/main/documentation/supported-tags.md) - [Life Cycle and Support Policies for the .NET Program on Red Hat Enterprise Linux](https://access.redhat.com/support/policy/updates/net-core) - [Umbraco long term support and end of life](https://umbraco.com/products/knowledge-center/long-term-support-and-end-of-life/) - [Kentico product support lifecycle](https://www.kentico.com/customers/supportcenter/support-lifecycle) - CVE-2025-55315, if you want to check the advisory yourself - [Microsoft Security Advisory CVE-2025-55315](https://github.com/dotnet/announcements/issues/371) - [Understanding CVE-2025-55315 - Microsoft Security Response Center](https://www.microsoft.com/en-us/msrc/blog/2025/10/understanding-cve-2025-55315) - [Understanding the worst .NET vulnerability ever - Andrew Lock](https://andrewlock.net/understanding-the-worst-dotnet-vulnerability-request-smuggling-and-cve-2025-55315/) - [CVE-2025-55315 on the Ubuntu security tracker](https://ubuntu.com/security/CVE-2025-55315) - [Reproducing CVE-2025-55315 - Hayden Barnes, HeroDevs](https://www.herodevs.com/blog-posts/reproducing-cve-2025-55315-the-cvss-9-9-cve-in-asp-net) - Episodes referenced in this one - [S08E07b - Hayden Barnes and CVE-2025-55315](https://dotnetcore.show/season-8/hayden-barnes-and-cve-2025-55315/) - [S09E03 - You Might Not Need to Upgrade: The Case for Staying Put](https://dotnetcore.show/season-9/you-might-not-need-to-upgrade-the-case-for-staying-put/) - [Get in touch with the show](https://dotnetcore.show/contact/)