SOUP (Software of Unknown Provenance) and OTS (Off-The-Shelf) software are the third-party code inside every modern medical device — operating systems, cryptographic libraries, web frameworks, database engines, open source packages, vendor SDKs. EN 62304:2006+A1:2015 defines SOUP in Section 3.29 and requires, through Sections 5.3, 7, and 8, that each SOUP item be identified, have requirements assigned, be analysed for contribution to hazardous situations, be placed under configuration management, and be monitored for anomalies and security issues throughout the lifecycle. EN IEC 81001-5-1:2022 layers the cybersecurity lifecycle for third-party components on top of that, and MDR Annex I Section 17 is the legal requirement that makes both standards binding. You cannot avoid SOUP. You can only control it.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • SOUP is defined in EN 62304:2006+A1:2015 Section 3.29 as a software item already developed and generally available, not developed for the purpose of being incorporated into a medical device, or software previously developed for which adequate records of the development processes are not available.
  • OTS software is the everyday term for the same concept — the operating system, the database, the libraries, the frameworks the team did not write.
  • EN 62304:2006+A1:2015 Section 5.3 requires that each SOUP item have functional and performance requirements, and that the hardware and software environment required by the SOUP be specified.
  • Sections 7 and 8 require that each SOUP item be placed under software risk management and software configuration management, with identification, version control, and monitoring for published anomalies.
  • EN IEC 81001-5-1:2022 requires the cybersecurity lifecycle to cover third-party components: identification, vulnerability monitoring, patching, and end-of-support planning.
  • MDR Annex I Section 17.2 requires software to be developed under the state of the art including risk management and information security; Section 17.4 requires minimum requirements for hardware, IT networks, and cybersecurity measures to be set out.
  • A Software Bill of Materials (SBOM) is the operational backbone of SOUP control. Without an SBOM you cannot demonstrate the lifecycle activities the standards require.
  • Picking SOUP well is a design decision. Picking SOUP badly is a technical file liability that compounds over every release.

Why SOUP is the category every founder underestimates

Every medical software startup we work with has SOUP. All of them. The ones that think they do not have SOUP have not looked at their dependency tree. The operating system is SOUP. The TLS library is SOUP. The HTTP framework is SOUP. The image decoder, the JSON parser, the logging library, the database driver, the machine learning runtime, the cloud SDK — SOUP. The typical modern medical software product is ninety-plus percent SOUP by line count and five to ten percent first-party code. That ratio is not a bug. It is how modern software is built, and the MDR does not ask you to stop. It asks you to control what you have pulled in.

The reason founders underestimate SOUP is that most of it never appears in the conscious design conversation. The team picks a web framework because it is what they know. They add a library to parse DICOM because writing one from scratch would take a year. They pull in a dependency for authentication because the alternative is writing cryptography themselves. Each of those decisions is individually sensible. Collectively they form a supply chain the team has never audited, versioned explicitly, or mapped against the hazards the device could contribute to. The first time someone forces that conversation is usually the first Notified Body audit, and by then the supply chain has been growing unmanaged for two or three years.

The cost of that late conversation is a reconstruction project. The team has to walk the dependency tree, assign each item an identifier, write functional requirements for software someone else wrote, run a retrospective risk analysis against hazards that were never considered at selection time, and document a configuration management approach for code that has been updated informally through npm install and pip install --upgrade. It is doable. It is never cheap. And it is never as convincing to the auditor as a file that has been kept in-flight from the first dependency the team added.

What EN 62304:2006+A1:2015 actually requires for SOUP

EN 62304:2006+A1:2015 treats SOUP as a first-class concept throughout the standard. The definition in Section 3.29 is the starting point — a software item already developed and generally available, not developed for the purpose of being incorporated into the medical device, or a previously developed software item for which adequate records of the development processes are not available. That definition captures both the commercial off-the-shelf component (Microsoft Windows, Oracle, a cloud SDK) and the open source library the team pulled from GitHub at midnight.

Section 5.3 — software requirements analysis — is where SOUP first appears in the lifecycle. The standard requires the manufacturer to specify functional and performance requirements for each SOUP item, and to specify the system hardware and software required by the SOUP item. The point is not that the manufacturer has to re-document the upstream project. The point is that the manufacturer has to decide — and record — what the SOUP is being used for in this specific device, what behaviour the device depends on, and what operating environment the SOUP requires to behave that way. "We use library X for Y, at version Z, running on platform W, and we depend on the following behaviours" is the content.

