FDA cybersecurity guidance summarized

The U.S. Food and Drug Administration (FDA) recently issued updated guidance for cybersecurity in medical devices. The FDA's new recommendations update previous guidance on the content of premarket submissions to address growing risks posed by cyber attacks on healthcare manufacturers, providers, and patients, such as ransomware attacks affecting hospitals.

The new guidelines stress the importance of mitigating cyber threats throughout the device lifecycle, particularly during development. They include security risk management recommendations that incorporate interoperability considerations.

Here we'll provide a brief overview of what's in the new FDA guidelines for medical device cybersecurity. We'll clarify what types of devices the FDA's guidance covers. We'll include a summary of recommendations the FDA in partnership with MITRE has developed for managing legacy medical device cybersecurity risks.

What are the new FDA guidelines for medical devices?

The FDA's new guidance invokes the regulatory authority of the device safety and quality systems (QS) requirements of the Code of Federal Regulations Title 21 Part 820 (21 CFR Part 820). Based on device specifics, these requirements may apply at the premarket stage, the postmarket stage, or both. QS requirements include guidelines for premarket documentation, design controls, software validation, and risk analysis.

Secure Product Development Framework (SPDF)

To satisfy QS requirements, the FDA recommends mitigating threats throughout the total product lifecycle (TPLC), starting with deployment of a Secure Product Development Framework. An SPDF consists of standard procedures that identify and reduce product vulnerabilities. It encompasses the entire product lifecycle from design to decommission.

An SPDF can reduce the need for re-engineering when postmarket connectivity features are added or vulnerabilities are discovered. This saves development resources and therefore money for the company’s bottomline. Furthermore, it can be integrated with existing processes.

The FDA recommends but does not require an SPDF as a way to follow QS requirements. QS requirements may be satisfied in other ways that meet regulatory standards.

Security risk management

A TPLC approach should include security risk management procedures throughout the product lifecycle. To support this precept, risk management should be updated as new information becomes available.

Documentation should account for differences between fielded devices. For instance, it should cover marketed devices and devices no longer marketed but still in use. Similarly, if updates do not automatically apply across all devices, different risk profiles should be developed for different software configurations.

Vulnerability metrics

To demonstrate security procedure effectiveness, the FDA recommends that manufacturers track certain metrics and, when possible, include these in premarket submissions and Premarket Approval Applications (PMA) annual reports. At a minimum, manufacturers should monitor:

• Percentage of updated or patched vulnerabilities (defect density)
• Duration from vulnerability identification to update or patch
• Duration from update or patch release to complete implementation in deployed devices

In cases of multiple vulnerabilities, averages can be provided.

Security architecture

Manufacturers bear responsibility for mitigating vulnerabilities in devices and the systems in which they operate, such as hospitals, cloud networks, design and deployment environments, and supply chains. A security architecture defines such systems and all connections into and out of them at both a high and detailed level. It should include information demonstrating that identified risks have been controlled.

Security architectures should include plans and procedures covering design and development, intended device uses, and design output. Premarket submissions should include security architecture documentation.

The FDA recommends that security architecture should be organized into "views" consisting of diagrams and text addressing specific security concerns. At a minimum, these should cover four key perspectives:

• Global system view
• Multi-patient harm view
• Updatability/patchability view
• Security use case view(s)

Views can be cross-referenced to avoid duplication.

Transparency

Cybersecurity risk management requires transparency. Key transparency measures should include device labeling and vulnerability management plans. Labels should incorporate risk information that would enable the end-user to maintain the device’s security.

Vulnerability management plans should cover procedures for identifying vulnerabilities after product release and communicating them to users. Plans should be included with premarket submissions so they can be evaluated.

How does the FDA define connected medical devices?

Per Section 524B the Federal Food, Drug, and Cosmetic Act (FD&C Act), the FDA defines medical cyber devices as devices that meet three criteria:

• Including software validated, installed, or authorized by the sponsor as a device or in a device
• Possessing capability of connecting to the internet
• Containing potential vulnerabilities to cybersecurity threats

Examples of features that characterize covered devices include:

• Wi-fi or cellular connectivity
• Network, server, or cloud connectivity
• Bluetooth or Bluetooth Low Energy
• Radiofrequency communications
• Inductive communications
• Hardware connectors with internet capability, such as serial ports, USB, or ethernet

The FDA's definition follows the definition of "software" used by the National Institute for Standards and Technology (NIST). Its definition of "cyber devices" includes devices that potentially can connect to the internet, even if that is not their intended use. This addresses vulnerabilities that can arise from devices interconnected with a larger ecosystem of medical device systems.

Summary of MITRE security recommendations

To implement the FDA's guidance for cybersecurity in medical devices, the FDA commissioned not-for-profit organization MITRE to develop specific recommendations for managing legacy medical device cybersecurity risks. These recommendations expand upon imperatives identified by the 2017 Healthcare Industry Cybersecurity Task Force Report, jointly coordinated by the Department of Health and Human Services (HHS), the Department of Homeland Security (DHS), and the National Institute of Standards and Technology (NIST). MITRE offered four major recommendations:

• Medical device manufacturers (MDMs) and health delivery organizations (HDOs) should share information over the lifecycle of medical devices.
• MDMs, HDOs, and other stakeholders should coordinate vulnerability notification, patching, and mitigation.
• HDOs should close cybersecurity skills gaps by using competency models to develop skilled workforces.
• HDOs lacking resources should receive support from sources such as regional mutual aid partnerships.

MITRE's report includes governance and data collection guidelines to help implement these recommendations:

• HDOs should emphasize cybersecurity when overseeing the medical technology lifecycle.
• MDMs should assume responsibility throughout the product lifecycle for identifying cybersecurity risks affecting medical devices they market.
• Both HDOs and MDMs should deploy cross-functional teams headed by senior management leaders tasked with enterprise risk management.
• Data collection should follow predetermined conditions and establish target benchmarks that focus on valuable information.
• Data collection should be streamlined to reduce excessive labor.
• Data should be used in a non-punitive manner to promote actionable steps.

To simplify data collection, MITRE recommends basing benchmarks on pilot snapshots of aggregated data. The report includes a checklist for conducting pilot studies.

Secure Your Total Product Lifecycle to Satisfy FDA Cybersecurity Guidelines

The FDA's guidance for premarket and legacy devices stresses the importance of security for the total product lifecycle from development to postmarket vulnerability management. Pentesting throughout your product development lifecycle can help you catch vulnerabilities before they stall your product release or impact your customers.

Connect with Cobalt to learn more about how our Pentest as a Service (PtaaS) platform can help you comply with FDA guidance with our IoT testing services to alleviate any cybersecurity concerns or requirements your company may have.