Managing Obsolescence: The Risk Hiding in End-of-Life Systems

Illustration for: Managing Obsolescence: The Risk Hiding in End-of-Life Systems

Every estate of any age carries systems the vendor has stopped supporting. These are not just old assets with more vulnerabilities than average. They are a different class of risk entirely, because the normal remedy, patching, is permanently unavailable. Managing obsolescence deliberately is one of the cheapest risk reductions available, yet most organisations only discover their exposure during an audit or an incident.

Why end of life is a distinct risk class

For a supported system, a new critical vulnerability starts a race between your patching process and the attackers. For an end-of-life system there is no race. The vendor will never ship a fix. Every vulnerability discovered after the end-of-support date is permanent, and researchers keep finding them for years because the codebase is often shared with newer versions. When a flaw is patched in Windows Server 2022, attackers diff the patch and check whether the same code exists in versions that will never receive it.

Line chart of unpatched exploitable vulnerabilities over time, where a supported platform sawtooths as patches land while an end of life platform climbs steadily after support ends

After end of support the exposure line only climbs, because no fixes will ever arrive.

This changes the risk calculation in three ways.

• Likelihood only rises. Exploit availability for old platforms improves over time as tooling matures and techniques are published.
• The exposure is open-ended. A missed patch is a gap for weeks, while an EOL platform is a gap for the rest of its life.
• Compliance positions weaken. ISO 27001 auditors, Cyber Essentials assessors and cyber insurers all now ask directly about unsupported software. Cyber Essentials in particular requires that software is licensed and supported, so a single EOL server in scope can cost you certification.

The incidents were predictable

The pattern is well established. WannaCry in May 2017 hit the NHS hard, and the National Audit Office’s report was blunt about the cause, finding that unpatched and unsupported Windows systems were a core factor, with Windows XP and unpatched Windows 7 estates still widespread across trusts. Organisations still running Windows Server 2003 after its July 2015 end of support spent years exposed to remotely exploitable flaws with no fix available. Windows Server 2008 and 2008 R2 reached end of support in January 2020 and promptly became a favourite ransomware foothold, because they sat in exactly the sort of forgotten corners that never made the migration budget.

Network kit is arguably worse. Unsupported firewalls, VPN concentrators and switches sit at the network edge, internet-facing, and are rarely covered by EDR. Several of the mass-exploitation campaigns of the last few years targeted appliance families where a portion of the installed base was past end of support and could not take the emergency fix at all. Those owners had no good options on the day, because the decision that mattered had been missed two years earlier.

Build an obsolescence register

You cannot manage what you have not dated. The obsolescence register is a view over your asset inventory that adds vendor lifecycle data, and it needs four things.

• End of mainstream support and end of extended support dates for each operating system, major application, database and hardware platform.
• The count of assets on each platform, and which of them are critical or internet-facing.
• The planned action, whether upgrade, replace, decommission, or accept with compensating controls.
• A named owner and a target date for that action.

Vendor lifecycle dates are public. Microsoft, Red Hat, Cisco and the major database vendors all publish them, and community-maintained sources collate them. The work is joining that data to your inventory, which is one more reason the inventory itself has to be sound. A simple table is enough to start.

Refresh it quarterly. The dates do not move often, but your estate does.

Plan 18 to 24 months ahead

The organisations that get burnt are rarely surprised by the date. They are surprised by how long replacement takes. A server migration involves application compatibility testing, licensing, change windows and sometimes a vendor who must certify their product on the new platform. Hardware replacement adds procurement lead times, which for network kit have stretched to months in recent years. Budget cycles add another lag, because if the money is agreed annually, a date you notice in month two of the financial year may not be fundable until month fourteen.

Working back from an end-of-support date, 18 to 24 months is a realistic runway for anything non-trivial. That means your register needs to flag platforms whose dates fall within the next two years, not the next quarter. Treat the flag as the trigger to open a project, assign an owner and put a line in the budget submission. An EOL date arriving without a funded plan is a governance failure, not a technical one.

Timeline of the 24 month replacement runway with milestones from flagging the date through budgeting, testing and procurement to migration before end of support

Working back from an end of support date, 18 to 24 months is a realistic runway for anything non trivial.

Compensating controls when replacement is impossible

Sometimes replacement genuinely cannot happen on time. A £2 million manufacturing line controlled by software certified only on Windows 7. A clinical device with a decade of service life left. In those cases, say so explicitly and compensate.

• Segment aggressively. Put the system in its own network zone with firewall rules allowing only the specific flows it needs. Assume it will be compromised and limit where that goes.
• Remove internet access entirely, in both directions, unless a documented flow requires it.
• Strip local attack surface by disabling unused services, removing browsers and mail clients, and applying application allow-listing where the platform supports it.
• Increase monitoring. If you cannot prevent, then detect. Forward its logs, watch for new processes and outbound connections, and alert on any authentication from it to the wider estate.
• Document the risk acceptance formally, with the business owner’s signature, a review date, and the compensating controls listed. Undocumented acceptance is just negligence with extra steps.

Compensating controls are a bridge, not a destination. Put a review date on every one and re-justify it annually.

Reporting EOL exposure to the board

Boards understand obsolescence better than most security topics, because it maps to asset depreciation and technical debt, concepts they already own. Give them three numbers, which are the count of unsupported systems, the subset that are critical or internet-facing, and the trend over the last four quarters. Add the date of the next big cliff, meaning the next major platform in your estate to lose support, and the funding status of the plan to deal with it. That is a one-slide report, and it invites exactly the right question, which is why the trend is not falling.

Mock one slide board report with stat tiles for unsupported systems, critical or internet facing count and the next support cliff, above a falling quarterly trend chart

Three numbers, one trend and the next cliff, which is everything a board needs on end of life exposure in one slide.

Start this week by exporting your operating system versions from whatever discovery tooling you have, joining them to public lifecycle dates, and counting what is already past end of support. Most organisations doing this for the first time find something internet-facing. Better you find it than someone else.

Asset obsolescence and end-of-life register in RaptorGRC

Asset obsolescence tracking in RaptorGRC.