An SBOM for a medical device is not a new artefact invented by regulators. It is what the EN 62304 configuration item list should have been all along: every library, every SOUP component, every version, tracked continuously and used as the feed for CVE monitoring under EN IEC 81001-5-1:2022.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I §17.2 and §17.4 require software to be developed under state-of-the-art lifecycle and IT security practices, and the harmonised standards translate that into SBOM-style visibility.
  • EN 62304:2006+A1:2015 §8 (configuration management) already requires a complete list of configuration items, including SOUP, with unique identifiers and versions.
  • A good SBOM follows naturally from that list. In Tibor's words, it is what the 62304 configuration list should have been all along.
  • SPDX and CycloneDX are the two dominant machine-readable SBOM formats. Either is acceptable. CycloneDX has stronger native support for vulnerability data.
  • The SBOM becomes useful only when it is wired into a CVE monitoring pipeline and regenerated on every software change under EN ISO 13485:2016+A11:2021 clause 7.3.9.

Why this matters now, not later

There was a stretch where European medical device teams could treat SBOMs as an American problem. The FDA pushed the concept hard, in 2023 it became part of pre-market submissions, and EU-focused startups assumed they had time. That assumption has closed. EN IEC 81001-5-1:2022 is the harmonised reference standard for health software security under the MDR, and its §4.4 (component analysis) and §9 (post-market plan) together define a requirement that functionally is an SBOM with CVE surveillance attached to it. MDCG 2019-16 Rev.1 points in the same direction when it describes the expected cybersecurity documentation.

The practical trigger for most startups is the surveillance audit. An auditor asks: show me the list of third-party components in your current release, with versions, and show me how you check them for vulnerabilities. If the answer is a hand-maintained spreadsheet last updated six months ago, the finding writes itself.

Tibor made the point plainly in his Round 2 interview. A good SBOM follows naturally from IEC 62304 configuration item lists. Libraries, SOUP components, versions, all tracked, updated on every software change. The SBOM is not a separate document. It is what the 62304 configuration item list should have been all along. That reframe is the single most useful thing a startup can take away. The SBOM is not new work. It is a cleaner, machine-readable version of work the standard already demanded.

What the standards actually require

MDR Annex I §17.2 requires software to be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, including information security, verification, and validation. §17.4 requires manufacturers to set out minimum requirements concerning IT security measures, including protection against unauthorised access.

EN 62304:2006+A1:2015 §8 (software configuration management) requires that configuration items are identified, that their versions are controlled, and that changes are traceable. §8.1.2 covers SOUP: the manufacturer must document the title, manufacturer, and unique identifier for each SOUP item, along with functional and performance requirements and the hardware and software items required for proper operation. That list, if it is actually complete and kept current, is already most of an SBOM.

EN IEC 81001-5-1:2022 §4.4 (component analysis) requires the manufacturer to identify and document the components of the software, including third-party components, and to establish and maintain information needed to analyse security properties. §5.2 (secure coding) and §5.4 (third-party components) extend the analysis to known vulnerabilities. §9 (post-market plan) expects ongoing monitoring for new vulnerabilities and timely response.

EN ISO 13485:2016+A11:2021 clause 7.3.9 ensures that whenever any of this changes, the change runs through design change control and the evidence is captured.

None of these clauses use the three-letter acronym SBOM. They do not need to. They describe the same thing in longer words.

SPDX and CycloneDX: pick one and move on

There are two dominant SBOM formats in the wild.

SPDX (Software Package Data Exchange) is an ISO/IEC standard (ISO/IEC 5962:2021). It originated in the Linux Foundation and is mature, widely tool-supported, and explicitly aimed at license and provenance information. SPDX 2.3 added support for security references but the native vulnerability integration is lighter than CycloneDX.

CycloneDX is an OWASP project aimed squarely at application security use cases. Its data model includes vulnerabilities, VEX (Vulnerability Exploitability eXchange) statements, and service dependencies. For a medical device team whose SBOM's primary purpose is CVE tracking, CycloneDX tends to be the faster path.

Both formats are acceptable to notified bodies. What matters is consistency. Pick one. Generate it automatically at build time. Store it alongside the release artefact in the configuration management repository. If a regulator or a customer later asks for the other format, conversion tools exist.

Felix's lean rule on format debates: spend fifteen minutes on the decision, not two weeks. The tooling is interchangeable. The discipline is not.

A worked example: building the SBOM for a Class IIb SaMD

Consider a Class IIb software-as-a-medical-device product. The build is a Python backend, a React frontend, and a small C++ inference module. Roughly 180 direct dependencies and about 900 transitive dependencies in total.

Step 1: generate the SBOM automatically in CI. The team adds CycloneDX generation to the build pipeline. Syft, cdxgen, or the native CycloneDX Maven, npm, and Python plugins emit one SBOM per build. The file is versioned alongside the release artefact. Manual SBOM maintenance is forbidden by the SOP. If it is not generated by the build, it does not count.

Step 2: reconcile with the EN 62304 configuration item list. The SBOM covers runtime and build dependencies automatically. The EN 62304 §8 configuration item list also covers items the tools miss: the operating system on the target device, the container base image, any firmware, any manually vendored code, and the build tools themselves where they affect the binary. The SOP says: the configuration item list is the superset. The SBOM is the machine-readable subset that covers third-party software. Discrepancies are reconciled at each release.

Step 3: attach a CVE feed. The SBOM is uploaded to a vulnerability scanner. Dependency-Track is the most common open-source option. Commercial alternatives exist. The scanner matches components against NVD and GitHub Advisory Database feeds and raises alerts when a CVE matches.

