End-of-Life Software: Planning Around What Cannot Be Patched

Once a product stops receiving security updates, no amount of vulnerability management helps it. The finding will appear in every report, the fix column will say upgrade, and the answer will be that the application only runs on that version. Cyber Essentials is direct about this: unsupported software must be removed from scope or segregated, and Windows 10 reaching its end of support on 14 October 2025 put that in front of a great many organisations at once.

Knowing what you actually have

Start with an inventory that includes versions and support dates, because most organisations discover more than they expected. Operating systems are the visible layer and rarely the whole story. Database engines, application frameworks, runtime libraries, hypervisors, network device firmware and the embedded systems inside medical or industrial equipment all have their own end of support dates. Add a column for the date support ends and sort by it, which turns a vague worry into a schedule with a budget attached and an order of work.

The three honest options

Replace, extend or isolate. Replacement is the only one that removes the problem, and it is the one that needs lead time and money. Extended support programmes buy a defined period at a cost that usually rises each year, which suits an estate with a migration already funded and dated. Isolation is what you do for the machine running a controller that the manufacturer stopped supporting in 2018: no internet access, a firewall policy allowing only the traffic the application needs, no shared credentials with the rest of the estate, and monitoring on the segment.

“Isolation gets promised and rarely delivered. The machine is put on its own VLAN and then somebody allows access from the whole office network so people can reach the application, which returns you to where you started. Write down exactly which sources and ports are permitted, then have somebody test it from a normal workstation and prove they cannot reach it.”

William Fieldhouse, Director, Aardwolf Security Ltd

Documenting the decision so it survives an audit

A risk acceptance is only credible when it names things. Record the system, the reason it cannot be upgraded, the compensating controls in place, the person accepting the risk, and the date the acceptance expires. An expiry date is the part that matters, because it forces the conversation to happen again rather than allowing the exception to become permanent. Auditors and certification assessors accept documented, controlled exceptions far more readily than they accept a system nobody has thought about.

Keeping the pressure on

Report unsupported software as its own metric rather than folding it into the general finding count, where it disappears among patchable items. Track the number of unsupported systems and the number with compensating controls in place, and show both to whoever owns the budget. Vulnerability assessment and reporting gives you the inventory side, and internal security assessments show whether the isolation you have described actually holds when somebody tries to cross it, which is the part that decides whether the compensating control is real.

Frequently asked questions about unsupported software

These questions come up whenever an end of support date approaches.

Does extended support satisfy Cyber Essentials?

Where the vendor is still providing security updates for the version in use, it generally does. Read the specific arrangement, since some extended programmes cover only critical issues and some cover a subset of products.

Can a firewall make an old system acceptable?

It makes it survivable, not acceptable indefinitely. Segmentation limits what an attacker reaches after compromising the system, and it does nothing about the compromise itself, so keep a replacement plan with a date on it.