Outdated or end of life? How to tell the two

"Is our site up to date?" sounds like a yes-or-no question. It is really two questions, and they have different answers, different risks and different fixes. One is whether you are running the newest patch in your release line. The other is whether anyone still ships security fixes for that line at all. This post separates them, shows real version data for WordPress, PHP and Next.js, and explains how CyberSpec now reports each one.

Two kinds of "old"

Most software ships in release lines (also called branches or cycles): WordPress 6.9, PHP 8.3, Next.js 16. Inside a line, the vendor publishes patch releases, such as 6.9.1 then 6.9.2 and onwards, which mostly carry bug and security fixes. At some point the vendor stops patching a line entirely. That date is its end of life.

That gives two separate states:

State	What it means	Fix
Outdated	The line is still supported, but you are behind its newest patch	Apply the patch release. Usually a small, low-risk update
End of life	The line no longer receives security fixes at all	Move to a supported line. Often a real upgrade project

The difference matters because an outdated site can be fixed this afternoon, while an end-of-life one cannot be fixed by patching at all. Nothing will ever be released for it again.

What the real data looks like

Support policies vary widely, which is why guessing from the version number fails. Here is what endoflife.date reported for three common stacks at the time of writing:

WordPress keeps patching old branches for a long time. Every line from 6.0 to 7.1 is still marked as receiving security fixes. A site on WordPress 6.1.1 is therefore outdated, not end of life: the fix is updating to 6.1.15, the newest release in that line, not a jump to 7.x. That is why "it's an old WordPress" is not, on its own, an end-of-life verdict.

PHP gives every line a fixed end date. PHP 8.1 reached end of life on 31 December 2025, and 8.2 follows on 31 December 2026. A site still on PHP 8.1 is end of life whatever patch it is on: 8.1.34 is the last release that line will ever get.

Next.js moves fast. Next.js 15 reached end of life on 21 October 2026 and 14 a year earlier, while 16 is current. A Next.js 15 app that was fine last month is unsupported this month, without anyone touching it.

The same version number can mean very different things depending on the project, so the check has to look up each project's own support calendar.

Why both matter for Cyber Essentials

Cyber Essentials treats the two states differently, and so should you.

End-of-life software is a straight fail. Under the security update management control, software in scope must be licensed and supported. Unsupported software has to be removed or cut off from the internet. There is no severity to argue about. We covered this in detail in end-of-life software fails Cyber Essentials.

Missing patches fail when they matter. Updates must be applied within 14 days of release when the vendor rates the fix critical or high risk, when it fixes a vulnerability scoring 7.0 or more, or when the vendor gives no severity detail. Being one patch behind is not automatically a fail. Being behind on a patch that fixes a serious vulnerability is.

In practice the safest habit is the same for both: stay on a supported line, and apply patch releases promptly instead of waiting to find out which ones were security fixes. The WordPress REST API RCE is a good example of a fix that existed long before most affected sites applied it.

How CyberSpec reports it

CyberSpec already names the frameworks and CMSs it detects on your verified sites, such as WordPress, Next.js, Drupal or PHP, with the version when the site exposes it. Each detected version is now checked against that project's support data from endoflife.date, together with the server software the network scan already fingerprints, such as nginx or OpenSSH. The result is one of two findings:

• End of life (high severity): the release line no longer gets security fixes. The finding states the date support ended and asks you to move to a supported line. On the Cyber Essentials readiness view it counts against security update management, because that is how an assessor treats it.
• Outdated version (medium severity): the line is supported, but a newer patch exists. The finding names the exact release to update to, for example "Update WordPress to 6.9.10 or later." On the readiness view it is listed under good-practice items rather than as a failure. Any serious vulnerability the missing patch fixes is reported separately as its own CVE finding.

When a line is both behind and unsupported, you get the end-of-life finding only. Upgrading within a dead line does not solve the problem, so there is no point telling you to. Findings close on their own when a later check sees the site patched or upgraded. New ones appear in the daily digest email, with the fix, within about a day.

Two honest limits. The check needs a version: many sites hide theirs, and those stay a plain detection with no verdict. And version strings that are not plain numbers, such as 1.0.2k or a beta tag, are skipped rather than guessed, because a wrong "you're outdated" is worse than none.

What to do with this

List what your public sites actually run, then ask both questions for each item: is this line still supported, and am I on its newest patch? If the answer to the first is no, plan the upgrade now, because no patch is coming. If only the second is no, it is usually a short job. Continuous scanning is how you keep asking both questions after the day you first check.