Summary
Very detailed cybersecurity requirements tied into Quality Management System (QMS) which go well beyond just following TIR57 and TIR97 recognised standards and encompass the Total Product Lifecycle (TPLC). Requires considerable effort in updating the existing QMS (SOP’s, WI’s, Templates etc.) in addition to training people. Implies following an established Secure Product Development Framework (SPDF) would be the sensible approach. Finally, there are new labelling requirements and Vulnerability Management Plans that need consideration. The headline recommendations are:
Detailed analysis by section
Talks about the increased need for robust cybersecurity controls to ensure medical device safety and effectiveness with threats to the healthcare sector becoming more frequent and severe. As connectivity increases cybersecurity across the whole system should be considered, not just at the device level. This draft contains guidance and clarity regarding existing requirements under the law and should be viewed as recommendations, however, if a different method is chosen by the device manufacturer, then it will lead to delays in approval. See the interview with Suzanne Schwartz, Director, FDA https://www.medtechdive.com/news/fda-draft-cybersecurity-guidance-requirements/621872/
This guidance applies to devices that contain software (including firmware) or programmable logic, as well as software as a medical device (SaMD). Not limited to devices that are network-enabled or contain other connected capabilities. Describes recommendations regarding the cybersecurity information to be submitted for devices under the following premarket submission types:
Recommendations generally align with or expand upon the recommendations in the Pre-Market Considerations for Medical Device Cybersecurity section of the International Medical Device Regulators Forum final guidance “Principles and Practices for Medical Device Cybersecurity,” issued March 2020. Appendix 3 contains specific considerations for IDE submissions due to the different risk-benefit thresholds.
Cites previous cyber attacks as examples of the impact poor cybersecurity can have, for instance, Wannacry ransomware attacks – cybersecurity is a shared responsibility among stakeholders throughout the use environment of the medical device system, hence the need for the update of this document.
A. Cybersecurity is Part of Device Safety and the Quality
Device Manufacturers must implement QMS processes for Cybersecurity risk management and validation processes. (TIR57 forms the basis for these activities).
These processes should address the identification of security risks, the design requirements for how the risks will be controlled, and the evidence that the controls function as designed and are effective in their environment of use for ensuring adequate security.
A Secure Product Development Framework (SPDF) is one way to satisfy QSR requirements.
An SPDF is a set of processes that help reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product’s lifecycle, including development, release, support, and decommission. Because of its benefits in helping comply with QSRs and cybersecurity, FDA encourages manufacturers to use an SPDF, but other approaches might also satisfy QSR requirements.
B. Designing for Security The device manufacturer will provide, implement and document the following security objectives throughout the system architecture.
The extent to which security requirements, architecture, supply chain and implementation are needed will depend on the criteria listed in the document section IV B.
Adherence to TIR57 and TIR97, and adopting SPDF will address this requirement.
C. Transparency
Provide users with information about the device’s cybersecurity controls, potential risks, and other relevant information, Software Bill of Materials (SBOM) and Cybersecurity risk report plus additional user documentation which includes how to securely configure or update a device etc. See document section IV C for the full list which also talks about labelling.
D. Submission Documentation
Device cybersecurity design and documentation is expected to scale with the cybersecurity risk of that device and manufacturers should consider the larger system in which the device may be used. The cybersecurity information being recommended to be included in submissions as detailed in the guidance is based on risks due to cybersecurity, not on any other criteria or level of risk/concern established in a separate FDA guidance (e.g., the software risk criteria in the Premarket Software Guidance). For example, a device that is determined to have a greater software risk may only have a small cybersecurity risk due to how the device is designed. Likewise, a device with a smaller software risk may have a significant cybersecurity risk. Therefore, the recommendations in the guidance regarding information to be submitted to the FDA are intended to address the cybersecurity risk, as assessed by the cybersecurity risk assessment, and are expected to scale based on the cybersecurity risk.
V. Using an SPDF to Manage Cybersecurity Risks
Again, summarising the benefits of using SPDF but saying they will accept alternatives “so long as their approach and documentation satisfies premarket submission requirements in applicable statutory provisions and regulations”. The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. Finally, “FDA does not recommend that manufacturers discontinue existing, effective processes”. Look at adopting an SPDF from the recommended ones.
A. Security Risk Management Cybersecurity risk management is different to Safety Risk Management (as per ISO 14971:2019). Different scoring methods and cybersecurity also considers factors, not within the remit of the FDA such as those related to business and reputational. TIR57 and TIR97 form the basis for setting up the processes together with a cybersecurity scoring method.
“FDA recommends that manufacturers establish a security risk management process that encompasses design controls (21 CFR 820.30), validation of production processes (21 CFR820.70), and corrective and preventive actions (21 CFR 820.100) to ensure both safety and security risks are adequately addressed. For completeness in performing risk analyses under 21 CFR 820.30(g), FDA recommends that device manufacturers conduct both a safety risk assessment per ISO 14971:2019 and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks”. “AAMI TIR57:2016 details how the security and safety risk management processes should interface to ensure all risks are adequately assessed”.
A.1. Threat Modelling
Process for carrying out Threat Modelling - See TIR57.
“The threat model should:
FDA recommends that premarket submissions include threat modelling documentation to demonstrate how the risks assessed, and controls implemented for the system address questions of safety and effectiveness. There are several methodologies and/or combinations of methods for threat modelling that manufacturers may choose to use. The rationale for the methodology(ies) selected should be provided with the threat modelling documentation.
A.2. Third-Party Software Components Besides conducting the traditional process for “Off-The-Shelf (OTS) Software for a product cybersecurity risk processes need to be added in and machine-readable “A Software Bill of Materials (SBOM)” should be produced for each OTS package. If a widely accepted SBOM format is used which does not include all the FDA required fields, then these need to be added in.
A.3. Security Assessment of Unresolved Anomalies
Part of the TIR57 process.
A.4. Security Risk Management Documentation
Security risk management plan and security risk management report such as those described in AAMI TIR57 inclusive of the system threat modelling, SBOM and associated documentation, and unresolved anomaly assessment(s) described above, should be sufficient to support the security risk management process aspect of demonstrating a reasonable assurance of safety and effectiveness. The security risk management report should:
A.5. TPLC Security Risk Management Cybersecurity risks may continue to be identified throughout the device’s TPLC – TIR97 will cover this. Manufacturers should ensure they have appropriate resources to identify, assess, and mitigate cybersecurity vulnerabilities as they are identified throughout the supported device lifecycle. Also, update the documentation and threat model’s etc. To demonstrate the effectiveness of a manufacturer’s processes, FDA recommends that a manufacturer track and record the measures and metrics (see document for list).
B. 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.
B.1. Implementation of Security Controls FDA considers the way in which a device addresses cybersecurity risks and the way in which the device responds when exposed to cybersecurity threats as functions of the device design. Effective cybersecurity relies upon security being “built in” to a device, and not “bolted on” after the device is designed. FDA recommends that device manufacturers’ design processes include design inputs for cybersecurity controls. See the document for the list of controls to include.
B.2. Security Architecture Views
FDA recommends that premarket submissions include multiple architecture views. See document for minimum FDA recommended views and what additional information on what to include on the views and supporting documentation.
C. Cybersecurity Testing
Very comprehensive list of testing that is required including Vulnerability Testing and Penetration testing. Also specifies the supporting documentation that needs to be a part of the submission.
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 labelling 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.
A. Labelling Recommendations for Devices with Cybersecurity Risks
Has a list of things that need to be communicated via labelling to users.
B. Vulnerability Management Plans Recognizing that cybersecurity risks evolve as technology evolves throughout a device’s TPLC, FDA recommends that manufacturers establish a plan for how they will identify and communicate vulnerabilities that are identified after releasing the device with users. FDA recommends that manufacturers submit their vulnerability communication plans as part of their premarket submissions so that FDA can assess whether the manufacturer has sufficiently addressed how to maintain the safety and effectiveness of the device after marketing authorization is achieved.