A Software Bill of Materials (SBOM) is a machine-readable inventory of every software component inside your device, including versions, suppliers, and licences. Under MDR Annex I §17.4 and the cybersecurity guidance in MDCG 2019-16 Rev.1, notified bodies now expect an SBOM as baseline evidence that you know what is running in your device and can respond when a vulnerability hits.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • An SBOM is the complete, versioned list of software components inside your medical device, including third-party and open-source code.
  • MDR Annex I §17.4 requires manufacturers to set minimum IT security requirements and MDCG 2019-16 Rev.1 operationalises that through an SBOM expectation.
  • EN IEC 81001-5-1:2022 is the harmonised standard that structures how to build, maintain, and use an SBOM across the security lifecycle.
  • The two practical formats are SPDX (ISO/IEC 5962:2021) and CycloneDX. Both are acceptable; pick one and use it consistently.
  • The SBOM is not a deliverable you generate once. It must be updated with every release and tied to your vulnerability monitoring and incident response process.
  • Your EN 62304 SOUP list is related but not identical. SBOM is broader, machine-readable, and built for continuous security monitoring.

Why the SBOM conversation arrived so fast

Until a few years ago, most MedTech startups treated software dependencies as an internal engineering concern. A list of libraries lived in a package.json or a requirements.txt, and the SOUP register in the technical file captured the handful of components the developer remembered to list. That era is over.

Two things changed. First, the MedTech industry absorbed the lesson from Log4Shell, SolarWinds, and the wave of healthcare ransomware attacks: if you do not know what is in your software, you cannot defend it. Second, notified bodies started asking for evidence that manufacturers could answer, within hours, the question "is your device affected by CVE-XXXX-YYYY?". The only sane way to answer that question at speed is to have an SBOM, kept current, queryable, and tied to a monitoring process.

At audits in 2025 and 2026, an SBOM is no longer a nice-to-have. When a notified body reviewer opens the cybersecurity section of a technical file, they expect to find one. If they do not, the finding writes itself.

What MDR actually says

The MDR does not use the phrase "Software Bill of Materials". It gets there through a chain of requirements.

Annex I §17.2 requires that software be "developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation". The harmonised route for "state of the art" on the lifecycle side is EN 62304:2006+A1:2015.

Annex I §17.4 is the pivot. It requires manufacturers to "set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended". This is the cybersecurity hook.

MDCG 2019-16 Rev.1 (December 2019, revised July 2020) is the guidance that translates §17.2 and §17.4 into concrete expectations. It explicitly discusses component inventories, the need to track third-party software, and the requirement to maintain that information across the product lifecycle. It is the document reviewers reach for when they write up an SBOM-related finding.

EN IEC 81001-5-1:2022 is the harmonised standard that sits on top of EN 62304 and adds the security lifecycle. It specifies activities for secure development, including the creation and maintenance of a software component inventory, vulnerability monitoring against that inventory, and coordinated disclosure. An SBOM is the artefact that makes every single one of those activities executable.

Put plainly: the MDR requires you to manage cybersecurity across the lifecycle. MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022 tell you how. Both documents point at the same conclusion — you need an inventory, machine-readable, versioned, and maintained. That inventory is the SBOM.

SBOM versus SOUP: the relationship that confuses everyone

EN 62304 clause 8 already requires a list of "Software Of Unknown Provenance" — code you use but did not develop under a 62304-compliant process. Founders reasonably ask: if I have a SOUP list, do I also need an SBOM?

Yes. They overlap but solve different problems.

The SOUP list exists for safety. It asks: does this component work correctly for its intended purpose inside my device, and what are the residual risks? It is a small number of entries, each accompanied by rationale, version control, and risk analysis under EN ISO 14971.

The SBOM exists for security. It asks: exactly which components, at which versions, with which licences, are inside the binary I shipped, so that when a CVE lands I can tell within an hour whether my device is affected? It is typically orders of magnitude larger than the SOUP list because it catches every transitive dependency, not just the ones a human flagged as consequential.

A healthy setup treats the SBOM as the ground truth inventory and derives the SOUP list from it. The SOUP list is the curated, safety-annotated subset. The SBOM is the complete, machine-readable graph.

Formats: SPDX or CycloneDX

Two formats dominate. Both are acceptable under MDCG 2019-16 Rev.1 because the guidance is format-agnostic — it cares about content, not syntax.

SPDX (Software Package Data Exchange) is standardised as ISO/IEC 5962:2021. It is broader in scope, with strong licence-tracking capabilities, and is the preferred choice when licence compliance is a priority.

CycloneDX is maintained by OWASP. It was designed from the start for security use cases. It has first-class support for vulnerability references, VEX (Vulnerability Exploitability eXchange) statements, and tight integration with tools like Dependency-Track.

For most SaMD startups, CycloneDX is the pragmatic pick because the tooling around vulnerability management is more mature. SPDX is equally defensible if your team already lives in that ecosystem. What matters is that you commit to one format, document that decision in your security plan, and use it consistently. Mixing formats inside a single product is where audit findings come from.

