The risk associated with legacy systems has evolved. No longer is it simply a case of slow rot, of unpatched flaws which may, at some point, be exploited by an attacker. Today, legacy systems are actively targeted by means of scanning for known vulnerable software versions, often within hours of a public disclosure. The key issue therefore is to identify the key differentiators of legacy systems that present exposure that cannot be covered by compensating controls.
In the following, we focus on which old systems have the sharpest exposure, how to rank them in the context of a limited budget, and which measures to modernise them will reduce their attack surface as opposed to just moving it.
Why unsupported software behaves differently from merely old software
If an application has reached end of life, it no longer receives any fixes. But that does not mean that research into that application ceases to exist. In fact, disclosures of vulnerabilities in outdated software are often linked to newer versions of the same codebase that have recently been discovered to have had the same vulnerability since release.
In addition to individual flaws, legacy software also can have a negative impact on detection due to being unable to deploy current endpoint software, inability to negotiate current TLS versions and inability to produce logs in formats that can be ingested by SIEM tools. In most cases significant custom work is required to get logs from unsupported software into a SIEM for detection.
The compliance and insurance dimension
Many cyber insurers are now asking questions around the number of unsupported Operating Systems and Database Engines currently in use across an organisation’s estate. It’s well documented that giving an incorrect answer to such questions at claim time could result in the policyholder’s claim being voided.
Ageing infrastructure and the limits of segmentation
Simple hardware failure can cause massive problems which the security team underestimates. Switch, storage controller and out-of-band management interfaces typically run old firmware which has not been updated after initial installation. These interfaces are typically connected to flat management networks. Logon credentials to these systems are typically default. Penetrating such a simple interface can give an attacker complete control below the level at which your monitoring is able to report problems.
Yes, segmentation of legacy systems works in most cases. A VLAN or firewall rule that hasn’t been tested recently with real traffic can contain a breach. But a 10-year-old rule set that has been extended with dozens of exceptions typically won’t. Test it.
Authentication debt and the integration problem
Authentication on legacy systems is typically the most exposed to attack. Many applications are unable to be configured to use modern single sign-on solutions like SAML / OIDC and thus are stuck with local account stores for users, and shared service accounts that get added to databases and applications in a completely ad-hoc fashion. Password policies can exist, but if they are not enforced beyond local group policy they are useless, which is why bringing in an experienced IT security partner to consolidate scattered account stores is usually money well spent.
In particularly poor integration scenarios, data movement between systems via scheduled file moves, database queries, or corporate middleware (written years ago for long-since retired applications) can embed credentials in scripts, include credentials in configuration files, never rotate said credentials, never expire said credentials, and can easily be read by an individual with legitimate access to the server hosting the application.
What to remediate first
- Internet-facing services running unsupported versions, regardless of perceived business criticality
- Any authentication path that bypasses multi-factor enforcement, including legacy mail protocols and VPN fallback
- Service accounts with domain-level privilege and no password rotation
- Management interfaces reachable from general user networks
- Integration credentials stored in plain text on shared file systems
Choosing a modernisation path for each system
The above method for prioritising modernisation of legacy systems can also help to stop premature and failed attempts at ‘blanket replacement’ of applications. These occur because similar systems are treated as if they were of equal importance. Programs to replace legacy systems should instead prioritise individual systems based on three criteria, 1) exploitability of the current system, 2) cost of modernisation, and 3) remaining business value of the function(s) currently performed by the system.
| Approach | Best suited to | Typical timeframe | Residual risk |
| Replace with supported product | Commodity functions with mature market alternatives | 6 to 18 months | Low, subject to migration errors |
| Rehost on current OS and database | Applications where source or vendor support still exists | 3 to 9 months | Moderate, application layer unchanged |
| Wrap with an identity-aware proxy | Systems that cannot be changed but must stay reachable | 4 to 12 weeks | Moderate, protects access not the code |
| Isolate and restrict to named users | Low-use systems retained for data retrieval only | 2 to 6 weeks | Higher, but bounded and monitored |
| Decommission and archive data | Functions superseded but kept ‘just in case’ | 4 to 10 weeks | Minimal once verified |
Measures that pay back quickly
- Build an accurate inventory keyed to support status rather than asset age, and refresh it quarterly.
- Place an identity-aware proxy in front of applications lacking modern authentication, so access decisions move to a layer you control.
- Move embedded credentials into a secrets manager and enforce rotation on service accounts.
- Ship logs from legacy hosts through a forwarder that normalises output, restoring detection coverage.
- Engage specialist IT security support for penetration testing scoped at legacy interfaces and integration points, where automated scanning performs poorly.
Making the case internally
Measuring risk in terms of operational impact will influence funding decisions more than counting missing patches. This will include systems which cannot be restored within the required Recovery Time Objective, privileged accounts outside of your identity management system and the percentage of your IT estate unseen by your current detection tools.
