FDA cybersecurity draft guidance draws concern from patients, industry

| 13 July 2022 | By Jeff Craven 

2719

The US Food and Drug Administration (FDA) has received more than 1,800 comments from the public, medical device manufacturers, and other stakeholders concerning its draft guidance on cybersecurity when it comes to quality systems and premarket submission content for medical devices.
 
This is not the agency’s first attempt at publishing an updated draft guidance on this topic: in April 2022, FDA created an entirely new draft guidance after receiving public comments online and in a public workshop on its 2018 draft guidance, which served as an updated for the premarket cybersecurity guidance FDA published in 2014.
 
The 2022 draft guidance for premarket cybersecurity in medical devices is over five times larger than the 2018 guidance, Suzanne Schwartz, director of the Office of Strategic Partnerships and Technology Innovation at the Center for Devices and Radiological Health (CDRH), told Regulatory Focus in an April interview, and “really raises the bar in its technical detail, in the expectations that we have of manufacturers, so that we’re not dealing with devices that are characterized by the same legacy challenges that we have today.” (RELATED: Cybersecurity: Third time’s a charm: US FDA reissues cybersecurity draft guidance, Regulatory Focus 7 April 2022)
 
FDA recognizes that the cybersecurity landscape is continuing to change, which is why the new draft guidance focuses on reducing cybersecurity risk through the total product life cycle (TPLC). One notable new change to the 2022 draft guidance from the 2018 version includes sponsors needing to provide a software bill of materials (SBOM) with their medical device, rather than a more comprehensive cybersecurity bill of materials (CBOM) than would also include hardware considerations. Another change is the agency asking manufacturers to consider quality system regulation (QSR), with one example being use of a secure product development framework (SPDF).
 
Patient and caregiver comments
 
The majority of the 1,800 comments came from patients with diabetes and their caregivers who wrote to the FDA concerned the new guidance would limit their ability to access their medical devices and data. Although the cut-off for public comments that would be guaranteed as seen by the agency before finalizing the draft guidance was on 7 July, the docket continues to receive numerous public comments past the deadline with similar concerns.

 
“I live with insulin-requiring diabetes, an incurable chronic disease requiring continuous monitoring of blood glucose values and administration of insulin,” one member of the public wrote using boilerplate language seen in the comments. “It is imperative that access to my own devices remain possible. I am not a malicious actor. The ability to receive glucose values from my continuous glucose monitor and the ability to command my insulin pump to deliver insulin are already permitted and expected of me. In fact, if I don't do these, I will die. So please do not let medical device manufacturers use cybersecurity as a pretense to prevent me from accessing my own devices.”
 
Security for lower risk devices
 
The Advanced Medical Technology Association (AdvaMed) said in their comment that FDA “generally takes a sensible approach regarding cybersecurity review of medical devices” but noted some issues with the new draft guidance, such as lack of direction on how to manage cybersecurity for lower risk medical devices.
 
“The Draft Guidance does not clearly contemplate a risk-based approach to managing medical device cybersecurity. Risk-based decision-making is a hallmark of FDA’s medical device regulations and should be a foundational element of its cybersecurity expectations. Indeed, the Draft Guidance states that device cybersecurity design and documentation is expected to scale with the cybersecurity risk of the device,” they wrote. “However, the Draft Guidance it is not clear as to what elements are expected for lower risk devices.”
 
Digital healthcare company Philips Healthcare echoed AdvaMed’s concerns about information needed for lower-risk devices. “We urge the agency to reconsider the breadth and depth of information being requested in premarket submissions and to include a discussion in each section of the guidance for how to scale requested information based on the manufacturer’s risk determination,” they wrote. “In addition, increased clarity on what information is mandatory versus what is desirable and an identification of the level of detail required would be extremely valuable.
 
The Connected Health Initiative also supported the risk-based approach to cybersecurity based on the level of risk for a device. “We encourage FDA to ensure that its new guidance on premarket submissions for device software functions reflects that the level of substance and detail in premarket documentation is scaled to the risk posed by the device software function (and not the intended use of either the device software function or the entire device that includes the device software function),” they wrote.
 
AdvaMed also requested FDA provide an implementation timeline of two years from the publication of the final guidance so sponsors have “time to review, adopt, and implement the guidance,” while Philips requested a transition period “no longer than 12 months.”
 
Least burdensome principles, other cybersecurity standards
 
In their comment, the Bringing Real-world Insight for Device Governance and Evaluation (BRIDGE) Coalition said least burdensome considerations or options should be written into the final guidance.
 
“The Coalition feels that the final guidance should explicitly consider least burdensome principles and incorporate least burdensome principles with specificity,” they wrote. “This must be more than simply mentioning least burdensome – least burdensome must be substantively incorporated in the revised principles. In addition, the final version must adopt the use of least burdensome principles in determining the method by which the developer and regulator determine how the developer establishes the satisfaction of an applicable element.”
 
Other stakeholders used their comments to point FDA in the direction of cybersecurity standards in other industries. Internet of Things (IoT) security company Device Authority requested the agency look at the FIDO Device Onboard (FDO) protocol open IoT standard for medical advices and use that as the certification standard for medical devices connected to the internet. Software company BlackBerry recommended FDA adopt MITRE’s Threat Assessment and Remediation Analysis (TARA) for medical devices for “software validation, risk analysis, cybersecurity risk management, and validation processes.”
 
Medical device software services company Innolitics asked the agency to better define the difference between threat modeling—"a process for identifying security objectives, risks, and vulnerabilities across the system, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system throughout its lifecycle”—and cybersecurity risk management.
 
“It is difficult to discern how threat modeling and cybersecurity risk management are different. It would be helpful if the guidance provided more detail on their distinction,” they said.
 
Include what is needed, not what isn’t
 
Software developer BeanStock Ventures requested FDA simplify the guidance and focus on what is needed to create a secure product. As it is written, the guidance is repetitive, lengthy, and difficult to read, they said.
 
“Minimize references to what is not needed to be created, documented, developed and tested, only describe what readers need to know in order to successfully develop a secure product. Minimize on the examples of what went wrong and how it could have been avoided – these examples could be a part of an article or white paper, but provides unnecessary information in the guidance,” they said.
 
The company also asked FDA to provide more information about the SPDF. “Why name a new process, instead of incorporating into the already existing design control processes? The security attributes described in the rest of this draft guidance reference design control process. There is very little explanation for what is SPDF,” the developer wrote.
 
Draft guidance, public docket

Comments are closed.