Every unsupported platform has a CVE list. That's Common Vulnerabilities and Exposures - a publicly maintained catalogue of known security weaknesses. Right now, anyone with a browser can look up the known vulnerabilities for whatever CMS version you're running. If that version is still supported, the vendor patches those vulnerabilities as they're disclosed. If it's not, the vulnerabilities just... sit there. Documented, searchable, exploitable.
And that list gets longer every single month.
We haven't had a breach. The platform is working fine. The risk of moving is greater than the risk of staying.
I hear some version of this in nearly every conversation I have with a CTO or IT director running an end-of-life platform. And I get it - genuinely. Migration is disruptive, expensive, and comes with its own risks. But I want to walk you through what "working fine" actually means in security terms, because there's a gap between how most technology leaders perceive the risk and what the risk actually looks like when you examine the mechanism.
Before I get into the mechanics, I want to start with the thing that tends to get the sharpest reaction when I raise it with CFOs and finance directors - because if this doesn't shift the conversation, nothing will.
Cyber insurance underwriters are getting increasingly specific about platform support status as part of the underwriting process. They're not just asking "do you have a firewall" anymore. They're asking about specific software versions, patch management processes, and end-of-life timelines. And buried in quite a few policies - sometimes in the exclusions, sometimes in the conditions - is language that limits or excludes coverage for breaches attributable to known vulnerabilities in unsupported software.
Think about what that means. The most likely breach vector for a legacy platform - exploitation of a known, unpatched vulnerability - may be the exact scenario your insurance doesn't cover.
I had a conversation with a managing partner at a law firm last year. They were paying something like £45,000 annually for cyber insurance. Decent coverage, sensible decision. I asked whether they'd checked whether their CMS - which had been end-of-life for about 14 months - was compliant with the policy's technical requirements. They hadn't. Their broker hadn't flagged it either, to be fair. When they checked, the policy had a clause requiring "vendor-supported software for all client-facing systems." Their CMS was client-facing. It wasn't vendor-supported. They were paying for a policy that almost certainly wouldn't have paid out in the exact scenario they were most vulnerable to.
This isn't an edge case. As underwriters become more technically literate - and they are, rapidly - the gap between what firms assume they're covered for and what they're actually covered for is widening.
The upside? A firm that addresses its legacy platform estate before renewal may find that the premium reduction partially offsets the upgrade cost. I've seen cases where the insurance saving alone covered 15-20% of the migration budget. Not enough to justify the project on its own, but enough to change the shape of the business case.
Confirm with your broker whether your current policy covers breaches attributable to unsupported platform vulnerabilities. Do it this week. The answer may accelerate a decision you've been deferring.
Let me be specific about what happens when a platform vendor ends support for a version, because the mechanics matter.
Security researchers - both ethical ones and the other kind - discover vulnerabilities in software all the time. In the platform itself, in its dependencies, in the underlying infrastructure it sits on. When a vulnerability is found and publicly disclosed, the vendor's security team patches the supported versions. Usually within days. Sometimes weeks for complex ones. The patch goes out, you apply it, the window closes.
When you're running an unsupported version, that same vulnerability gets discovered and disclosed in exactly the same way. It appears in the same databases. It's written up in the same security bulletins. Except no patch arrives. Not because the vulnerability is less severe - but because the vendor has stopped maintaining that version.
So now you're in a position where the vulnerability is known, it's documented, and it's open. The scanning tools that attackers use to identify vulnerable systems will find your platform, check the version, cross-reference it against the known vulnerability list, and flag it as exploitable.
This isn't some sophisticated nation-state attack scenario. This is automated scanning at scale. The digital equivalent of someone walking down a street trying every door handle - except they already know which doors don't have locks.
I was talking to an IT director at a mid-sized accountancy firm about eighteen months ago - maybe 250 people, four offices. They were running a version of their CMS that had gone end-of-life about two years prior. He told me the platform was "battle-tested" and that nothing had gone wrong. I asked him how many known vulnerabilities had been disclosed for that version since support ended. He didn't know. We looked it up together. Fourteen. Fourteen publicly documented vulnerabilities with no available patch. He went quiet for a bit after that.
I'll be honest - I've had that conversation enough times that I've stopped being surprised by it. What does still catch me off guard is how often the IT director already suspects the answer before we look it up. They know the platform is out of support. They know they should have moved. They're just hoping nobody asks.
"Nothing has happened yet" is not the same as "nothing is wrong." You're not running a slightly out-of-date platform. You're running a platform with a publicly documented list of exploitable weaknesses and no mechanism for closing them.
If you're operating in a regulated sector - law, financial services, accountancy - the consequences of a breach on a legacy platform extend well beyond the breach itself.
Start with data protection. UK GDPR requires you to take "appropriate technical measures" to protect personal data. Running an unsupported platform with known, unpatched vulnerabilities is difficult to defend as an appropriate technical measure. I'm not a lawyer, but I've sat in enough rooms with compliance teams to know that an ICO investigation following a breach will look specifically at your platform's support status. If the platform was end-of-life and you knew it - or should have known it - that becomes a central finding, not a footnote.
Then there's the sector-specific stuff. If you're a law firm, your SRA Code duties around client confidentiality create obligations that a breach on a legacy platform may violate - and here's the bit that catches people off guard - regardless of whether client data was actually accessed. The demonstrable vulnerability itself may be sufficient. The fact that you were running a platform with known exploitable weaknesses that you hadn't addressed is the problem, not just whether someone got through the door.
Financial services firms face a similar dynamic under FCA obligations. The compliance dimension alone makes the case for addressing this sooner rather than later.
And then there's reputation. A firm that discloses a breach and has to explain it happened because they were running unsupported software faces questions that go well beyond IT. Clients, prospects, and referral partners will wonder about the quality of governance across the whole firm. Rightly or wrongly, it becomes a proxy for how seriously you take risk management in general.
People sometimes treat legacy platform security risk as abstract. It's not.
WannaCry in 2017 is probably the most dramatic example. The ransomware exploited a vulnerability in Windows XP and Windows Server 2003, both unsupported at the time. Microsoft had patched the vulnerability in supported versions two months earlier. But organisations still running unsupported versions - including multiple NHS trusts - had no patch to apply. The result was operational paralysis across healthcare, manufacturing, and professional services. The NHS alone cancelled roughly 19,000 appointments.
The Equifax breach the same year is arguably more instructive for professional services firms. It exploited a known vulnerability in the Apache Struts framework. The patch had been available for months. Equifax hadn't applied it. The breach exposed personal data of 147 million people and cost the company over $1.4 billion in settlements and remediation.
That was ages ago. Things have moved on.
They have - but not in the direction that makes you safer. The volume of disclosed vulnerabilities grows year on year. The time between disclosure and exploitation has shortened. Automated scanning tools are more sophisticated and more widely available. The window between "vulnerability published" and "vulnerability exploited" has compressed to days in some cases.
More recently - and more relevant if you're in professional services - the MOVEit file transfer vulnerability in 2023 affected hundreds of organisations including law firms, financial services companies, and government bodies. Same mechanism: known vulnerability, delayed or impossible patching, mass exploitation. The firms on supported versions patched quickly. The ones that weren't... didn't.
You don't need a full penetration test to understand your basic legacy platform security exposure. These four questions will get you most of the way there, and your IT team should be able to answer them in an afternoon.
What platforms and dependencies in your estate are running versions that no longer receive vendor security patches? This is your starting point. Every item on this list represents an open vulnerability window. Don't just check the CMS - check the framework it runs on, the server OS, the database, and any third-party plugins or integrations. The chain is only as strong as the weakest link, and the weakest link is usually a plugin nobody remembers installing.
When was the last security patch applied to each platform in the estate? A platform that hasn't been patched in six months has accumulated six months of known, unaddressed vulnerabilities. A platform that hasn't been patched in two years - well, you can do the maths.
Does your current cyber insurance policy specify a requirement for supported platforms, and have you confirmed that your estate is compliant? See above. Seriously.
What is the vendor lifecycle status for each major platform? Knowing the end-of-support date in advance lets you plan a migration rather than react to an emergency. If your CMS vendor has announced end-of-life for your version in 18 months, that's a migration timeline, not a future problem.
The risk of moving is greater than the risk of staying.
I understand why people feel this way. Migration projects have their own risks - data loss, downtime, integration failures, budget overruns. I've written about how technical debt compounds, and the financial dynamics are genuinely complex. I've also seen migrations go wrong. We had a project a few years back where a dependency nobody had documented properly caused a two-week delay right at the end of delivery. Not catastrophic, but not fun either - and it's the kind of thing that makes people gun-shy about moving at all.
But here's what I'd push back on: the risk of staying isn't static. It grows. Every month your unsupported platform remains in production, the number of known, unpatched vulnerabilities increases. The insurance exposure gets harder to defend. The regulatory risk compounds. And the eventual migration - because it will happen eventually, either on your terms or on terms dictated by a breach - gets more expensive and more urgent.
Emergency migrations cost two to three times more than planned ones. That's a pattern we've seen consistently across the 170-plus projects we've delivered. The firm that plans a migration over 12 months, with proper assessment, phased delivery, and risk management, pays a fraction of what the firm that has to move in eight weeks because something went wrong. To put rough numbers on it: a migration we'd scope at £80-120k as a planned programme can easily become a £200-300k emergency when the trigger is a breach or a vendor pulling support overnight.
There's a companion piece worth reading on what happens when your only developer leaves - because the key-person dependency risk and the legacy platform security risk tend to travel together. The same platforms that are end-of-life are often the ones being maintained by a single person who's the only one who understands how they work. When that person leaves, you've got both problems at once.
If any of this has landed - and if you're running an unsupported platform in a regulated sector, it should have - the first step isn't to panic and commission a six-figure migration programme. It's to understand your actual exposure.
Get the answers to those four questions. Call your insurance broker. Have a conversation with your CMS vendor about their lifecycle timeline. If you want a structured way to work through it, we've put together a one-page legacy platform security risk checklist covering support status, last patch date, insurance compliance, and vendor lifecycle - with a traffic-light risk rating for each. It takes about thirty minutes using publicly available vendor information and your internal IT records.
And if you want to understand which elements of your platform estate are creating security exposure - and what a migration prioritisation would look like - we do 14-day platform security assessments. The output is a clear picture of where the risk sits, what needs to move first, and what a realistic timeline and budget looks like.
"We haven't had a breach yet" is not a security posture. It's just luck. And luck has a shelf life.