29. How does cybersecurity affect the choice of medical devices?

Purchasing medical devices that don’t support the highest levels of security provides opportunities for hackers to exploit vulnerabilities on the device and/or wireless network. A system that has wonderful clinical attributes, but with security vulnerabilities, creates a risk the HDO should evaluate and understand.

Some hospitals may be constrained to continue use of existing medical devices that don’t meet the highest levels of security. As part of a security framework and plan, the hospital should minimize security risks and plan responses for if/when those devices are compromised as part of a medical device security program.

For more details and understanding, please consider industry-created guidance documents. A favorite is Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients.28

30. How do I deal with legacy medical devices with obsolete security features?

HDOs are grappling with legacy systems in a few ways and, preferably, include the following as part of a security framework:
  1. Segment network-connected medical systems so that those medical systems are shielded from other types of devices on the same network. Segmentation may include virtual local area networks (VLANs), firewalling (only include the specific IP addresses, ports, and protocols that are required by the medical device) and/or using a VPN to connect the non-secure device to the hospital network.
  2. Develop a process for replacing medical devices that includes security considerations (e.g., devices running unsupported operating systems).
  3. Restrict the purchase of medical devices that fail to meet security guidelines by creating a process for assessing medical systems that includes analyzing and addressing the risk(s) of the system before the systems are actually purchased. Preferably include in the requests for quotation (RFQs) sent to vendors the HDO’s security requirements, such as WPA2-AES, to communicate to MDMs that security is important.

31. What is a medical device security program and why is implementing one a worthwhile endeavor?

Medical devices are a key and potentially vulnerable set of devices at any HDO. Aging legacy systems, lack of inventory management, lack of risk awareness and education, lack of security intake processes, and inability to patch make medical devices a big challenge for any hospital. Without a security program in place to actively address these challenges, your organization is at a much greater risk of a successful attack or breach and also in a weak position to respond rapidly to an attack.

32. What is a key to starting a successful medical device security program?

One of the first steps is gaining support from senior leadership for instating a medical device security program. To do that, explain the “why,” in their language. For example, explain the costs of a data breach or a ransomware attack and the subsequent impact (potential patient diversion and lower revenues). Including the risk of physical and financial harm to patients further bolsters the argument for a medical device security program. Finally, emphasize that once a medical device is compromised, all networked systems—including HR and finance—are at risk.

33. What are the top priorities for a new medical device security program?


  1. Develop an intake process for new medical equipment that allows for security-related questioning and analysis.
  2. Discover each network-connected medical device connected to your internal networks, since networked medical devices will make up the bulk (if not all) of the device scope for the medical device security program.

34. What are the top things to be concerned about when assessing a new medical device?
  1. Software patching (updates): Ensure the provider has a reliable and secure method for distributing patches and that the provider actively assess new vulnerabilities as they are discovered. Routinely patching devices is one of the better ways to minimize your overall risk landscape.
  2. Supported operating system: Making sure you understand the operating system on the device in question and how long that operating system will receive security updates is a big part of knowing what types of risks need to be addressed.
  3. Default passwords: Require that all default passwords be removed before the new system is installed.
  4. Encryption: Consider the highest level of encryption your network supports and the highest level of encryption the organization would like, e.g., WPA2-AES or WPA3-Enterprise. Set a standard for encryption that supports BOTH the HDO’s requirement and the most recent industry standard. Ensure the device encrypts electronic protected health information (ePHI) not only in transit, but also at rest.
  5. Authentication: Ensure the device supports the latest industry standards for secure methods to authenticate the device to the network. The device should also provide a secure method to authenticate software updates and any apps added to the device.
  6. Software bill of materials (BoM): In order to ensure a full picture is created during the initial assessment of the device, having a database of all the software on the device is vital. This allows determination of known vulnerabilities by comparing the software BoM to the National Vulnerability Database. The MDM should provide the software BoM and agree to provide updates to the HDO when software is patched. Understanding how to patch and which vulnerabilities exist for each piece of software is a major component when assessing a new medical system and when assessing the threat of new vulnerabilities. As part of device life cycle management, the MDM should routinely assess software for vulnerabilities and provide this information to customers.
  7. The MDM’s analysis of attack surfaces and mitigations and any vulnerability testing completed by the manufacturer.

If the manufacturer cannot or will not provide this information or will not address known vulnerabilities, consider it a warning about the security posture of the manufacturer and its devices.

For Bluetooth devices, see Question 80, “What are some Bluetooth-specific security considerations?”

35. Where should a medical device security program reside: HTM/clinical engineering or IT/IS security?

It does not really matter where the program officially lives as long as its guiding principle is to reduce network and device security risks that impact patients and employees. It is more important that the two groups work together for an integrated plan and execution.

36. What are some materials our organization should look at to help get started on building a medical device security program?


  • Health Industry Cybersecurity Practices, particularly Table 6, “Suggested Practices to Combat Attacks Against Medical Devices That May Affect Patient Safety”28
  • Medical Device and Health IT Joint Security Plan29
  • Framework for Improving Critical Infrastructure Cybersecurity30
  • Medical Device Cybersecurity: A Guide for HTM Professionals31

37. What’s the difference between encryption and authentication?

Encryption is the process of converting data into a form that is not readable/understandable by an unauthorized person or device. Authentication is the process of ensuring that a person/device is actually the person/device it claims to be. Secure communication requires both authentication and encryption.

38. Are there any security risks if I broadcast my service set identifier (SSID)? Is there any reason to hide SSIDs?

No. Hiding the SSID provides no real security. Even if the SSID is hidden, it is transmitted in the clear by every device that is connected to that SSID and also by the AP in probe-response frames. Moreover, many clients send out probe requests with the SSID visible even when outside of the facility. Microsoft TechNet has an excellent article with a section explaining why non-broadcast networks are not a security feature.32

Some hospitals have found that hiding SSIDs for all but guest networks helps patients and their families to identify the proper SSID for guest access. Before hiding SSIDs on clinical networks, ensure that all devices can connect correctly. Devices that strictly follow Dynamic Frequency Selection (DFS) requirements fail to connect to APs on DFS channels that don’t broadcast SSIDs, because clients are not allowed to transmit until after receiving a transmission from an AP.

39. What security-related information should an MDM provide to an HDO?

The ANSI/NEMA HN 1-2019 Manufacturer Disclosure Statement for Medical Device Security (MDS2)33 is an industry standard that provides a set questions to which MDMs can respond for each device model. This information supports the HDO’s risk management.