Closing the Cybersecurity Gap in Legacy Medical Devices

If you manufacture connected medical devices, here is the uncomfortable truth. Many devices used in hospitals today would struggle to meet current cybersecurity requirements if they were submitted to the U.S. Food and Drug Administration (FDA) as “new” devices.

This isn’t down to manufacturers not caring, it’s because the world has moved. Clinical life cycles stretch 10 to 20 years. Cyber threat cycles do not. And the longer a device stays deployed, the more likely it is to accumulate vulnerabilities, outdated dependencies, and workarounds that quietly become risks.

In an FBI/IC3 public advisory, the Bureau cited research finding 53% of connected medical devices and other IoT devices in hospitals had known critical vulnerabilities, and about one-third of healthcare IoT devices had an identified critical risk potentially implicating device operation. That is not a compliance problem; it’s a patient safety problem.

In medtech, cybersecurity must go beyond protecting patient databases to protecting the integrity and availability of therapy. If a device can be manipulated, degraded, or made unavailable, you don’t just have an IT issue; you have a security issue and a clinical risk.

This article is about the gap, why it’s widening, why patching isn’t always the answer, and how to take a risk-based approach to securing the installed base in a way that’s defensible, practical, and aligned with where the FDA and the market are going.

The Bar Moved: The FDA is Enforcing Lifecycle Security, Not Submission Security

The FDA has been consistent on one core point: cybersecurity is part of device safety and effectiveness. What has changed is how clearly the FDA is tying that to a manufacturer’s ability to prove security was built in and can be sustained.

The most current premarket cybersecurity guidance is the FDA’s June 27, 2025, final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. The message is simple: Security is a lifecycle obligation, not a one-time document set.

The FDA encourages using a Secure Product Development Framework (SPDF), meaning a repeatable secure development process, so security is systematic rather than a best effort right before submission. That expectation matters beyond premarket because it changes how customers evaluate your entire portfolio.

There is also a gating effect now. The FDA published a Refuse to Accept (RTA) policy tied to cybersecurity information under 524B. In plain language: if required cybersecurity elements are missing, the FDA may treat the submission as administratively incomplete, which can create delays before substantive review even begins.

Even if your immediate concern is legacy devices, this matters because it shifts the standard of care across the industry. Hospitals and procurement teams don’t separate your newest platforms from your installed base when they decide whether they trust your brand.

Cybersecurity Is Now Legal Exposure, Not Just Engineering Debt

If you still think cybersecurity is only about passing the FDA, zoom out.

In July 2025, the DOJ announced a $9.8 million False Claims Act settlement with Illumina tied to allegations involving cybersecurity vulnerabilities and misrepresentation of cybersecurity posture in sales to federal agencies. The takeaway is that cybersecurity representations, what you claim, imply, or certify, are increasingly enforceable territory.

That reality forces an executive-level question device makers cannot dodge: “If a customer assumes our device is maintainable and secure over its lifecycle, can we back that up?” If the answer is no, then legacy devices become more than a technical problem. They become a governance problem.

What Legacy Really Means Now

Most manufacturers understand legacy to mean “old.” That definition does not hold anymore.

A device becomes a legacy cybersecurity problem the moment it cannot responsibly be defended against current threats because of architecture, OS constraints, lack of secure update capability, cryptography limitations, or unsupported third-party components.

This is the structural mismatch: Hardware stays deployed for 10 to 20 years, while software dependencies and support cycles are far shorter. Threat models also age quickly, especially as connectivity changes.

This results in devices that still perform clinically, but are functionally trapped: outdated operating systems, hardcoded credentials, insecure protocols, limited compute for modern crypto, and dependencies that no longer receive security fixes. Some might ask, “Why don’t you just patch it?”

The reality is that many legacy devices cannot be patched on demand the way people expect.

Sometimes it is purely technical, for example, an old OS, locked toolchains, or an architecture that was never built for authenticated updates. Sometimes patching is possible in theory but unrealistic in practice because of validation burden, clinical downtime, regression risk, and service logistics.

So if patching isn’t available or not timely, the right answer is a risk-based strategy that prioritizes two things: exposure (how reachable it is) and impact (what happens if it is compromised). Patch when you can. Where you can’t, reduce exposure and increase detectability with compensating controls, proportional to risk.

Real-World Wake-Up Calls: This Is Already Happening

The risk isn’t hypothetical. We have already seen legacy product realities collide with modern threats in public, documented ways.

The FDA issued a safety communication on cybersecurity vulnerabilities in certain Contec and Epsimed patient monitors, including risks like device disruption and the potential for unauthorized control. In parallel, CISA published an analysis describing the Contec CMS8000 as containing backdoor behavior in a CISA fact sheet. Design decisions made years ago can turn into today’s exposure once devices are connected in the real world.

The FDA has also treated cybersecurity as a corrective action for implanted devices. In its pacemaker firmware update safety communication, the FDA described a firmware update intended as a corrective action to reduce risk from potential exploitation.

And the legacy code problem is real. The FDA publicly warned about the URGENT/11 vulnerabilities in a widely used third-party TCP/IP stack, noting that, if exploited by a remote attacker, they could pose risks to medical devices and hospital networks. This is exactly the kind of sector-wide exposure that becomes painful when devices cannot be updated quickly. Once you accept that many legacy devices cannot be patched quickly, the next question is where to start.

Risk-Based Prioritization: Reachability Multiplies Risk

After you build an inventory, the fastest way to reduce risk is to prioritize devices based on reachability. In general, the most urgent legacy issues are devices that are routable on enterprise networks, broadly reachable across segments, dependent on remote service access, and clinically critical.

