Software Bill of Materials (SBOM) for IoMT Software: FDA Compliance Guide

A connected medical device submission may be blocked by the U.S. FDA due to insufficient cybersecurity documentation. A software bill of materials sbom for IoMT software provides a precise, machine-readable list of all software components that are used by connected medical devices.  From open-source libraries to transitive dependencies are mentioned inside the SBOM.

Even one missing, out-of-date, or misidentified component can cause a cybersecurity and compliance issue that could block the submission. The FDA now demands strict security standards from all connected medical devices. Without the exact computer-readable list of each software component and background libraries, getting FDA compliance is impossible.

In this article, you will get a complete idea about how to make your connected medical software FDA-compliant, what is required by FDA Section 524B, how to choose a proper format of SBOM, and how to automate the process of SBOM generation.

Key Takeaways

• The FDA mandates that manufacturers of IoMT devices must have a fully comprehensive and machine-readable SBOM.
• SBOM should include the dependencies and transitive dependencies present in the entire device ecosystem.
• CycloneDX and SPDX can be used to create standard forms of SBOM.
• VEX can help identify whether the vulnerabilities of components are affecting the device or not.
• Automation of SBOM generation within the CI/CD pipeline will ensure that software inventory is kept up-to-date.

What Is a Software Bill of Materials (SBOM) for IoMT Software?

A healthcare software bill of materials sbom for IoMT software is a machine-readable architectural representation of all software components. It also includes third-party libraries, open-source packages, and firmware elements that are included within an IoMT device. 

To comply with established government baseline guidelines such as Minimum Elements for an SBOM (NTIA/CISA), the following seven metadata elements need to be provided for every component integrated within your IoMT device:

• Name of Supplier: Original manufacturer, developer, or open-source entity behind a particular software component.
• Name of Component: Standard name of the particular software package.
• Version of Component: Exact version of the software library used in your build.
• Unique Identifiers: Common keys, such as Package URL, that identify a particular software component.
• Dependency Relationships: Relationships between different software components.
• Author of Data: The exact tool or entity that created the inventory document.
• Timestamp: Date and time when the software inventory was created in your build process.

Why Does FDA Need an SBOM for IoMT Software?

IoMT devices gather sensitive data from patients, communicate real-time health information, provide automatic treatment, and remain connected to the healthcare network. If any of the third-party software elements used in the device have an unknown vulnerability, hackers may exploit the flaw to steal patient data, compromise the device, and cause harm to patients.

This is why, under the FDA Medical Device Cybersecurity Standards, manufacturers must provide the medical device SBOM (Software Bill of Materials). The SBOM allows regulators and healthcare organizations to receive information about the software components used in the device. This helps in the following aspects:

• Identification of Vulnerable Devices: In case there is a zero-day or software vulnerability that becomes known, manufacturers and healthcare providers will be able to determine which models of devices have the vulnerable software.
• Supply Chain Risk Assessment: The SBOM will allow identification of what commercial, third-party, and open-source software libraries are used in the device.
• Validation of Safety Protections: Regulators can find out if any software vulnerabilities were known to the manufacturer and addressed by the manufacturer in the process of device certification.

What are the key FDA expectations for IoMT Software Bills of Materials?

The FDA SBOM requirements are consistent with the National Telecommunications and Information Administration (NTIA) minimum elements. Your submission should meet three key requirements to be compliant with a software bill of materials for IoMT software:

• Data Fields: Component names, version numbers, supplier names, unique identifiers (PURLs/CPEs), and cryptographic hashes.
• Machine Readability: Producing structured output in validated JSON, XML, or YAML format. Flat PDF or Excel spreadsheets will not be accepted.
• Depth & Breadth: The breadth of coverage from microcontroller to Linux OS layers, to companion mobile application to cloud API.

What Regulatory Frameworks and Compliance Standards Govern IoMT Software Cybersecurity?

There are three different categories of regulation that need to be considered when securing your connected medical device. These include federal regulations, risk standards, and national security frameworks.

The following is a breakdown of the regulatory regimes governing IoMT software cybersecurity:

1. FD&C Act Section 524B (FDA Cyber Device Mandate): This federal regulation allows the FDA to withhold approval of a medical device submission. Approval methods include 510(k), De Novo, or PMA, should cybersecurity not be present. If your device connects to the internet or a network, then Section 524B mandates that there be three basic elements:

