It's no secret that regulations are increasingly requiring documentation that evidences cybersecurity hygiene in connected devices, both new and updated.
Consider, for example, EO 14028, a 2021 executive order that defined and required SBOM use and the sharing of SBOMs both with and within U.S. government entities.
Also, there's the EU NIS2 Directive, which includes cybersecurity risk management measures that specifically reference software supply chain security while also establishing hefty fines for noncompliance.
There's also the FDA Final Guidance on Cybersecurity, issued in September 2023, which requires SBOMs to be submitted to the FDA for review, applies to any medical device with software, and is the main focus of this post.
FDA Final Guidance on Cybersecurity
The FDA Final Guidance on Cybersecurity was issued in September 2023 and provides recommendations on medical device cybersecurity considerations and what information should be included in premarket submissions.
The guidance, applying to all medical devices with software including firmware, and even those that don't require premarket submissions, covers:
- Cybersecurity device design
- Labeling
- Documentation that FDA recommends be included in premarket submissions for devices with cybersecurity risk.
These expectations are meant to promote consistency, facilitate the FDA's premarket review, and help boost the resiliency of marketed medical devices against increasing cybersecurity threats.
The FDA Final Guidance supersedes the final guidance published by the FDA in 2014 in the “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.”
Not following the FDA Final Guidance on Cybersecurity may result in a Refuse to Accept (RTA) outcome.
What's Covered by the FDA's Final Guidance?
New medical devices are included within the scope of the FDA's Final Guidance. These provisions apply to premarket devices that include any type of software, including firmware, and not just connected devices.
Existing medical devices are also covered. Any updated submissions or any updated releases of an existing device fall within the scope of the FDA's Final Guidance on Cybersecurity.
Lastly, the FDA's Final Guidance spans to various types of premarket submissions, e.g., Premarket Notification (510(k)) submissions, De Novo requests, and Premarket Approval Applications (PMAs).
What Documentation does the FDA's Final Guidance Require?
Secure Product Development Framework
The FDA Final Guidance on Cybersecurity requires a Secure Product Development Framework (SPDF), which means following and documenting the SPDF process used in the development of the device's software.
SBOM
Submissions with any type of software must include a machine-readable, formatted SBOM that follows CycloneDX or SPDX standard in JSON or XML. The SBOM must include first- and third-party software components.
Threat Model
The FDA's Final Guidance also requires a threat model that reflects the results of a full threat modeling exercise for the device and the submission of the proof of threat modeling to the FDA.
Vulnerability Management
Proof of vulnerability triaging must be evident in submissions, along with any considerations for vulnerability exploitability and whether a vulnerability is reachable.
Vulnerability Disclosures
Submissions must contain documentation that shows how the manufacturer will identify and timely disclose post-market vulnerabilities along with the plan for making post-market software updates.
Penetration Test Report
A penetration test report should also be included where manufacturers include details of the testing methods and results. These tests should be performed by independent experts who are independent from the software developers.
What about FDA 524B?
The FDA's Final Guidance still points, in several places, to section 3305 of the Consolidated Appropriations Act, 2023, which added Section 524B “Ensuring Cybersecurity of Medical Devices” to the FD&C Act.
"Under section 524B(a) of the FD&C Act, a person who submits a 510(k), PMA, PDP, De Novo, or HDE for a device that meets the definition of a cyber device, as defined under section 524B(c) of the FD&C Act, is required to submit information to ensure that cyber devices meet the cybersecurity requirements under section 524B(b) of the FD&C Act," the FDA writes.
Section 524B(c) of the FD&C Act then goes on to define a “cyber device” as a device that:
- "includes software validated, installed, or authorized by the sponsor as a device or in a device
- can connect to the internet
- contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats."
As of this writing, the FDA has drafted proposed updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act, which are open for public comment until May 13, 2024.
What Is an SBOM and What Information Is Included?
An SBOM provides a full list of components in a software package. This includes both first- and third-party code, meaning code that your developers wrote as well as OSS components they imported.
SBOMs should be made available in machine readable files (JSON or XML) and follow SBOM standards (CycloneDX or SPDX). The vulnerabilities associated with the software components in an SBOM should also be provided in a related file (VDR).
The SBOM's information should also be complete. Components added after compiling the software, i.e., binary code or drivers, need to be included.
Source code SBOMs are not complete device SBOMs.
What's So Hard about Building a Connected Product SBOM?
Connected devices are comprised of complex hardware and software supply chains with more than 80% of components coming from 3rd, 4th, or 5th parties. Also, software is often developed in compiled form or embedded within hardware being integrated within a product.
These realities complicate efforts to see inside these devices and create accurate, complete inventories of their software components. This, in turn, makes it more difficult to assess product security and software supply chain security, goals of the FDA's regulatory initiatives.
So, where do medical device manufacturers, looking to improve their product security and/or comply with evolving FDA regulation, go from here?
How Finite State Can Help You Achieve FDA Compliance
Finite State can help medical device manufacturers achieve FDA compliance by providing complete and automated SBOM documentation.
Finite State can combine SBOMs by ingesting OEM SBOMs and combining these with MDM SBOMs to provide a single SBOM for submission.
Finite State can provide complete SBOMs by including post-build components.
Finite State can provide continuous monitoring with daily data refreshes that pinpoint new vulnerabilities that emerge post market.
The Finite State Next Generation Platform
Delivering high-quality, secure, and innovative products on time is crucial for medical device manufacturers. Traditional AppSec tools alone aren’t enough to provide the SBOM documentation needed to comply with FDA cybersecurity guidance. Submissions relying on this evidence alone could result in a “Refuse to Accept” issuance by the FDA, delay product launches, and incur large cost outlays.
Since many binary components are added at the final software build step, there’s often no access to their source code, which means AppSec tools won’t detect and report on them.
Section 524B(b)(3) of the FD&C Act requires manufacturers to “(3) provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components” and then points to the Final Guidance for assistance in complying with this requirement.
You need a complete SBOM that includes all of the software components within your connected product.
Finite State solves this problem for medical device manufacturers with easy-to-generate and complete SBOMs that deliver in-depth analysis and visibility into all commercial, open-source, and off-the shelf software components, including binary operating systems and files. Shorten the time to market with easy, automated documentation and generation to provide proof of security and testing to customers and regulators.
Learn more about how we can help you achieve FDA compliance.
Share this
You May Also Like
These Related Stories