FDA Releases New Guidance on Cybersecurity for Medical Device

Product Development & Management

FDA Releases New Guidance on Cybersecurity for Medical Device

By |

FDA Releases New Guidance on Cybersecurity for Medical Device

In this post, we highlight and summarize parts of the new “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff.” It is important to note that this content contains non-binding guidance and therefore is not currently for implementation.

With that said, while this draft is non-binding, some organizations may adapt to this guidance proactively to address hot topics not covered in formal regulation, for example: U/X Human Factors, Software as a Medical Device (SaMD), combination products, and others.

This blog post, while quoting the FDA draft guidance directly, is not a full representation of the content. It is comprised of snippets that were particularly relevant or interesting to the author. It also does not cover any appendices.

You can find the full draft guidance here.

Following this information, subject matter expert, Vincent Balgos, weighs in on the draft guidance. Read to the end to see his thoughts!

FDA Guidance for Cybersecurity for Medical Device

With the increasing integration of wireless, Internet- and network-connected capabilities, portable media (e.g., USB or CD), and the frequent electronic exchange of medical device related health information, the need for robust cybersecurity controls to ensure medical device safety and effectiveness has become more important.

In addition, cybersecurity threats to the healthcare sector have become more frequent and more severe, carrying increased potential for clinical impact. Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the U.S. and globally. Such cyberattacks and exploits may lead to patient harm as a result of clinical hazards, such as delay in diagnoses and/or treatment.

Increased connectivity and interoperability have resulted in individual devices operating as single elements of larger medical device systems. These systems can include health care facility networks, other devices, and software update servers, among other interconnected components. Consequently, without adequate cybersecurity considerations across all aspects of these systems, a cybersecurity threat can compromise the safety and/or effectiveness of a device by compromising the functionality of any asset in the system. As a result, ensuring device safety and effectiveness includes adequate device cybersecurity, as well as its security as part of the larger system. For the current edition of the FDA-recognized consensus standard(s) referenced in this document, see the FDA Recognized Consensus Standards Database.

Scope: Who Does This Apply To?

This guidance document is applicable to devices that contain software (including firmware) or programmable logic, as well as software as a medical device (SaMD). The guidance is not limited to devices that are network-enabled or contain other connected capabilities. This guidance describes recommendations regarding the cybersecurity information to be submitted for devices under the following premarket submission types:

  • Premarket Notification (510(k)) submissions;
  • De Novo requests;
  • Premarket Approval Applications (PMAs) and PMA supplements;
  • Product Development Protocols (PDPs);
  • Investigational Device Exemption (IDE) submissions; and
  • Humanitarian Device Exemption (HDE) submissions.

General Principles

This section provides general principles for device cybersecurity relevant to device manufacturers. These principles, found throughout this guidance document, are important to the improvement of device cybersecurity and, when followed, are expected to have a positive impact on patient safety.

These general principles include:

  • Cybersecurity is Part of Device Safety and the Quality System Regulations
  • Designing for Security
  • Transparency in Cybersecurity
  • Submission Documentation

RELATED: Understanding FDA Medical Device Class and Classifications, and its Impact on Requirements Management

Using an SPDF to Manage Cybersecurity Risks

The documentation recommended in this guidance is based on FDA’s experience evaluating the safety and effectiveness of devices with cybersecurity vulnerabilities. However, sponsors may use alternative approaches and provide different documentation so long as their approach and documentation satisfies premarket submission requirements in applicable statutory provisions and regulations. The increasingly interconnected nature of medical devices has demonstrated the importance of addressing cybersecurity risks associated with device connectivity in device design because of the effects on safety and effectiveness.

Cybersecurity risks that are introduced by threats directly to the medical device or to the larger medical device system can be reasonably controlled through using an SPDF.

The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. From a security context, these are also trustworthy and resilient devices. These devices can then be managed (e.g., installed, configured, updated, review of device logs) through the device design and associated labeling by the device manufacturers and/or users (e.g., patients, healthcare facilities). For health care facilities, these devices may also be managed within their own cybersecurity risk management frameworks, such as the National Institute of Standards and Technology Framework for Improving Critical Infrastructure Cybersecurity, generally referred to as the NIST Cybersecurity Framework or NIST CSF.

Security Risk Management

