Cybersecurity 8 min read

A medical device SBOM: what the FDA requires, what the MDR expects, and how to keep it

SBOM required by the FDA (§524B), expected under the MDR (MDCG 2019-16), outside the CRA for a device: contents, CycloneDX/SPDX formats, generation.

Houssam Karrach · Software architect

The SBOM was long an engineering best practice that few teams formalised. That era is over. In the United States it is a legal requirement: the FDA has required it since 2023 in every “cyber device” submission. In Europe, the MDCG 2019-16 guidance on medical device cybersecurity lists it among the information to provide to users. The Cyber Resilience Act mandates an SBOM for digital products, but explicitly excludes those covered by the MDR. For a team building medical software, the question is no longer “do I need an SBOM?” but “will mine hold up in front of a regulator?”.

What is an SBOM, exactly?

Definition: an SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all the software components — commercial, open-source, off-the-shelf — that make up a product, with their dependency relationships. It is your software’s parts list, the equivalent of a bill of materials for the software supply chain.

The NTIA structures the topic in three inseparable areas: the data fields (what each component must document), automation support (machine generation and reading, to scale), and practices and processes (how the SBOM is requested, produced and used). A PDF listing dependencies is not an SBOM: the requirement is a structured format that tools can consume.

What must a compliant SBOM contain?

The NTIA defines seven minimum data fields for each component:

  1. Supplier Name;
  2. Component Name;
  3. Version;
  4. Other Unique Identifiers;
  5. Dependency Relationship;
  6. SBOM Author;
  7. Timestamp.

For a medical device, the FDA premarket guidance additionally expects, for each component: the asset where the component resides, the level of support provided by its manufacturer, its end-of-support date, and its known vulnerabilities. Those last three are decisive: they turn the SBOM from a mere inventory into a life-cycle risk-management tool.

Three texts of different natures, and only one applies directly to your device’s software on the European side:

United States EU, medical device EU, non-MDR product
Text FD&C Act, section 524B MDR Annex I (17.2, 23.4 ab) and MDCG 2019-16 rev. 1 guidance Cyber Resilience Act, Regulation (EU) 2024/2847
SBOM status Legal premarket admissibility requirement Not named by the MDR; listed by MDCG 2019-16 among information to provide to users Mandatory element of the technical documentation
Since / deadline In force since 29 March 2023 MDR applicable since 26 May 2021 Entered into force 10 Dec 2024; main obligations from 11 Dec 2027
Scope Commercial, open-source and off-the-shelf components Not specified At minimum the top-level dependencies
Disclosure In the FDA submission Information intended for the device’s users In the technical documentation, provided to market surveillance authorities on request

The point that often trips teams up: the CRA does not apply to a medical device’s software. Its Article 2(2) excludes products covered by Regulation (EU) 2017/745 (MDR) and 2017/746 (IVDR), which already address their cybersecurity. It does concern your other digital products placed on the EU market, if they are not devices. For the device itself, the SBOM follows from the state of the art in information security required by MDR Annex I (17.2), for which IEC 81001-5-1:2021 is the reference.

An SBOM is not one more compliance deliverable: it is the same technical artifact that feeds your FDA file, your MDR documentation, and your SOUP management under 62304 at once. Build it once, use it everywhere.

Which format: CycloneDX or SPDX?

Two standards share the field:

  • CycloneDX — driven by OWASP, standardised as ECMA-424, designed with a security focus (vulnerabilities, VEX).
  • SPDX — driven by the Linux Foundation, published as ISO/IEC 5962:2021, rooted in open-source licence compliance.

No text mandates one over the other: the FDA asks for a machine-readable format, and the CRA, for the products it covers, a commonly used, machine-readable format. CycloneDX and SPDX both meet that criterion. In practice, many teams generate both, because tools, customers and authorities each lean a different way.

How do you generate and maintain it?

An SBOM is not written by hand: it is generated from your sources of truth.

  • Generate from lockfiles (package-lock.json, poetry.lock, go.sum…) with tools like Syft, Trivy or your ecosystem’s CycloneDX plugin — include transitive dependencies, base images and runtimes.
  • Regenerate on every release, automatically, in CI. An SBOM frozen on audit day is wrong by the next version.
  • Wire it into the rest of compliance: every third-party component is a SOUP in the IEC 62304 sense — the SBOM is its inventory; and it is the pivot of post-market vulnerability management, since it lets you identify affected devices within minutes when a CVE is published.

That last point is what gives the SBOM its real value: not ticking a regulatory box, but knowing instantly what your product contains the day a critical vulnerability drops. What happens next — continuous scanning, triage, and traced decisions — is covered in From SBOM to VEX: managing vulnerabilities without drowning the team.

FAQ

01Do I have to make the SBOM public?

No. On the FDA side, it is attached to the premarket submission. On the MDR side, the MDCG 2019-16 guidance lists it among the information intended for the device’s users, which does not require publishing it. For a non-MDR product under the CRA, it is part of the technical documentation, provided to market surveillance authorities on request. The transparency required is regulatory, not public.

02Must it include transitive dependencies?

For the products it covers, the CRA’s legal minimum covers top-level dependencies, but the expected practice — and what tools produce — covers the full graph, transitive dependencies included. For vulnerability management, partial depth is a blind spot: a CVE often hides in a dependency of a dependency.

03Is an SBOM enough to prove my cybersecurity compliance?

No. It is a necessary but not sufficient piece. It fits into a broader cyber file — vulnerability management plan, threat model, security testing. An SBOM with no monitoring and triage process behind it is just a list.

References & standards cited

  1. [01] FD&C Act, section 524B — Ensuring Cybersecurity of Devices (FDA Digital Health Center of Excellence)
  2. [02] FDA Guidance — Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (2023)
  3. [03] NTIA — The Minimum Elements For a Software Bill of Materials (SBOM) (12 July 2021)
  4. [04] Regulation (EU) 2024/2847 — Cyber Resilience Act (products with digital elements)
  5. [05] IEC 81001-5-1:2021 — Health software — Security — Activities in the product life cycle
  6. [06] ISO/IEC 5962:2021 — SPDX (Software Bill of Materials format)
  7. [07] IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes

Medical software that has to hold up in production?

Free first call: we look at your architecture together, and at what's holding back your release to production.

Book a call →

Read next

All articles →
Cybersecurity 8 min Unicis Platform CE: open-source GRC for a medical device team Unicis Platform CE, self-hosted open-source GRC: what it covers for a medical device software team — ISMS, risk register, GDPR — and where the MDR file starts. Cybersecurity 10 min The Stryker attack hit no medical device — and that is exactly the problem The Stryker attack reached no medical device, but the manufacturer's control plane. What that changes for the scope of your threat model. Cybersecurity 12 min Threat modelling a medical device: architecture views and the risk matrix The threat model the FDA expects: four security architecture views, the risk matrix, exploitability rather than probability, and the transfer into ISO 14971.