Updating Medical Device Software in the Field

Connected medical equipment and devices have become an essential part of modern healthcare. These devices play a crucial role in diagnosing illnesses, monitoring patients’ conditions, and delivering treatment. The ability to update these devices is critical for ensuring their continued safety, efficacy, and security. However, updating software in medical devices can be quite challenging due to an assortment of reasons.

This process has been called by many names, but one of the predominant terms is FOTA or Firmware Over The Air (“air” can refer to a wireless or wired connection).

Regulatory Basis

Most of the worldwide regulatory agencies require FOTA capability to be included in medical devices, principally for addressing cybersecurity issues as they occur, including:
FDA, April 2022—Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff. Simply calls out the requirement: “Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product’s lifecycle” and “Design devices to anticipate the need for software and firmware patches and updates to address future cybersecurity vulnerabilities. This will likely necessitate the need for additional storage space and processing resources.”¹

European Medical Device Regulation (MDR)—The MDR requires manufacturers to provide evidence of software validation and maintain a system for managing software updates and upgrades. The regulation also requires that software updates and changes do not negatively impact the safety or performance of the device. Such as: “Practice 7 – Security update management: The processes specified by this practice are used to ensure that security updates and security patches associated with the product are tested for regressions and made available to product users in a timely manner.”²

International Medical Device Regulators Forum (IMDRF)—Software as a Medical Device (SaMD) Guidelines. These guidelines recommend that SaMD be designed to allow for updates and changes and manufacturers should have a process for managing software updates and upgrades. Specifically, “Manufacturers should make it feasible for users to safely implement information security updates.”³

There are two situations, however, where a manufacturer may successfully argue against the need to have FOTA updates designed into their device:

1. The medical device has an extremely short operating life, such as devices where the operating life is measured in hours—as is seen in some disposable diagnostic devices and in continuous glucose monitoring.
2. The manufacturer is betting on using recalls as an alternative to FOTA updates. This is a pretty big bet, as the average cost of a medical device recall is approximately $2 million.

Both of these are going to be topics of discussion during the premarket submission process with the regulatory agency, and in the end, they may not agree with the manufacturer’s position.

General Considerations

USB flash drives and other physical or non-FOTA update vectors are not a good approach to updating a medical device because:

• Physically distributing the flash drives to all devices in the world
• Manual delivery makes it very slow to roll out an update
• No back reporting (or, at best, very little) on the progress/status of updated devices
• Potential for device-to-device contamination (malware, worms, etc.)
• Very large risk of software exposure and subsequent reverse engineering by attackers and competitors

FOTA is a superior approach, but performing it effectively, securely, and efficiently is not a simple matter. Software updates are conveyed in what we will call an “Update Image,” which consists of the updated software, plus other things we will review later. An Update Image contains what is generally referred to as an update or a patch. An update is complete, whole, executable images of software (app, OS, etc.), while a patch is generally considered a partial software update from a third-party software component vendor. (A high-level reference on this process can be found on the NTIA’s website.⁴) There are implicit constraints a device FOTA has to comply with:

• Cannot result in a non-functional device/system
• Requires human approval
• Can only rarely take place without reset(s) of the device/system
• No device in a medical device system will be upgraded until all devices can be upgraded to co-exist
• Rollout has to start within 60 days after the manufacturer learns of a vulnerability

The type of target device affects the nature and technical details of the FOTA process. For example, if the target device is an embedded PC (Windows or Linux) using a file system, this simplifies how the update process is performed. Some standards could be applied in this scenario as well, such as The Update Framework,⁵ which requires Linux to function.

The second type of target device is far more common and is based on custom electronics with or without an operating system. These types of devices have no standard update process, and typically, they do not use any file system. These systems are harder to update.

In either type of device, the non-volatile storage (Flash/HDD/SSD/etc.) should have more than twice the capacity of the estimated size of the entire programmable system, including operating system, application, device drivers, libraries, communication stacks, etc. The device should have at least two versions of the programmable system in memory at all times: the previous, known-good version, plus the new, Update Image version, plus room for the bootloader/update agent software needed.

FOTA Considerations for Healthcare Delivery Organizations

When it comes to FOTA, healthcare delivery organizations (HDOs) have specific needs and concerns, including:

• Human-readable details about how the FOTA operation is performed, its requirements, and how the process is secured
• Initiation control of the FOTA operation, so devices can be removed from active use before beginning
• Initiation of the FOTA operation may require specific user authentication
• Some devices cannot be removed from patients, such as implantables. These should only be updated by a healthcare professional.
• Timely/thorough communication regarding a device’s pending update
• Human-readable integrity checks before and after being installed in a device
• Machine-readable or printable confirmation of a successful update for HDO records

The availability of additional support data, such as:

• Post update “installation qualification” procedure
• Software bill of materials for the new version
• Internet/intranet access and IT support for the target device before, during, and after FOTA
• Updated software may require retraining users on how to navigate or operate the device.

Considerations for MDMs

Medical device manufacturers (MDMs), likewise, have their own needs, such as:

• Preventing exposure and reverse engineering of the Update Image (e.g., with encryption)
• Ensuring the integrity of the Update Image and the final code base in the target device (i.e., a signed or hash-protected Update Image)
• Rollback prevention (i.e., include metadata for version in the Update Image, which can only be greater than the old version being replaced)
• Ensure the correct update image is installed on the correct device (i.e., include metadata for the specific model of the targeted device)
• Ability to rapidly roll out the update (but not too rapidly! Update rates should be throttled to limit the impact of any Update Image mistakes)
• Internal controls on how FOTA is initiated, such as multiple approvals, YubiKeys, etc., to avoid an insider attack (a disgruntled employee could decide to push out an Update Image that will “brick” all the targeted devices)
• Dynamic status reporting to regulators and other stakeholders on the FOTA progress, including accumulated metrics such as time periods to reach specific penetration percentage milestones
• Maintaining detailed reporting of device updates and devices not updated, including failed update attempts
• Conversion of “semi-dynamic data” in the device to work with the new version, such as current settings, credentials, logs, and data structures. This can include the data’s location and units of measure employed.

When possible, electronic hardware selection should favor built-in controls for performing updates, such as secure boot features.

Creating a FOTA system opens up the possibility of many potential vulnerabilities, including:

• Modification of the Update Image during distribution
• Exposure of the Update Image that can be reverse engineered
• Rollback of the device to an older version with known vulnerabilities, that can then be exploited
• Wrong Update Image applied to a device/system
• Exposed active communication ports (USB, Wi-Fi, Ethernet, etc.)
• Worms/ransomware (Wi-Fi, Ethernet)
• Malware Cross Infection (USB Flash drive)
• Insider attack by a disgruntled MDM employee

Conclusion

In summary, while it is now a regulatory requirement, updating medical device software can be a complex process that requires careful planning, testing, and compliance assurance. Manufacturers must also consider potential risks, compatibility issues, user training, data privacy, and security concerns when updating medical device software.

Hopefully, this article has provided a level of appreciation for the scope of the challenge, and helped you to better evaluate the current or future FOTA program in your organization. 

References

1. bit.ly/mpo230621
2. bit.ly/mpo230622
3. bit.ly/mpo230623
4. bit.ly/mpo230624
5. bit.ly/mpo230625

---

Christopher Gates is the director of Product Security at Velentium. He has more than 50 years of experience developing and securing medical devices and works with numerous industry-leading device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, Bluetooth SIG, and FDA to present, define, and codify tools, techniques, and processes that enable the creation of secure medical devices.