To fully account for cybersecurity risks in devices, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates. In the context of cybersecurity, security risk management processes are critical because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, completely secure. Security risk management should be part of a manufacturer’s quality system. Specifically, the QSR requires, among other things, that manufacturers’ processes address design (21 CFR 820.30), validation of the production processes (21 CFR 820.70), and corrective or preventive actions (21 CFR 820.100). These processes entail the technical, personnel, and management practices, among others, that manufacturers use to manage potential risks to their devices and ensure that their devices remain safe and effective, which includes security.

Specific security risk management documentation where FDA has recommendations regarding 354 their scope and/or content are discussed in the following subsections:

  1. Threat Modeling
  2. Third-Party Software Components
  3. Security Assessment of Unresolved Anomalies
  4. Security Risk Management Documentation
  5. TPLC Security Risk Management

Security Architecture

Manufacturers are responsible for identifying cybersecurity risks in their devices and the systems in which they expect those devices to operate and implementing the appropriate controls to mitigate those risks. These risks may include those introduced by device reliance on hospital networks, cloud infrastructure, or “other functions” (as defined in FDA’s guidance “Multiple Function Device Products: Policy and Considerations), for example. FDA recommends that all medical devices provide and enforce the security objectives in Section IV, above, but recognizes that implementations to address the security objectives may vary.

Throughout this section, FDA outlines the recommended security controls and recommendations on how to document the resultant security architecture in premarket submissions through specific Security Architecture Views.

Cybersecurity Testing

As with other areas of product development, testing is used to demonstrate the effectiveness of control mitigations. While software development and cybersecurity are closely related disciplines, cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness.

Security testing documentation and any associated reports or assessments should be submitted in the premarket submission. FDA recommends that the following types of testing, among others, be provided in the submission:

  • Security requirements
  • Threat mitigation
  • Vulnerability testing
  • Penetration testing

RELATED: Software as a Medical Device (SaMD): Four Key Development Best Practices

Cybersecurity Transparency

In order for users to manage security risks in devices, either by an end user or within a larger risk management framework like the NIST CSF, transparency is critical to ensure safe and effective use and integration of devices and systems. This transparency can be conveyed through both labeling and the establishment of vulnerability management plans. However, different types of users (e.g., manufacturers, servicers, patients, etc.) will have different abilities to take on a mitigation role, and the need for actions to ensure continued cybersecurity should be appropriate for the type of user.

In this section, FDA provides recommendations on:

  • Labeling Recommendations for Devices with Cybersecurity Risks
  • Vulnerability Management Plans
Vincent Balgos Afterward:

In general, cybersecurity continues to be a growing and significant issue in recent years. From the Experian data breach (2017), Marriot Hotel (2018), and LinkedIn (2021), the volume of sensitive data exposed at an alarming frequency poses a significant risk. In the healthcare sector, the Scripps Health cyberattack in my hometown of San Diego, CA, some estimate that the minimal impact is expected to be >$100 million. More significantly, the potential impact of sensitive patient data out in the public domain is immeasurable.

On the medical device front, the FDA has issued recalls on a variety of devices (insulin pumps, pacemakers, etc.) citing cybersecurity risks for years. As medical device technology advances, and interoperability becomes more common, the opportunity of cybersecurity risks is ever more present.

Medical companies have (or need to soon) started considering cybersecurity as part of their standard business practices. In addition to the suggestions mentioned in the FDA draft guidance, many of us at Jama Software have seen medical company initiatives that include hiring cybersecurity experts to proactively support these efforts, incorporating a dedicated cybersecurity focus within the overall risk management procedure, and/or continued monitoring of the products and systems for potential exploits.

Since a single vulnerability can have dramatic impact, a systems approach to cybersecurity can provide valuable perspective for various levels of mitigation. In complex systems, with multiple interfaces, data streams, etc., potential vulnerabilities increase at a non-linear rate.

But how does one measure the cybersecurity level of a product’s software? An emerging metric is the Common Vulnerability Score System (CVSS) that assesses software vulnerabilities in a quantitative value. Some organizations may include this CVSS as a design requirement during the product development phase.

This approach proactively incorporates cybersecurity best practices early in the design process, which in turn demonstrates security traceability into the design, and its subsequent testing. With Jama Connect, and specifically our unique ability to create Live Traceability™ across the product development process, this cybersecurity requirement can be continually monitored (along with all other requirements) to ensure that the final product is safe, effective, and secured from potential cyberattacks.

RELATED


Jama Software
Latest posts by Jama Software (see all)