An end-of-life system is not technical debt. It's a risk register entry
Almost every company has some end-of-life system. An old server with an application nobody can move any more, a distribution that stopped getting updates two years ago, a device whose manufacturer disappeared from the market long ago. It is usually treated as technical debt: something that will have to be cleaned up one day, it works for now, so let it work.
That is a category error. An end-of-life system is not a backlog item. It is a risk decision that someone makes, consciously or not, every day that system keeps running.
Why EOL changes the nature of the problem
A supported system that contains a vulnerability has a way out: the vendor releases a patch, you install it, the matter is closed. That is the normal cycle and it is not a risk, it is work.
An end-of-life system loses the vendor's standard free support path. That does not always mean a patch will never appear: extended paid support, a supplier backport or a third-party solution may exist. Each option has to be confirmed for the particular product. The realistic choices are upgrade or migration, extended support, compensating controls, time-boxed risk acceptance or retirement.
And that is what turns EOL into a risk register entry rather than a technical task. A technical task has a solution. A risk has to be consciously managed with something.
"We're about to migrate it" is not a plan
The most common reaction to EOL is "we know, we plan to migrate it". The trouble is that this sentence is not a migration plan. It is a migration intention, and an intention has no date, no owner and no milestones. Systems "to be migrated this year" can stand for five, because there is always something more urgent, and EOL risk is quiet: it does not hurt until it explodes.
The auditor knows this and will not settle for a declaration. They will ask for specifics, and specifics have three elements.
The three things an auditor must see
Interestingly, none of them is technical. The auditor does not expect you to eliminate EOL overnight. They expect you to have it under control, and control looks like this:
A named risk owner. A specific person who has taken this risk upon themselves. Not "the IT department", not "the company", but a name. The point is that someone is answerable for the decision and has an interest in keeping an eye on it. A risk with no owner belongs to no one, and a risk that belongs to no one is not managed.
A time-boxed acceptance. The decision to keep an end-of-life system must have an expiry date. Not "we accept this risk", but "we accept this risk until the end of Q3, after which the decision is taken again". An open-ended acceptance is an anti-pattern, because in practice it means "we forget about this forever". An expiry date forces a return to the matter before the risk quietly grows.
An exit plan with milestones. It need not be complicated, but it must be concrete: migration, isolation or decommissioning, with interim dates. "By year end we move the application to a supported version, by end of August we have a test environment" is a plan. "We'll sort it out at some point" is not.
Those three things together turn EOL from a hidden bomb into a managed, documented risk. And that is exactly what a risk-based approach in ISO 27001 or NIS2 requires: not zero risk, but conscious command of it.
Compensating controls for the transition
Since the end-of-life system stays for a while, it is worth reducing its exposure. Typical measures are network segmentation, access limited to essential services, removal of internet exposure, heightened monitoring or virtual patching. These do not replace a vendor fix, but they may reduce the likelihood and impact of exploitation.
When keeping EOL is rational
I would be dishonest to claim EOL must always be removed immediately. Sometimes consciously keeping an end-of-life system is a reasonable decision. An isolated machine with no network connection, driving a device that will be retired within a year anyway, where the migration cost is absurdly high against the real risk, is a legitimate candidate for acceptance. The point is not that EOL should not exist. The point is that its existence should be a signed decision, not an omission nobody remembers.
The difference between those two is everything. The auditor will accept the first. The second is a nonconformity.
In practice
Keeping a risk acceptance with an owner, an expiry date and a reminder as the deadline approaches can be done by hand, but it is easy to forget, and a forgotten acceptance is once again an open-ended acceptance. I built this as part of the process: an EOL acceptance with an owner, time-boxed, that flags itself when it expires. If you want to see what such a time-boxed acceptance looks like, enter the demo.
An end-of-life system is not a source of shame. The problem is the absence of an explicit decision and controls. A risk-register entry does not guarantee a positive audit result, but it shows the owner, expiry, compensating controls and exit plan needed to assess whether the risk is genuinely managed.
Sources
Weekly CVE digest
One email a week with newly published vulnerabilities worth knowing about. No account needed.
This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.