Your Medical Device Software Will Need Updated — Better Plan For It Now

By Rick Brooks and Josh Branch, Battelle

If your medical device has software, someday that software will need to be updated. Do you have a plan in place to ensure that updates can be made safely and securely?

Software updates are a fact of modern life. On the consumer side, we're all used to our phones, computers, and smart gadgets nagging us to download the latest patch and, occasionally, deciding to shut down of their own accord — usually at an inconvenient moment — to perform a critical update.

In the medical device world, the stakes can be much higher. A device that doesn't get a critical update when it is needed may be left with a security vulnerability that puts patient safety or data at risk. At the same time, the update process itself can introduce new security vulnerabilities.

While no medical device containing code is ever 100-percent secure, the industry has made significant improvements in device security over the last decade. However, once devices are released into the market, they are part of an evolving software and security ecosystem in which new vulnerabilities are discovered or introduced all the time. The FDA's postmarket guidance for medical device manufacturers recommends that the latter have a plan for patching software and firmware to address new vulnerabilities as they emerge; the 2018 Medical Device Safety Action Plan outlines the FDA’s intent to make this a requirement for device developers moving forward.  

Medical device developers may want to send software or firmware updates for other reasons, as well. These include:

• Introducing new features or functions (for the user or the device company);
• Making improvements to the user experience, or patching bugs identified after market release; and
• Maintaining compatibility with other devices, software, and operating systems that the device must interact with.

Considerations For Secure Medical Devices Updates

Regardless of the reason for the updates, device manufacturers must ensure that the update process itself is secure and does not introduce new vulnerabilities to the device. The best way to do this is proactively, by building into the device, from the very beginning stages of design, a secure update process. Manufacturers should look at several critical questions:

• How will emerging security risks and critical flaws, which would necessitate a software update, be identified and prioritized?
• How will the device be updated — manually on site (e.g., thumb drives), remotely through a network connection, remotely through a cellular connection, etc.?
• Does the device have enough processing power and memory to support the update process? Does the device need a dedicated processor to securely and safely handle updates?
• What is the authentication process? How will the device verify that the update is genuine and coming from the manufacturer?
• How has the patch been tested to ensure that it will not increase the risk of device failure or malfunction?
• What fail-safes are in place, in the device, to reduce the risk of failure or malfunction during or after a patch? What if the download or update process is interrupted?
• Can critical software updates be safely automated to ensure that all users receive the update? Or could the update process put patient safety at risk if not carefully coordinated?

Building a Software Bill of Materials

The FDA's Medical Device Safety Action Plan outlines evolving expectations for the medical device industry, including expectations for secure updates. Specifically, the FDA plans to:

Consider potential new premarket authorities to require firms, on the front end, to: (i) build capability to update and patch device security into a product’s design and to provide appropriate data regarding this capability to FDA as part of the device’s premarket submission; and, (ii) develop a “Software Bill of Materials” that must be provided to FDA as part of a premarket submission and made available to medical device customers and users.

What does this mean for device developers? First and foremost, it means that developers need to consider the update process on the front end, long before the device is released. Second, it will require developers to pay a lot more attention to the bits of code in their devices.

Creating a "Software Bill of Materials" (BOM) for each medical device (and each version of the device) is a good first step to proactive update management. The software BOM details all the pieces of code contained in the device, including the operating system; custom, in-house developed firmware and software; and code contained in third-party components, such as a Bluetooth processor stack, embedded microcontroller FW, or even fuse bit settings.

Keeping an accurate and up-to-date software BOM for every medical device in circulation — including the specific release version of each piece of code — will enable manufacturers to quickly identify which devices are impacted by an identified security vulnerability, and to develop effective response plans.

Proactive Steps Toward Secure Medical Device Software Updates

A secure medical device update plan encompasses several elements, including these steps medical device manufacturers should be taking already:

1. Start with secure design — First, make sure you are following up-to-date cybersecurity guidelines as you develop your device. These guidelines evolve quickly as new vulnerabilities emerge; if you don't have cybersecurity expertise on staff, it is usually prudent to contract with a medical device cybersecurity expert to evaluate your design plans.
2. Build or select hardware with updates in mind — When daily operation of the device requires minimal memory and processing power, device manufacturers may opt for hardware geared only towards those needs. That makes sense, especially when faced with size, weight, or cost constraints. However, updating the device may require more memory and processing power than is needed for standard operation of the device.

Make sure your device has enough memory and processing power to handle a secure update that includes modern cryptographic functions. This includes memory for secure key storage and processing power to handle cryptographic functions, such as digital signature creation/verification and data encryption.

3. Create a secure delivery mechanism for software updates — There are six key aspects to consider in developing a secure delivery mechanism for software updates:

1. Authentication — a method for verifying the identity of the update provider
2. Authorization — a permissions system that verifies that the person or system triggering the update is authorized to do so
3. Availability — the ability of the device to receive and process the update without impacting primary functionality
4. Confidentiality — appropriate encryption to protect data security and privacy
5. Integrity — a method for ensuring that data received during the update is complete and accurate
6. Nonrepudiation — accurate event logs to enable tracking and troubleshooting of device updates

4. Build fault tolerance into your update mechanism  — A robust, fault-tolerant design must consider how it handles and recovers from typical faults that may occur during the update process, such as the loss of communication (network connectivity) or loss of power during an update. Devices with critical functions (e.g., pacemakers), or devices with low bandwidth connections (e.g., Bluetooth Low Energy), must consider how to expedite the update process and minimize downtime.
5. Consider how updates are triggered and timed — Automatic updates from the manufacturer’s website may be ideal to ensure prompt updates for some types of medical devices. However, for life-sustaining devices, applying a software update at an incorrect time can put patients at risk. The design must consider when it is authorized to install an update and who it has been authorized by. For example, a large hospital will want to test and validate a software update before they authorize the update to be installed on their devices.

A proactive approach to secure software updates will help medical device manufacturers avoid substantial headaches after the device is released. Incorporating secure design elements will ensure that medical devices can receive the updates they need to improve functionality, protect patient safety and data security, and maintain compatibility with other devices and systems.

About The Authors

Rick Brooks is the Director of Systems, Software, and Electrical Engineering, and DeviceSecure Services for Battelle’s Medical Device and Health Analytics Business. Rick leads an organization at Battelle that develops technology-enabled medical devices and software solutions. Over his career, Rick has served in a variety of roles for product development projects for the commercial, government, and medical products industries. He holds a degree in Electrical Engineering and received his Project Management Professional (PMP) certification in 2009. He is a voting member of the Association for the Advancement of Medical Instrumentation (AAMI) working group on cybersecurity for medical devices.

Josh Branch is a software engineer at Battelle with experience covering a diverse range of applications, including both embedded and non-embedded software.  His core skills include extensive development in C, C++, C#, and Java to target platforms including Windows Desktop, Microsoft Azure/AWS, Mobile Applications, Embedded Linux, and various microcontroller cores including ARM Cortex-M, AVR, and PIC.  Josh leads software teams that develop technology-enabled medical devices, with a focus on transitioning cybersecurity improvements into production use.