Copy to clipboard 
In September 2022, I wrote about the latest FDA draft guidance on cybersecurity in medical devices. At the time, we knew that FDA had significantly changed direction on cybersecurity between drafts — twice! We didn’t know if FDA would change direction again or when the draft guidance would become final. We also didn’t know how the guidance should be applied to medical device Quality Systems. In fact, my 2022 article ended with an admonishment not to revamp Quality Systems based on the volatile draft guidance.
Now, we have the answers needed to move forward. FDA’s cybersecurity guidance, which was made final in September 2023, includes recommendations that are intended to promote consistency, facilitate efficient premarket review and help to ensure marketed medical devices are sufficiently resilient to cybersecurity threats. The document supersedes the final guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” issued in October 2014.
FDA released the final guidance because of the increased integration of wireless, internet- and network-connected capabilities, portable media 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, according to FDA.
FDA acknowledges that cybersecurity threats to the healthcare sector have become more frequent and more severe and carry 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 United States and globally,” noted the final guidance. “Such cyber attacks and exploits may lead to patient harm as a result of clinical hazards, such as delay in diagnoses and/or treatment.”
FDA’s final guidance largely follows the path of the 2022 draft. Unfortunately, thanks to the broad language of the guidance, industry was still left with some questions about applying the recommendations to Quality Systems. Fortunately, FDA has clarified its application in private correspondence.
Below are answers to commonly asked questions that will provide clarity to FDA’s final guidance. The first two questions hit on what FDA expects Quality Systems to do and not to do under the final guidance. Understanding the difference will spare you from unnecessary effort, costs and delays in the device design process. The final question is inspired by recent developments in the Quality System Regulation itself.
Q: How should medical device manufacturers implement comprehensive cybersecurity risk management programs and documentation across the whole Quality System?
Manufacturers should ensure that their quality processes account for cybersecurity vulnerabilities that are inherent to the device software. For example, they should ensure that their complaint and Standard Operating Procedures (SOPs) for Corrective and Preventive Actions (CAPA) include steps to consider when determining whether the device software might have been compromised.
However, manufacturers are not expected to apply cybersecurity controls to their quality software controls. For example, they don’t need to ensure that the quality software used for complaint and CAPA handling in an eQMS (e.g., Qualio or Greenlight Guru) has been assessed for cybersecurity threats to the quality software itself. Admittedly, applying cybersecurity controls to quality software is a good idea, but as FDA says this precaution is outside of the scope of the final guidance’s recommendations.
Q: How should manufacturers implement the Secure Project Development Framework (SPDF)?
The Quality System should specify that the SPDF includes Security Risk Management, Security Architecture and Cybersecurity Testing to “ensure design processes are in place to design secure devices.” Concerning Risk Management, “manufacturers should have a Security Risk Management Report (as recommended in Section V.A. of the final guidance) as part of their Risk Management File [RMF].”
In other words, FDA expects the RMF to use the Security Risk Management Plan and Report to identify the subset of security risks that are also safety risks. Only those safety risks should be added to the RMF — not the non-safety security risks (e.g., confidentiality). Everything described in this paragraph can be fully controlled by the SOP for Risk Management.
Manufacturers are not expected to create a formal SPDF “file” within the Quality System. Quality Systems already need to include a Design History File (DHF), a Risk Management File (RMF) and, in some cases, a Usability Engineering File (UEF). Regardless of the extent of the cybersecurity documentation that’s created for the SPDF, the Quality System itself needs only to account for the Security Risk Management Plan and Report.
Q: How should manufacturers implement the Software Bill of Materials (SBOM)?
Manufacturers should ensure that the SBOM includes their software components, as well as third-party software components. FDA’s guidance documents Off-The-Shelf (OTS) Software Use in Medical Devices and Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software are the best sources for describing third-party software components.
The SBOM itself must be machine-readable (e.g., an Excel spreadsheet), and its content should include the minimum elements (“baseline attributes”) identified in the National Telecommunications and Information Administration (NTIA) document Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).
That last reference to the NTIA might give some manufacturers pause because the International Medical Device Regulators Forum (IMDRF) already has its own SBOM and cybersecurity guidance documents that are specific to medical devices. However, the requirement for the eight “baseline attributes” — which include author name, timestamp, supplier name — is indeed minimal. These elements can be included as columns in the SBOM, and the SBOM itself is already supposed to be controlled by an SOP for Software Development.
Q: How Does the New QMSR Impact Cybersecurity Guidance?
There’s been a lot said and written recently about FDA’s promulgation of the revised 21 CFR Part 820. This final rule will replace the long-established Quality System Regulation (QSR) with a Quality Management System Regulation (QMSR) that incorporates by reference ISO 13485:2016.
It’s important to note that the final rule for the QMSR, which was published on January 31, will be effective in February 2026, whereas the new cybersecurity guidance document is effective now. Furthermore, the changes required by the QMSR two years from now will mostly be seen in an increased application of risk considerations to existing quality processes.
In that sense, the new cybersecurity guidance document anticipates the QMSR not only temporally but also conceptually, and the eventual QMS updates for the QMSR should be no more burdensome than the immediate ones for the new cybersecurity guidance document.
So, there you have it. Updating your Quality System for the new final guidance on cybersecurity requires:
- Adding a few brief lines about “accounting for cybersecurity vulnerabilities that are inherent to the device software” to multiple SOPs (complaint handling, internal audits, design controls, etc.).
- Adding a brief section to the SOP for risk management about the SPDF.
- Adding a few more details about the SBOM to the SOP for software development.
This is not to minimize the extensive cybersecurity work that will be required for regulatory submissions, but that’s another article. The final guidance’s impact on Quality Systems is for now far less than some had feared.
