What “end of life” actually means
Every piece of software has a support lifecycle. For a given version — say PHP 8.1, Ubuntu 20.04, or Redis 6 — the vendor commits to shipping bug fixes and, crucially, security patches for a defined window. When that window closes, the version reaches end of life (EOL): no more patches, no more advisories, no more fixes — even for critical vulnerabilities.
The software doesn't stop working the day it goes EOL. That's exactly the problem. It keeps serving traffic, keeps holding data, and keeps looking healthy — while the stream of security fixes that was protecting it has silently dried up. From that day on, every newly disclosed CVE against it is permanent.
EOL is a known, dated event — which is why auditors are unforgiving about it
Unlike a zero-day, an EOL date is published years in advance. An auditor who finds you running unsupported software isn't looking at bad luck — they're looking at a risk you could see coming and didn't manage. That's the difference between an observation and a finding.
Why every framework cares
“Keep your software supported and patched” shows up in every major standard, under slightly different language:
| Framework | What it requires |
|---|---|
| PCI DSS v4.0 — Req. 6.3.3 | All system components must be protected from known vulnerabilities by installing applicable security patches. Software that is no longer supported by the vendor cannot meet this, so it must be removed or covered by a documented compensating control. |
| SOC 2 (CC7.1) | The entity must identify and manage vulnerabilities. Running EOL software with no patch path is the textbook example of an unmanaged vulnerability an auditor will test for. |
| ISO 27001:2022 — A.8.8 | Management of technical vulnerabilities: obtain timely information about vulnerabilities and take action. Unsupported software makes 'take action' impossible, so it must be tracked and risk-assessed. |
| NIS2 / DORA | Both demand proactive risk management of ICT assets. An accurate software inventory with lifecycle tracking is foundational evidence for essential and financial entities. |
The common thread
You can only patch what you know you're running. Every one of these controls quietly assumes you have an accurate, current inventory of your software and its versions. Most organisations don't — which is why this is such a frequent finding.
Why the spreadsheet always loses
The usual approach is a spreadsheet: someone lists the technologies in use, notes the versions, and maybe pastes in an EOL date they googled. It fails for three predictable reasons:
The dates go stale the moment you save the file
EOL dates get revised, extended, or brought forward by vendors. A date typed in once is a snapshot, not a signal — and nobody re-checks 40 rows by hand every quarter.
Nobody is watching the calendar
A version that is 'supported until next March' needs someone to notice in February. A static list never raises its hand. The first time anyone looks is usually the week before the audit.
It drifts from reality
New services get deployed, versions get bumped, old boxes linger. Without a single owned inventory, the spreadsheet and production quietly diverge until the document is fiction.
What “good” looks like
A software inventory that actually helps you pass an audit has four properties:
- Complete. Every technology that stores, processes, or protects data is listed — with the exact version deployed and the host it runs on.
- Live. EOL dates are resolved from an authoritative source and re-checked automatically, not typed in once.
- Ranked. Anything already EOL or approaching it is surfaced at the top, so remediation effort goes where the risk is.
- Proactive. The system warns you months ahead, so upgrades are planned into a sprint — not scrambled the week a CVE drops.
How AllowNow does it
AllowNow's Software Inventory turns lifecycle tracking into a living control:
| Capability | What it gives you |
|---|---|
| Search & add | Look up any technology — nginx, PHP, Docker, PostgreSQL, memcached — and record the version you run, backed by the endoflife.date catalogue. |
| Automatic EOL dates | Pick a release cycle and AllowNow resolves its EOL date, latest patch, and support status — no manual date entry. |
| Highlighting | Items that are EOL or approaching it are badged and sorted to the top, with an at-a-glance count of what needs attention. |
| Automatic reminders | Owners get an email digest of software that is EOL or nearing it, so you act months ahead — and it re-checks dates so nothing lapses silently. |
Turn an audit scramble into a background task
Instead of reconstructing a software list under deadline pressure, you maintain it once and let AllowNow keep the dates honest. When the auditor asks “how do you manage unsupported software?”, the answer is a live inventory with dated evidence and a reminder trail — not a promise.
Ready to build yours? Follow the step-by-step guide to tracking software end-of-life to set up your inventory in about ten minutes.