Legacy Application Security: Compensating Controls

Most organisations run at least one application that is out of support, hard to change and too important to switch off, and attackers know it. A legacy application may be a bespoke system written in a language nobody on staff still uses, a vendor product whose maker no longer ships patches, or a platform pinned to an end-of-life operating system or runtime. When replacement is years away, the job is to contain the risk: shrink who and what can reach the application, wrap modern authentication and monitoring around it, and plan the exit. This guide sets out the compensating controls that work, how to choose between them, how to roll them out and how to measure them. It is for application owners, security architects and risk managers. Shielding a single unpatched vulnerability is covered in the Virtual Patching Guide; this page covers the whole system.

Key takeaways

Treat legacy applications as inherently high risk. OWASP's Legacy Application Management Cheat Sheet advises exactly that for authorisation decisions, and least privilege applies with extra force.
Isolation is the strongest single control. If nothing untrusted can reach the application, most of its unpatched flaws are unreachable; restricted subnets, allowlists and broker services do most of the work.
Put modern identity in front, because you cannot put it inside. An identity-aware proxy, VPN or ZTNA gateway with MFA can protect an application that only understands local passwords.
Legacy systems hide non-human credentials. Hard-coded database passwords, shared service accounts and old integration keys are often the easiest way in and out.
A compensating control without an exit plan is a permanent exception. Record the risk decision, an owner, a review date and a funded migration path.

What makes an application "legacy" and why it is risky

OWASP defines legacy applications as those recognised as outdated but still in active use, whether because no viable alternative exists, replacement is too expensive, or the application is bespoke and serves a niche role. It identifies three security problems: the product may be end of life and no longer receive patches; the skills to troubleshoot or fix it may have left the organisation; and custom data formats and old protocols can stop its logs and data reaching security tools such as a SIEM.

Legacy type	Typical example	Main risk	First control to reach for
Vendor product out of support	Line-of-business suite whose vendor stopped shipping fixes	Known vulnerabilities that will never be patched	Network isolation and virtual patching
Bespoke code, lost expertise	In-house application in an older language or framework	Unknown vulnerabilities, slow fixes	Access restriction and monitoring; train a second maintainer
Supported application on unsupported platform	Application certified only on an end-of-life operating system or runtime	Platform vulnerabilities and weak defaults	Host hardening, allowlisting, segmentation
Old protocols and authentication	Plain-text protocols, local accounts, no MFA, no SSO	Credential theft and interception	Front-end proxy with modern authentication; encrypted tunnels
Embedded or appliance software	Systems tied to lab, medical or industrial equipment	Cannot be changed without recertification	Strict segmentation and monitored conduits

NIST SP 800-53 Rev. 5 control SA-22 Unsupported System Components sets the baseline expectation: replace components when support ends, or provide alternative sources of continued support. Its discussion explicitly recognises exceptions for systems that provide critical mission or business capabilities where newer technologies are not available, or that are so isolated that replacement is not an option. It also notes organisations can establish in-house support with custom patches or contract external providers. In other words, the standard accepts that legacy will exist, but expects a deliberate decision and a support arrangement. For platform-level timelines see the Operating System End of Life and Extended Support Guide and the End-of-Life Language Runtimes page.

Know what you have before you protect it

OWASP puts inventory first: document each legacy application with version numbers, date of production, configuration settings, the network locations it needs, the services on its hosts, and where relevant its physical location and who may access it. A software bill of materials helps where the application relies on third-party components. See the SBOM Guide.

Then assess the risk. OWASP suggests four questions that set how conservative the controls must be:

Data: what information does the application store or handle, and what would compromise mean for the business and its regulatory obligations?
Known weaknesses: do the application, its dependencies or its infrastructure have known vulnerabilities, how exploitable are they, and could they be fixed with the right skills?
Availability: how critical is the application to business continuity?
Pivot value: could an attacker who compromises it reach other critical data or a privileged network?

Answer these in writing, rate the result with your normal risk method, and record it. The written record is what turns "we have an old system" into an accepted, owned risk with a review date, which is what auditors and SA-22 expect.

Compensating controls that work

No single control is enough. Layer them so that an attacker has to defeat several independent barriers to reach the application's weaknesses.