Section 7 — software risk management — requires that each SOUP item be analysed for its potential contribution to hazardous situations. The manufacturer identifies the software items, including SOUP, that could contribute to a hazardous situation identified in the EN ISO 14971:2019+A11:2021 risk file, evaluates the potential causes of that contribution (including failure of the SOUP item, unexpected results, incorrect inputs, and unexpected behaviours), and specifies risk control measures either inside the SOUP, around the SOUP, or in the supporting software that wraps it. A SOUP item that cannot cause a hazardous situation in the device is identified but does not need the deep analysis. A SOUP item that can — and many can, directly or indirectly — has to have a documented risk analysis and controls.

Section 8 — software configuration management — requires that each SOUP item be placed under configuration management with an identifier, a version, a designation of the supplier, and a record of the specific version actually used in each release of the device software. The standard also requires that the manufacturer evaluate published anomalies in SOUP items, specifically those that could affect the medical device, and feed relevant findings into the problem resolution process under Section 9. The monitoring obligation is ongoing — it does not end at release.

Read together, Sections 5.3, 7, and 8 say: know what SOUP you have, know what you use it for, know how it can hurt the patient, control its version, and keep watching it after release. That is the legal content of SOUP management under EN 62304:2006+A1:2015.

EN IEC 81001-5-1:2022 and the cybersecurity layer

EN 62304:2006+A1:2015 covers SOUP from the safety-of-the-software angle. It does not fully cover the cybersecurity supply chain. That is where EN IEC 81001-5-1:2022 comes in.

EN IEC 81001-5-1:2022 is the harmonised standard for the cybersecurity lifecycle of health software and health IT systems, and it applies to MDR Annex I Section 17.2 (development under the state of the art including information security) and Section 17.4 (minimum requirements for hardware, IT networks, and cybersecurity measures). The standard requires that the manufacturer identify third-party components used in the product, monitor them for published vulnerabilities throughout the lifecycle, have a documented process for evaluating and remediating vulnerabilities, plan for end-of-support of third-party components, and communicate relevant information to the operator of the device.

In practice, EN IEC 81001-5-1:2022 turns the SOUP list from a configuration management artefact into a live security feed. Every SOUP item on the list has to be cross-referenced against public vulnerability sources (CVE databases, vendor advisories, distribution security lists) on a defined cadence. New vulnerabilities that affect the device trigger a risk evaluation and, where needed, a patch or a compensating control. The process has to be documented, running, and audited — not a policy in a binder.

MDCG 2019-16 Rev.1 is the interpretive guidance that sits alongside EN IEC 81001-5-1:2022 for MDR cybersecurity. It is worth reading end-to-end, but the single most important paragraph for SOUP is the one that makes clear the manufacturer cannot transfer cybersecurity responsibility to the upstream project. The open source library is not the manufacturer of the medical device. The company shipping the CE-marked device is. Which means every cybersecurity obligation for every dependency eventually lands on the manufacturer's desk, and the process the manufacturer has built is how those obligations get met.

The SBOM — what it is and why the lifecycle depends on it

A Software Bill of Materials (SBOM) is a formal, machine-readable list of every software component in the product, including version, supplier, and dependency relationships. SBOMs can be expressed in formats like SPDX or CycloneDX. They are generated by tooling that walks the build, not by humans typing names into spreadsheets.

The SBOM is not explicitly named in EN 62304:2006+A1:2015 — the standard pre-dates the term in its current form — but the Section 8 configuration management obligations for SOUP and the Section 5.3 environment specification obligations cannot be satisfied at scale without something that looks exactly like an SBOM. EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 explicitly expect a component inventory that is current, complete, and linked to vulnerability monitoring. The SBOM is the operational form that inventory takes.

The SBOM is also the bridge between the engineering practice and the regulatory file. Engineering generates the SBOM from the build. The regulatory file references the SBOM as the SOUP inventory. The vulnerability monitoring process queries the SBOM against CVE sources. The configuration management record pins the SBOM to the release. The risk management file references SOUP items by their SBOM identifiers. One artefact, many regulatory jobs. A product without a live SBOM will eventually reconstruct one under audit pressure, and reconstruction is always more expensive than generation from the build.

Integrating SOUP into the risk management file

The SOUP risk analysis is a subset of the EN ISO 14971:2019+A11:2021 risk management file, not a parallel document. The integration is what the Notified Body will look for.