Why? Because network reachability turns a weakness into an opportunity. It increases the likelihood, attack paths, and blast radius.

That doesn’t mean proximity and physical vectors don’t matter. Bluetooth Low Energy (BLE) and other local wireless interfaces can be low- or high-risk depending on pairing and authentication, range, and whether the interface can pivot into higher-impact functions. USB and service ports aren’t low risk by default in healthcare either. Devices are handled by biomed staff, vendors, and contractors, and weakly controlled service modes can become a real pathway.

A simple, defensible way to say it is this: Connectivity drives likelihood, and clinical function drives consequence. Triage should prioritize the intersection of those two.

A Practical Model that Works: Inventory, Triage, Contain, or Patch

If you want a legacy program that holds up with the FDA, customers, and your own quality system, don’t start with a shopping list of tools. Start with an operating model: inventory, triage, act, repeat.

Inventory means you can answer basic questions quickly: What OS is deployed? What services are exposed? How is the device connected in the real world? What third-party components exist? Is the device patchable? How is remote service performed?

Act means you do the right thing based on reality. If the device is patchable in a timely and safe way: fix, validate, deploy, and communicate. If the device is functionally unpatchable in the short term, contain risk with compensating controls and communicate transparently.

In legacy environments, containment is often the most responsible option available on the timeline that the threat environment demands.

Segmentation Based on Risk

Putting a device on a VLAN isn’t a strategy. Effective segmentation is enforceable, testable, and specific enough that a hospital can implement it without breaking workflow.

For high-risk, hard-to-patch legacy devices, segmentation should be designed to answer three questions: Who can talk to the device? What can the device talk to? How fast would we know if either of those changed?

That typically translates into controls like allowlisting (permit-only network rules), dedicated device zones with access control lists (ACLs) between zones, no direct internet access from device segments, controlled remote service via jump hosts (controlled gateways), and multi-factor authentication (MFA), and monitoring tuned to known-good device behavior.

The goal is simple: reduce exposure and shrink attack paths.

Legacy Cybersecurity Is a Supply Chain and Service Problem

Legacy cybersecurity involves more than just original engineering designs. It requires a coordinated effort across sustaining engineering and supplier management, tied to the outsourced ecosystem.

If you want a legacy strategy that holds up, you need suppliers and partners aligned on security obligations. That means your contracts and quality agreements should address things like:

• Software bill of materials (SBOM) inputs from suppliers, defined deliverables, not best effort;
• End-of-life notifications for OS, libraries, chipsets, and modules, with clear lead times;
• Vulnerability notification windows and patch expectations (SLAs) appropriate to risk;
• Controls around service tooling: credentialing, MFA, logging, and least privilege;
• Clear ownership for field actions: updates, labeling changes, customer mitigations, and end-of-support transitions.

This is where a lot of programs quietly fail. The OEM builds a good internal process, but the ecosystem does not move with it. Then an issue hits, and everyone scrambles for answers that the contracts never required them to provide.

Legacy cybersecurity succeeds when it’s treated as an operational capability spanning quality, regulatory, service, supplier management, and customer success, not as a one-off engineering project.

Legacy Triage Quickstart

When working with healthcare facilities, we suggest the following approach to help triage their installed base into address now, plan remediation, or monitor and manage:

1. Inventory (non-negotiable)
   Do we know the device’s real-world connectivity, exposed services, OS, and dependencies, and whether it is realistically patchable?
2. Patchability decision
   • Patchable: authenticated update path, realistic validation, deployable in the field
   • Functionally unpatchable in the short term: any one of those is no
3. Exposure score (likelihood driver)
   • High: routable network, broad reachability, or remote service access
   • Medium: local wireless proximity with weak controls or realistic attacker access
   • Lower: physical access only, with strong service controls
4. Impact score (consequence driver)
   Could compromise affect therapy delivery, alarms, measurement accuracy, or availability? Could it cause misdiagnosis, delayed diagnosis, or denial of therapy?
5. Action
   • Address now if: high exposure plus unpatchable, shared, or hardcoded credentials, unsupported OS with known exploitability, or a credible pathway to essential performance impact
   • Plan remediation if: risk can be controlled via segmentation, hardening, and monitoring while patching or modernization is planned
   • Monitor and manage if: strong update path, minimal attack surface, strong identity controls, and controlled risk profile

Containment minimum standard for unpatchable high-risk devices: allowlisting, no internet access, restricted remote service (jump host, MFA, monitoring), hardening guidance, and a clear residual risk communication plan.

The Bottom Line

Hospitals are increasingly evaluating cybersecurity posture alongside clinical efficacy. Procurement teams want clear support timelines and end-of-life policies, fast “are we affected” responses, predictable patch communication, and mitigation guidance that fits clinical reality.

Manufacturers who embrace transparency win trust. Manufacturers who avoid it lose it, quietly at first, then suddenly.

Legacy medical device cybersecurity isn’t solved by a massive remediation effort. It is solved by an honest portfolio view, a repeatable triage process, and a post-market operating model that treats security as part of patient safety.

Maturity should be the focus here, not perfection: inventory and visibility; prioritization based on reachability and patient impact; patch when you can and contain when you cannot; segmentation and compensating controls that are specific and enforceable; fast, clear customer communication; and supplier and service alignment that supports lifecycle security.

The market is shifting, and the manufacturers who lead with responsible legacy management will earn trust and keep it.

Christian Espinosa is the founder and CEO of Blue Goat Cyber, a company that provides full-service medical device cybersecurity that lands 510(k), De Novo, and PMA submissions on the first pass: penetration testing, SBOMs, threat modeling, and eSTAR-ready documentation, handled end to end.