End-of-life software fails Cyber Essentials

Most Cyber Essentials failures get argued about — a CVSS score, a missing header, whether a finding is really in scope. End-of-life software isn't one of those. Under Cyber Essentials' requirements for IT infrastructure, any device in scope running software the vendor no longer supports is an automatic fail, full stop. There's no CVSS threshold to argue and no severity to triage — the software's support status is the whole test.

What "unsupported" actually means here

The scheme's definition is narrower than "old" and stricter than "still works fine." Software is supported only while its vendor is still shipping security updates for it. The moment that stops — whether the vendor announces it years in advance or pulls support with no warning — the software is out of compliance, on that date, regardless of whether a patch was actually needed. NCSC's Cyber Essentials scheme doesn't accept "it hasn't been exploited yet" as a defence, because the control isn't measuring exploitation. It's measuring whether anyone is still watching for the next one.

That catches more than the obvious case of an ancient Windows Server box. It catches a web server running an EOL'd Apache or nginx branch that's otherwise been kept current within that branch. It catches a plugin or library still receiving application updates from the site owner but built against a runtime the upstream vendor stopped patching eighteen months ago. Version currency and support status are two different questions, and Cyber Essentials only asks the second one.

Why an annual scan misses it

A point-in-time assessment answers one question honestly: was this device compliant on the day someone looked? Software support timelines don't wait for that date. A product can be fully supported at certification and cross its end-of-life date eleven months into a twelve-month certification window — quietly, with no CVE, no incident, no reason for anyone to go looking. The certificate stays on the wall describing a state of the estate that stopped being true months earlier.

This is the same drift problem that shows up everywhere else in continuous compliance — a firewall rule opened for a project that shipped, a cert renewed onto a host nobody remembers provisioning — except end-of-life status is unusually predictable. Vendors publish EOL dates in advance. The information needed to catch this before it becomes a fail already exists publicly; it just isn't watched.

Finding it without maintaining the list yourself

Tracking end-of-life dates by hand means keeping a spreadsheet current across every OS, web server, database, and library version running on every in-scope device — a list that's stale the moment a vendor updates their support policy. endoflife.date maintains exactly that data as a public product-and-cycle lookup, and it's the practical alternative to re-deriving vendor support calendars from scratch for each customer.

The detection problem is really two problems: knowing what's running, and knowing whether what's running is still supported. The first is a version banner off an open service — the same fingerprinting an external scan already does to find known-vulnerable versions. The second is a lookup against that fingerprint. Neither needs a second collection pass; the same port-and-service data that answers "is this exposed" also answers "is this end-of-life."

What CyberSpec does about it

CyberSpec's continuous scanning runs an end-of-life sweep against every previously fingerprinted service, checking each version banner against current vendor support status rather than waiting for the next full scan to notice a support window closed. When a service crosses into unsupported territory, it's raised as its own finding immediately — not silently folded into the next report, and not something that needs a fresh scan to surface.

That matters specifically because of the drift problem above: the whole failure mode is a date passing quietly between assessments. A compliance view that only reflects the last scan reproduces the exact blind spot an annual pentest already has, just on a shorter cycle. Catching it requires checking continuously against a support calendar that changes on its own schedule, not on the customer's.

The decision this leaves you with

If Cyber Essentials matters to the business, the real question isn't whether an audit will catch unsupported software eventually — it will, that's the one control with zero ambiguity. It's whether you find out from your own tooling before the certification renewal, or from the assessor during it. One of those is a maintenance ticket. The other is a failed audit with your customer's name already on the paperwork.