Skip to main content

Software has an expiry date — even the software that just works

The site looks the same, but the foundation underneath may have stopped getting security updates. Here is what end of life means, and why it matters.

By Lars Henrik Netland

Produced with AI tools, edited and fact-checked by the author

Last updated: 30 June 2026

"The site works fine." That is the most common objection to spending money on technical maintenance, and it is both true and irrelevant at the same time. That something works says nothing about whether it is safe.

Software has something in common with food: it goes out of date. Not because it stops working, but because it stops being looked after.

What "end of life" actually means

Everything a website or web application is built on (the runtime, the frameworks, the databases, the libraries) has a defined lifespan. The publishers promise security updates for a period, typically a few years. Then comes the date when support ends. In the trade it is called "end of life", or EOL.

From that day something important happens: new security holes that are discovered are never patched. The code keeps running as before. The site looks identical. But every new vulnerability that becomes known stays open, for good.

2026 is a big expiry year

This is not theory. On 30 April this year Node.js 20 reached its end date. This is the runtime behind a large share of the world's web backends. No more security updates, whatever is discovered. And Node 20 is just one of around fifty major products reaching end of life in 2026, alongside Java 17 and MySQL 8.0 among others.

At the same time a large number of websites out there are still running on technology that expired long ago — PHP versions that lost support in 2022, Node versions that lost it last year. The owners notice nothing. The sites load as before. That is precisely what makes the problem insidious.

Why attackers love outdated software

When a security hole in a widely used technology becomes publicly known, two things happen at once: the supported versions get an update that closes the hole, and attackers start scanning the internet for systems that have not had it.

The scanning is automated and global. It does not care whether your business is large or small, well known or unknown. It is looking for one thing only: known holes that were never patched. A website on an outdated foundation is by definition on that list, and stays there, because no update is ever coming.

And should something go wrong, it is your business that carries the responsibility. A data breach through a known, unpatched security hole is hard to defend, both towards customers and against the data protection rules.

Looks the same ≠ is equally safe

Here is the core of it: a website can sit untouched for three years and look exactly the same to visitors, while the foundation underneath has gone from supported and safe to unsupported and exposed. Nothing visible has changed. Everything material has.

We have written before that a website is never finished: content, design and features have to develop in step with the business. This is the other, more invisible half of the same truth: even if you change nothing at all, the world changes around your code. Technical maintenance is not the same as redecorating. It is changing the oil.

What technical maintenance actually involves

Concretely it is about things like this:

  • Upgrading runtimes before they reach their end date, planned and tested, not in a panic afterwards.
  • Regular updates of dependencies and frameworks, with testing that confirms everything still works.
  • Monitoring that picks up when a component in the solution gains known vulnerabilities.
  • A person with responsibility who actually knows which versions your solution runs on, and when they expire.

This is the core of a sensible operations and maintenance agreement, and it applies to the backend just as much as to the visible parts.

The questions to ask

Do you know which versions your website runs on today? Very few do, and that is fine. But somebody should know. Ask your supplier:

  1. Which runtimes and frameworks does our solution run on, and when do they reach end of life?
  2. Who is responsible for upgrading before that date, and is it part of our agreement?
  3. When was the foundation last upgraded?

If the answer to the last one is "never" or "don't know", you do not have an acute problem, but you do have a date in the calendar that gets closer every day. The difference between good and bad operations is whether someone sees it coming.