SOUP (Software of Unknown Provenance): IEC 62304 Compliance Guide for Medical Device Manufacturers

Why Every Medical Device with Software Uses SOUP

If your medical device contains software, it almost certainly uses Software of Unknown Provenance (SOUP). The operating system (Linux, Windows IoT, Android), hardware drivers, communication libraries (TCP/IP stacks), encryption modules, database engines, UI frameworks — all of these are SOUP. Even the code generated by your compiler contributes to SOUP items. You cannot build a modern medical device without it.

IEC 62304, the international standard for medical device software lifecycle processes, defines SOUP as "a software item that is already developed and generally available, and that has not been developed for the purpose of being incorporated into the medical device (also known as 'off-the-shelf software') or software previously developed for which adequate records of the development processes are not available."

The key word is "unknown." SOUP is not necessarily bad software. The Linux kernel, OpenSSL, and PostgreSQL are among the most thoroughly tested software components in existence. But from IEC 62304's perspective, they are unknown because they were not developed under your quality management system, and you cannot produce the complete development records that IEC 62304 would require for software you developed in-house.

This distinction drives the entire regulatory framework for SOUP management: you are responsible for ensuring the safety and effectiveness of your device, including every SOUP component within it, even though you did not develop those components. This guide explains how to meet that responsibility.

IEC 62304 Requirements for SOUP: Clause by Clause

IEC 62304 references SOUP requirements across several clauses. Understanding which clauses apply depends on your software safety classification (Class A, B, or C).

Clause 5.1.7 — Software Development Plan

Your Software Development Plan must identify all SOUP items planned for use in the device, including configuration and change management of SOUP items. This means your plan needs to name every third-party component, its version, and how you will manage changes to it.

Clause 5.3.3 — Software Requirements for SOUP

For each SOUP item, you must define functional and performance requirements that the SOUP must meet for its intended use within your device. This is not a description of what the SOUP does generally — it is a specification of what your device requires the SOUP to do in your specific application.

Clause 5.3.4 — SOUP Anomaly Evaluation

You must review known anomalies (bugs, vulnerabilities) in the SOUP item against your device's intended use. This involves:

• Reviewing the SOUP's published issue tracker, release notes, and vulnerability databases (e.g., CVE/NVD)
• Assessing whether any known anomaly could create a hazardous situation in your device
• Documenting the evaluation and its conclusions

Clause 5.3.6 — SOUP Verification

You must verify that the SOUP meets the requirements you defined in clause 5.3.3. This means testing the SOUP in the context of your device — not testing it in isolation. Verification activities include:

• Integration testing that exercises the SOUP through your device's interfaces
• Boundary value testing for inputs the SOUP will receive
• Stress testing under expected operating conditions
• Regression testing after SOUP version changes

Clause 7.1.2 and 7.1.3 — Risk Management for SOUP

SOUP items must be included in your software risk management process. Specifically:

• Clause 7.1.2: Identify potential hazardous situations that could arise from SOUP failures
• Clause 7.1.3: Evaluate the risk associated with each identified hazardous situation and implement risk control measures

This is where the safety classification becomes critical. A logging library used in a Class C device (where failure could cause death or serious injury) inherits that classification and requires a correspondingly thorough risk analysis.

Clause 8.1.2 — SOUP in Software Maintenance

During post-market maintenance, you must monitor SOUP items for new anomalies and security vulnerabilities. When a SOUP component is updated (whether by you or by the upstream maintainer), you must:

• Evaluate the impact of the change on your device
• Re-verify that the updated SOUP still meets your requirements
• Update risk management documentation if new risks are identified

Software Safety Classification and SOUP

IEC 62304 assigns one of three safety classes to each software system based on the potential for the software to contribute to a hazardous situation:

The Inheritance Principle

A SOUP item inherits the safety class of the software system it is part of. A logging library embedded inside a Class C drug dosage calculation engine is Class C by default. The only exception is demonstrated architectural segregation — proof through both architecture documentation and test evidence that the SOUP's failure cannot propagate to the safety-critical function.

Segregation claims are a consistent area of regulatory scrutiny. Auditors and notified bodies expect specific architectural mechanisms:

• Container isolation
• Memory protection
• Hardware partitioning
• Watchdog circuits
• Separate execution environments

A narrative statement of "logical separation" without corresponding test data will not hold up under a Class C audit.

The SOUP Assessment Process: Step by Step

Step 1: Identify All SOUP Components

