Skip to content
TrustList
News

Azure Functions ends .NET 8, .NET 9 and PowerShell 7.4 support on 10 November

Editorial

By TrustList Editorial

Microsoft stops security updates for Azure Functions apps on .NET 8, .NET 9, the in-process model and PowerShell 7.4 on 10 November. Some apps must change hosting plan before they can upgrade.

About Azure Functions ends .NET 8, .NET 9 and PowerShell 7.4 support on 10 November

Azure Functions ends .NET 8, .NET 9 and PowerShell 7.4 support on 10 November

23 September 2026 — Microsoft has set a firm date for older language versions on Azure Functions, its serverless computing service. In notices published on 23 September 2026, it says support for .NET 8, .NET 9 and PowerShell 7.4 on Azure Functions ends on 10 November 2026. Apps will keep running after that date, but they will get no security updates and no customer support.

What changes

For .NET, Microsoft's notice says apps "will continue to operate, but security updates will no longer be provided". It asks customers to move to .NET 10. How much work that takes depends on how an app was built. Apps using the older "in-process" model must first be migrated to the "isolated worker" model and then upgraded. Microsoft says all apps should be off the in-process model by 10 November. Apps already on the isolated worker model can upgrade directly.

A separate notice sets the same date for PowerShell 7.4 and points customers to PowerShell 7.6, which became generally available on Azure Functions on 21 September. A third notice, dated 22 September, says support for Node.js 22 ends on 30 April 2027, with Node.js 24 as the target.

There is a catch for some customers. For both .NET and PowerShell, apps on the Linux Consumption plan must move to the Flex Consumption plan before they can upgrade. That is a change to hosting, networking and billing, not just a code change.

Who is affected

This affects organisations running their own function apps on these versions, which is common for integrations, scheduled jobs, webhooks and automation scripts. It also affects buyers whose suppliers, managed service providers or software vendors run Azure Functions on their behalf. Running unsupported runtimes can breach security clauses in contracts or insurance conditions, and may come up in audits such as ISO 27001 or Cyber Essentials Plus.

What to do

  • Build an inventory. List every function app with its runtime version, hosting plan and owner. Azure Resource Graph or the portal can report runtime versions across subscriptions.
  • Prioritise in-process .NET apps. Moving to the isolated worker model changes how apps start up, bind to triggers and handle dependencies. Allow time to test before November.
  • Plan hosting changes. For apps on Linux Consumption, estimate the cost of Flex Consumption and check networking and scaling settings before you move.
  • Ask your suppliers. Where a partner runs functions for you, ask them to confirm in writing which runtimes they use and when they will upgrade.
  • Put Node.js 22 on the roadmap. April 2027 is further off, but it is better to include it in the same round of work.

Six weeks is short for a change of programming model. Teams that have not started should begin with an inventory this week.

Not yet independently verified. This rests on Microsoft’s own Azure update notices. No independent report of it was found, so it is only as reliable as that page. We will update this when it can be confirmed, and remove this note.

Sources