How to establish what in the company no longer gets patches

The question “is everything up to date” almost always gets a yes, because updates install themselves. The question “is everything still supported” is an entirely different matter, and the answer usually does not exist.

The difference matters. Software past its end of support does not stop working and displays no warning. It simply stops receiving security patches — and vulnerabilities found after that date stay open forever.

Why this is underrated

Because there is no symptom. The machine behaves identically the day before end of support and the day after. Nothing breaks, nobody complains, nothing reaches the ticket queue.

It is usually noticed only when some vulnerability is exploited at scale — and then it turns out there are three such machines in the company that nobody remembered.

Where it usually sits

Roughly in order of frequency:

Servers that “just work”. A domain controller or file server set up eight years ago, needing no attention and therefore never looked at.

Machines driving equipment. Production, laboratories, measurement gear. A separate case, because replacement is often impossible — I have described that in another note.

Databases. Database engines have shorter support cycles than most people assume, and upgrading is often blocked by an application that only works with the old version.

Application runtimes. The language version a shop or internal application runs on stops receiving patches after end of support regardless of the application itself being actively developed.

Network devices. A router or firewall whose vendor has not released firmware for four years. That device sits on the boundary with the internet, which makes it the worst possible place for this.

Company phones. A five-year-old model no longer receiving patches, reading company mail.

Building the list without buying a tool

Step 1: write down what actually runs

A spreadsheet is enough. Columns: name, version, where it sits, what it is for, who owns the matter.

Sources: the endpoint management console, the directory inventory, network device panels, and — not to be skipped — talking to people. Some things leave no trace in any console.

Step 2: check the end-of-support dates

Vendors publish them openly. For most common systems, databases, runtimes and browsers the dates are also collected by several public reference sites — looking up a name and version takes a minute.

One extra column in the spreadsheet is enough: end-of-support date.

Step 3: split into three groups

• Past the date — the risk already exists.
• Ending within a year — budget and a maintenance window need planning.
• Supported — review in a year.

Step 4: one of three decisions per “past the date” entry

We replace it — with a date and a named owner.

It cannot be replaced, so we isolate it — cut off from the internet, put on its own network segment, restrict what may connect to it, and set a review date.

We knowingly accept the risk — written down, with a justification and a deadline. That is an honest decision if it is a decision. It stops being one when it is merely the absence of a decision.

Worth doing at the same time

While building this list, three things almost always surface that are unrelated to the topic and worth as much:

• machines nobody knew were still running,
• accounts and services left by people who have gone,
• at least one device with a default administrator password.

Which is why this review is usually done once and pays for itself several times.

How not to redo it from scratch every year

The end-of-support date in a spreadsheet ages by itself — that is its advantage. Once a year, sort the list by that column and see what has moved into the first group.

Tie the review to something that happens anyway: the year end, budget planning, a contract review. A deadline tied to nothing does not get kept — tested repeatedly.