• Machine-readable FDA software bill of materials.
• Process for identifying and mitigating post-market cybersecurity issues.
• Process for securely updating the software of the device.

2. AAMI TIR57 & ANSI/AAMI SW96: FDA evaluators compare the device to these consensus safety standards. They ask your engineers to do threat modeling and include software supply chain risk in your primary ISO 14971 risk management document.

3. Executive Order 14028 & NTIA Minimum Elements: After serious breaches across the world in the supply chain, Executive Order 14028 laid down the basis for software inventories.

FDA requires NTIA Minimum Elements to ensure all software bills of materials for IoMT software include standardized vendor, version, and component relationship elements.

Which Standard Format Should You Choose for Your Medical Software?

CycloneDX and SPDX are two machine-readable schemas that have FDA recognition. CycloneDX has a strong focus on cybersecurity, and SPDX is highly proficient in licensing compliance for open source. Your choice of schema will depend on your engineering architecture and build processes.

Why Is Scanning Medical Device Code Different from Regular Software?

Scanning the code of medical products is difficult due to the presence of microchips, custom operating systems, and mobile companion applications in one product. Enterprise software products typically use package managers with a list of all dependencies collected in one location.

Medical devices commonly execute low-level code, namely C or C++, directly on the microcontroller without any standard package.

• Embedded Firmware: Real-time operating systems running on microcontrollers do not use standard package manifests.
• Embedded Linux Distributions: Custom embedded distributions built via Yocto Project need recipe metadata extraction.
• Mobile Applications: iOS and Android mobile apps communicating via Bluetooth may contain third-party SDKs.
• Cloud Infrastructure: Backend services supporting clinical telemetry may require container images and serverless scanning.

Avoid FDA 510(k) Submission Delays

Avoid costly FDA 510(k) delays by identifying SBOM compliance gaps before submission.

Book an SBOM Gap Assessment →

How Do You Track Main vs. Hidden Software Ingredients in Medical Devices?

To determine the main and hidden software components of a medical device, the development team needs to utilize the automated Software Composition Analysis (SCA) process. Direct Dependencies include primary software components picked by the developers explicitly.

The process of scanning compiled binaries, project lock files, and manifest files will allow you to include both direct and hidden dependencies in your Healthcare Software Bill of Materials (SBOM). According to cybersecurity experts, transitive dependencies contain more than 80% of vulnerabilities in open-source software.

What Is Vulnerability Exploitability eXchange (VEX) and Why Is It Critical for FDA Submissions?

The Vulnerability Exploitability eXchange (VEX) identifies whether a security problem in the upstream product component affects the hardware. In its absence, the software bill of materials for IoMT software lists all the vulnerabilities of the components. Regardless of whether the code is ever called or compiled.

According to established VEX standards, medical device vulnerabilities can be grouped into four status classes:

• Not Affected:Vulnerability does not present any clinical risk because the affected code is unreachable/uncompiled.
  
• Affected: Vulnerability presents some safety risk and needs mitigation/patching.
• Fixed: Vulnerability was fixed in the present software version.
• Under Investigation: The engineering team is investigating the safety implications of the vulnerability.

How Can You Automate SBOM Creation During Software Builds?

You can create an SBOM automatically through software builds by incorporating automated software composition technologies into your DevSecOps CI/CD pipeline. Manually creating it will be error-prone and outdated once new changes have been made.

Automated build processes guarantee that each software release will automatically produce an exact FDA software bill of materials. Follow these steps to generate it automatically:

• Integrate automated scanning plug-ins right into the continuous integration build pipeline environments.
• Program scanners to scan lockfiles, package manifest files, and binary code automatically.
• Generate unique hash values for each software element to validate the binary integrity consistently.
• Validate the generated files with automated schema validators for proper CycloneDX/SPDX syntax format.
• Digitally sign the final file and save it together with your compiled software release files.

What Are the Common SBOM Compliance Pitfalls?

Completion of an SBOM in medical devices involves collaboration among the medical device sponsor, regulatory team, software vendors, and engineering team. The FDA applies a strict Refuse-to-Accept (RTA) policy under Section 524B. The incomplete cybersecurity package is flagged with a submission hold or an additional information deficiency letter.

1. Incomplete or  “Shallow” Software Inventories

