Cybersecurity

Legacy Software Is Now the Fastest Way Into Your Company

TuniCyberLabs Team
8 min read

Attackers do not pick you, they scan for you. Unpatched and end-of-life systems are the primary initial access route into small and mid-sized companies, and "it still works" is not a defence.

Most breaches do not begin with a bespoke exploit written for your company. They begin with a system you stopped thinking about years ago, found by an automated sweep that checks the whole internet for the same short list of known holes. Legacy software has stopped being a technical debt problem. It is now the fastest, cheapest and most reliable route into a business.

Your oldest system is your front door

Attackers do not go after your best defended asset. They go after the one nobody owns, and that is almost always the oldest: a plugin heavy CMS, an unpatched VPN appliance, an application from a supplier who no longer trades, a server nobody dares reboot. Unowned, undocumented and unpatched is exactly the profile mass exploitation is built around.

The same pattern repeats in incident after incident:

  • The compromised asset was known but not owned. Someone had it on a spreadsheet. Nobody had it in a patch cycle.
  • It was reachable from the internet. A legacy internal system is a risk. A legacy internet facing system is an emergency with a date on it you have not seen yet.
  • The flaw was public. It had an identifier, a vendor advisory and usually a fix that predated the intrusion by a long margin.
  • Nothing was watching. Old systems rarely send logs anywhere useful, so an intruder gets weeks of quiet instead of minutes.

If you cannot name the person responsible for patching every internet facing system you run this quarter, you do not have legacy risk. You have an open door.

How attackers find you, and why it is nothing personal

By scanning the entire internet. A vulnerability gets published, someone writes or buys a check for it, and the whole routable address space is swept for the fingerprint. You are found because a version banner matched a pattern, not because a human chose your company. Selection happens later, after access already exists.

Two public resources define this game, and both are free. The CISA Known Exploited Vulnerabilities catalogue lists flaws with confirmed exploitation in the wild, which makes it the closest public equivalent of an attacker shopping list. The NIST National Vulnerability Database holds the fuller record, including the affected version ranges you need in order to work out whether your specific build is in scope or not.

The consequence is simple and unpleasant. Your patch window is not set by your change calendar. It is set by how quickly commodity exploitation follows public disclosure, and that gap has been closing for years. A quarterly maintenance window is not a plan for anything with a public IP address.

Why "it still works" is not a security position

Because "it works" describes function, not exposure. Software does not rot on its own, the world around it moves. Every month, new vulnerabilities are published against the exact version you froze, proof of concept code becomes packaged tooling, and the population able to use it widens from specialists to anyone renting a kit by the week.

  • Frozen plus unsupported equals a published list of ways in. Once a version stops receiving fixes, each new advisory against it is permanent. Your exposure only ever grows.
  • The freeze is deeper than you think. It is not just the app. It is the language runtime, the framework, the database, the OS, the TLS library and the appliance firmware underneath all of it.
  • Runtimes have hard, published dates. The PHP supported versions page shows exactly when security support ends for each branch. Check yours before you read further, it takes thirty seconds.

This is why so many businesses discover their real exposure through their website first. If yours runs on a CMS with a long plugin list, read The WordPress Security Reality Check Every Business Owner Avoids before you make any other decision.

The three legacy patterns that get companies breached

Three recurring shapes account for most initial access: the edge, the dependency layer, and identity. Each one fails quietly, each one is cheap for an attacker to test at scale, and each one is fixable without touching your core application.

1. Edge devices and remote access. VPN concentrators, firewalls, file transfer appliances and remote desktop gateways sit on the internet by design and get patched last by habit. Ransomware crews favour them because a single exploit delivers network position with no phishing and no user interaction. The practical playbook and the reporting path are on CISA Stop Ransomware. 2. The dependency layer under your application. An abandoned open source package is not neutral, it is a project someone else can adopt or impersonate. Supply chain compromise through unmaintained dependencies, typosquatted package names and confusion between internal and public registries all exploit the same gap: nobody owns the manifest. 3. Identity running on old rails. Reused passwords, SMS codes, and legacy protocols that quietly bypass modern controls. Credential stuffing turns other companies' breaches into your incident, and infostealer malware skips passwords entirely by stealing live session tokens from a browser. Check whether your domain already appears in public breach corpora at Have I Been Pwned.

What running past end of support actually costs

More than the upgrade you deferred. The bill arrives as emergency work at emergency rates, and it lands in quarters you did not budget for. Vendors publish end of support dates years in advance, so this is the rare risk that is fully knowable long before it bites.

  • Emergency migration costs multiples of planned migration. No procurement leverage, no phased cutover, no testing window.
  • Downtime is priced by your customers, not by you. Days offline during recovery, plus data restoration that has never actually been rehearsed.
  • Insurance and contracts. Cyber proposal forms and enterprise vendor questionnaires now ask directly about unsupported software and patch timelines. A wrong answer is a coverage and contract problem, not just an ops problem.
  • Talent and velocity. Good engineers refuse to own systems they cannot patch, and every new feature costs more on a frozen stack.

