SOUP Management Under IEC 62304: A Complete Guide for Medical Device Software
Table of Contents
Introduction
SOUP management under IEC 62304 is one of the most underestimated — and most frequently audited — aspects of medical device software compliance. Almost every modern medical device software system relies on third-party components: open-source libraries, commercial operating systems, cloud APIs, cryptographic modules. Each one of these is SOUP, and each one requires a structured, documented management process throughout the entire software lifecycle.
This article is part of our ongoing series on IEC 62304 medical device software. If you haven’t read our foundational article on software safety classification and the Software Development Plan, we recommend starting there before diving into this topic.
What Is SOUP? Definition Under IEC 62304
SOUP stands for Software of Unknown Provenance. IEC 62304 defines it as any software item that:
- Was not developed specifically for the medical device being built, or
- Was previously developed, but adequate records of its development process are not available
In plain terms: if you did not write it yourself under a controlled IEC 62304-compliant process, it is SOUP.
Common examples of SOUP in medical device software include:
- Operating systems — Linux, Windows, Android, FreeRTOS
- Open-source libraries — OpenSSL, TensorFlow, NumPy, React
- Commercial off-the-shelf (COTS) software — database engines, communication stacks, UI frameworks
- Cloud service APIs — AWS, Azure, Google Cloud services
- Legacy software — previously developed internal code for which adequate development records no longer exist
It is worth noting that the FDA uses a slightly different term — Off-The-Shelf (OTS) software — but the underlying concept and regulatory expectations are substantially similar.
Figure 1: What counts as SOUP: classification diagram
Why SOUP Management Matters — The Regulatory and Safety Case
The use of SOUP is not prohibited under IEC 62304. In fact, it is expected and accepted — the standard recognizes that rebuilding every software component from scratch is neither practical nor economically viable. What the standard does require is that manufacturers demonstrate control over every SOUP component used in the device.
The rationale is straightforward: a failure in a SOUP component is a failure in the medical device software. If an open-source cryptographic library has a known vulnerability, or if a commercial operating system receives a breaking update, these events can directly impact patient safety. Without a structured SOUP management process, manufacturers have no mechanism to detect, assess, or respond to these risks.
From a regulatory standpoint, SOUP management is scrutinized closely during:
- FDA premarket submissions (510k, De Novo, PMA) — the FDA expects a documented SOUP list as part of the software documentation package
- CE marking under EU MDR 2017/745 — notified bodies routinely audit SOUP documentation during technical file review
- ISO 13485 audits — SOUP falls under software configuration management and supplier control obligations
Gaps in SOUP documentation are among the most common findings in regulatory audits and FDA warning letters related to software.
IEC 62304 Requirements for SOUP Management — Clause by Clause
IEC 62304 does not have a single dedicated “SOUP chapter” — instead, SOUP-related requirements are distributed across several clauses of the standard. Understanding which clause requires what is essential for building a compliant process.
Clause 5.3.3 — Functional and Performance Requirements for SOUP
For each SOUP item used in the software architecture, the manufacturer must specify the functional and performance requirements that the SOUP must fulfill within the medical device. This means defining what you expect the SOUP to do — not just noting that it exists.
Clause 5.3.4 — Hardware and Software Requirements of the SOUP Item
Manufacturers must identify the hardware and software environment in which each SOUP item is designed to operate, including dependencies on other software components, minimum hardware specifications, and operating environment assumptions.
Clause 5.3.5 — Segregation of SOUP
The standard requires identifying the level of segregation necessary to control the risk posed by each SOUP item. Higher-class software systems (Class B and C) may require architectural isolation of SOUP components to prevent failures from propagating to safety-critical functions.
Clause 5.5.4 — Evaluation of SOUP Anomalies
IEC 62304 requires manufacturers to evaluate known anomalies (bugs, defects, known issues) of each SOUP item and document whether those anomalies pose an unacceptable risk in the context of the medical device. This evaluation must be version-specific — the anomaly list for version 1.2.3 of a library is different from version 1.3.0.
Clause 6.1 — Maintenance of SOUP
The standard places ongoing obligations on manufacturers to monitor SOUP components throughout the product lifecycle, including tracking updates, security patches, and end-of-life announcements from vendors and open-source communities.
Clause 8 — Software Configuration Management
Every SOUP item must be brought under configuration control — meaning its name, version, supplier, and known anomalies must be documented and controlled as part of the overall software configuration management system.
Figure 2 — IEC 62304 clauses relevant to SOUP management
The SOUP Management Process — Step by Step
A compliant SOUP management process under IEC 62304 can be broken down into five core activities that span the entire software lifecycle.
Step 1 — Identification and Documentation
The first step is building a complete inventory of every SOUP component used in the software system. This inventory — commonly referred to as the SOUP List or, in modern terminology, the Software Bill of Materials (SBOM) — must capture for each item:
- Software name and version number
- Supplier or source (vendor, open-source repository, internal legacy system)
- Intended use within the medical device software
- Known anomalies list reference
- Safety class applicable to the SOUP item
This list must be version-controlled and updated whenever a SOUP component is added, updated, or removed.
Step 2 — Risk Assessment
For each identified SOUP item, a risk assessment must be performed in alignment with ISO 14971. The key questions to answer are:
- What could go wrong if this SOUP component fails or behaves unexpectedly?
- What is the severity of the potential harm to the patient, user, or third parties?
- Are there risk control measures in place (architectural isolation, runtime monitoring, redundancy) that reduce the risk to an acceptable level?
The safety class of the SOUP item is typically inherited from the safety class of the software system it belongs to — a SOUP component integrated into a Class C software system is generally treated as Class C, unless specific architectural segregation justifies a lower classification.
Step 3 — Verification and Validation
Unlike software developed under a controlled IEC 62304 process, SOUP components come without a pre-existing verification package. Manufacturers must therefore design and execute their own verification strategy for each SOUP item, demonstrating that it performs as required within the specific medical device context.
This typically includes:
- Integration testing to verify that the SOUP interacts correctly with the surrounding software
- Functional testing against the specified functional and performance requirements
- Review of the supplier’s publicly available test results, certifications, or quality documentation (where available)
- Static analysis of the SOUP’s known anomaly list against the device’s risk profile
Step 4 — Configuration Management and Change Control
Every SOUP item must be placed under formal configuration control. This means that any change to a SOUP component — including updates, patches, and version upgrades — must go through a defined change control process that includes:
- Impact assessment: does the new version introduce new anomalies or change behavior in safety-relevant ways?
- Re-verification: does the updated SOUP still meet its specified functional and performance requirements?
- Update to the SOUP list and SBOM
- Documentation of the decision to accept or reject the change
Step 5 — Ongoing Monitoring Throughout the Lifecycle
SOUP management does not end at product release. IEC 62304 requires manufacturers to continuously monitor SOUP components throughout the product’s commercial lifetime. This includes:
- Tracking security advisories and vulnerability disclosures from vendors and open-source communities
- Monitoring CVE (Common Vulnerabilities and Exposures) databases for newly discovered vulnerabilities in SOUP components
- Evaluating whether newly disclosed anomalies pose an unacceptable risk and initiating corrective actions when necessary
- Managing end-of-life (EOL) situations — when a SOUP component is no longer supported, the manufacturer must assess the impact and plan a migration strategy.
Figure 3 — The SOUP management lifecycle
SOUP and Cybersecurity — An Increasingly Critical Intersection
The intersection of SOUP management and cybersecurity has become one of the most important — and most regulated — areas in medical device software development. With the increasing connectivity of medical devices, SOUP components represent one of the largest attack surfaces available to malicious actors.
Regulatory bodies are responding accordingly. The FDA’s 2023 Cybersecurity Guidance for Medical Devices explicitly requires manufacturers to submit an SBOM as part of premarket submissions, enabling rapid identification of vulnerable components when new security threats emerge. The EU’s NIS-2 Directive and the Cyber Resilience Act (CRA) impose similar transparency obligations on software supply chains.
From an IEC 62304 perspective, cybersecurity-related SOUP management activities include:
Vulnerability monitoring: Manufacturers must continuously monitor the CVE (Common Vulnerabilities and Exposures) database and vendor security advisories for newly disclosed vulnerabilities in SOUP components. When a vulnerability is identified, a documented evaluation must determine whether it poses an unacceptable risk to the medical device and, if so, what corrective action is required.
Patch management: Security patches for SOUP components must be evaluated and applied through the formal change control process. The key challenge is balancing the urgency of security patching against the regulatory overhead of re-verification — a documented patch management procedure is essential.
Software Bill of Materials (SBOM): The SBOM is the practical tool that makes cybersecurity monitoring feasible at scale. Without a complete, up-to-date SBOM, it is impossible to know which SOUP components are affected when a new vulnerability is disclosed. Standardized SBOM formats — CycloneDX and SPDX — are increasingly required by regulators and should be adopted from the start of the project.
Supply chain security: Manufacturers must verify the integrity and authenticity of SOUP components obtained from external sources. This includes verifying checksums or digital signatures, using official distribution channels, and documenting supplier evaluation as part of the purchasing process under ISO 13485.
Figure 4 — Common SOUP management pitfalls
Common Pitfalls in SOUP Management — What Auditors Find
Based on typical regulatory audit findings, these are the most frequent failures in SOUP management under IEC 62304:
Incomplete SOUP identification: Many manufacturers document only the “obvious” SOUP components (the operating system, a major library) and overlook transitive dependencies — the libraries that their libraries depend on. A single npm or pip package can have dozens of transitive dependencies, each of which is technically SOUP.
Missing version specificity: Documenting “OpenSSL” as a SOUP component without specifying the exact version is not compliant. The anomaly list, the vulnerability profile, and the functional behavior of a SOUP component are all version-specific.
Lack of anomaly evaluation: Simply listing known anomalies is not sufficient — IEC 62304 requires a documented evaluation of each anomaly, explaining why it does or does not pose an unacceptable risk in the specific device context.
No post-market monitoring process: Many manufacturers treat SOUP management as a development-phase activity and fail to establish a process for monitoring SOUP components after product release. This is a significant compliance gap and a genuine patient safety risk.
SBOM not maintained: The SBOM must be a living document — updated every time a SOUP component changes. Static documents created at release and never updated are a common audit finding.
Best Practices for SOUP Management Under IEC 62304
To build a robust, audit-ready SOUP management process, manufacturers should consider the following best practices:
Start SOUP management at the architecture phase, not at the end of development. Every architectural decision to use a third-party component should immediately trigger the SOUP identification and risk assessment process. Retroactively documenting SOUP at the end of a development project is expensive, error-prone, and almost always results in compliance gaps.
Use automated Software Composition Analysis (SCA) tools to generate and maintain the SBOM. Tools such as FOSSA, Snyk, Black Duck, or open-source alternatives can automatically scan codebases and dependency files, identify all SOUP components including transitive dependencies, and flag known vulnerabilities in real time. Manual SBOM maintenance for large codebases is not scalable.
Adopt a standardized SBOM format from day one. CycloneDX and SPDX are the two most widely recognized formats and are explicitly referenced in FDA guidance. Using a standard format facilitates regulatory submissions and enables interoperability with vulnerability scanning tools.
Integrate SOUP anomaly evaluation into the risk management file. SOUP anomalies should not exist in a separate document — they should be traceable to the overall risk management file per ISO 14971, with explicit documentation of whether each anomaly has been assessed and whether it requires a risk control measure.
Establish a documented post-market SOUP monitoring procedure. This procedure should define who is responsible for monitoring, how frequently monitoring occurs, which sources are consulted (CVE database, vendor advisories, open-source security mailing lists), and what the decision criteria are for triggering a corrective action.
Define clear criteria for SOUP version updates. Not every new version of a SOUP component requires immediate action, but the decision to update or not must be documented. A simple decision matrix — based on severity of new anomalies, availability of fixes, and regulatory impact — makes this process manageable and auditable.
Conclusions
SOUP management under IEC 62304 is not a bureaucratic formality — it is one of the most practically impactful activities in medical device software development. Every third-party component integrated into a medical device is a potential source of safety failures and security vulnerabilities, and the standard’s requirements exist precisely to ensure that manufacturers maintain meaningful control over these risks throughout the entire product lifecycle.
The five-step process outlined in this article — identification, risk assessment, verification, configuration management, and ongoing monitoring — provides a practical framework for building a compliant and audit-ready SOUP management system. Combined with a well-maintained SBOM and a proactive cybersecurity monitoring process, it forms a robust foundation for long-term regulatory compliance.
As medical device software grows in complexity and connectivity, the importance of SOUP management will only increase. Manufacturers who invest in solid SOUP processes today will be better positioned for regulatory submissions, faster to respond to newly disclosed vulnerabilities, and ultimately better equipped to protect the patients who depend on their devices.
This article is part of our ongoing IEC 62304 series. Upcoming posts will cover software verification and validation requirements, cybersecurity risk assessment for medical device software, and post-market surveillance obligations under IEC 62304 and EU MDR.
