SBOM for Medical Devices: Complete Guide to FDA Section 524B, EU CRA & NTIA Compliance (2026)

Why SBOMs Are Now Mandatory for Medical Devices

Section 524B of the FD&C Act, added by the Consolidated Appropriations Act of 2023 (signed December 29, 2022), took effect on March 29, 2023, making Software Bills of Materials (SBOMs) a legal requirement for FDA "cyber devices." The FDA's authority to refuse submissions missing SBOMs took effect on October 1, 2023. In the EU, the Cyber Resilience Act (CRA), which entered into force on December 10, 2024, will require SBOMs for all products with digital elements by December 11, 2027.

Modern medical device software consists of 75% or more external components — open-source libraries, third-party modules, commercial off-the-shelf software, and their transitive dependencies. The Log4Shell vulnerability (CVE-2021-44228) demonstrated catastrophically that a single vulnerable component buried deep in a dependency chain can compromise thousands of devices across hundreds of manufacturers. SBOMs exist to make that supply chain transparent.

This guide covers the complete SBOM landscape for medical device manufacturers: what regulators require, which formats to use, how to generate and maintain SBOMs, and how to integrate them into your quality management system and regulatory submissions.

What Is an SBOM?

A Software Bill of Materials (SBOM) is a machine-readable inventory of every software component in a product, including:

• Proprietary software developed in-house
• Open-source libraries and frameworks
• Commercial off-the-shelf (COTS) software and third-party modules
• Transitive dependencies — the "software within the software"
• Build tools and toolchains used during compilation
• Firmware and embedded software in hardware components

The analogy is a food ingredient label: just as food packaging lists every ingredient, an SBOM lists every software component so that regulators, healthcare providers, and manufacturers themselves can identify vulnerabilities, manage lifecycle risks, and ensure traceability.

Regulatory Requirements: FDA, EU, and International

FDA Requirements (Section 524B and 2025 Guidance)

The FDA's requirements for SBOMs come from two sources:

Statutory requirement (Section 524B of the FD&C Act): For devices that qualify as "cyber devices," an SBOM is legally required under Section 524B(b)(3). A device is a "cyber device" if it:

1. Contains software (including firmware)
2. Can connect to the internet or another network (directly or indirectly)
3. Has features that could be vulnerable to cybersecurity threats

FDA Guidance: On June 27, 2025, the FDA issued updated final guidance — "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" — replacing the September 2023 version. This guidance clarifies that for cyber devices, SBOMs are mandatory. For all other software-containing devices, SBOMs are strongly recommended.

The guidance explicitly references the NTIA Minimum Elements for a Software Bill of Materials (July 2021) as the baseline. The February 2026 guidance update reinforced and expanded these expectations in Section V.A.4 and Appendix 4.

The FDA also began requesting VEX (Vulnerability Exploitability eXchange) files alongside SBOMs in some premarket cybersecurity submissions, as confirmed by RunSafe Security's March 2026 reporting. VEX artifacts document whether known vulnerabilities in SBOM-listed components are actually exploitable in the device's specific configuration.

EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (Regulation 2024/2847) entered into force on December 10, 2024, with a phased implementation:

• September 11, 2026: Vulnerability and incident reporting requirements take effect
• December 11, 2027: All remaining requirements, including SBOM generation, take full effect

The CRA requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products."

While the CRA excludes medical devices (which fall under vertical legislation — the MDR/IVDR), its SBOM requirements are referenced in 13 separate passages and establish the "state of the art" baseline. The EU MDR's Annex I, Section 17.2 requires IT security "in accordance with the state of the art" — and SBOMs are now state of the art.

EU MDR and BSI TR-03183

The MDCG 2019-16 rev. 1 does not explicitly mandate SBOMs, but it does require vulnerability monitoring, which is impractical without an SBOM. Germany's Federal Office for Information Security (BSI) published Technical Guideline TR-03183-2, "Software Bill of Materials (SBOM)," which defines the state-of-the-art requirements for SBOMs in the EU market.

IMDRF N73

The International Medical Device Regulators Forum published IMDRF N73 — "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity" — which provides high-level best practices for SBOM generation, management, distribution, and utilization across medical device stakeholders, including manufacturers, healthcare providers, and regulators.

Regulatory Comparison Table

NTIA Minimum Elements: The Baseline Every SBOM Must Meet

The FDA does not define its own SBOM fields. Instead, it references the NTIA Minimum Elements published in July 2021. Every SBOM submitted to the FDA must include these fields for each software component:

FDA Expectations Beyond the NTIA Baseline

For medical device submissions, the FDA expects additional information beyond the NTIA minimum:

