If you are reading this, you are probably already aware that the FDA released its long awaited final guidance for Cybersecurity in September 2023. This was long overdue - the last released document was in 2014, and since then 2 drafts were released. The recently released guidance also falls on the tails of the Omnibus Act of Dec. 2022, ensuring cybersecurity for medical device, and the FDA’s “Refuse to Accept” submissions without the necessary cybersecurity requirements as of October 1st.
Let’s dive in and discuss some of the major components of the newest guidance, taking a special look at what is new from prior submission expectations. The guidance is 53 pages, so I’ve chosen to cover the major deliverables - Architecture Views, Threat Modeling, Controls & Requirements, Traceability, Software Bill of Materials (SBOM), Testing, Labeling, and Post-Market Plans. Note that some of the “new” topics were in last year’s draft guidance, but the FDA did not officially adopt them until this final guidance release.
While diagrams with descriptions of the security design were encouraged before, the new guidance leans into the concept of Architecture Views. A “View” is a combination of diagram(s) and text describing the security architecture from a perspective of a specific concern. The FDA recommends providing, at minimum, the following types of “views” in premarket submissions:
The guidance succinctly describes expectations of each of these types of views in section VB2. However, Appendix 2B provides 19 details expected for every communication path for each Use Case View. That will be a bear to document and is hopefully not enforced to the letter.
But overall, these “views” with their specific perspective seem like they would be helpful for a reviewer to understand the security of the system.
Threat modeling has been expected as part of the submission for a while, and is much like performing a safety Hazard Analysis, but for security threats. Different methodologies for threat modeling have been used in the IT world, and Mitre has a “Playbook for Threat Modeling Medical Devices'' available online to help. Microsoft’s S.T.R.I.D.E methodology works for some. At Promenade, we found the Asset-based threat model methodology described in AAMI TIR57 to be very systematic and relatively easy for our clients to understand, being used to ISO 14971 hazard analysis and FMEA’s. But whatever the approach, the objective is to identify and assess threats and vulnerabilities, and to establish appropriate controls for each threat. And it appears that the agency is flexible on which methodology is used.
Describing the controls implemented has long been a requirement for submission. The guidance seems a little muddled on the terms “security controls” versus “requirements” and seems to use the terms interchangeably. But the basic list of controls necessary remains fundamentally the same:
Traceability of Threat Model ->Control-> Requirement->Test is not new. But a search of “traceability” in the released guidance comes up with the following in addition:
Satisfying these new traceability requirements could be quite burdensome and falls into my category of “wait-and-see” if they are truly required.
The requirement of providing an SBOM, listing third party software used, and checking for associated known vulnerabilities has been expected from the FDA for a while. In addition, the guidance wants the manufacturer to document:
This might be available from commercial software, but for open-source software, it is generally not reliably available. I presume they will have to accept that.
The testing requirements as listed have not changed much. While the guidance doesn’t specifically call it out, I believe it is safe to assume that the extent of vulnerability testing (attack surface analysis, fuzz testing, vulnerability chaining, etc.) would be commensurate with the risk of the device.
There is an increasing emphasis on the need for manufacturers to provide transparency about a device's security design to users and HCO's. This is not really new to this guidance - hospitals and large HCO’s have been requesting detailed information about the security of the medical device as part of their evaluation process, and the FDA has been following suit to make this information part of required labeling.
Requiring plans and SOPs to manage cybersecurity while the device is in the field has been expected since the release of the Postmarket guidance of 2016. This new guidance gives a clear list of what should be in the plan, as shown below:
September’s final Cybersecurity guidance has clearly increased the documentation requirements for submission. Overall, it is helpful to have a released guidance to work with. After we saw that the 2018 draft guidance was being enforced, we made the Promenade templates compliant. Now, we have been able to update our templates to follow this final guidance. But it is yet to be seen how quickly and vigorously the FDA reviewers will pivot expectations to require the new concepts and associated details presented in the guidance. The guidance states that the documentation should scale with risk, but it does not give clues as to what can be safely reduced for lower risk systems. We will have to learn from their responses.
I hope this article was helpful. If you need support to satisfy this new guidance, please contact us.