The healthcare industry has been hit hard by cyber incidents in recent years, including a number that have impacted medical devices. Against this backdrop, the U.S. government passed new cybersecurity requirements that took effect in 2023 — including a mandate to produce SBOMs (software bill of materials) — for medical devices.

The new cybersecurity requirements apply to multiple types of premarket submissions — 510(k), 513, 515(c), 515(f), and 520(m) — and, broadly, they include three main focus areas:

  • Provide an SBOM that inventories commercial, open source, and off-the-shelf software  
  • Submit a plan for monitoring, remediating, and disclosing postmarket vulnerabilities and exploits  
  • Create and maintain processes to provide a “reasonable assurance that the device and related systems are cybersecure” 
    • Plus, make updates and patches available postmarket 

Notably, starting on Oct. 1, 2023, the FDA was given the authority to refuse to accept premarket submissions that don’t include comprehensive and accurate cyber information, including SBOMs. 

Although, as mentioned, medical device manufacturers must include a range of documentation and information in their premarket submission, this blog will focus mostly on the SBOM requirements. (For reference, these can be found in the “Risk Management - Software Bill of Materials (SBOM) and Related Information” section of the premarket eSTAR.) We’ll break down the scope of the FDA’s requirements, how SBOMs (and SBOM-related information) should be structured, and how FOSSA can help manufacturers fulfill SBOM requirements.

Scope of the FDA’s SBOM Requirements

Whether a medical device is subject to the FDA’s SBOM requirements depends on the a) type of device and b) the premarket review submission date. 

Types of Medical Devices

The new FDA cybersecurity requirements apply only to “cyber devices.” The FDA defines a “cyber device” as one 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. 

Medical device manufacturers that are unclear whether their products are considered cyber devices are encouraged to contact the FDA for clarification.

Submission Timing

The FDA SBOM requirements apply to medical device applications submitted to the FDA on or after March 29, 2023. Additionally, if manufacturers of devices that gained premarket approval before March 29 make changes that require a new premarket submission, the new submission must include the required SBOM (and SBOM-related information).

Pillars of the FDA’s SBOM Requirements

Medical device manufacturers must provide the following types of SBOM artifacts and/or assessments to earn premarket approval.

  1. The SBOM itself 
  2. Support information (e.g. current level of support and support end date) for all software components identified in the SBOM
  3. An assessment of vulnerabilities in the software components identified in the SBOM — plus any controls or mitigation steps to address those vulnerabilities

SBOM Structure and Requirements

The FDA requires SBOMs to be generated in a format and structure that aligns with the NTIA’s (the U.S. Government’s National Telecommunications and Information Administration) minimum elements.

This means, as a starting point, SBOMs must be produced and transmitted in a machine-readable format (like SPDX or CycloneDX). Additionally, they must include the following data fields:

  • Supplier name
  • Component name
  • Version of the component
  • Other unique identifiers (e.g. CPE or PURL)
  • Dependency relationship (e.g. Component X may be a dependency of Component Y)
  • Author of SBOM data
  • Timestamp (e.g. date and time when the SBOM was generated)

Component Support Information

In addition to submitting a machine-readable SBOM with the data fields described above, medical device manufacturers must also communicate information about how the software components in their medical devices are supported. Two types of support information must be provided:

  1. Level of support from the component manufacturer (as defined by the type of monitoring and maintenance): whether it’s actively maintained, no longer maintained, or abandoned
  2. The component’s end-of-support date 

Notably, support information must be provided for all types of components identified in your SBOM, including open source. This may be challenging since open source components infrequently include detailed support information; it may need to be inferred based on registry updates or commit history. If you are unable to communicate support information for a particular component, the FDA asks that you provide a justification explaining why. 

It’s also important to note that this support information can be transmitted in two ways:

  1. It be embedded directly into the SBOM that’s submitted for premarket review
  2. It can be included in a separate document

Component Vulnerability Information

The other category of required SBOM-related information is a vulnerability assessment. 

This starts with a listing of all known vulnerabilities — e.g. those in CISA’s KEV (Known Exploitability Vulnerabilities) Catalog — plus an explanation of how the manufacturer discovered said vulnerabilities. (The reason manufacturers are asked to communicate how they identified vulnerabilities is so the FDA can evaluate whether “the assessment methods were sufficiently robust.” The FDA wants to make sure manufacturers have the context they need to have confidence in a fix when a vulnerability is identified.)

In addition to a list of known vulnerabilities and information about how they were discovered, medical device manufacturers should provide:

  • An evaluation of the identified known vulnerabilities, “including device and system impacts”
  • Controls in place to address the vulnerability; if there are compensating controls, those should be “described in an appropriate level of detail”

It’s important to note that, although a list of all identified vulnerabilities must be provided, it is not necessary that your submission be free of all identified vulnerabilities. Rather, you must be able to reasonably defend your security posture via means such as lack of exploitability or compensating controls. 

SBOMs and the FDA’s Postmarket Requirements

In contrast to the premarket submission, the FDA doesn’t have specific SBOM requirements that impact medical devices once they’re on the market. However, that doesn’t mean manufacturers should view SBOMs as solely a premarket initiative. 

On the contrary, SBOMs can play an important role in several postmarket processes. 

For example, medical device manufacturers are required to disclose vulnerabilities to customers and address them in a timely manner. Maintaining an up-to-date SBOM makes it easier to determine whether a device is impacted by new vulnerabilities (and then make the proper fix if it is).

For example, oftentimes a new vulnerability may appear to impact your submission; however, after an internal investigation, you may determine that the CVE as used in your device is not exploitable. Maintaining an accurate SBOM with proper VEX (Vulnerability Exploitability eXchange) statements will expedite relaying this information to your customers.  

The FDA will also continuously monitor your SBOMs for new vulnerabilities. Ensuring you have continuous vulnerability management tied directly to your submitted SBOM will allow you to preempt any FDA findings with your internal, and thus more accurate, assessments.   

Additionally, it’s not always a matter of regulatory compliance per se, but there’s a growing trend among security-conscious customers to require SBOMs as a condition of purchase. Some customers may also require manufacturers to provide access to the latest SBOM version(s) on a continuous basis and/or VEX information. I suspect SBOMs with accurate VEX or other means to communicate vulnerability status will be a requirement from nearly all major hospitals in the coming years.   

How FOSSA Can Help Fulfill the FDA’s SBOM Requirements

FOSSA is a leading SBOM management provider, and we’re actively supporting medical device manufacturers as they navigate the FDA’s premarket review. 

Here are some of the ways we help manufacturers fulfill the FDA’s requirements for SBOMs and SBOM-related information:

  1. You can use our platform to generate a machine-readable SBOM (in CycloneDX and/or SPDX) that includes the NTIA-required minimum elements
  2. FOSSA provides a complete inventory of known vulnerabilities in your software, including contextual information (like CVE score and recommended fix); this informs the required vulnerability assessment document
  3. FOSSA allows you to codify internal assessments as NTIA-compliant VEX statuses and justifications, enabling automated VEX generation and communication of exploitability 
  4. FOSSA ingests third-party SBOMs (and consolidates SBOM data from all your SBOMs), which helps manufacturers stay on top of vulnerabilities from not only first-party, but also third-party software supply chain risks
  5. FOSSA analyzes open source components' level of support to determine abandoned or actively maintained components
  6. FOSSA provides a global package inventory to search across all first- or third-party SBOMs and components, enabling impact assessment as new high-priority vulnerabilities are introduced postmarket. 

Feel free to reach out to our team if you have any questions about FOSSA or if you’d like to get started with a trial of our SBOM management solution.