Pitfall: Reviewers look for high-level listings of software. Sometimes organizations fail to include any information on sub-libraries, pinned versions, vendors, or machine-readable format (CycloneDX/SPDX).

Solution: Export machine-readable CycloneDX/SPDX files that can be done automatically from your build pipeline. This should include all direct libraries and transitive dependencies.

2. Lack of Consensus Standard Alignment for Threat Models

Pitfall: Providing generic STRIDE threat modeling templates that do not have DFDs, trust boundaries, or a connection with patient safety.

Solution: Align your threat models to AAMI TIR57 and ANSI/AAMI SW96. Each threat should be traced back to the trust boundary and connected to its specific security control and clinical risk.

3. Security Risk Registers Disconnected from ISO 14971

Pitfall: Monitoring the cybersecurity vulnerabilities in an independent security spreadsheet that does not link to the main file of medical device safety.

Solution: Align all cybersecurity vulnerabilities with relevant hazards and patient risks in your ISO 14971 risk management file. Show clearly how exploitability links to the probability of harm.

4. Gaps in the Secure Product Development Framework (SPDF)

Pitfall: Design controls with cybersecurity deliverables not adequately documented throughout the phases of development. It should include requirements, architecture, implementation, testing, and release. 

Solution: Integrate your SPDF into your Quality Management System (QMSR / ISO 13485). Maintain tangible objective evidence (e.g., secure code review log, threat model sign-off, verification test report).

5. Narrow Penetration Testing Scope or Automated-Only Scans

Pitfall: Submission of pen test report scans that only cover web APIs or are entirely automated vulnerability scans without any medical device context.

Solution: Conduct penetration testing manually and automatically on all attack surfaces of the medical device. This includes Bluetooth Low Energy (BLE), Wi-Fi, physical USB/service port, microchip debug port, and cloud backend.

6. Missing Coordinated Vulnerability Disclosure (CVD) Programs

Pitfall:No publicly available channel exists that would allow ethical hackers to submit reports of security vulnerabilities. Also, no timeline exists for dealing with these reports internally.

Solution: Create and release a CVD program based on ISO/IEC 29147 and ISO/IEC 30111 standards. Specify tight internal SLAs for the triage of received reports and patches.

7. Poor Post-Market Surveillance & Vulnerability Monitoring

Pitfall: Mentioning pre-market safety measures, but not addressing how to keep track of vulnerabilities and apply fixes once the product is launched.

Solution: Provide a post-market surveillance plan showing how you will actively monitor for vulnerabilities using security feeds like NVD, CISA alerts, and ISACs.

8. Insufficient Cybersecurity Information in Device Labeling

Pitfall: IFU not providing information about important security configuration guidance, open port needs, or software EoS.

Solution: Ensure that you include a separate cybersecurity section in your device labeling. Provide information about recommended network hardening configurations, open ports/protocols, EoS date, and methods for getting SBOMs.

9. Missing SBOM Lifecycle and Maintenance Workflows

Pitfall: Delivering just one static SBOM without providing details on how the SBOM will evolve during the lifecycle of the product.

Solution: Outline the specific process of creating an SBOM with every build, ensuring component accuracy, and meeting post-market customer requirements.

10. Insufficient Security Architecture Diagrams

Pitfall: Submissions of a generic block diagram not demonstrating system layouts globally, harm vectors to multiple patients, and update paths.

Solution: Offer multi-view architecture diagrams as described in FDA guidelines, Appendix 2. Include documentation for each data flow, trust boundary, authentication gateway, and encryption boundary at all global, device, and cloud levels.

How Do You Maintain an SBOM Postmarket Throughout the Device Lifecycle?

An SBOM is a living document that needs constant monitoring even beyond market approval. If new software vulnerabilities (CVEs) are detected in devices out there on the market, we should take immediate actions.

Lifecycle management post-market of an SBOM in the field of healthcare would be as follows:

• Continuous Vulnerability Monitoring: Automated scanning of your SBOM database against new CVE/NVD feeds.
• Version Control: Updating the medical device SBOM artifact every time a new software patch or firmware is available.
• Patch Coordination Deployment: Deployment of security patches in healthcare institutions based on your 524B plan.

FDA SBOM Compliance Checklist for IoMT Medical Devices

Before you apply to the FDA with your connected medical device, go through the checklist below to make sure that you meet the regulations in Section 524B with regard to your software inventory. 

