MedTech Terms
    The authoritative reference
    All terms
    Software & AISoftware LifecycleSOUP

    Software of Unknown Provenance

    Software not developed for medical device use, or lacking adequate development records, incorporated into a device.

    Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed May 5, 2026

    Definition

    Per IEC 62304 clause 3.29, SOUP is 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 OTS - off-the-shelf software), or a software item previously developed for which adequate records of the development processes are not available. Common examples: operating systems, compilers, open-source libraries, third-party SDKs, and firmware components.
    What the regulation says
    Regulators view Software of Unknown Provenance (SOUP) as a critical component requiring stringent controls due to its potential impact on medical device safety and effectiveness. Standards like IEC 62304:2006+A1:2015, "Medical device software, Software life cycle processes," specifically address SOUP, outlining requirements for its identification, risk management, and documentation within the medical device software life cycle. The FDA also emphasizes the importance of managing off-the-shelf software, which includes SOUP, in its guidance documents regarding premarket submissions for medical devices.

    What this means in practice

    IEC 62304 clauses 5.3.3, 5.3.4, 7.1.2, and 7.1.3 impose specific obligations: identify the SOUP item (title, version, manufacturer), specify functional and performance requirements, document hardware and software requirements, evaluate anomaly lists published by the SOUP supplier, and address SOUP-related hazards in the risk file. FDA's 2023 Cybersecurity in Medical Devices guidance and Section 524B further require every SOUP component to appear in the SBOM (SPDX or CycloneDX), be monitored for vulnerabilities throughout the device lifecycle, and have a coordinated disclosure and patch plan. Notified Bodies routinely audit SOUP evaluation as part of QMS surveillance.

    Examples

    • Linux kernel in a bedside monitor: SOUP requiring version pinning, CVE monitoring, and hazard analysis of relied-upon kernel features.
    • OpenSSL used for TLS: SOUP that must be tracked in the SBOM with active vulnerability monitoring (Heartbleed-class risks).
    • A commercial DICOM library: SOUP with functional requirements documented against the vendor's release notes and known anomaly list.
    • A Python numerical library (NumPy) used in an image-analysis SaMD: SOUP requiring documented rationale for numerical accuracy in the intended clinical range.
    Common pitfalls
    • •Listing SOUP only in the SBOM but not evaluating anomaly lists or writing SOUP-specific requirements. IEC 62304 requires both.
    • •Treating an internally reused legacy component as 'in-house' when development records are inadequate - it is SOUP by definition.
    • •Not re-evaluating SOUP after a version bump. Any SOUP change triggers a change impact analysis under IEC 62304 clause 6.
    • •Missing SOUP in Class C software items where clause 5.3.4 requires additional performance requirements and hardware requirements to be specified.
    • •Assuming an FDA-cleared SOUP inherits regulatory status - it does not; the device manufacturer remains responsible.

    Frequently asked questions

    Almost always yes. Even if source is available, it typically was not developed for medical device use and lacks lifecycle records meeting IEC 62304. The exception is when the manufacturer takes it in-house and applies the full IEC 62304 process including retrospective evidence.

    Cross-references

    Used by

    Things that build on this term.

    Grouped by theme
    Cited by

    Where this term appears across MedTech Terms.

    Learning paths (2)
    Ecosystems (1)

    Primary references

    3 sources
    Link health: 3 verified· last checked 2026-06-20
    ISO·1FDA·1MDCG·1
    1. 1
      IEC 62304:2006/AMD1:2015
      Verified
      ISOiso.org
    2. 2
      FDA Cybersecurity in Medical Devices (2023)
      Verified
      FDAfda.gov
    3. 3
      MDCG Software Guidance
      Verified
      MDCGhealth.ec.europa.eu

    Inline markers like [1] jump to the matching reference above.