Control	What it does	Strength	Cost and trade-off
Network isolation	Restricted subnet or VLAN, IP allowlisting, closing unneeded ports, air gap where required	Very high: unreachable flaws cannot be exploited	Integration and user access need redesign; air gaps complicate support
Broker or intermediary service	A modern API or service moves data in and out so users never touch the legacy system directly	High: shrinks the attack surface to one well-built interface	Development effort; must itself be secured
Identity-aware front end	Proxy, VPN or ZTNA gateway enforcing SSO and MFA before any traffic reaches the application	High against credential attacks and opportunistic scanning	Application still trusts whatever passes the proxy; protect the back-end path
Feature reduction	Disable high-risk functions, especially administrative interfaces, for ordinary users	Medium to high	May need configuration skills that have been lost
Virtual patching	WAF or IPS rules blocking exploitation of known flaws	Medium: depends on rule quality and coverage	Rules need maintenance; see the Virtual Patching Guide
Host hardening and allowlisting	Remove unneeded services, apply application allowlisting so only known binaries run	High against malware on the host	Testing burden on fragile systems
Encryption wrapping	Encrypted tunnels or TLS-terminating proxies around plain-text protocols; encryption at rest where possible	Medium to high against interception	Latency; some protocols resist tunnelling
Third-party or in-house support	Extended support contracts, backported fixes or custom patches (the SA-22 alternative)	Varies with provider quality	Ongoing cost; verify what is actually covered

Choosing the right mix

Internet-facing legacy application: the highest-risk case, because T1190 Exploit Public-Facing Application needs no foothold. Remove direct exposure first: place it behind an identity-aware proxy or VPN so only authenticated users reach it, add virtual patches for known flaws, and alert on every exploitation attempt. If it must be public, consider a broker service in front.
Internal application used by many staff: segment it so only the user subnets and integration hosts that need it can connect, put SSO and MFA in front, and remove administrative functions from general users.
Back-office system with a few integrations: isolate tightly and expose only the integration ports to named hosts; a broker API is often cheaper than it looks.
Equipment-bound system: treat it as OT: zone it, allow only defined conduits, and monitor passively. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Small and large organisations: a small organisation with one legacy application can often get most of the benefit from a firewall rule set, a VPN with MFA and good backups. A large organisation with dozens needs a register, a standard legacy hosting zone with shared monitoring, and a portfolio-level migration budget, because one-off controls per application do not scale.

Where identity fits

Legacy applications are often the worst identity hygiene in the estate. Typical findings are local user stores with no MFA, shared administrator accounts, database connection strings with passwords in configuration files, integration accounts whose passwords never change because nobody knows what will break, and access that survived every leaver process because the application is not connected to provisioning.

Front it with SSO: an identity-aware proxy can enforce MFA and conditional access and pass a trusted identity to the application. See the Identity-Aware Proxy Guide.
Broker privileged access: route administrator sessions through a PAM platform with session recording rather than shared passwords. See the Privileged Access Management Guide.
Find and vault the machine credentials: inventory service accounts, database logins and API keys the application uses, move them into a vault, restrict where they can be used from, and rotate what can be rotated. Where the application cannot fetch secrets at runtime, a wrapper or sidecar can. See the Short-Lived Credentials Migration Guide for Legacy Applications.
Reconcile accounts regularly: if the application cannot take automated deprovisioning, run a scheduled access review against HR records.

Rolling out the controls

Register and assess. Add the application to a legacy register with owner, data classification, dependencies, known vulnerabilities and the four OWASP risk questions answered.
Map real traffic. Before changing anything, record which hosts and users talk to it, on which ports, for several weeks. This becomes the allowlist and prevents surprise outages.
Back it up and test the restore. Fragile systems fail in unexpected ways when touched; a tested restore is your rollback for everything that follows. See the Business Continuity and Disaster Recovery Guide.
Apply network controls in monitor mode. Introduce firewall rules as log-only where the platform allows, review hits, then enforce. Keep the previous rule set ready to restore.
Add the identity front end. Pilot with a small user group, then move everyone, then block the old direct path.
Harden the host and enable monitoring. Remove unneeded services, run allowlisting in audit mode before enforcement, and connect logs to the SIEM, building a parser or export if needed.
Document and review. Write down the residual risk, the controls, the owner and a review date, and add the migration milestones to a plan of action and milestones.

Monitoring legacy systems

OWASP recommends an especially high degree of monitoring for legacy applications with rapid response to potential incidents, and acknowledges the obstacle: their logs may not be in a format security tools can ingest. Its suggested workarounds are custom APIs or converters that turn security-relevant data into an ingestible format, scheduled scripts that report on indicators of compromise, close watch on anomalous traffic in and out of the legacy environment, and an incident response playbook prepared in advance with escalation contacts.

Signal	Where to collect it	Why it matters
Any connection from outside the allowlist	Firewall or segmentation gateway logs	Either a misconfiguration or an intrusion attempt; both need action
Exploit attempts against known CVEs	WAF or IPS in front of the application	Shows the compensating control is being tested
Logins outside working hours or from new sources	Proxy, VPN or application authentication logs	Credential misuse, T1078 Valid Accounts
Outbound connections from the legacy host	Network flow data, DNS logs	Legacy hosts rarely need to initiate connections; new ones suggest compromise
New processes or binaries	Allowlisting or EDR audit logs, file integrity monitoring	Malware or unauthorised change on a host that should be static
Bulk data reads or exports	Database audit logs, broker service logs	Exfiltration

Metrics:

Coverage: share of registered legacy applications with a completed risk assessment, an owner and a review date.
Exposure: number of legacy applications directly reachable from the internet or from general user networks (target zero for the first).
Authentication: share of legacy applications behind SSO and MFA.
Known exploited exposure: count of vulnerabilities listed in the CISA KEV catalogue present on legacy systems without a compensating control. See the CISA KEV Catalogue Guide.
Migration progress: legacy applications retired or migrated per year against plan, and overdue exception reviews.

Common failure patterns

Exception with no expiry. A risk acceptance signed once and never reviewed becomes permanent. Every exception needs a review date and an owner who can be asked.
Proxy in front, open path behind. An identity-aware proxy is bypassed if the application still accepts connections directly from the network. Block the old path.
Single maintainer. OWASP warns that losing the one person who understands the system removes the ability to fix it; train at least two and keep troubleshooting runbooks.
Logs that go nowhere. The application logs to a local file in a custom format and nobody reads it. Build the export before you need it.
Forgotten integration credentials. Hard-coded passwords in batch jobs and connection strings outlive staff, projects and suppliers, and give attackers a quiet route in.
Virtual patches treated as the fix. Rules cover known attack patterns only; they do not make the application maintained. Keep the migration funded.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	SA-22	Replace unsupported components or arrange alternative support; documented exceptions
NIST SP 800-53 Rev. 5	CM-8, RA-3, CA-5	Inventory, risk assessment, plan of action and milestones for migration
NIST SP 800-53 Rev. 5	SC-7, SC-7(21), CM-7(5), AC-6, IA-2(1), SI-4	Boundary protection, component isolation, allowlisting, least privilege, MFA for privileged accounts, monitoring
NIST CSF 2.0	ID.AM-02, ID.AM-08, PR.PS-02, PR.IR-01	Software inventory, life-cycle management, software maintained or replaced commensurate with risk, protecting networks from unauthorised access
MITRE ATT&CK	T1190, T1133, T1210, T1078	Exploiting public-facing and remote services, lateral movement via unpatched services, use of valid accounts

Practitioner checklist

Keep a legacy application register with owner, versions, dependencies, data classification and known vulnerabilities.
Answer the data, weakness, availability and pivot questions for each application and record the risk decision with a review date.
Remove direct internet exposure; put SSO and MFA in front through a proxy, VPN or ZTNA gateway and block the direct path.
Restrict network access to the hosts and ports observed in a traffic baseline, and close everything else.
Disable administrative and high-risk functions for ordinary users and broker privileged sessions through PAM.
Inventory and vault service accounts, connection strings and keys the application uses; rotate what can be rotated.
Get logs into the SIEM, monitor outbound connections and new processes, and prepare an incident playbook.
Arrange alternative support (extended support, backports or in-house fixes) and train a second maintainer.
Fund and schedule the migration, with milestones tracked like any other remediation.

Legacy Application Security: Compensating Controls for Systems You Cannot Replace