Securing Yesterday’s Medical Devices against Cyber Threats: Addressing Legacy MedTech
Medical devices often far outlast their support period. How can these reliable devices avoid becoming a security liability?
Tim Miller
September 25, 2025
In recent years, regulators have paid closer attention to the security of medical devices. From pacemakers to MRI machines to electronic health record systems, the cybersecurity risk has never been greater. A compromised device can be more than an inconvenience; it can put the health — or even the life — of patients at risk. Requirements like those included in section 524B of the Federal Food, Drug, and Cosmetic Act will improve the security of future medical devices. But what about devices already on the market and in the field? There are steps that health delivery organizations (HDOs) and device manufacturers can take to secure legacy medical devices.
Why Medical Devices Are Special
To some degree, medical devices are no different than any other computing device. They have software that runs on hardware. So does your phone, your laptop, and your television. But medical devices have a few characteristics that set them apart:
- Life-or-death impact. An exploited application on a laptop can be incredibly inconvenient: strained resources from cryptominers, data encrypted by ransomware, and financial information stolen. An exploited medical device can slow health care as providers fall back to paper records, or it can cause direct harm by modifying treatment — giving too much or too little of a medicine, for example. Patches have to be right the first time; there is little room for patches that are incomplete or that introduce additional bugs or vulnerabilities.
- High price tag. A new MRI machine can run in the low millions of dollars. Other diagnostic and imaging equipment can cost many thousands of dollars. HDOs have a strong financial incentive to hold on to equipment for as long as it continues to function. This can be years or decades beyond the manufacturer’s support period.
- Difficult to replace. Some medical devices are physically implanted in a patient. If a software vulnerability can’t be patched through an over-the-air update, the patient may need to undergo major surgery to modify or replace the device. This presents additional cost and risk to the patient, and may require weeks to physically recover.
These unique characteristics make traditional cybersecurity considerations weightier. Convenience-versus-security is a common tradeoff to consider in IT environments. In medical devices, “convenience” is replaced by “patient outcomes”. Quick access to data allows providers to make more informed decisions. This is important in office settings, but can be vital in emergency situations. But if sharing is over-prioritized against security, the HDO and patient face risks. Improperly disclosing medical information can lead to large fines for an HDO. Worse, an outage can push providers to fall back to paper forms. This can result in slower treatment and increase the risk of errors which could harm the patient. With the average ransomware incident requiring 30 days to recover, a single attack can have a broad impact.
The challenge of legacy devices
Medical devices are reliable and durable. That’s good news in general, but the longevity combined with the expense means that equipment remains in use far longer than the manufacturer provides support. In some cases, the equipment may be older than the technician operating it.
Old hardware is often accompanied by old software. I recently spoke to a company that does software development for medical devices that told me the code base was older than some of the developers working on it. Software that old is likely written in C or C++. Those languages have made incredible contributions to the field of technology and continue to power a huge swath of the Internet. At the same time, C and C++ lack the memory safety features of newer languages like Rust, allowing for an entire class of vulnerabilities that don’t have to exist. Additionally, the workforce has less experience with C/C++ than it did a decade or two ago. We’re not to COBOL-levels of arcanity, but the necessary deep expertise will be harder to find as the years go by.
Even when there’s a desire and skill to address vulnerabilities in decades-old equipment, one key piece is often missing: the source code. It might be hard to imagine now with ubiquitous use of version control systems, but historically, code was not always version-controlled. For products that reached end of life, the code may have been deleted or simply lost. For example, NASA did not preserve the full source code for Apollo 10’s lunar lander. Thankfully, no one is still using that hardware to land on the moon, but it’s a good example.
How manufacturers can address legacy devices
FDA regulations introduced in the last few years, including section 524B(Bb), will improve the security of new medical devices. But that doesn’t solve the problem of what’s already on the market and in the field. Here are some steps that manufacturers can do to help secure legacy devices:
- Share information. While it may be unpleasant to tell device owners about newly discovered vulnerabilities in your legacy devices, it’s more unpleasant to be in the headlines after a hospital goes offline. Manufacturers need to have a process for quickly sharing information about vulnerabilities — and how to mitigate them — with HDOs. Ideally, HDOs also have a way to communicate with each other so that they can share mitigations and workarounds that they’ve developed.
- Develop prevention strategies. Don’t wait until a vulnerability is discovered. Develop ways for device owners to prevent compromise of legacy devices and share those with HDOs proactively.
- Determine criteria for providing patches after “end of life.” With sufficient motivation, no software is truly end of life. HDOs won’t be writing the kinds of checks that the U.S. Department of Defense supposedly writes to keep receiving support for 1990s versions of Windows, but that doesn’t mean manufacturers can’t provide fixes for end of life devices. Not every vulnerability will meet the threshold of importance for this exceptional support, but some may. Manufacturers need to determine what criteria they will use to decide what constitutes a sufficiently-bad vulnerability and collect the resources they will need to provide a patch if one becomes necessary.
- Offer trade-in incentives for unsupported devices. This may be the most costly of approaches, but it can provide long-term value for both manufacturers and HDOs. The fewer legacy devices in use, the lower the risk of a vulnerability causing significant harm. Of course, no matter how generous the trade-in program, there will be HDOs who decline to participate.
How health delivery organizations can address legacy devices
While manufacturers can do a lot to help HDOs keep their devices secure, it’s ultimately up to the owner. Purchasing new devices that have stricter pre-market requirements is the most effective way to improve device security, but when that’s not practical, there are other steps to take.
- Locate and identify devices. Just like with any other device, security starts with knowing it exists. HDOs need a full inventory of all devices they own, including where they’re located, what resources they need access to, and when they reach (or reached) end of life. This may require going from room-to-room checking every device if you don’t already have a robust inventory.
- Join information sharing groups. If the manufacturer or an industry group has a way of communicating newly-discovered vulnerabilities, you want to be a part of that group. The earlier you know about a vulnerability, the better your chances of taking protective steps before a device is compromised. Information sharing groups will allow HDOs to learn from each other and improve their security posture.
- Reduce exposure. The best way to deal with a vulnerability is to not have to deal with it. Like with general IT resources, there are approaches that can reduce or eliminate certain threats. Using the device inventory, HDOs can use network segmentation to reduce the possibility of compromises spreading. Most exploits against medical devices aren’t targeted directly, they’re either incidental damage from another exploit or they’re the entry vector into the network. In addition, devices that don’t require connecting external drives can have policies that restrict mounting USB drives.
- Have plans. Vulnerabilities are inevitable; panic is optional. HDOs need robust business continuity plans, since the times when normal business operations are disrupted is when people need healthcare the most. These business continuity plans should consider what to do in case of a vulnerability in one or more medical device systems, including containing damage, providing continuity of care, and restoring the systems to service.
Talk to Kusari
Kusari can help you secure every step of your software supply chain. Our products are built on years of software and security expertise in regulated industries. With Kusari Inspector and Kusari Platform, you uncover hidden and transitive dependencies inside legacy software, identify vulnerabilities in older, static codebases that would otherwise be missed, tie your findings to regulatory requirements so you can proactively address compliance and prioritize fixes so you focus on what will make an impact rather than wasting effort on low-risk patches. If you’re ready to take the next step, schedule a custom demo.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?