This will help you avoid typical errors in FDA submissions, prevent a Refuse-to-Accept (RTA), and stay on the right regulatory path.

• Standardized Machine-Readable Format: Your IoMT software creates its software bill of materials (SBOM) in an FDA-supported format, using CycloneDX or SPDX.
  
• Validated Machine-Readable Format: The file is machine-readable and validated with JSON, XML, or YAML structure.
• Complete Data Attributes: The inventory meets all essential FDA SBOM Requirements, namely Component Name, Version, Supplier, Cryptographic Hash, and Unique Identifier (PURL/CPE).
• Complete Dependency Tree:The team includes the dependencies, both direct packages and transitive (nested) sub-libraries, completely.
  
• Complete System Tier Coverage: All the software components in the device are included in the inventory. From firmware on the embedded microchip to companion mobile apps and cloud telemetry API endpoints.
• VEX Documentation: VEX documentation is provided to substantiate any unexploitable or mitigated vulnerabilities upstream from the software bill of materials.
• Pipeline Support for Automated SBOM Creation:SBOM creation automates right into your CI/CD pipeline DevSecOps runners.
  
• Postmarket Security Compliance: Your submission is compliant with the FDA Medical Device Cybersecurity Standards, which include the SBOM and postmarket cybersecurity management.

How Does Qualysec Secure FDA Approval For Your IoMT Device?

Qualysec connects software development with FDA compliance by providing comprehensive cybersecurity services for medical devices. Our key services include:

• Secure Bill of Materials Creation: We create machine-readable SBOMs (CycloneDX/SPDX) for direct and transitive dependencies in embedded firmware, apps, and cloud APIs. This avoids RTA rejection by the FDA.  
• Hybrid Penetration Testing: Our white-hat ethical hackers conduct manual black-box and white-box penetration tests on all IoMT attack surfaces. These include BLE, WiFi, hardware debuggers, and cloud telemetry.  
• VEX & Threat Modeling: We implement a Vulnerability Exploitability eXchange (VEX) workflow to integrate discovered software vulnerabilities. The ISO 14971 clinical risk management document and AAMI TIR57/SW96 threat models document the vulnerabilities.
  
• Post-Market Product Coordination: We perform continuous CVE monitoring, CVD policy, and patch management required for post-market life cycle compliance. 

Qualysec transforms cybersecurity data into pre-market FDA-compliant documents.

Conclusion

Creating a software bill of materials sbom for IoMT software to make it compliant is no longer just a tick-the-box for FDA cybersecurity documents for FDA clearance but is a necessary cybersecurity requirement for any connected health IT infrastructure.

Using a standard machine-readable format, automating the process in CI/CD pipelines, tracking transitive dependencies, and including VEX exploitability information will help achieve FDA clearance and ensure patient safety.

Preparing for an FDA 510(k) Submission?

Generate FDA-compliant SBOMs, VEX documentation, and cybersecurity assessments with expert support.

Speak with Our FDA Compliance Team →

FAQs

1. What is an SBOM and why is it required by the FDA for IoMT devices?

An SBOM is an electronically readable record of all software components in a connected medical device. As per section 524B, the FDA requires it to detect any software weaknesses quickly and safeguard patients from harm.

2. What file types does the FDA support for SBOMs in medical devices?

The FDA supports machine-readable file types such as JSON, XML, or YAML in OWASP CycloneDX or SPDX standards. The FDA absolutely rejects unstructured files such as simple PDFs or Excel sheets.

3. Why do IoMT SBOMs require transitive dependencies?

Transitive dependencies conceal sub-libraries that major libraries import; more than 80% of vulnerabilities in open-source software exist here. The FDA mandates comprehensive mapping of dependencies to avoid any security gaps.

4. What is VEX and why is it critical for FDA approvals?

Vulnerability Exploitability eXchange (VEX) is important for determining whether the discovered flaw in the software component affects the device. VEX ensures FDA reviewers that inaccessible code is not harmful to patients.

5. What triggers a Refuse-to-Accept (RTA) action on SBOMs at the FDA?

Submissions will be held back if the SBOM is lacking essential metadata information. It can also be put on hold if the SBOM is not tracking dependencies deeply or uses static formats. Missing links between cyber threats and ISO 14971 safety files are another reason for rejection.