What "out of support" means for software you depend on

Your supplier has mentioned that a framework, or the server your application runs on, is "going out of support". It sounded like something to take seriously, but it wasn't clear how. The application is working. Nobody has complained. And on the day the date passes, nothing visible changes at all, which is exactly why it deserves a plan. This article explains what support means, what it doesn't, why dates are published, what to say when an auditor or insurer asks, and the options you have. It is written for the person who carries the risk, not the person who writes the code.

What support covers

When a vendor supports a product, three things are normally included.

• Security fixes. When someone finds a weakness, the vendor publishes a correction. This is the part that matters most.
• Bug fixes. Problems that aren't security issues, such as incorrect results or crashes, are corrected in updates.
• Vendor help. You can raise a problem with the vendor and expect them to look at it.

Support does not mean the product will get new features, or that it will work with everything else you own. It means the vendor is still looking after it.

Microsoft's own lifecycle FAQ for Windows puts the consequence plainly: after the end date, customers "will no longer receive technical assistance, software updates, or security fixes". The same page notes that the operating system may still work after that date.

Software keeps working, and that is the difficulty

When support ends, the software doesn't stop. The server restarts as usual, the application carries on, and your staff see no difference. If anything, that is reassuring in the wrong way.

What changes is that the weaknesses found from that day onwards stay unfixed. Every month, researchers and attackers find new ones across the industry. For supported software, the vendor issues a correction and you install it. For unsupported software, the weakness stays, and the longer it stays the more widely it is known. Nothing about your own system has altered, but the exposure has.

That's the sense in which software becomes "exposed". The safety net of fixes has been withdrawn, quietly, and the risk rises slowly and invisibly, while the software itself carries on as before.

Why vendors publish dates

Vendors set a support period when a product is released, and publish the end date in advance. The reason is practical: they can't maintain every old version indefinitely, and customers need notice to plan.

The periods differ by product. A few real examples, each from the publisher:

The Windows Server 2012 dates are covered in more detail in our article on what to do when Windows Server 2012 updates end. The .NET dates are worth a closer look, because they surprise people. Microsoft's policy page lists .NET 8 and .NET 9 as ending on the same day, 10 November 2026, and gives the support periods as three years for long-term support releases and two years for standard-term releases. .NET 10, a long-term support release, is listed as supported until 14 November 2028. We will look at what that means for .NET applications specifically in the coming weeks.

Dates are worth checking against the publisher's own page, as dates and rules are occasionally revised. The ones above are as we found them on 22 October 2026.

Questions it raises for auditors, insurers and customers

Unsupported software tends to come to light through other people's questions. A customer's security questionnaire asks whether all software is supported by its vendor. An insurer asks about patching. An auditor asks for an inventory and reviews the end dates.

This is not unreasonable of them. The UK's Cyber Essentials scheme, for instance, includes a security update management control; we explain what it involves in our plain-English guide to Cyber Essentials. If you can't say what you run, and when each part goes out of support, those questions are hard to answer well. If you can, they are straightforward, and the conversation moves on.

Your options

When something is approaching its end date, there are four broad choices. They sit on a ladder, from least to most change.

1. Stay and mitigate. Keep the software, and reduce the exposure around it. That might mean isolating the server from the internet, restricting who can reach it, tightening access and monitoring it more closely. Some vendors also sell extended security updates for a time, usually for a fee. This buys time. It doesn't remove the underlying issue, and it should come with a review date.
2. Upgrade. Move to a version that is still supported. For a framework such as .NET, this is often the best balance of cost and benefit, and the earlier you plan it the smoother it goes.
3. Replace. If the software is too old to upgrade sensibly, or the business has moved on, replace it with something new, with a proper transition plan.
4. Retire. Sometimes nobody really needs it any more. Switching something off, once you have kept what the law and the business need, is the cheapest option of all.

There's no single right answer. The right rung depends on how critical the system is, how exposed it is, and what the upgrade would involve.

Why planning is cheaper than reacting

An upgrade done to a plan can be tested, scheduled around the business and done without drama. An upgrade done after an incident, or in a rush to satisfy a customer's deadline, is the same work under pressure, with less choice about when and how.

There's also more room for choice early on. With a year in hand you can look at all four options. With a week, you often have one.

Finding out what you run

You can't plan around dates you haven't seen. The first piece of work is a simple inventory: what software and platforms your organisation depends on, which version each is on, where it runs, and who looks after it.

For each item, record the end-of-support date from the publisher's own page. That produces a short list ordered by date, which is more useful than any amount of worry. Many organisations are surprised to find it is shorter than they feared, and a few items on it turn out to be easy.

A sensible first step

This week, you could:

1. Ask whoever looks after your software for a list of the frameworks, operating systems and databases it uses, with version numbers.
2. Look up the end-of-support date for each one on the vendor's own lifecycle page, and note anything within the next twelve months.
3. For each item that's close, pick a rung on the ladder above, even provisionally, so that the conversation with your supplier starts from an option.

If you'd like help with this, a software health audit of one system includes exactly this kind of review, and our software care service looks after systems so that dates like these are planned for well in advance.