Somewhere in your stack is code that will never be fixed. Not "not fixed yet". Never. The repository is archived, the vendor published a lifecycle date and closed the door. Every flaw found in that code from today onward is permanent. That is a different problem from being behind on updates, and it needs a different plan.
What "no upstream fix" actually means
An end of life dependency is not an outdated dependency, it is a permanent one. The vendor has stopped shipping security releases, so a flaw disclosed tomorrow gets a public write-up, a tracking identifier, and no patch. The hole stays open for exactly as long as that code runs in production.
Three things happen the moment support ends:
- ▸Disclosure does not stop. Researchers keep publishing against dead software, and those findings stay useful for years precisely because nothing will fix them. New entries land in the NIST National Vulnerability Database whether or not a maintainer is listening.
- ▸Your options collapse. For supported software the fix is "apply the update". For unsupported software it is "replace, rewrite, or isolate", and each costs budget and calendar time. That cost is why teams postpone, and postponing compounds the risk.
- ▸The dates are public, and not secret from attackers. PHP supported versions, Node.js releases and end-of-life and the Microsoft product lifecycle publish exact end of security support dates for the layers carrying most legacy business systems.
Write those dates down with a named owner beside each one. A date nobody owns is a date nobody acts on.
The four kinds of unfixable dependency
Not every dead dependency is equally dangerous, and treating them alike wastes the budget you need for the ones that matter. Sort yours into four buckets. Reachability from the internet and evidence of real exploitation matter far more than a version number that looks alarming in a scanner report.
- ▸Dead runtime, still exposed. An unsupported PHP, Python 2, .NET Framework, Java or Node version handling public internet requests. Highest risk, first to move, no argument.
- ▸Dead framework, still central. The framework everything is built on, sitting in the request path doing routing, sessions and templating. Vulnerabilities here are frequently pre-authentication, the worst class there is.
- ▸Abandoned package, deep in the tree. A transitive dependency something else pulled in, last released years ago. Often harmless. Sometimes it is the image parser handling user uploads.
- ▸Dead software with a brand name. Unsupported operating systems, database engines, VPN appliances, firmware. Forgotten because "that is infrastructure, not code", and routinely the way in.
The bucket that actually hurts is dead code in the request path reachable without a login. That is the population dominating the CISA Known Exploited Vulnerabilities catalogue, which tracks flaws confirmed as exploited in the wild rather than theoretical severity.
How attackers find this before you do
Attackers do not need your source code or an insider. Unsupported software announces itself through response headers, error pages, asset paths, login markup and TLS behaviour. Internet-wide scanning matches those fingerprints against known exploitable flaws, and every hit gets queued for automated exploitation. No human targeting decision is involved.
- ▸Fingerprint, then match. Scanners read technology and version signals, then fire payloads for vulnerabilities that are already public and already packaged into off-the-shelf tooling.
- ▸Exploitation follows disclosure fast. Once an internet-facing flaw has a working public exploit, the gap before mass scanning is short. Legacy systems lose that race by definition, because there is no patch to apply.
- ▸Old authentication is soft. Legacy login stacks predate rate limiting, phishing-resistant second factors and modern session invalidation. Credential stuffing works better against them, and session tokens lifted by infostealer malware stay valid far too long.
We described the same pattern at the CMS layer in The WordPress Security Reality Check Every Business Owner Avoids. The mechanism does not change when the software is bespoke, it just gets less visible.
Why backporting the patch yourself usually fails
Backporting looks like the cheap escape and rarely is. You take the upstream fix, adapt it to your ancient version, test it and ship. It works once. Then it becomes a permanent commitment: every future flaw in that component is now your team's problem, forever, arriving on somebody else's schedule.
- ▸The patch often does not apply. Modern fixes assume modern internals. Backporting means understanding both the vulnerability and a decade of divergence, which is deep, specialised, expensive work.
- ▸Silent partial fixes are common. A backport that compiles and passes tests can still miss the real attack path. You then believe you are protected, which is more dangerous than knowing you are not.
- ▸Extended support is a bridge, not a strategy. Paying a vendor to keep patching an old runtime buys eighteen honest months. It fails as a plan, because extended support also ends, at a price that climbs every year.
Backport when a specific, actively exploited flaw needs closing this week and the replacement lands this quarter. Otherwise spend those hours on the migration itself.
Compensating controls buy time, not safety
A firewall rule, a network segment or an IP allowlist can reduce exposure to a flaw that will never be patched. None of them fix it. Treat compensating controls as scaffolding with an explicit removal date attached, not as a resolution, and put that date somewhere the finance team can see it.
- ▸Remove the exposure. Taking dead components off the public internet is the most effective control available. Admin panels, legacy APIs and management interfaces rarely need to be reachable from anywhere on earth.
- ▸Segment hard. Flat internal networks turn one compromised box into an organisation-wide encryption event, and legacy systems usually sit on the flattest part of the network.
- ▸Monitor as though you expect it to fail. Ship logs somewhere the legacy box cannot delete them, alert on anomalous outbound traffic, rehearse the response. Prevention there is weak by definition.
The migration order that reduces risk fastest
Do not migrate by architecture diagram, migrate by exposure. Sequence the work so unsupported code facing the internet without authentication moves first, and internal, authenticated, boring code moves last. That order delivers the most risk reduction per euro spent, which is what keeps a modernisation programme funded past the first budget review.
1. Cut the perimeter. Anything unsupported and reachable without a login: the public site, the customer portal, file upload endpoints, the payment path, the forgotten subdomain. 2. Move the runtime before the application. A supported language runtime and operating system often unlocks dozens of dependency updates at once. Unglamorous, and usually the highest leverage single step. 3. Replace authentication and session handling. Modern identity, proper session invalidation and phishing-resistant MFA shrink the blast radius of everything you have not migrated yet. 4. Strangle the monolith by business domain. Route one capability at a time to new code behind a facade, so you ship value continuously instead of betting the company on one cutover weekend. 5. Clean the dependency tree last. Once the runtime is current, most abandoned packages have living replacements, and the stubborn remainder is visible against a small surface.
If the legacy system is a public website, the SEO-safe version of this sequencing is in Leaving WordPress: A Migration Playbook That Does Not Lose Your SEO. If it is a business system trapped inside a vendor platform, Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software covers the data and contract side.
What to do in the first thirty days
You cannot migrate a legacy estate in a month, but you can stop guessing in a month. The goal of the first thirty days is one defensible list: what you run, what is dead, what is exposed, what is being exploited right now, and who owns each line of it.
- ▸Week one, inventory. Every runtime, framework, package, operating system and appliance, with version and published end of support date.
- ▸Week two, exposure map. Which of those are reachable from the internet, and which accept input before a user authenticates.
- ▸Week three, reality check. Cross-reference the KEV catalogue and the NVD to separate "old" from "old and actively exploited". Those three words change the conversation with your board.
- ▸Week four, a costed sequence. Owners, dates, budget, and a named executive sponsor. Without a sponsor this becomes a document, not a programme.
The routine that keeps that list true afterwards is ordinary maintenance done properly, which is rarer than it sounds. We broke the difference down in What Website Maintenance Should Actually Include (and What You Are Probably Paying For).
How to avoid arriving here again
End of life arrives on a schedule published years in advance. Organisations get caught because nobody owns the calendar, not because the information was hidden. Build support dates into procurement, architecture review and annual budgeting, and the emergency migration becomes a routine upgrade nobody panics about.
- ▸Choose dependencies on maintenance record, not feature list. Release cadence, active maintainers, a published security policy, and how the project handled its last serious vulnerability.
- ▸Track end of support dates as funded milestones, a year ahead, alongside everything else with a deadline.
- ▸Design for replaceability. Keep third-party code behind interfaces you control, so swapping a library is contained rather than an excavation.
- ▸Expect the regulatory floor to rise. The EU Cyber Resilience Act attaches obligations around vulnerability handling and support periods to products with digital elements. Knowingly running unsupported software is moving from a technical debt problem to a governance one.
How TuniCyberLabs helps
We inventory legacy estates, separate the dependencies that can still be patched from the ones that never will be, and sequence the migration by exposure so risk drops early. Then we build the replacement: supported runtimes, modern authentication, and a dependency tree somebody is still maintaining. Engineering in Tunisia, company in Estonia, delivery across the EU and North Africa.
If part of your stack is past its last security release, book a legacy risk and migration assessment and we will tell you honestly what has to move first.