The pattern that works. The ISO 14971 process identifies hazards and hazardous situations for the device. The software risk management process under EN 62304:2006+A1:2015 Section 7 identifies which software items — first-party and SOUP — contribute to those hazardous situations. For each contributing SOUP item, the file records the possible failure modes (crash, wrong output, silent corruption, resource exhaustion, security compromise), the mitigations inside or around the SOUP (input validation, output checking, sandboxing, version pinning, monitoring), and the residual risk. The residual risk feeds back into the ISO 14971 evaluation.

The pattern that fails. A separate "SOUP risk assessment" document that lists every dependency with a generic risk level and no connection to the device hazards. Auditors can spot this in minutes. It has the appearance of rigour and none of the substance.

Change control for SOUP — updating without breaking the file

SOUP changes constantly. Upstream projects release new versions, ship security patches, deprecate APIs, and occasionally disappear. The manufacturer's configuration management and change control processes have to handle all of that without forcing a full lifecycle re-run every time a minor version bumps.

The mechanism the standard supports is a classified change control. Trivial changes (patch versions with only security fixes in unrelated modules) can go through a lightweight evaluation and be recorded. Substantive changes (new minor or major versions, API changes, behaviour changes in functions the device uses) require a full evaluation including requirements impact, risk impact, verification impact, and a regression test plan. Changes that alter intended use or safety behaviour trigger the change-to-the-device analysis under MDCG guidance.

The practical move is to pin SOUP versions exactly in the build, not to float them. A lock file that specifies the exact version of every dependency at every depth of the tree is the engineering expression of configuration management for SOUP. "We always use the latest" is not a strategy the standard accepts, because it means the version actually shipped is unknown until it ships.

Common mistakes

  • Not maintaining an SBOM at all. If you cannot produce the SOUP list on demand, you are not running the process. This is the single most common finding.
  • Treating the OS as "not SOUP." The operating system is SOUP. So is the container runtime. So is the cloud platform where the workload runs. Each one has to be in the inventory, in the risk analysis, and in the vulnerability monitoring.
  • Floating dependency versions in production. Unpinned dependencies mean the version shipped is unknown. Pin everything. Update deliberately.
  • Copying generic SOUP risk templates. A generic risk entry ("the library could fail, mitigation: use reliable library") is not a risk analysis. It is a placeholder the auditor will flag.
  • Ignoring the vulnerability feed after release. Post-market cybersecurity is a live process. A SOUP inventory that was valid at release and has not been updated since is not a running process — it is a snapshot.
  • Picking heavy SOUP for convenience, then inheriting its risk. Pulling in a 500-dependency framework to save an afternoon of first-party code adds 499 things to monitor. The decision has to be made consciously, not by default.
  • Separating "open source" from "commercial" SOUP in the process. Both are SOUP under EN 62304:2006+A1:2015. The lifecycle activities are the same. The difference is who the supplier is and how you monitor them, not whether the obligations apply.

The Subtract to Ship angle

SOUP is a category where Subtract to Ship cuts in two directions at once. The first direction is the obvious one: fewer SOUP items means less regulatory work. Every dependency in the tree is another thing to identify, requirements-specify, risk-analyse, configuration-manage, and vulnerability-monitor. The tenth dependency costs ten times as much to keep as the first one, because the process has to run across all of them. Adding a SOUP item for convenience, without a real need, is the opposite of subtraction — it is adding permanent process load to save a day of engineering.

The second direction is less obvious and more important: narrow the scope of the medical module so that most of the dependency tree is outside it. If the product has a clear architectural boundary between the regulated medical component and the surrounding non-medical infrastructure, only the SOUP inside the regulated boundary is subject to the full EN 62304:2006+A1:2015 treatment. The surrounding infrastructure still has to be secure and well-run, but the lifecycle weight is much lower. This is the same subtraction move we apply across the software lifecycle (see post 376) — scope the regulated module narrowly, keep the regulated code base small, and the SOUP that needs full treatment shrinks with it.

Every SOUP item that survives this subtraction has to trace to a specific use in the device, a specific requirement in Section 5.3, a specific risk entry under Section 7, a specific configuration record under Section 8, and (if it has network exposure or handles sensitive data) a specific cybersecurity evaluation under EN IEC 81001-5-1:2022. Items that cannot trace that way come out of the dependency tree before the lifecycle starts, not after the audit. For the broader framework, see post 065.

Reality Check — Is your SOUP process audit-ready?

  1. Can you produce an SBOM for the current release of your device software within a few minutes, from the build system — not from a hand-maintained spreadsheet?
  2. Is every SOUP item in the SBOM linked to a documented use in the device, with functional and performance requirements under EN 62304:2006+A1:2015 Section 5.3?
  3. Have the SOUP items that could contribute to a hazardous situation been identified in the EN ISO 14971:2019+A11:2021 risk file, with specific failure modes and mitigations, under EN 62304:2006+A1:2015 Section 7?
  4. Are all SOUP versions pinned in the build, and is the exact SOUP configuration of each release reproducible from the configuration management record under EN 62304:2006+A1:2015 Section 8?
  5. Do you have a running vulnerability monitoring process for every SOUP item in the SBOM, aligned with EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1?
  6. Do you have a change control process that classifies SOUP updates by impact and runs the appropriate level of re-verification?
  7. Do you have an end-of-support plan for SOUP items whose upstream projects could be deprecated or abandoned during the device lifecycle?
  8. Is the SOUP lifecycle work integrated into the engineering team's daily practice, or is it a separate regulatory activity run after the fact?

Any question you cannot answer with a clear yes is a gap between current practice and what the Notified Body will want to see, and the gap will only grow as the dependency tree grows.

Frequently Asked Questions

What is the difference between SOUP and OTS software? In practice, nothing. OTS (Off-The-Shelf) is the everyday engineering term. SOUP (Software of Unknown Provenance) is the formal term defined in EN 62304:2006+A1:2015 Section 3.29. The standard uses SOUP as the defined concept, so regulatory documentation uses SOUP. The two terms cover the same set of third-party components — operating systems, libraries, frameworks, databases, SDKs, open source packages — anything the manufacturer did not develop under its own lifecycle.

Is open source software automatically SOUP? Yes, unless the manufacturer has brought the open source component under its own full EN 62304:2006+A1:2015 lifecycle — which is almost never practical and almost never done. In every real case we have seen, open source components are treated as SOUP. The license being open does not mean the development records meet the standard's definition of "adequate records." It means the code is inspectable, which is useful for risk analysis but does not change the SOUP status.

Do I need an SBOM to comply with EN 62304:2006+A1:2015? The standard does not use the term SBOM, but it requires a SOUP inventory with identifiers, versions, and suppliers (Section 8) that is kept current and linked to the risk management and problem resolution processes. An SBOM generated from the build is the practical form this inventory takes in a modern development environment. EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 also expect a component inventory for cybersecurity monitoring. If you do not call it an SBOM, you still have to have one.

How do I handle a SOUP item that becomes vulnerable after release? The process is: the vulnerability monitoring under EN IEC 81001-5-1:2022 detects it, the risk management process under EN 62304:2006+A1:2015 Section 7 and EN ISO 14971:2019+A11:2021 evaluates whether it affects the device, the problem resolution process under Section 9 decides whether a patch, a compensating control, or a communication to users is required, and the change is rolled out under configuration management. If the vulnerability rises to the level of a field safety issue, MDR vigilance obligations under Articles 87-92 also apply. The process has to exist and be running, not be invented at the moment the CVE lands.

Can I use a large open source framework if it has hundreds of transitive dependencies? You can, but every transitive dependency is still SOUP under EN 62304:2006+A1:2015. You cannot hide them behind the top-level framework. The SBOM walks the full tree, and the configuration management, risk analysis (for items that can contribute to hazardous situations), and vulnerability monitoring obligations apply to the whole tree. The practical consequence is that heavy frameworks carry a regulatory cost proportional to their dependency tree, and a lighter framework is often the cheaper regulatory choice even if the upfront engineering work is slightly larger.

What happens if a SOUP supplier stops maintaining the component? EN IEC 81001-5-1:2022 requires an end-of-support plan. The manufacturer has to have a strategy: migrate to a supported alternative, fork and maintain internally (which ends the SOUP status and brings the code under the manufacturer's full lifecycle), remove the functionality, or retire the device. Ignoring the end-of-support is not an option — an unmaintained SOUP item on a live device becomes a cybersecurity liability the moment the next relevant vulnerability lands.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17 (software and electronic programmable systems), including Section 17.2 and Section 17.4. Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Sections 3.29 (SOUP definition), 5.3 (software requirements analysis, SOUP requirements), 7 (software risk management), 8 (software configuration management).
  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 (IEC 81001-5-1:2021).
  4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.
  5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  6. MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for medical devices. December 2019; Rev.1 July 2020.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the third-party software components that make up the majority of every modern medical device software stack. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 and EN IEC 81001-5-1:2022 are the harmonised tools that provide presumption of conformity with the software-lifecycle and cybersecurity aspects of MDR Annex I Section 17, not independent authorities. For startup-specific regulatory support on SOUP management, SBOM generation, and cybersecurity lifecycle implementation, Zechmeister Strategic Solutions is where this work is done in practice.