Running software that no longer gets updates? Cyber Essentials will flag it

Here's a scenario that plays out often enough to be a pattern, not a one-off: a business is running a version of Windows, or an older release of PHP on their web server, or a copy of Microsoft Office that's several major versions behind. It works fine. Nobody's complained about it. The machine does its job. What it doesn't do is receive security updates any more, because the vendor stopped issuing them for that version months or years ago. Every vulnerability discovered in that software since the end-of-life date has been publicly documented and left permanently unfixed on that machine.

Cyber Essentials asks about this directly under CE5 Patch Management: do you use only software versions that still receive security updates? It's the companion question to patching within 14 days, and it catches a different but related problem. Patching within 14 days only works if the software you're running is still being patched at all.

What end-of-life software actually means

Every piece of software has a support lifecycle. Vendors commit to releasing security patches for a defined period, after which the product reaches end-of-life and updates stop. From that point, any new vulnerability discovered in that software stays unpatched forever, regardless of how serious it is or how many people are affected by it.

This isn't a niche problem. Windows 10 reached end of life in October 2025. Older versions of PHP that power a significant proportion of the web have been out of support for years. Specific releases of widely-used business software frequently fall off the support calendar without the businesses using them noticing, because the software still runs, and running feels the same as supported.

Why this gap is so common in small businesses

End-of-life software tends to accumulate invisibly. Nobody makes a decision to run unsupported software. It happens because an upgrade was deferred once, then deferred again, then forgotten about entirely because the thing still worked. Legacy machines kept for one specific purpose are particularly prone to this: the dedicated computer that runs one piece of specialist software, the server that's been in the corner for six years, the laptop someone uses occasionally that nobody's touched since the original setup.

Upgrading can also feel risky in a way that patching doesn't. A security patch is a small, specific change. A version upgrade might change the interface, affect compatibility with other tools, or require budget for a new licence. Those concerns are often legitimate, but deferring an upgrade indefinitely doesn't make the risk of running unsupported software smaller, it makes it permanent.

How to find out what you're actually running

Start by listing every piece of software in regular use across every device, including operating systems, browsers, office suites, server software if applicable, and any specialist tools used for specific business functions. For each one, check the vendor's support page for the current support status of the version you're running. Most major vendors publish this information clearly, and a quick search for "[software name] end of life dates" will usually surface it immediately.

Where something has reached end-of-life, the question becomes whether it can be upgraded, replaced, or decommissioned. A machine that genuinely can't run a supported version of an operating system is a machine that needs replacing, not patching, and an assessor will reach the same conclusion.

Frequently asked questions

Does this apply to every piece of software, or just the operating system? Cyber Essentials' scope covers any software that could be exploited to access or damage systems, which in practice includes operating systems, browsers, office software, and any server-side software your business runs, not just the OS.

What if we rely on specialist software that hasn't been updated by the vendor in years? This is a genuine challenge for businesses using niche or legacy software; the honest answer is that running it represents an accepted risk, and an assessor may ask how that risk is being managed or mitigated in the absence of a supported alternative.

Does a web browser count, even though it updates itself automatically? Yes, and auto-updating browsers are generally fine for this requirement precisely because they stay current without manual intervention; the problem arises with software that doesn't update itself and nobody is manually keeping current.

How does this interact with the 14-day patching requirement? They work together: the 14-day requirement covers applying updates when they're available, while this requirement covers ensuring you're running software that still has updates available to apply.

What counts as "still receiving security updates" if a vendor releases patches infrequently? The test is whether the vendor has formally ended support for that version, not how often patches happen to be released; infrequent patches for a supported product are fine, zero patches because support ended is not.

Run a free scan of your domain and your CE Readiness checklist will walk through this and the rest of CE5 Patch Management, completing your full pre-assessment picture before your assessor asks: olimpio.io/free-scan