A worked example

A three-person SaMD startup is building a Class IIa clinical decision support web application. Backend in Python, frontend in TypeScript, deployed as containers.

Before SBOM discipline, their SOUP list had 14 entries — the libraries someone remembered to add during design reviews. When Log4Shell-style events happened, the CTO spent a weekend manually checking requirements.txt files across three services.

After implementing an SBOM process, the picture changed:

  1. The CI pipeline runs cyclonedx-py against each Python service and @cyclonedx/cyclonedx-npm against the frontend on every build. Container SBOMs are generated with syft.
  2. The build merges service SBOMs into one product-level CycloneDX document, tagged with the release version. This single document is attached to the release record in the DHF.
  3. The SBOM is uploaded to a Dependency-Track instance. When the NVD publishes a new CVE, Dependency-Track matches it against the current SBOM and raises a ticket within minutes.
  4. The total component count is 847 — not 14. The SOUP list remains 14 entries, curated from the SBOM with safety rationale for each.
  5. When the next high-severity vulnerability arrived, the answer to "are we affected?" took 90 seconds, not 90 hours.

The technical file now contains: the SBOM document per release, the SBOM generation procedure, the vulnerability monitoring SOP referencing Dependency-Track, and the link from the SBOM back to the §17.4 security risk assessment. That is an audit-ready package.

The Subtract to Ship playbook

You do not need a cybersecurity department to run this. You need four things, wired together and small enough to maintain.

1. Generate automatically, never by hand. Pick one tool per ecosystem — syft for containers, cyclonedx-py or cyclonedx-npm for source, cyclonedx-gradle-plugin for JVM. Wire them into CI. An SBOM that is written manually is wrong the day after you write it.

2. Tie the SBOM to a release, not a branch. Every released build produces exactly one SBOM, stored with the build artefact and referenced from the design output record. This is how traceability to EN 62304 clause 5.8 (software release) actually works in practice.

3. Feed the SBOM into active vulnerability monitoring. An SBOM that sits in a folder is a liability. An SBOM watched by Dependency-Track, Grype, or an equivalent scanner is an asset. The security risk management file under EN IEC 81001-5-1:2022 should reference the monitoring tool by name and describe the triage workflow.

4. Connect SBOM to your incident response procedure. When a CVE triggers an alert, your SOP should say: who assesses impact, who decides on a patch release, who notifies users under Annex I §23.4 if a residual risk remains. This is where SBOM stops being an inventory and becomes a working part of your QMS.

Everything else — fancy dashboards, licence audits, supply-chain attestations — is optional. The four items above are the minimum viable SBOM programme. Ship that first.

Reality Check

  1. Can you produce the SBOM for your most recent release in under five minutes, without asking a developer to run anything manually?
  2. Does every SBOM entry include component name, version, supplier or origin, and a unique identifier (PURL or CPE)?
  3. Is your SBOM format decision (SPDX or CycloneDX) documented in your cybersecurity plan, with rationale?
  4. When a new critical CVE is published tonight, what is the maximum time before you can answer "are we affected?" with evidence?
  5. Does your SOUP list under EN 62304 reconcile against your SBOM, and can you show the reconciliation?
  6. Is the SBOM attached to the release record in your DHF, or does it live only in the build system?
  7. Who in your team is named, in writing, as the owner of SBOM maintenance and vulnerability triage?
  8. If your notified body reviewer asked for the SBOM of a release from eighteen months ago, could you retrieve it?

Frequently Asked Questions

Is an SBOM legally required under MDR? The MDR text does not use the word "SBOM". The legal requirement is in Annex I §17.2 and §17.4 to manage software security across the lifecycle. MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022 make clear that a component inventory is the expected way to meet those requirements. In practice, notified bodies now treat the absence of an SBOM as a non-conformity.

SPDX or CycloneDX — which do notified bodies prefer? Neither is mandated. Reviewers care that the SBOM is complete, machine-readable, version-controlled, and actively used for vulnerability monitoring. Pick the format your tooling supports best and commit to it.

Do Class I software devices need an SBOM? The cybersecurity requirements in Annex I §17.4 apply regardless of class. A Class I SaMD with networked components absolutely needs an SBOM. The effort should scale with risk, not disappear.

Does our SOUP list satisfy the SBOM requirement? No. The SOUP list is a safety-focused, curated subset. The SBOM is the complete machine-readable inventory. You need both, and the SOUP list should be derivable from the SBOM.

How often must the SBOM be updated? On every release. If you ship a patch, the SBOM changes. Continuous generation in CI is the only maintainable approach.

What about hardware components — do we need a hardware BOM too? EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 focus on software. Hardware bills of materials are separately required for manufacturing and supplier control under EN ISO 13485, but that is a different document with different owners.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2, §17.4, §23.4.
  2. MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for medical devices (December 2019, Rev.1 July 2020).
  3. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle.
  4. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes.
  5. ISO/IEC 5962:2021 — Information technology — SPDX Specification V2.2.1.