Australian cloud for business software — built and run in Sydney since 2003

NetLeverage
NetLeverage

.NET on Windows Server: what Windows Update patches and what it leaves to you

Technical article
Hosting

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Many business applications hosted on Windows Server are built on .NET. A common assumption is that if the server is up to date with Windows updates, the application's .NET is too. That is only half true. There are two different products called .NET, they are updated in different ways, and on a server one of them is not updated automatically by default.

The timing makes this worth checking now. According to Microsoft's .NET support policy page, support for both .NET 8 and .NET 9 ended on November 10, 2026. An application still running on either no longer receives security fixes.

Why it matters

A runtime that no longer receives security fixes is a risk however well the rest of the server is maintained. It may also put you outside vendor support: an application vendor may ask you to move to a supported runtime before helping with a fault.

The two .NET families also break in different ways. .NET Framework updates arrive with Windows and can affect any Framework application on the server in the same update. Modern .NET updates arrive separately, and self-contained applications do not receive them from the server at all; only a new application release updates them.

How it works

Two products with similar names

.NET Framework is the older, Windows-only platform. Versions 4.x are part of Windows. Microsoft's lifecycle FAQ says that Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). It generally follows the lifecycle policy of the underlying Windows OS on which it is installed, but this does not keep every old Framework version supported. The same FAQ records retirement of 4.0, 4.5 and 4.5.1 on 12 January 2016, and 4.5.2, 4.6 and 4.6.1 on 26 April 2022. Check the exact installed Framework release against its current support entry as well as the Windows version.

.NET Framework 3.5 SP1 is a special case. On Windows Server 2019 and later it is a separate product: Microsoft's FAQ says that from Windows Server 2019 it is a standalone product and receives 5 years of mainstream support followed by 5 years of extended support. The lifecycle page lists its end date as January 2029.

Modern .NET (formerly .NET Core; now versions such as .NET 8, 10 and 11) is a separate product that is installed alongside Windows rather than as part of it. Microsoft explains the difference in how each is updated: The .NET installer executables are independent products that can be serviced using Microsoft Update (MU) on Windows. MU is different to Windows Update (WU), which is used to service operating system components like .NET Framework.

Servers are not updated automatically by default

The key detail for hosted servers is this line from Microsoft's .NET installation page: Updates for server operating systems are supported by WSUS and Microsoft Update Catalog, but not AU. AU is Automatic Updates, the mechanism most people mean when they say a machine updates itself.

In other words, on a Windows Server machine, .NET Framework is updated with Windows, but modern .NET runtimes are not updated automatically unless someone has set it up. Microsoft documents opt-in settings for servers, and administrators can also approve .NET updates through Windows Server Update Services (WSUS) or install them by hand. If nobody has done any of these, the runtime stays at whatever version was installed.

Several versions can sit side by side

Modern .NET versions do not replace each other. Microsoft notes that the installers support side-by-side (SxS) installations across major and minor releases. A server can have .NET 8, 9 and 10 runtimes all installed at once. Installing .NET 10 does not remove .NET 8 or move applications to it. By default an application does not simply move to a newer major runtime because it is installed. Runtime selection also depends on the application's configured roll-forward policy.

Patch updates are picked up, major versions are not

Within one major version, applications generally follow the latest patch on the server. Microsoft's support policy says that Once a patch update has been installed, applications begin using the update by default. Its publishing guide adds that an application published the default way, called framework-dependent, automatically rolls forward to the latest .NET security patch available on the environment that runs the app.

Moving to a new major version, such as from .NET 8 to .NET 10, requires a supported migration plan. Microsoft documents policies such as Major and LatestMajor that can permit major-version roll-forward, including runtime configuration settings. A migration may therefore use a new application build or an explicitly vendor-supported runtime configuration after compatibility testing. Do not force roll-forward to hide an unsupported application dependency.

Self-contained applications carry their own runtime

Some applications are published self-contained: the .NET runtime is shipped inside the application folder. Updating .NET on the server does nothing for these. Microsoft lists the drawback plainly: The .NET Runtime can only be upgraded by releasing a new version of the app. For a self-contained application, security fixes to .NET reach you only when the vendor releases an update.

Web applications on IIS: the Hosting Bundle

ASP.NET Core web applications hosted on IIS usually rely on the .NET Hosting Bundle. Microsoft describes it as an installer for the .NET Runtime and the ASP.NET Core Module that lets those applications run with IIS. Order matters on a new server: If the Hosting Bundle is installed before IIS, the bundle installation must be repaired.

Support lengths

Microsoft releases a new major .NET version each November. According to its policy, LTS releases get free support and patches for three years. STS releases get free support and patches for two years. On 14 November 2026 the page listed:

Version Type Support ends
.NET 11 STS 14 November 2028
.NET 10 LTS 14 November 2028
.NET 9 STS Ended 10 November 2026
.NET 8 LTS Ended 10 November 2026

Staying on a supported version is not enough on its own. Microsoft's policy says: Within a release's support lifecycle, systems must remain current on released patch updates.

What to choose and why

Make an inventory first

For each hosted server, list:

  • which .NET Framework version is installed, and whether 3.5 is enabled;
  • which modern .NET runtimes and Hosting Bundle versions are installed;
  • which applications use which runtime, and whether each is framework-dependent or self-contained.

The last point usually needs the vendor or developer. Ask them directly.

Decide how modern .NET will be patched

Choose and record a servicing method that covers the actual installation: a supported server opt-in to .NET updates, approved WSUS updates, or controlled manual patching. Microsoft's update coverage describes installer-executable installations; do not assume a ZIP/script-deployed runtime or application-local copy is covered. Include installation method and path in the inventory, then verify the chosen updater changes every intended runtime and the applications still work.

Because patch updates are picked up by framework-dependent applications automatically, test them on a non-production server before they reach production, as you would for Windows updates.

Plan the move off .NET 8 and 9

If an application still depends on .NET 8 or 9, ask the vendor when a version built for .NET 10 will be available, and plan the upgrade. Leaving the old runtime installed for applications that no longer need it adds risk without benefit; remove it once nothing depends on it, after checking with the vendor.

Treat self-contained applications as vendor-patched

For a self-contained application, the vendor owns .NET patching. Make sure your support agreement covers security updates for the runtime the application ships with, and install application updates promptly.

Risks and limits

  • .NET Framework updates can affect several Framework applications in the same update. They arrive with monthly Windows updates; test before production as usual.
  • Removing an old runtime can break an application that still needs it. Confirm with the vendor first.
  • WSUS can report confusing results. Microsoft notes that WSUS might in some cases report a missing update for an older version than the one installed; check against the versions actually present.
  • Dates and versions here are as listed on 14 November 2026. Check the support policy page before acting.
  • No commands or registry changes are given. Microsoft's .NET installation page documents the server opt-in and blocking settings; test any change on a non-production server first.

Sources

Opened 14 November 2026.

Related service: Managed support.

Related future topics

  • Testing .NET and Windows updates before production on a hosted server.
  • Questions to ask an application vendor about runtime support.
  • Moving an IIS-hosted ASP.NET Core application to a new .NET version.

Learning notes

  • Supported .NET Framework releases are Windows components, but specific older releases have retired. Check both the installed Framework version and the Windows lifecycle.
  • Modern .NET is a separate product updated through Microsoft Update, and servers are not updated automatically by default.
  • Framework-dependent applications pick up patch updates; self-contained ones need a new application release.
  • .NET 8 and 9 support ended on 10 November 2026; .NET 10 is the current LTS release.
  • Choose and record one patching method for modern .NET on every server.