New FDA requirements go into effect October 1, 2023 for all new premarket submissions of medical devices. Let’s break down what they are and how software companies can meet them.

Cybersecurity Requirements

These changes were passed into law on December 29, 2022 in the 2023 “Omnibus” budget. Section 3305 of the Omnibus added a section called “Ensuring Cybersecurity of Medical Devices” to the FDA’s charter. Here’s a preview of the requirements:

(2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches to the device and related systems to address—

(A) on a reasonably justified regular cycle, known unacceptable vulnerabilities; and
(B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks;

(3) provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components;

FDA-2023-D-1030: Cybersecurity in Medical Devices

Read all Regulations and Legal Requirements

Regulated Software as a Medical Device (SaMD)

Keeping software secure is universally important — but new challenges in the Software as a Medical Device (SaMD) category require new procedures to meet these requirements.

Software stacks, especially ones with embedded AI/ML, are complex codebases with many dependencies. SaaS products are deployed frequently, requiring full automation for meeting the cybersecurity requirements.

To generate the required artifacts, here’s a list of capabilities that may be new to your engineering organization:

1. Choose the correct scope (see below)
2. Produce a software bill of materials (SBOM) for each software component, on each release
3. Enrich that SBOM with the latest vulnerability, on each release
4. Provide context to engineers in order to fix issues without hassle
5. Track SLAs for fixing each vulnerability from when it was first seen to last seen
6. Tools for tracking fixes across teams and understanding dependency relationships
7. Continually aggregating your SBOM and vulnerability results into one document for regulators
8. Provide a mechanism for your customers to access your aggregated supply chain data

Our guide for running a successful vulnerability management program is a good reference for how organizations do this at scale. The key is context — give your engineers the tools to understand risk right in their pull request. Give your security team the context of live inventory and filter the list of risks to prevent useless investigation.

Scoping your Vulnerability Program

Understanding where to draw the lines for the components or microservices of your medical device is essential to communicate the correct level of information to regulators. Here’s a quick break down of what is included and not included in the SaMD category:

Included:

• software for processing data, predicting risk or producing recommendations for diagnosis
• treatment planning software for radiology
• smartphone applications that use sensors to diagnose a medical condition

Not Included:

• firmware or microcode driving pumps, motors, etc. in a medical device
• software for communicating data from a medical device, eg. encryption components or a VPN
• software for clinical communication like scheduling visits, video calling, or patient registration
• a database or query layer providing input to a medical device

Read more about categorization of SaMD from the IMDRF.

Using EdgeBit for Scoping

EdgeBit maps your software components to a stream of SBOMs produced during your build process. The best scope strategy is to build your SBOM from a deployable artifact like a container, which won’t include any development tools.

You’ll want to understand the vulnerabilities in all of your components, but choose SLAs and suppression policies for the FDA-scoped differently than the rest to prioritize staying on top of those issues first.

Identifying which parts of your software dependencies are active vs dormant is another excellent scoping mechanism.

EdgeBit automatically identifies and suppresses vulnerabilities tied to dormant dependencies. Frequently an open source project may include libraries, plugins or other dependencies that you don’t use based on your application.

EdgeBit helps you descope the dormant bits while maintaining compatibility with upstream sources for easy updates.

Connect with an EdgeBit Engineer

This is a complex space and every software stack is different. EdgeBit engineers are available to hear how you’re thinking about the new requirements and how these new practices can fit into your existing engineering culture and toolset.