Vendor dates are published, not secret. The Microsoft product lifecycle pages carry them for the Windows and server products most businesses run. Plan against those dates and the emergency never happens. For what a competent maintenance arrangement should actually cover, see What Website Maintenance Should Actually Include (and What You Are Probably Paying For).

Find your real exposure this week

Start from the outside, the way an attacker does. You do not need a tool purchase or a consultant to get eighty percent of the value. You need one afternoon, an honest list and a named owner per line. Most companies find at least one internet facing system nobody knew was still running.

  • List every hostname, IP and third party service that answers from the internet, including staging, old marketing sites and forgotten subdomains.
  • Record the exact version of each OS, runtime, framework and appliance firmware, then find its published end of support date.
  • Note the date each one was last patched, and who did it. If the answer is nobody, that is your finding.
  • Pull the dependency manifest for each application and check the age of the newest release of every direct dependency.
  • Verify administrative access: phishing resistant MFA on, legacy protocols off, shared accounts eliminated.
  • Test a restore, not a backup. An untested backup is a belief, not a control.

Work through The Small Business Website Security Checklist for 2026 alongside this and you will have a defensible picture in a day.

Fix it without a two year rewrite

By sequencing on exposure, not on age. The goal is not a clean stack, it is removing the paths that a mass scan can reach. Most companies can eliminate the majority of their realistic initial access risk in a quarter while the deeper modernisation runs on a normal budget cycle.

  • Kill or replace internet facing legacy first. Anything unsupported and publicly reachable is the entire emergency. Retire it, replace it, or put it behind an identity aware proxy this month.
  • Isolate what genuinely cannot move. Machines running production lines or accounting systems get their own segment, no internet path, no shared credentials, and full logging.
  • Strangle, do not rewrite. Move one capability at a time behind a stable interface so the old system shrinks with each release instead of waiting for a big bang that never ships.
  • Plan the exits deliberately. Migrations fail on data, integrations and search visibility rather than code. Leaving WordPress: A Migration Playbook That Does Not Lose Your SEO covers the web side, and Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software covers the operational systems.

How TuniCyberLabs helps

We start with the attacker view: what of yours answers from the internet, what version it runs, when its support ended, and who owns it. Then we sequence the work, remediating the exposed edge quickly and modernising the core through incremental replacement so your business keeps running while the legacy footprint shrinks release by release. Our engineering team in Tunisia and our Estonian base let EU and North African clients get senior modernisation work at a rate that makes doing it properly affordable.

Book a legacy exposure review and get a prioritised list of what to fix first: talk to our team.

TAGS
legacy softwarevulnerability managementpatch managementinitial accessend of liferansomwaremodernisationattack surface

Frequently Asked Questions

Why is legacy software the most common way attackers get in?

+

Because it is cheap to find and cheap to exploit. Attackers scan the whole internet for version fingerprints matching publicly documented vulnerabilities, then exploit every match. Legacy systems are unpatched by definition, usually unmonitored, and often owned by nobody, so an intruder gets weeks of quiet access. No targeting, no phishing and no skill are required beyond running a commodity tool.

Our old system still works fine. Is that not good enough?

+

No, because working describes function, not exposure. The software has not changed but the world around it has: new vulnerabilities are published against your exact frozen version every month, and once support ends none of them will ever be fixed. Your risk only increases from that point. Working software with no patch path is a permanent, published list of ways into your network.

How do I know if my software is end of life?

+

Check the vendor lifecycle page for every layer, not just the application. That means the operating system, language runtime, framework, database, appliance firmware and any plugins. Microsoft, PHP and Node.js all publish end of support dates years in advance. Record the version and the date for each component, then cross-reference the CISA Known Exploited Vulnerabilities catalogue for anything already under active exploitation.

What should I fix first if I cannot fix everything?

+

Anything unsupported that answers from the internet. Sequence by exposure rather than by age: internet facing edge devices and remote access first, then internet facing applications, then internal systems holding sensitive data, then everything else. This ordering removes the paths that mass scanning can reach, which is where the overwhelming majority of realistic initial access attempts actually land.

Does a firewall or WAF make legacy software safe to keep running?

+

It reduces risk, it does not remove it. A web application firewall can block known exploit patterns and network segmentation limits how far an intruder moves, but neither fixes the underlying flaw and neither helps against a new technique. Treat compensating controls as a way to buy time for a scheduled replacement, never as a permanent substitute for supported software.

How long does modernising a legacy system usually take?

+

The urgent part is quick and the deep part is not. Removing or isolating unsupported internet facing systems is typically weeks of work. Replacing a core business application takes months and should run as incremental replacement, moving one capability at a time behind a stable interface, so the legacy footprint shrinks with every release rather than waiting on a single high risk cutover.

Need help with
this topic
?

Our team specializes in the technologies and strategies discussed in this article. Let’s talk about how we can help your business.

Get in Touch