Medical Device Interoperability Risks

Updated October 26, 2024

Medical devices are often designed to connect to other devices and systems. This opens up extended functionality and the ability to rapidly move information and help patients in new ways. Unfortunately, this also expands a system’s attack surface and often gives attackers the ability to attack other systems through the device or vice versa. Interoperability considerations in medical devices are paramount. Device manufacturers and security teams should keep this in mind when accounting for a medical device’s cybersecurity.

Table of Contents

• Addressing Interoperability And Security Considerations
• Testing Interoperable Systems
• Medical Device Cybersecurity FAQs

Why this matters

The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 3, 2026 final guidance) made cybersecurity documentation a gating criterion for clearance under Section 524B of the FD&C Act. Reviewers now apply this guidance to medical device interoperability risks the same way they apply software lifecycle expectations from IEC 62304 and security risk-management expectations from AAMI TIR57 and ANSI/AAMI SW96:2023.

Gaps in this area are the single most common driver of first-cycle cybersecurity Additional Information (AI) requests. The FDA's FY2024 CDRH performance reports show cybersecurity is among the top deficiency categories cited in 510(k) and PMA AI letters, behind only software documentation and clinical evidence. Treating it as a checklist exercise rather than a design-controlled engineering artifact is what creates the gap.

Addressing Interoperability And Security Considerations

The first major consideration with interoperability is whether or not interoperability applies to the device in question. This distinction may be more difficult to make than it would seem at first glance. Some devices may connect with other devices in very minor ways or may interact with systems in a seemingly insignificant way. Any time a device can connect or communicate with another device or system, it should be assessed for interoperability risks.

Once a device is deemed to be interoperable, the next focus is the functionality of the interoperability. It can be good to break interoperability into two areas: data in and data out. Data in can be thought of as any information going from an external device or system to the medical device under test. An example of this could be a human interface device (HID) such as a mouse or a keyboard. Data out follows the opposite flow, where data leaves the trust boundary of the device and goes to an external device or system. Something that would meet this definition could be a printer, or a PACS server taking processed data out of the device.

While this is not an absolute rule, typically, connections passing data out will be used to jump from the device to other systems, while connections in will go from other systems to the device under test. This is an important distinction to make, as it influences the starting point for testing. As mentioned above, this is not an absolute rule, and all testing should take place on any entrypoint into the trust boundary.

The next major concern is what type of data is going through the interoperable connections. It may be the case that the data is of minor enough concern that exploitation is unlikely. It may also be the case that attack techniques are not commonly known or researched for the data type under test. In cases like these, it may be possible to explain this level of risk and shift focus toward more sensitive areas. This is a delicate decision to make, and it is important to make a careful assessment of each specific case where this is handled.

Testing Interoperable Systems

Once key targets are identified, the next step is to thoroughly test them for proper security. What happens during this testing largely depends on the connection under test and what components are at the ends of these connections. Security testers will have specialized tools and techniques that apply to each connection, interface, and data type. These test cases should be adjusted based on the data being passed through these connections to ensure that security is prioritized in the correct places.

See also: NeuroTech Cybersecurity Risks, The Overlooked Threat in MedTech, and QNX Vulnerabilities in Medical Devices.

The first step in interoperability testing is to properly threat model what could happen to the system and go from there. Following an established threat modeling framework, such as STRIDE or DREAD can provide a good start for what attacks should be considered. Threat modeling tends to work from the risk inwards, meaning the first concern is impact, and the next is how it can be exploited. Finally, threat modeling should preemptively explore mitigations before testing is performed.

Once the threat model is complete, the next phase is the actual testing of the interfaces. This testing will vary heavily depending on what the physical or network connection specifications are, but all ultimately look to find the impact on patient data and patient safety. By following the threats identified through threat modeling, security testers should be able to develop a clear understanding of the attacks that can be done. Security testers will also typically have established test cases for many different interfaces and network connections that meet industry expectations.

When in doubt, it can be a good idea to consult with a security professional. Specialists can help identify areas for improvement in the planning phase and perform the testing process in its entirety. The team at Blue Goat is capable of facilitating the entire submission process to regulatory bodies, from the testing side to the documentation side. Reach out to our team of experts to start your submission process guided by us.

How Blue Goat approaches this

Blue Goat Cyber's medical device practice is led by engineers with CISSP, OSCP, and prior military red-team backgrounds. We treat cybersecurity documentation as design-controlled engineering output, not a submission template, every artifact (threat model, SBOM, security risk assessment, penetration test, labeling) traces back to a controlled requirement and a verified result.

Our engagements deliver the full Feb 3, 2026 guidance documentation set scoped to the device's risk profile, integrated with the existing IEC 62304 software lifecycle and ISO 14971 risk file. See our medical device cybersecurity services for the full scope. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

FAQ

What are the primary cybersecurity risks of medical device interoperability?

The primary risks include an expanded attack surface, potential for unauthorized access to interconnected systems, and vulnerabilities in data exchange. Exploiting one device could compromise others connected to it.

How does the FDA address medical device interoperability cybersecurity?

The FDA requires manufacturers to consider cybersecurity throughout the total product lifecycle, including interoperability. The February 3, 2026 final guidance emphasizes secure design, threat modeling, and postmarket vulnerability management for connected devices.

How should manufacturers approach testing interoperable medical devices?

Manufacturers should start with complete threat modeling to identify potential attack vectors. Subsequent testing must be tailored to specific connection types and data flows, focusing on impacts to patient data and safety.

What is the difference between 'data in' and 'data out' in interoperability testing?

'Data in' refers to information flowing from an external system to the medical device, like a keyboard input. 'Data out' involves data moving from the device to an external system, such as a printer or PACS server. Both directions require assessment.

Does minor connectivity still require cybersecurity assessment?

Yes, any connection point, no matter how minor it seems, should be assessed for interoperability risks. Even seemingly insignificant interactions can present an attack vector if not properly secured.

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.