Cyberattackers are well aware of medtech software weaknesses. Are you?

By Joseph Saunders, RunSafe Security

Medical device cybersecurity issues are a risk to patient health and safety. [Illustration by Stockye Studio via Stock.Adobe.com]

Healthcare cybersecurity conversations typically focus on hospital IT networks and patient data protection. What’s less talked about is the risks in the software powering medical devices themselves.

According to a 2025 report from Claroty, 93% of healthcare organizations have confirmed known exploited vulnerabilities (KEVs) in their Internet of Medical Things (IoMT) devices. The FDA’s recent requirements on post-market cybersecurity and the growing role of software bill of materials (SBOMs) signal that regulators are increasingly aware of these issues and are making a push for greater software security.

What are ways to improve device security and address widespread problems? The following three risks in medical device software are a strong place to start.

Risk 1: IoMT devices and insecure internet connectivity

IoMT has reshaped healthcare delivery with improved operational efficiencies and capabilities for patient care. However, insecure internet connectivity is a risk to everything from imaging systems to patient devices.

Major weak spots for IoMT devices are the vulnerabilities and connectivity issues in underlying operating systems, particularly for devices running on legacy Windows and Linux platforms.

We saw this clearly with URGENT/11, a set of 11 critical vulnerabilities in the TCP/IP stack (IPnet) of VxWorks, a real-time operating system (RTOS) deployed in over 2 billion embedded devices, including MRI machines, infusion pumps, and patient monitors. The vulnerabilities stemmed from memory corruption flaws that allowed remote code execution, as well as vulnerabilities that led to information leaks or logic flaws. By exploiting these vulnerabilities, attackers could potentially manipulate infusion pump dosing, falsify emergency alerts on monitors, or otherwise manipulate devices remotely.

URGENT/11 highlights how connectivity risks can turn into widespread problems and allow attackers to move laterally across healthcare networks.

Risk 2: Open source code and third-party components

While third-party components and open source code offer efficiency advantages for development teams, they introduce risks to medical device software that require proactive management. Ultimately, device developers and manufacturers are responsible for all aspects of their software, including components that come from elsewhere.

SBOMs, particularly those generated at build time, provide visibility into the software supply chain, including any open source code or vendor-supplied components. SBOMs allow for early identification of vulnerabilities and provide a comprehensive list of issues that need mitigation to meet FDA submission timelines. SBOMs also support post-market security efforts by providing immediate access to a complete component inventory when vulnerabilities are discovered down the line.

Importantly for development teams, SBOMs reveal common, recurring vulnerabilities in software, allowing organizations to address them systematically through secure coding practices or specialized security solutions focused on areas of greatest risk.

Risk 3: Unpatched Vulnerabilities

Perhaps the most persistent challenge in medical device security is patching vulnerabilities in deployed devices. Patching medical devices is time-consuming and difficult for many reasons. Not patching, however, leaves devices exposed.

Forescout Vedere Labs found that 32% of DICOM workstations have critical unpatched vulnerabilities, while 26% of pump controllers have critical unpatched vulnerabilities, with 20% having extreme exploitability.

As seen in the URGENT/11 example, unpatched vulnerabilities can have far-reaching consequences across healthcare environments. One significant way to reduce risk is by focusing on removing entire classes of vulnerabilities from device software. For example, memory-based vulnerabilities are common in medical devices and software written in C/C++. By embedding runtime security solutions into the software development process, manufacturers can effectively eliminate attackers’ ability to exploit memory-based flaws, even in devices that cannot be easily updated.

Next steps for device security

Medical device software issues are a risk to patient health and safety. The risks outlined above also directly affect product development, regulatory approval processes, and overall healthcare security.

To address challenges, there are several areas to consider:

• Enhanced device-level security protocols: Incorporate authentication measures, encrypted communications, and runtime protection directly into development processes.
• Secure software supply chain practices: Implement rigorous vendor assessments and open source component review processes.
• Comprehensive SBOM monitoring: Integrate SBOM generation and analysis into the software development lifecycle to catch vulnerabilities before they reach production and to align with FDA expectations.
• Address entire classes of vulnerabilities: Consider security solutions that reduce software risk by eliminating the ability to exploit common vulnerabilities across codebases.

Attackers are well aware of the software weaknesses in medical devices. By pinpointing the greatest areas of risk, device developers and manufacturers can take the upper hand and protect products and the patients who depend on them.

RunSafe Security founder and CEO Joe Saunders [Photo courtesy of RunSafe Security]

Joe Saunders is the founder and CEO of RunSafe Security, a pioneer in cyberhardening technology for embedded systems across critical infrastructure. Saunders has built and scaled technology for both private and public sector security needs in his 25 years in national security and cybersecurity, and aims to transform the field by challenging outdated assumptions and disrupting hacker economics.

How to submit a contribution to MDO

The opinions expressed in this blog post are the author’s only and do not necessarily reflect those of Medical Design & Outsourcing or its employees.