FDA draft guidance on Postmarket Management of Cybersecurity in Medical Devices
The FDA released one week ago a new draft guidance on Postmarket Management of Cybersecurity in Medical Devices.
This guidance is the sister of the guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices released in 2014. Both guidances address cybersecurity at different steps of software lifecycle: the 2014 guidance is about cybersecurity during design and development, the 2016 draft guidance is about cybersecurity during post-market surveillance.
Essential Clinical Performance
Before going further, the first thing to introduce is the new concept of Essential Clinical Performance. This concept has been developed for the purpose of this guidance and most of the approach developed in the guidance stems from this concept. In a footnote, FDA makes the parallel with the concept of essential performance found in IEC 60601-1
Have look at both definitions:
ESSENTIAL PERFORMANCE (IEC 60601-1 ed3.1)
performance of a clinical function, other than that related to BASIC SAFETY, where loss or degradation beyond the limits specified by the MANUFACTURER results in an unacceptable RISK
Essential Clinical Performance (FDA draft guidance)
Essential clinical performance means performance that is necessary to achieve freedom from unacceptable clinical risk, as defined by the manufacturer. Compromise of the essential clinical performance can produce a hazardous situation that results in harm and/or may require intervention to prevent harm.
If you are used to applying IEC 60601-1 3rd edition and its risk-based approach, the content of this guidance will be easier to understand.
Based on the concept of essential clinical performance, this guidance defines the process to set-up for the postmarket management of cybersecurity. This is a risk-based process detailed in sections 5 and 6 of the guidance, which references ISO 14971.
Recommendations are mostly about evaluation of risks, with new scales of severity and probability.
Rather than repeating the content of the guidance, here are a few comments.
In section 4 definitions, the terms "compensating controls", "cybersecurity signal", "exploit", "remediation", "threat", "threat modeling" and "vulnerability" are defined. All these terms are taken from the field of IT security. They require to have a background either in IT security or software to well understand the meaning of these terms.
People working in the medical device industry are more likely to be trained to ISO 19471, and to know the meaning of terms like "hazardous phenomenon", "hazardous situation", "hazard", and "mitigation action".
The guidance would be easier to understand by people who have a QA/RA background but not a technical background, if the guidance contained a section explaining the correspondence between definitions of section 4 and definitions of section 3 of ISO 14971.
ISAO vs 21 CFR part 806
One peculiar recommendation of this guidance is inviting manufacturer to participate to an Information Sharing Analysis Organization (ISAO). Manufacturers participating to such programme will be exempted from reporting non-serious adverse events linked to cybersecurity, per 21 CFR 806.
References to NIST documents
This guidance contains several references to National Institute of Standards and Technology (NIST) documents. While most are just references, the FDA recommends applying the NIST Framework for Improving Critical Infrastructure Cybersecurity.
This framework represents a consistent effort for manufacturers.
Common Vulnerability Scoring System
The Common Vulnerability Scoring System (CVSS) is a method to provide a numerical score reflecting the severity of a vulnerability. Like NIST framework, applying the CVSS represents a consistent effort. However, it may be better to define a more simple scale, which is closer to the scoring habits of medical device risk management.
Fifty shades of risk
I can't help but commenting the figure on page 15!
The text talks about binary determination of uncontrolled or controlled risk. And the figure given as an example uses an artistic greyscale. I won't bet that this figure will remain like that in the final guidance.
Consequences for manufacturers
Performing a relevant risk assessment for cybersecurity requires the help of experts in security. Manufacturers will have to recruit skilled people or consultants, and train people involved in the process, like QA/RA. At least, risk managers should understand what cybersecurity guys are doing, to ensure that the risk management process remains effective.
Post-market surveillance procedure and risk-management procedures are going to be touched by this guidance. A separate procedure or instruction could be necessary to manage cybersecurity signals, risk analysis vs essential clinical performance, and remediation actions or fixes.
This guidance has also an impact on maintenance and problems resolution processes of IEC 62304. Depending on how they're structured, procedures implementing these processes could be impacted.
But what do you prefer?
The known cost of cybersecurity?
Or the unknown cost of a cyberattack?
A guidance or a standard?
The content of this guidance is new to medical device manufacturers. There is no equivalent of this guidance neither in the regulations (this guidance is an interpretation of regulations written long before cybersecurity became a concern), nor in recognized standards.
If you search the Recognized Consensus Standards database for "Cybersecurity", you won't find anything. If you search for security, you will find standards, but their content doesn't cover the content of this guidance.
This guidance is probably worth making a standard. Before IEC 62304, people used to apply the General Principles of Software Validation FDA guidance. Likewise, people are going to apply this guidance until a international standard is released (If it is ever released!). The content of this standard would be the same as the content of this guidance, stripped from any reference to US governmental organizations.
This guidance is still a draft but don't expect its core principles to change a lot. Thus anticipate the work necessary to implement its recommendations. It takes time to build a process like that, and you won't know whether it's effective or not until you face a real problem.