Jul 28, 2020

“My medical device doesn’t have network or wireless connectivity, so cybersecurity regulatory requirements don’t apply, correct?” We get this question quite often during initial conversations with medical device manufacturers. The short answer is, that assumption isn’t all that accurate. 

During discussions we often discover that the device in question has exposed USB or ethernet ports that oftentimes aren’t disabled and furthermore don’t require data to be encrypted. Sometimes we find that there is a CAN bus as part of the device’s command and control communications. Typically, the answer is that the main risk control that has been deployed is that the device sits in an access-controlled room.

Often, we follow this exchange with a simple question: “What if an attacker were able to gain access to your device, what could they potentially do?” We ask that question because we know that the spirit of the regulatory guidance documents that have come out over the last few years focuses on shared responsibility, so simply saying that a device isn’t network-connected or sits behind an access-controlled room does not adequately address the potential cyber risk of a device.

The conversation then tends to get interesting. Answers might be something like:

  • Inject malware into the code;
  • Extract IP;
  • Use it as a pivot point into a hospital intranet because the hardwired ethernet is communicating data to EHR platforms. 

Now, what is the likelihood of all of that happening? Or better yet, how would you answer that question coming from an external stakeholder? Simply claiming that these threats are unlikely to occur is not a sufficient answer for regulators and end customers. This is where the relevance of guidance documents and standards like AAMI TIR-57, NIST 800-30, or UL 2900-2-1 come into play to help manufacturers address and document such risk analysis.

The bottom line is that cybersecurity requirements do not just apply to wireless or network-enabled medical devices.  Any manufacturer developing devices that are software-enabled or have the ability to transmit data should prepare to make more than just claims about their security, but should also be able to clearly articulate and document how cybersecurity risks have been considered, as well as being able to provide evidence in the form of test reports validating the efficacy of the risk controls that have been implemented. The rule of thumb that may actually be best to consider is that, if a device has any software enablement--regardless of whether external interfaces are utilized--considering cybersecurity risk and adequate documentation of associated risk analysis is recommended. These sorts of traceable and documented risk mitigation processes are what regulators and end customers are seeking.

Christopher Beeman is Practice Lead at Emergo by UL’s Digital Health & Cybersecurity unit.

Related medical device software and cybersecurity compliance information:

  • Cyber regulatory support for connected medical devices
  • Organizational procedures consulting for medical device cybersecurity
  • Webinar: US FDA premarket guidance for medical device cybersecurity risk management

Author

  • Christopher Beeman

Related