Lifecycle metadata:

• Software level of support — actively maintained, legacy, or unsupported/abandoned
• End-of-support date — when the component vendor stops providing patches
• End-of-life date — when the component will no longer function or be usable

Vulnerability context:

• All known vulnerabilities (CVEs) associated with each component
• Cross-reference against CISA's Known Exploited Vulnerabilities (KEV) Catalog
• Documentation of mitigations for each identified vulnerability
• Risk mitigation plan tied to postmarket monitoring

SBOM Formats: SPDX vs CycloneDX vs SWID

Three standard formats exist for SBOMs. The choice matters because it affects tool compatibility, vulnerability scanning integration, and regulatory acceptance.

Format Comparison

Recommendation for medical device manufacturers: Use CycloneDX as your primary SBOM format for its native VEX support and security-focused design. Generate SPDX as a secondary format for license compliance documentation. SWID tags are optional and primarily useful for hospital IT asset tracking.

How to Create an FDA-Compliant SBOM: Step-by-Step

Phase 1: Complete Software Inventory (Weeks 1-2)

Scan all source code, binaries, containers, and build environments to identify every software component:

• Run automated scanning tools against your codebase and build artifacts
• Document all top-level and transitive (nested) dependencies
• Record component versions, sources, and licensing information
• Identify all SOUP (Software of Unknown Provenance) per IEC 62304
• Catalog firmware and embedded software in hardware components

Phase 2: Vulnerability Analysis (Weeks 3-4)

Cross-reference every component against vulnerability databases:

• Pull fresh CVE data for every component from NVD and CISA KEV
• Score each vulnerability using CVSS v4.0
• Flag anything that could impact device safety or clinical performance
• Assess exploitability in the specific device context (not all CVEs are exploitable in every configuration)
• Prepare VEX documentation for vulnerabilities that are mitigated by design

Phase 3: SBOM Generation (Weeks 5-6)

Export your inventory in the required formats:

• Generate CycloneDX JSON and/or SPDX JSON for machine-readable submission
• Add lifecycle metadata (support level, end-of-support date, end-of-life date) for each component
• Create a human-readable summary (recommended: two-page document explaining how you build, update, and monitor the SBOM)
• Validate completeness against NTIA minimum elements checklist
• Ensure Package URLs (purls) are correct for every component

Phase 4: Integration and Validation (Weeks 7-8)

Wire SBOM creation into your development and quality processes:

• Integrate SBOM generation into your CI/CD pipeline so a fresh SBOM is produced with every build
• Link SBOM data to your change-control and patch-management workflows
• Connect to your QMS (ISO 13485 configuration management per Clause 7.5.9)
• Conduct a dry-run "new CVE found" drill to prove your response process works
• Map SBOM components to your Design History File (DHF) and risk management file

Phase 5: Submission Package Assembly

For your FDA premarket submission:

• Include machine-readable SBOM in eSTAR format (Section 5 for cybersecurity)
• Attach human-readable SBOM summary
• Include VEX documents where applicable
• Provide traceability between the SBOM, threat model, cybersecurity risk assessment, and testing documentation
• Document your post-market SBOM maintenance strategy

SBOM Tools Comparison

Recommendation: For small to mid-size manufacturers, start with Syft or Trivy for SBOM generation (free) and add a commercial tool like FOSSA or Snyk for ongoing vulnerability monitoring. For larger organizations or complex devices, Synopsys Black Duck provides the deepest analysis. MedTech-specific tools like MedCrypt and Ketryx offer the tightest integration with FDA submission workflows.

SBOM and ISO 13485 Configuration Management

The FDA's June 2025 guidance ties SBOMs to ISO 13485 configuration management requirements (Clause 7.5.9). This is a critical linkage: your SBOM is not a standalone document — it is part of your device's configuration identity.

Specific integration points:

• Design Transfer (Clause 7.3.8): The SBOM becomes part of the Device Master Record (DMR) at design transfer, documenting the exact software configuration going into production
• Configuration Management (Clause 7.5.9): Every software change (version update, patch, component swap) must update the SBOM and go through change control
• Document Control (Clause 4.2.4): SBOM versions are controlled documents with revision history and approval workflows
• Management Review (Clause 5.6): SBOM-related cybersecurity risks should be a standing agenda item in management reviews
• Post-Market Surveillance (Clause 8.2.1): SBOM data feeds into vulnerability monitoring and complaint analysis

Post-Market SBOM Management

Medical devices operate for 10 to 15 years. SBOM management does not end at submission — it is a lifecycle responsibility.

Continuous Vulnerability Monitoring

