New FDA Cybersecurity Premarket Submission Requirements

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 1^st.

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.

Architecture Views

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:

• Global System View
• Multi-Patient Harm View
• Updateability/Patchability View
• Security Use Case View(s)

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 and Risk Assessment

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.

Controls and Requirements

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:

• Authentication
• Authorization
• Cryptography
• Code, Data, and Execution Integrity
• Confidentiality
• Event Detection and Logging
• Resiliency and Recovery
• Updatability and Patchability

Traceability

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:

• “Provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation as discussed later in this guidance as well as other relevant cybersecurity risk management documentation.” (emphasis mine)
• Security architecture views should: “Establish traceability of architecture elements to user and medical device system security requirements. Such traceability should exist throughout the cybersecurity risk management documentation.”

• Use Case Views should have – “Traceability of asset to the SBOM component”

Satisfying these new traceability requirements could be quite burdensome and falls into my category of “wait-and-see” if they are truly required.

SBOM

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:

• “The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned).”
• “The software component’s end-of-support date”

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.

Testing

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.

Labeling

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.

Postmarket Plans

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:

•  Personnel responsible; 
• Sources, methods, and frequency for monitoring and identifying vulnerabilities (e.g., researchers, NIST national vulnerability database (NIST NVD), third-party software manufacturers); 
• Identify and address vulnerabilities identified in CISA Known Exploited Vulnerabilities Catalog; 
• Periodic security testing; 
• Timeline to develop and release patches; 
• Update processes; 
• Patching capability (i.e., rate at which update can be delivered to devices); 
• Description of their coordinated vulnerability disclosure process; and 
• Description of how the manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.

Summary

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.

‍