What is SOUP and how do I manage it under IEC 62304?
IEC 62304 §8.1.2 · AMD1:2015 §5.3 and §7.1.3
The short answer
SOUP stands for Software of Unknown Provenance. It is any software component that was not developed by you under a full IEC 62304-compliant lifecycle process. SOUP includes open-source libraries, commercial off-the-shelf components, operating systems, and AI/ML frameworks. SOUP management is one of the most common IEC 62304 audit finding areas.
What counts as SOUP
- Open-source libraries (React, numpy, pandas, OpenCV, scikit-learn)
- Commercial off-the-shelf software components (third-party SDKs, proprietary libraries)
- Operating systems (Linux, Windows, RTOS variants)
- AI/ML frameworks (TensorFlow, PyTorch, ONNX Runtime, Keras)
- Cloud SDKs and platform libraries (AWS SDK, Azure SDK)
- Database engines and ORMs
- Middleware and communication libraries
If a component was not developed by your organisation under your IEC 62304 processes — and you do not have full access to its development history and records — it is SOUP.
SOUP management activities by safety class
| Activity | Class A | Class B | Class C |
|---|---|---|---|
| Identify and list SOUP items | Required | Required | Required |
| Document known anomalies | Required | Required | Required |
| Evaluate SOUP performance in intended use | — | Required | Required |
| Document anomaly evaluation rationale | — | Required | Required |
| Evaluate SOUP development process | — | — | Required |
| Document requirements SOUP must satisfy | — | — | Required |
SOUP register contents
Your SOUP register should document for each SOUP item:
- Name and version: Exact version identifier (e.g. numpy 1.26.3, not just "numpy")
- Manufacturer / maintainer: Who develops and maintains the component
- Intended function in the device: What role does this SOUP play in your software system
- Software safety class of using item: The class of the software item that uses this SOUP
- Known anomalies evaluation: Review of known bugs, CVEs, and open issues; assessment of impact on your intended use
- Update history: Record of version upgrades and re-evaluation dates
SOUP change management
When a SOUP component version changes (e.g. security patch, major library upgrade):
- Update the SOUP register with the new version
- Re-evaluate known anomalies for the new version
- Assess impact on your software safety class determination
- Perform regression testing appropriate to the software class
- Update release records to reflect the SOUP version change
AI/ML frameworks as SOUP
AI and ML frameworks used in medical device software (TensorFlow, PyTorch, ONNX Runtime, etc.) are SOUP. They require the same SOUP management activities as any other third-party library.
The custom model architecture and training code developed by your team is a software item — not SOUP. It is developed software that must comply with the full IEC 62304 lifecycle requirements for its safety class.
Pre-trained model weights from a third party (e.g. a foundation model fine-tuned for your device) represent an additional SOUP-like component that should be explicitly documented and evaluated.
Frequently asked questions
Can I use open-source software in a medical device?
Yes. IEC 62304 does not prohibit open-source software. It does require that you manage open-source components as SOUP — document the version, evaluate known anomalies, and include in your SOUP register. For Class C software, you must also evaluate whether the open-source library's development process is adequate for your intended use.
Does every library need a SOUP register entry?
Yes — every third-party component that is part of your device software system requires a SOUP register entry. A common approach is to use your package manifest (package.json, requirements.txt, etc.) as the basis for the SOUP register, supplemented with the IEC 62304 required fields.
How many known anomalies is acceptable?
IEC 62304 does not impose a limit on the number of known anomalies. What is required is that you evaluate each anomaly (known bug or CVE) and document your assessment of its impact on your device's intended use. An open CVE with no code path to your device function can be documented as having no impact — the documentation of that assessment is what matters.
Should I pin SOUP versions?
Yes. Version pinning (specifying exact versions in your package manifest and build configuration) is strongly recommended. It ensures reproducible builds, enables accurate anomaly evaluation, and is required for your configuration management baseline under IEC 62304 §8.