• Automated monitoring: Subscribe to NVD, CISA KEV, and vendor security advisories. Cross-reference against your SBOM components automatically.
• Response SLAs: Define internal response timelines. FDA expects "reasonable assurance of cybersecurity" — this means documented procedures for triage, assessment, and remediation.
• Patch management: Maintain a documented process for evaluating and deploying patches. Connect to your ECO (Engineering Change Order) workflow.
• SBOM updates: Every software update triggers a new SBOM version. Track changes through your QMS change control process.

Incident Reporting

The EU CRA requires vulnerability and incident reporting to begin by September 11, 2026. While medical devices are excluded from the CRA, the NIS2 Directive (which may apply to device manufacturers as essential/important entities) requires similar reporting. In the US, Section 524B of the FD&C Act codified postmarket vulnerability reporting obligations.

SBOM Sharing with Healthcare Providers

The IMDRF N73 guidance recommends that manufacturers provide SBOMs to healthcare providers to support their cybersecurity risk management. This enables hospitals to:

• Assess device risk before procurement
• Monitor for vulnerabilities across their installed base
• Implement compensating controls for devices with known vulnerabilities
• Plan patching and upgrade schedules

Common Mistakes and How to Avoid Them

FAQ

Is an SBOM required for all medical devices?

No. Under FDA rules, SBOMs are legally required only for "cyber devices" — devices that contain software, can connect to a network, and have cybersecurity-relevant features. However, the FDA strongly recommends SBOMs for all software-containing devices, and the EU's state-of-the-art expectations increasingly treat SBOMs as necessary for any device with software.

What format should I use for my SBOM?

The FDA accepts CycloneDX, SPDX, and SWID tags. CycloneDX is recommended for medical devices because of its native VEX support and security-focused design. Both CycloneDX and SPDX qualify as the "commonly used and machine-readable format" required by the EU CRA.

What happens if I don't include an SBOM in my FDA submission?

For cyber devices, the FDA can issue a Refuse to Accept (RTA) ruling, which sends the submission back without review. This was the case for a healthcare technology company in early 2026 that avoided an RTA by using CycloneDX SBOM data to discover and fix a critical vulnerability before submission, as documented by Censinet.

Do I need to update my SBOM after FDA approval?

Yes. Medical devices are used for 10-15 years. The FDA's June 2025 guidance expects SBOMs to be living documents, updated as part of your quality system's configuration management process. Every software change triggers a new SBOM version, and ongoing vulnerability monitoring against the SBOM is expected.

What is VEX and do I need it?

VEX (Vulnerability Exploitability eXchange) is a companion document to the SBOM that indicates whether specific vulnerabilities are exploitable in your device's particular configuration. The FDA has begun requesting VEX files alongside SBOMs in premarket submissions. It is not yet required by statute but is strongly expected for submissions where components have known CVEs.

How are SBOMs different from a Software Bill of Materials in the hardware sense?

A hardware BOM lists physical components (resistors, ICs, PCBs). An SBOM lists software components (libraries, frameworks, OS packages, firmware). Both serve transparency and traceability purposes. Your medical device needs both — the hardware BOM in the Device Master Record (DMR) and the software BOM in the cybersecurity documentation package.

Does the EU CRA apply to medical devices?

The CRA explicitly excludes medical devices from its scope (they are covered by the MDR/IVDR). However, the CRA's SBOM requirements define the "state of the art," which the MDR requires compliance with via Annex I, Section 17.2. In practice, medical device manufacturers selling in the EU should follow CRA-level SBOM requirements.

Can I use a spreadsheet instead of a machine-readable format?

For smaller companies with simpler devices, a well-organized spreadsheet may meet the FDA's basic expectations for non-cyber devices. However, for cyber devices, machine-readable formats (CycloneDX or SPDX) are effectively required. Machine-readable SBOMs enable automated vulnerability scanning, which is a core part of the FDA's cybersecurity expectations.

What is the relationship between SBOM and IEC 62304?

IEC 62304 (Medical Device Software — Software Lifecycle Processes) requires identification and control of software components, including SOUP (Software of Unknown Provenance). The SBOM is the practical tool that fulfills this requirement — it is the document that lists every SOUP item, its version, its origin, and its risk classification. Your SBOM should map directly to your Software Architecture Design (SAD) document and IEC 62304 software maintenance process.

How do SBOMs connect to my risk management file (ISO 14971)?

SBOM components with known vulnerabilities are hazards that must be evaluated in your ISO 14971 risk management process. For each vulnerability identified in the SBOM, document the potential harm (patient safety impact), the severity, the probability of occurrence, the risk level, and the mitigation controls. The FDA's 2025 guidance explicitly calls for "traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation."