FDA, IMDRF Chart Different Courses on Cybersecurity

Cybersecurity became a pertinent question again recently upon the news that the U.S. Department of Justice had arraigned two hackers accused of life science espionage conducted on behalf of the People’s Republic of China.

Cybersecurity became a pertinent question again recently upon the news that the U.S. Department of Justice had arraigned two hackers accused of life science espionage conducted on behalf of the People’s Republic of China. While these allegations have more to do with hacking the computer systems of research institutions, they raise once again the question of how medical devices in hospitals can continue to operate safely if the hospital IT system is compromised.

Two of the most important voices in medical device cybersecurity, the U.S. FDA and the International Medical Device Regulators Forum, are collaborating on a number of projects. However, the two have taken seemingly different approaches to cybersecurity, with the IMDRF relying on a single document whereas the FDA has broken the task into two parts, a draft guidance for the contents of regulatory submissions and a guidance for post-market cybersecurity management.

One point of interest regarding the FDA premarket contents draft is that it would replace a final guidance from 2014. The agency explained that the 2018 draft is a necessity driven in part by the proliferation of ransomware, which may be a reference to the WannaCry attack of May 2017. This draft is still not available in final form, however.

FDA Premarket Draft More Prescriptive

In section 5.1, the IMDRF cybersecurity guidance provides recommendations for security requirements and architecture design, which states that the related design inputs can “come from various phases across the product’s life cycle.” The developer/manufacturer should manage communication security by several means, including by determining:

  • How a device would interface with networks and other devices;
  • How a device design would validate all inputs, including from devices and environments that may be less secure than the subject device; and
  • How the design will address unauthorized access, modification and replay of function, including the use of a time-out mechanism.

One of the more noteworthy features of the FDA’s 2018 draft is that it sets forth two tiers of cybersecurity risk, which are not tied to the inherent risk associated with that device. The higher of these two tiers is for devices that can connect with other devices, non-medical products, a network or the Internet, while the lower tier is for any devices that do not meet the criteria spelled out for the first tier.

Section V of the 2018 FDA draft is more detailed regarding design requirements, although devices that fall into the lower cybersecurity risk tier are not subject to all the conditions thus enumerated. In the section for limiting access to trusted users and devices only, the FDA draft stipulates that the manufacturer/developer describe:

  • Features that provide authentication of users;
  • Automated time-out mechanisms;
  • A method for layered authorization (e.g., caregivers, patients, health care professionals); and
  • A consideration of the use of physical locks on devices and communication ports (which also appears in the IMDRF guidance).

The FDA premarket draft lists a number of recommendations for authentication and check-authorization for any safety-critical commands, provisions that again are spelled out in much greater detail than seen in the IMDRF guidance. One example of this is that a device should have the capacity to verify authentication tags for software and firmware content.

Conversely, the IMDRF discussion of user authentication states little more than the manufacturer should consider the use of user access controls that bear a validation feature for grant of privileges to various types of users. The document lists several examples, such as passwords, hardware keys, biometrics, or a “signal of intent that cannot be produced by another device.”

CBOM, SBOM Sources of Regulatory Tension

One of the more interesting questions about the FDA draft is its use of a cybersecurity bill of materials (CBOM), which is defined as a list of items that includes any open-source or off-the-shelf software and hardware components. The IMDRF guidance uses the term software bill of materials (SBOM), but one of the parties that commented on the FDA draft, AdvaMed, said the agency should avoid introducing another acronym into the regulatory dictionary, given the already-widespread use of SBOM. One of the arguments in this regard is that the inclusion of hardware to the CBOM is impracticable, given that manufacturers of off-the-shelf hardware components may not be willing and/or able to provide such information.

The IMDRF guidance recommends a greater degree of regulatory harmonization on cybersecurity than exists at present, but it also lists a large number of existing cybersecurity regulations in draft or final form. This includes those developed by regulatory agencies in Canada, Germany, Japan and China, as well as the still-pending implementation of the latest medical device regulations in the European Union. One item that both the FDA and IMDRF approaches have incorporated is the use of Parts 1 and 2-1 of UL 2900-1:2017, the first of which the FDA officially recognized in 2017. Part 1 of the UL standard addressed general requirements, while Part 2 offers recommendations for network-connectable components of healthcare and wellness systems. The FDA added Part 2-1 to its list of recognized standards in June 2018.

The December 2016 FDA final guidance for post-market cybersecurity management states that the agency’s device center had entered into a memorandum of understanding with the National Information Sharing & Analysis Center, one of several information sharing and analysis organizations (ISAOs). While the IMDRF also recommends participation in such organizations, the key difference is that the FDA guidance has a set of documentation requirements for determining whether the manufacturer/developer is an active participant in an ISAO.

The two documents take substantially different approaches to the hazards to patients associated with vulnerabilities that are identified in the post-market setting, with the FDA offering five levels of risk. These range from negligible to catastrophic, whereas the IMDRF guidance addresses tiers of hazard in a section dealing with software updates and patches. For the IMDRF approach, there are three classes of regulatory requirements that would be imposed for updates, which includes:

  • Low (cybersecurity enhancement or “cyber hygiene, not related to known vulnerability);
  • Medium (for acceptable residual risk of patient harm, no associated functional impact); and
  • High (unacceptable residual risk of patient harm, even if no adverse events or deaths are reported).

Both documents cite at least one iteration of ISO 14971 in association with risk management for cybersecurity, but the IMDRF document lists the 2019 version of this standard, while the FDA makes reference to the 2010 revision of ANSI/AAMI/ISO 14971:2007.

Device makers will have to continue to navigate the differences between these and other approaches to cybersecurity for the immediate future, and it is nearly impossible to predict when a noticeably greater degree of harmonization will arrive. The IMDRF approach was finalized in March 2020, suggesting that its provisions are unlikely to change again at any time in the near term. The FDA’s position is seemingly more subject to revision, however, given that the post-market guidance is four years old, perhaps a near eternity in cybersecurity time, while the premarket draft has been sitting in docket for nearly two years. Very little betting money has been won by those who have wagered against stringent FDA standards, but the agency’s well-documented push for regulatory harmonization is at least one source of optimism on this point.

Get more of Enzyme

Sign up for the latest updates in your inbox
Ready to level up? Inquire about certification.
info@enzyme.com or

Ready to do more?