SBOM for Medical Devices: A Practical Guide to Building and Maintaining One for Your Device Submission

If your device contains software and can connect to the internet, directly or indirectly, your submission is not complete without a Software Bill of Materials. Since 1 October 2023, FDA can refuse to accept (RTA) a cyber device submission that lacks the section 524B information, including the SBOM. Regulators have stopped treating the SBOM as a nice extra. It is the inventory that makes vulnerability management possible, and reviewers read it closely.

What the FDA Expects 

Section 524B of the FD&C Act, effective 29 March 2023, requires sponsors of a cyber device to provide an SBOM covering commercial, open-source and off-the-shelf software components. This applies to 510(k), De Novo, PMA, PDP, and HDE submissions. A cyber device is one that includes software, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats. 

FDA’s current premarket submission cybersecurity guidance, issued 3 February 2026, asks for a machine-readable SBOM consistent with the NTIA SBOM minimum elements. FDA’s guidance still references the NTIA elements, but the 2026 CISA baseline is a superset, so building the 2026 fields covers both. For each component, it also recommends two extra data points that are often missed: the level of support from the component manufacturer, such as actively maintained, no longer maintained or abandoned, and the component’s end-of-support date. Submissions should also list known vulnerabilities, including any in the CISA Known Exploited Vulnerabilities Catalog, with their risk assessment and controls. 

The Wider Baseline 

In July 2026, CISA and international partners published the 2026 Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA baseline and expanding the minimum data fields from seven to 17. It adds fields many existing SBOMs do not carry: a digital signature, data format name and version, generation context, tool name and version, SBOM version, component hash value and algorithm, and component license. The old top-level depth limit is gone, so coverage now means all components, including transitive dependencies. 

In the EU, devices under MDR and IVDR sit outside the Cyber Resilience Act (Article 2(2) of Regulation (EU) 2024/2847), because those Regulations already cover cybersecurity. MDR does not name the SBOM, but Annex I sections 17.2 and 17.4 require state-of-the-art software development and IT security, and MDCG 2019-16 lists the software bill of materials among the security information manufacturers should provide alongside the instructions for use. 

Other Markets 

Outside the US and EU, the International Medical Device Regulators Forum (IMDRF) has published principles and practices for SBOMs in medical device cybersecurity, which many regulators draw on. Building to the FDA and 2026 CISA expectations positions you well for these markets too. 

SBOM and the IEC 62304 SOUP List 

If you follow IEC 62304, you already keep a list of software of unknown provenance (SOUP). The two overlaps but are not the same: the SOUP list supports safety and lifecycle decisions, while the SBOM supports vulnerability management and must cover every component, including transitive dependencies. Generate both from one source, so they never disagree. IEC 81001-5-1 links the two by setting security expectations across the software lifecycle. 

How to Build One 

1. Scope it honestly. Cover application software, firmware, the operating system or RTOS, installers, the companion app and any manufacturer-controlled cloud or update server. Code written by a contract manufacturer is still yours to declare. 
2. Generate it from the build. Wire SBOM generation into your CI/CD pipeline, so the output matches the exact binary you shipped. Add binary composition analysis for firmware and supplier-provided binaries your source scanner cannot see. 
3. Pick a format and stay in it. SPDX and CycloneDX are the two widely used machine-readable options. State the format version you use, such as SPDX 2.3 or CycloneDX 1.6, and give each component a unique identifier such as a PURL or CPE, so tools can match it to vulnerability databases. 
4. Enrich it. Add support status, end-of-support dates, licenses, and known vulnerability findings. Use VEX (Vulnerability Exploitability exchange) statements to record whether each listed vulnerability actually affects the device. Reviewers find this format easy to follow. 
5. Be explicit about gaps. State clearly whether data is unknown to you or deliberately withheld. Both SPDX and CycloneDX have explicit ways to mark data as unknown or withheld, such as NOASSERTION in SPDX.

How to Maintain It 

Generate a fresh SBOM for every build and release, and reissue when you correct earlier data. Version it, timestamp it and sign it. Make current SBOM information available to users on a continuing basis, because labeling expectations now cover this. Then feed it into continuous monitoring against the NVD and CISA KEV, which is what your post market vulnerability management plan under Section 524B(b)(1) actually runs on. 

Common SBOM Deficiencies 

• In the SBOMs we review, these gaps cause the most trouble:
• Missing transitive dependencies. Fix: Scan the full dependency tree, not just top-level packages. 
• Supplier components treated as out of scope. Fix: Require SBOMs from suppliers by contract or use binary analysis.
• No support status or end-of-support dates. Fix: Add both fields for every component and review them for each release. 
• An SBOM that no longer matches the released build. Fix: Generate it in CI/CD from the shipped binary.
• A file that cannot be parsed by a tool. Fix: Validate it against the SPDX or CycloneDX schema before submission.
• Vague versions such as ‘latest’ or version ranges. Fix: Record the exact version shipped.
• No unique component identifiers. Fix: Add a PURL or CPE for each component.
• Known vulnerabilities listed with no assessment. Fix: Add a risk assessment or VEX statement for each. 

A Note on Expert Validation 

A specialist review usually focuses on three questions this guide cannot answer for you. First, whether your device meets the cyber device definition at all, since connectivity through a companion app, a service port or a USB update path can bring a device into scope when teams assume it is not. Second, how far down your supply chain the SBOM needs to go for your architecture, particularly where a contract manufacturer or chipset vendor supplies firmware you cannot scan yourself. Third, whether your SBOM, threat model, risk assessment and test evidence tell one consistent story, because reviewers read them together, and a mismatch between any two is a common reason for additional information requests. 

Where NexorTest Fits 

NexorTest supports medical device manufacturers with cybersecurity and penetration testing, SaMD regulatory consulting, IEC 62304 software lifecycle work and global submissions. If you are preparing a cyber device submission and want a second pair of eyes on the SBOM package, get in touch. You can also download our SBOM submission checklist.