Step 4: triage pipeline. Each CVE alert becomes a software problem report under EN 62304 §6.2. A two-person triage (engineering plus quality) decides: is the affected function actually used, is the exploit relevant in this product's context, and what is the security risk reassessment under EN IEC 81001-5-1 §5.4? The triage decision is documented. If the decision is "not exploitable in our context", the rationale is VEX-encoded so the SBOM itself carries the justification forward.

Step 5: feed to patch management. Critical and high-severity findings flow into the patch management process described in the cybersecurity patch management post in this series. The SBOM is both the detector and the evidence source.

Step 6: release and retention. Each release stores its SBOM, its vulnerability scan result at release time, and its triage decisions. Two years later, when a regulator or a customer asks what was shipping in version 3.4.1 and what the known-unknowns were, the answer is one lookup away.

Tooling cost for the whole pipeline on an open-source stack: usually zero in licences, one to three engineering weeks to build out initially, and a few hours per month to maintain. Tibor's experience is that startups massively overestimate the cost of SBOM infrastructure and then underestimate the cost of not having one when the first CVE hits.

The Subtract to Ship playbook for SBOMs

1. Make the SBOM the EN 62304 configuration item list, not a second document. Write the SOP so that the SBOM is the authoritative machine-readable form and the configuration item list points to it. One source of truth. Less to maintain. Less to fall out of sync.

2. Generate it at build time or not at all. Manual SBOMs rot within weeks. Build-time generation is the only pattern Felix recommends to his cohort. If the build system cannot emit an SBOM, that is a tooling problem to fix, not a reason to fall back to spreadsheets.

3. Pick CycloneDX unless there is a specific reason to use SPDX. For cybersecurity use cases it is the lower-friction path. The tooling is mature and free.

4. Wire it to a CVE scanner on day one. An SBOM that nobody scans is a file that exists to pass audits, not to protect patients. Dependency-Track takes an afternoon to stand up.

5. Document the triage rule. When a CVE matches, who decides, how fast, and by what criteria? Put that in the SBOM governance SOP. A two-person rule (engineering and quality) is enough for most startups.

6. Keep historical SBOMs for every release. Retention aligned with the technical documentation retention obligation under MDR Article 10(8) (currently at least ten years after the last device is placed on the market, fifteen for implantables) is the safe default.

7. Use VEX to suppress noise without losing the audit trail. A VEX statement attached to the SBOM is how you say "this CVE is present in our dependency but is not exploitable in our product" with a documented rationale. It keeps the signal-to-noise ratio survivable as the dependency tree grows.

Reality Check

  1. Can you produce the current SBOM for your latest release in under sixty seconds, from the build artefact?
  2. Is the SBOM generated automatically by your build pipeline, or is it maintained by a human?
  3. Does your EN 62304 §8 configuration item list reconcile against the SBOM at every release, with the discrepancies documented?
  4. Is the SBOM scanned automatically against a CVE database, and who receives the alerts?
  5. When a CVE hits, do you have a documented triage process that feeds into software problem reports under EN 62304 §6.2?
  6. Can you recover the SBOM for a release from two years ago without archaeology?
  7. Does your post-market surveillance plan name the SBOM as a data source under MDR Articles 83 to 86?

Frequently Asked Questions

Is an SBOM formally required by the MDR? The MDR does not use the word SBOM. Annex I §17.2 and §17.4 require state-of-the-art software development and IT security measures. The harmonised standards, specifically EN 62304:2006+A1:2015 §8 and EN IEC 81001-5-1:2022 §4.4, require component-level visibility that in practice is an SBOM. Notified bodies increasingly ask for one by name.

What is the difference between an SBOM and the EN 62304 SOUP list? The SOUP list under §8.1.2 covers software of unknown provenance with title, manufacturer, and unique identifier. An SBOM covers the same components plus direct and transitive dependencies, in a machine-readable format with hashes, licenses, and vulnerability references. A full SBOM is a superset of a traditional SOUP list.

SPDX or CycloneDX, which one do notified bodies prefer? Neither in particular. Both are accepted. CycloneDX has stronger native support for vulnerability and VEX data, so for cybersecurity-driven use cases it is often the faster path. SPDX is an ISO standard and is strong on licensing metadata. Either is defensible.

Do we need to share our SBOM externally? Under MDR alone, no general obligation to publish. Hospital procurement, especially in Germany and the Nordics, increasingly asks for an SBOM as part of tender documentation. Under the US cybersecurity rules for devices sold into the FDA market, sharing is expected. Plan to be able to share on request.

How often do we regenerate the SBOM? At every build. The SBOM is a build artefact, not a release artefact. Build-time generation means the SBOM is always exact for the binaries that could ship.

Can we use AI tools to analyse our SBOM? Yes, for triage support and false-positive filtering, as long as the final decision is human and documented. AI-assisted triage speeds things up but does not replace the EN 62304 §6.2 software problem report process.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 10(8), Annex I §17.2, §17.4.
  2. EN 62304:2006+A1:2015, Medical device software, software lifecycle processes, §6.2, §8, §8.1.2.
  3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, §4.4, §5.2, §5.4, §9.
  4. EN ISO 13485:2016+A11:2021, Medical devices, Quality management systems, clause 7.3.9.
  5. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices.
  6. ISO/IEC 5962:2021, SPDX Specification V2.2.1.
  7. OWASP CycloneDX Specification, current version.