Create a comprehensive SOUP inventory. For each component, document:

• Name and manufacturer
• Version number (exact, not "latest")
• Where it resides in your software architecture
• License type (open-source license, commercial license)
• Function within your device
• Whether it is directly or indirectly safety-related

Start with your build system's dependency list. For compiled languages, check your package manager (npm, pip, Maven, NuGet, Cargo). For embedded systems, review your board support package, RTOS, driver libraries, and toolchain outputs. Include transitive dependencies — a library that your dependency depends on is also SOUP that you must assess.

Step 2: Define Requirements for Each SOUP Item

For each SOUP component, document the specific requirements it must satisfy in your device. These requirements should cover:

• Functional requirements: What must the SOUP do in your application?
• Performance requirements: Throughput, latency, memory usage constraints
• Interface requirements: How does your code interact with the SOUP?
• Security requirements: What data does it handle? What protections must it provide?

This is the foundation of your verification strategy. If you cannot state what the SOUP is supposed to do, you cannot verify that it does it correctly.

Step 3: Conduct Risk Assessment

For each SOUP item, analyze the risks it introduces:

• What happens if the SOUP fails to meet its requirements?
• Could the failure create a hazardous situation?
• What is the severity of the potential harm?
• Are there known anomalies that could contribute to the hazardous situation?

Document this analysis in your software risk management file. The analysis should link to your overall device risk management per ISO 14971.

Step 4: Implement Risk Control Measures

Based on the risk assessment, implement controls:

• Architectural segregation: Isolate the SOUP from safety-critical functions so its failure cannot propagate
• Input validation: Validate all data passed to and from the SOUP
• Monitoring: Implement runtime monitoring (watchdogs, health checks) to detect SOUP failures
• Redundancy: For critical functions, implement redundant mechanisms that do not rely on the same SOUP
• Configuration hardening: Disable unused features in the SOUP to reduce the attack surface

Step 5: Verify SOUP Operation

Design and execute verification tests that demonstrate each SOUP item meets its requirements in the context of your device:

• Integration tests that exercise the SOUP through your device's interfaces
• Boundary value tests for edge cases the SOUP will encounter
• Stress tests under expected operating conditions
• Security tests for SOUP components that handle sensitive data or communications

Step 6: Document Everything

Your SOUP documentation should include:

• SOUP inventory list
• Requirements specification for each SOUP item
• Risk analysis for each SOUP item
• Verification test protocols and results
• Anomaly evaluation records (including CVE review results)
• Justification for use (why this SOUP was selected)
• Version history and change log

SOUP vs. OTS vs. COTS: What Is the Difference?

The terms are largely interchangeable in regulatory contexts, but the distinctions matter for communication:

All of these are SOUP from IEC 62304's perspective. The FDA uses "OTS Software" in its guidance documents, but the assessment requirements are the same. Your documentation should use IEC 62304 terminology (SOUP) when complying with that standard and FDA terminology (OTS) when responding to FDA expectations.

Common SOUP Examples in Medical Devices

Open-Source Software as SOUP

Open-source software (OSS) presents both advantages and challenges as SOUP in medical devices.

Advantages

• Transparency: Source code is available for review, unlike proprietary COTS where you rely solely on the vendor's documentation
• Community scrutiny: Widely used OSS projects are reviewed by thousands of developers, which can identify vulnerabilities faster than proprietary alternatives
• No vendor dependency: You can maintain the software yourself if the original maintainer abandons the project
• Cost: No licensing fees reduce development costs

Challenges

• No guaranteed support: If a critical vulnerability is discovered, you cannot demand a fix — you must either wait for the community or fix it yourself
• License compliance: Open-source licenses (GPL, LGPL, Apache, MIT, BSD) have different requirements regarding attribution, source code distribution, and derivative works. Non-compliance can create legal liability
• Quality variability: Not all open-source projects maintain the same level of testing and documentation
• Cybersecurity: Publicly available source code means attackers can also review it for vulnerabilities

Best Practices for Open-Source SOUP

1. Prefer actively maintained projects with regular releases, responsive maintainers, and a large user base
2. Review the project's security practices — do they have a security policy, CVE reporting mechanism, and timely patches?
3. Pin exact versions in your build configuration and update only after verification
4. Monitor CVE databases (NVD, GitHub Advisory Database) for vulnerabilities in your SOUP components
5. Minimize the libraries you use — prefer small, focused libraries over large frameworks with many unused functions
6. Maintain a Software Bill of Materials (SBOM) that lists every OSS component, its version, and its license

SOUP and Cybersecurity

Cybersecurity requirements for medical devices have intensified significantly. FDA's Section 524B of the FD&C Act requires manufacturers to implement cybersecurity controls for connected devices, including maintaining a Software Bill of Materials. The EU Cyber Resilience Act and NIS2 Directive add similar expectations for the European market.

For SOUP management, this means:

• SBOM generation: You must be able to produce a complete, machine-readable SBOM listing all software components (including SOUP) in your device
• Vulnerability monitoring: Continuous monitoring of CVE databases for vulnerabilities in your SOUP components
• Patch management: A defined process for evaluating and deploying SOUP security patches
• Vulnerability disclosure: A coordinated vulnerability disclosure policy for reporting issues found in SOUP used in your device

The intersection of IEC 62304 SOUP requirements and cybersecurity regulations means that SOUP management is no longer just a software lifecycle concern — it is a patient safety and regulatory compliance imperative.

Can Software Be "Not SOUP"?

Yes. Software is not SOUP if it was developed entirely under your quality management system, following IEC 62304 lifecycle processes, with complete development records available. Additionally, some third-party software has been pre-certified to IEC 62304 — for example, BlackBerry's QNX OS for Safety has been pre-certified to IEC 62304 Class C. Pre-certified software may not meet the definition of SOUP if the certification provides the development records that IEC 62304 requires.

However, the team-NB FAQ for EN 62304 clarifies an important point: nothing prevents a manufacturer from declaring all their software to be SOUP, provided it meets the definition. And doing so is not necessarily less work — in some cases, the verification and documentation burden for SOUP may exceed what would have been required for software developed under IEC 62304 processes.

Post-Market SOUP Management

SOUP management does not end at product release. IEC 62304 Clause 8 and post-market surveillance requirements under FDA and EU MDR require ongoing monitoring.

Ongoing Activities

• Monitor upstream releases: Track new versions of each SOUP component for bug fixes, security patches, and breaking changes
• Review CVE databases: Check NVD, GitHub Security Advisories, and vendor security bulletins for vulnerabilities in your SOUP
• Evaluate impact: When a new vulnerability or bug is identified, assess whether it affects your device's safety or effectiveness
• Deploy patches: When a risk is identified, deploy patches through your change control process
• Re-verify: After any SOUP update, re-verify that the device still meets its requirements

Frequency

• Critical vulnerabilities: Immediate assessment and patching (within days)
• Regular monitoring: Monthly review of CVE databases and upstream release notes
• Scheduled updates: Quarterly or semi-annual updates for non-critical changes
• Full reassessment: Annual comprehensive review of all SOUP components

SOUP Documentation Checklist

Use this checklist to ensure your SOUP documentation is audit-ready:

• SOUP inventory list with name, version, manufacturer, and license for each component
• Architecture diagram showing where each SOUP item resides in the system
• Requirements specification for each SOUP item (what it must do in your device)
• Anomaly evaluation record for each SOUP item (review of known bugs and CVEs)
• Risk analysis for each SOUP item (what happens if it fails)
• Risk control measures implemented for SOUP-related risks
• Verification test protocols and results for each SOUP item
• Justification for use (why this SOUP was selected over alternatives)
• SBOM (Software Bill of Materials) in machine-readable format
• License compliance documentation for all open-source SOUP
• Post-market surveillance plan for ongoing SOUP monitoring
• Change control records for all SOUP version updates

Key Takeaways

1. You cannot avoid SOUP — even your compiler generates SOUP items. The question is not whether you use SOUP, but how well you manage it.
2. SOUP inherits the safety class of the software system it is part of. A logging library in a Class C system is Class C unless you can demonstrate architectural segregation.
3. IEC 62304 requires the same activities for SOUP as for your own software, except for detailed development (Clause 5.4) and coding (Clause 5.5). This is not a shortcut.
4. Document everything — your SOUP inventory, requirements, risk analysis, verification results, and anomaly evaluations must all be traceable and audit-ready.
5. Cybersecurity regulations now overlap with SOUP management through SBOM requirements and vulnerability monitoring mandates.
6. Post-market SOUP management is mandatory. You must monitor for new vulnerabilities and bugs throughout the device's lifetime.
7. Prefer actively maintained, well-documented open-source software over obscure or abandoned projects — your post-market surveillance depends on the SOUP maintainer's ongoing activity.