Healthcare organizations spend a lot of time preparing for cyberattacks, but far less time confronting a quieter source of exposure: the unsupported applications that remain in their environments long after their primary purpose has ended.

Legacy systems often remain in production because many organizations lack an ongoing application management program and a disciplined process for deciding what to retire. Over time, mergers, EHR transitions, departmental purchases and fragmented ownership create sprawling environments that make it more difficult to determine which applications need to be decommissioned and archived. This “application bloat” creates cybersecurity and compliance risk in ways many health leaders may not fully appreciate.

How Legacy Systems Raise the Stakes

Legacy applications were not designed for modern identity controls, audit requirements, segmentation strategies or patching expectations. Some cannot be patched at all. Others sit outside normal monitoring and vulnerability management because they are treated as exceptions, temporary holdovers or low-priority systems that never got retired.

Change Healthcare offers a vivid example. Public testimony indicates the attackers used stolen credentials to log in to a legacy, "old" Citrix remote access portal that lacked multi-factor authentication (MFA). UnitedHealth’s CEO described Change as an older company with older technologies that the company had been working to upgrade or integrate after a prior acquisition. The total financial impact of the attack is estimated at roughly $2.5 billion.

But the issue is not simply that these systems are old. It’s that many organizations already know some of these applications cannot meet modern security expectations. Once leadership knows that and keeps the system running anyway, it creates an active control gap.

From a regulatory standpoint, that can significantly change the discussion. If an organization has a documented HIPAA security program, and a system within scope is known to be unsupported, unpatchable or missing required controls, leaving it in operation without adequate remediation or formal exception handling can start to look less like an unavoidable incident and more like a failure to implement reasonable and appropriate safeguards. Regulators will ask whether the risk was identified, whether leadership formally accepted it, and whether a real remediation or decommissioning plan existed.

That scrutiny is not hypothetical. The Office of Civil Rights (OCR) at the U.S. Department of Health and Human Services has already shown where this can go. In March 2026, MMG Fusion, a healthcare business associate software company, entered into a settlement and corrective action plan after a breach affecting roughly 15 million individuals, with OCR citing failures including the lack of an accurate and thorough risk analysis.

The insurance implications can be just as serious. If a breach traces back to a system that was out of compliance with internal policy or inconsistent with the controls represented during underwriting, insurers may scrutinize the claim much more aggressively. Even when coverage is not denied outright, disputes over whether known risks were left unresolved can affect payouts, premiums and future coverage terms.

Litigation risk follows the same pattern. Plaintiffs’ attorneys do not need the organization to be perfect. They need a clear story. One of the worst stories in any breach case is that the organization had a security program, knew a system was risky, kept it online anyway, and then suffered an incident through that same system. That story can also gain traction in court. In February 2026, the Delaware Supreme Court allowed claims against Blackbaud to move forward based on allegations tied to obsolete servers and weak security controls.

Behind the Firewall Is Not a Strategy

One reason healthcare leaders underestimate this problem is that many of these systems are internal. They sit behind the firewall, so people treat them as low risk. That is a mistake. Internal-only does not mean safe. Attackers frequently use weaker internal systems as stepping stones to move deeper into the environment, gain privileged access, or obtain the credentials, tokens and secrets needed to reach more critical assets. For example, Oracle Health said an attacker used compromised credentials to access legacy Cerner migration servers that had not yet been moved to Oracle Cloud and copied data out of the environment.

Legacy systems are especially dangerous because they tend to survive through a familiar mix of risk acceptance, compensating controls and some version of “we still need the data.” That may be true. However, there is a significant difference between needing the data and needing the original application to remain live in production.

The real question is whether there is still a defensible reason to keep the application itself operating despite known control deficiencies. If the answer is yes, leadership should be prepared to show why, under what formal approval, with what safeguards, and for how long. If the answer is no, then keeping the system online only widens the gap between the organization’s stated security posture and the reality of its environment.

Why Healthcare Is at a Turning Point

Healthcare organizations cannot keep defending yesterday’s applications against today’s threats and expectations. At a time when cyberattacks are becoming more frequent, more disruptive and more sophisticated, health systems should be looking for every practical opportunity to reduce unnecessary exposure. That is why CIOs and CISOs need to make application retirement part of cyber resilience, not just cost management.

It is true that application rationalization has historically been difficult. For years, the archiving process itself was often too slow and too cumbersome to make application retirement and data archiving feel realistic. As a result, outdated systems stayed in production far longer than they should have.

What has changed is that health systems no longer have to choose between preserving access to historical data and continuing to carry the risk of the original application. Better tools, more modern archiving approaches and managed services for decommissioning are making it increasingly possible to retire outdated systems in a way that is faster, more disciplined and more practical than it was even a few years ago. That should make application decommissioning and archiving a more urgent priority for healthcare leaders.

Because in the end, the question is not whether an old system still contains useful information. The question is whether there is still a defensible reason to keep that system running in production.

And in many cases, there is not.