End of support is a date on a vendor web page, not an event you can feel. Nothing breaks that morning, no alarm fires, no customer notices. What changes is that the flow of security fixes stops permanently, and every vulnerability discovered from that day onward stays open in your estate forever. That is the moment unsupported software crosses over from an engineering preference into a compliance, insurance and contractual problem.
What end of life actually means
It means the vendor will never issue another security patch for that version, however severe the flaw. It does not mean the software stops running, and that is precisely the trap. End of support is a permanent, one way change to your risk profile that produces no visible symptom on the day it takes effect.
The vocabulary matters when you are filling in a questionnaire:
- ▸End of sale means you cannot buy it. Irrelevant to your risk.
- ▸End of mainstream support means no new features and often no free bug fixes, but security updates may continue for a defined period.
- ▸End of extended support is the real line. After it, no security updates at all, unless you buy into a paid extension programme where one exists.
- ▸Paid extensions are a bridge, not a destination. They cost more each year by design, and they eventually stop too.
This applies to every layer, not just the obvious one. Vendors publish these dates years ahead: the Microsoft product lifecycle covers the Windows and server estate, and Node.js releases and end-of-life covers a runtime that quietly sits under a very large number of business applications.
The day patches stop, risk starts compounding
Because exposure accumulates while your defences stay fixed. On day one after support ends, your risk is roughly what it was the day before. Six months later, every vulnerability published against that version in the meantime is a permanent hole, and there will never be a fix.
- ▸Exposure only moves in one direction. There is no maintenance activity that reduces it, because maintenance no longer exists for that version.
- ▸Attack tooling improves. Techniques that once needed a specialist become packaged and rented, so the population of people who can exploit your version keeps growing.
- ▸Compensating controls decay too. Segmentation drifts, firewall rules accumulate exceptions, and the WAF signature that blocked one pattern does nothing for the next.
- ▸The dependency underneath ages faster than the app. An application can be actively developed and still sit on an unsupported runtime, which is the most common version of this problem we find.
The honest framing for a board: unsupported software is not a vulnerability, it is a guarantee of future vulnerabilities with no remediation path.
Your insurer and your auditor now ask the same question
Directly and in writing. Cyber insurance proposal forms and enterprise vendor security questionnaires both ask whether you run unsupported software, how quickly you patch, whether administrative access uses phishing resistant multi-factor authentication, and whether backups are tested. These are not formalities, they are the underwriting and the procurement decision.
- ▸A wrong answer on a proposal form is a coverage problem. Insurers ask because the answer materially affects risk. Answering optimistically about something you have not inventoried is a bad position to be in at claim time.
- ▸Being unable to answer is itself the finding. Auditors do not need to find an exploited system. If you cannot produce an accurate inventory with owners and support dates, the control is absent by definition.
- ▸Enterprise customers push it down the chain. If you sell to larger organisations or the public sector, their questionnaire becomes your requirement, and a poor answer costs you the contract long before it costs you a breach.
Asset management sits at the front of every serious control framework for exactly this reason. The NIST Cybersecurity Framework starts with identifying what you have, because every downstream control depends on a complete inventory.
EU regulation treats unsupported software as unmanaged risk
As a governance failure rather than a technical detail. The EU NIS2 Directive requires in-scope organisations to take risk management measures covering their systems and their supply chain, with incident reporting duties and explicit management body accountability. Running software that can never be patched, with no register and no plan, is difficult to present as managed risk.
The EU Cyber Resilience Act approaches the same problem from the other side. It places obligations on products with digital elements, including vulnerability handling and declared support periods. Two practical consequences for a business owner:
- ▸If you buy software, support periods become a stated, comparable property. "How long will this be supported?" moves from an awkward sales question to something you can require in writing during procurement.
- ▸If you sell software, you are the manufacturer. Whatever you ship to customers, including bespoke systems and connected products, brings vulnerability handling duties with it. Build that assumption into your roadmap now rather than discovering it during a customer audit.
Neither regime asks you to be perfect. Both assume you know what you run, that you have a plan with dates, and that someone senior owns it.
Build an end-of-life register
One table, one row per component, one named human per row. The register is what turns a vague anxiety into a budget line and an audit answer. It should be boring, complete and current, and it should live somewhere your finance and leadership teams can read it, not buried in a ticketing system.
The fields that actually matter:
- ▸Component and exact version. Not "our CRM", but the application, its runtime, its database and its host OS as separate rows.
- ▸Layer. Operating system, runtime, framework, library, appliance firmware, plugin, or hosted service.
- ▸Vendor and published end of support date. With a link to the vendor page as evidence.
- ▸Internet exposure. Reachable from the internet, yes or no, and what authentication sits in front of it.
- ▸Data touched. Personal data, payment data, credentials, or nothing sensitive. This drives urgency and your regulatory position.
- ▸Named owner. A person, not a team or a supplier.
- ▸Decision and target quarter. Upgrade, replace, isolate or retire, with a budget owner attached.
- ▸Compensating controls in place today. What is actually reducing the risk while the item waits.
Keep the register from rotting
By generating most of it automatically. A register maintained by hand is dead within two quarters, because nobody updates a spreadsheet after a deployment. The fix is to derive it from artefacts your build and infrastructure already produce, then review the exceptions rather than the whole list.
- ▸Produce a bill of materials per build. A machine readable inventory in a standard format such as CycloneDX gives you a component list you can diff over time and query when the next major advisory lands.
- ▸Rescan your external footprint monthly. New subdomains, forgotten staging environments and shadow SaaS appear constantly, and the register is only as good as its coverage.
- ▸Set a standing quarterly review. Anything within twelve months of end of support gets an owner and a budget decision. Anything already past it gets a date this quarter or a written acceptance signed by someone senior.
- ▸Attach it to your maintenance arrangement. If you pay somebody for upkeep, this register is part of the deliverable. What Website Maintenance Should Actually Include (and What You Are Probably Paying For) sets out what that should cover.
When the clock has already run out
Triage by exposure and data sensitivity, then move. Most organisations discover several items already past their date, and the temptation is either panic or paralysis. Neither is necessary. Sort into four buckets and give every item a decision within a fortnight.
- ▸Upgrade in place. Cheapest when a supported version of the same product exists and your integrations survive it. Do this first and get the easy wins off the register.
- ▸Replace. The right call when the product is dead, the supplier has vanished, or the licensing has become extortionate. Plan it as a project, not an emergency.
- ▸Isolate. For systems that genuinely cannot move, such as machinery controllers, remove all internet paths, segment the network, strip shared credentials and log everything.
- ▸Retire. The best outcome and the most commonly missed. A surprising share of legacy systems are still running because nobody checked whether anyone still uses them.
For the two migrations that come up most often, Leaving WordPress: A Migration Playbook That Does Not Lose Your SEO covers the public web side without losing search visibility, and Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software covers moving operational systems off tools you have outgrown. If you want the practical control baseline to pair with the register, use The Small Business Website Security Checklist for 2026.
How TuniCyberLabs helps
We build the register with you, from real artefacts rather than memory: an external footprint scan, a component inventory per application, vendor support dates with evidence links, and a named owner and target quarter for every row past or approaching its date. Then we do the work, upgrading what can be upgraded, replacing what cannot, and isolating what has to stay. Estonian base, engineering team in Tunisia, senior modernisation work at a cost that lets you actually finish the programme.
Want your end-of-life register built and costed this quarter? See how we work.