FDA’s new final guidance replaces the April 2022 draft guidance of the same name, which we analyzed online here, and it also supersedes FDA’s 2014 final guidance “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.” There were more than 1,800 public comments on the draft version of the guidance, which FDA was required to finalize by the end of September, 2023. In announcing release of the final guidance, the agency emphasized how the “increased integration of wireless devices, electronic exchange of medical device-related information, and cybersecurity vulnerabilities and incidents, highlight the importance of having stronger cybersecurity measures.” The final version of the guidance mirrors closely the draft version, with the exceptions outlined below and implements many of the documentation expectations that FDA has been requesting over the last year.

PATCH Act implementation

The Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act) was signed into law on December 29, 2022 as a part of the 2023 Consolidated Appropriations Act (CAA). The PATCH Act’s text can be found in Section 3305 of the CAA: “Ensuring Cybersecurity of Medical Devices,” which amended the Federal Food, Drug, and Cosmetic Act (FDCA) by adding section 524B, “Ensuring Cybersecurity of Devices.” Effective March 29 of this year, the law empowered FDA to issue “refuse to accept” (RTA) decisions to applicants that fail to include the information it needs to ensure medical devices meet cybersecurity requirements. However, FDA indicated in March that it did not plan to exercise its new authority until October of this year.

Primarily, the finalized guidance differs from the draft version of the guidance in its references to helping manufacturers of “cyber devices” meet their obligations under section 524B of the FDCA. Section 524B(c) of the FDCA defines “cyber device” as a device that “(1) includes software validated, installed, or  authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.”

General Premarket Submission Documentation Elements and Scaling with Risk

Most significantly novel in the final guidance is the addition of Appendix 4: “General Premarket Submission Documentation Elements and Scaling with Risk,” which summarizes the specific documentation elements identified throughout the cybersecurity guidance for premarket submissions, the associated sections of the guidance for the document, and whether the documentation is recommended for IDE submissions. It notes that “device cybersecurity design and documentation are expected to scale with the cybersecurity risk of that device.”

For example, a device with either only one hardware connection (e.g., USB port) or a SaMD product with limited other software dependencies and connectivity will likely only need to have single architecture view for each of the global system, multi-patient harm, and updateability/patchability views, because “the security use case view(s) will likely be limited to a smaller subset of unique views to address the available connectivity and software.” However, for a device with greater complexities such as wireless connections, “multiple architecture views may be needed for the multi-patient harm and updateability/patchability views as there may be multiple ways to cause multi-patient harm or update elements of the device.”

Interoperability considerations

The final version guidance adds a section on interoperability, emphasizing how it is “an important consideration when assessing the cybersecurity of the end-to-end medical device system.” The final guidance says that “when properly implemented, the cybersecurity controls can help assure that these [interoperability] capabilities remain safe and effective.” Indeed, in the notice announcing the final guidance, FDA touts how the final guidance “clarified interoperability considerations and that cybersecurity controls should not be intended to prohibit a user from accessing their device data.”

System architecture diagrams

Previously limited in its draft guidance discussion to “call-flow” diagrams, the final guidance expands to recommend that manufacturers provide “diagrams” (used more generally) “to help describe the medical device system architecture, interfaces, communication protocols, threats, and cybersecurity controls used throughout the system.” FDA adds: “Different diagramming methods can be used to describe the architecture, including data flow diagrams, state diagrams, swim-lane diagrams, and call-flow diagrams, among others.”

Other changes

The following minor changes were also made between the draft and final versions of the guidance:

• New terms. To keep pace with the evolving cybersecurity regulatory landscape, FDA added definitions of the following terms to the guidance: anomaly; attack surface analysis; boundary analysis; closed box testing; fuzz testing; reasonably foreseeable misuse; uncontrolled risk; unresolved anomaly; and, vulnerability chaining. The agency also expanded its definition for a “Software Bill of Materials (SBOM).”

• BLAs and INDs. Although previously noted in a footnote, FDA made sure to explicitly state in the body of the final version of the guidance that its recommendations regarding the cybersecurity information to be submitted for devices apply to Biologics License Application (BLA) and Investigational New Drug (IND) submissions when submitted to the Center for Radiological Health (CDRH) or the Center for Biologics Evaluation and Research (CBER), among other submissions.

• Combination products. FDA also made sure to state that its recommendations in this guidance apply to the device constituent part of a combination product.

• Duplicate documentation. The final guidance advises that when threat modeling documentation “sufficiently captures” the security architecture view, FDA does “not expect manufacturers to duplicate documentation.”

• Legacy use cryptographic algorithms. FDA cautions that device makers should not implement cryptographic algorithms that have been deprecated or disallowed in applicable standards or best practices (e.g., NIST SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths).

Next steps

On November 2, 2023, FDA will host a webinar for industry and other stakeholders interested in learning more about this guidance.

Although neither the final guidance nor the Federal Register notice discuss the date when FDA plans to start using its recently acquired PATCH Act authority, FDA said in March of this year that the agency could start refusing filings that lack cybersecurity information as soon as October 1, 2023.