IEC 62304 §5.3.3-5.3.4 SOUP identification and specification requirements — component name, version, and supplier tracking is a long-standing IEC 62304 obligation formalized here.
§524B SBOM submission requirements elevate SOUP documentation to a premarket deliverable; functional and performance requirements must be explicitly documented for each component, including significant transitive dependencies.
Documented functional requirements per SOUP item, transitive dependency coverage, and automated generation from build artifacts — manual lists diverging from deployed software are a gap.
Maps to
ISO 13485: §7.4.1 Purchasing process
Pre-QMSR Part 820 (legacy QSR): §820.50 Purchasing controls.
IEC 62304: §5.3.3 Specify functional and performance requirements of soup item, §5.3.4 Specify system hardware and software required by soup item
Requirement text
The manufacturer shall identify all Software of Unknown Provenance (SOUP) items used in the medical device software and document their functional and performance requirements. For each SOUP item, the manufacturer shall specify the title, version, manufacturer, and the requirements that the SOUP item is expected to fulfill in the context of the medical device software.
Why this clause exists
Software that is not enumerated cannot be evaluated — and in the medical device context, a third-party library whose functional requirements are undocumented cannot be verified or validated as performing its intended role in the device software correctly or safely. IEC 62304 sections 5.3.3 and 5.3.4 establish the SOUP identification and specification obligation because the alternative — treating all incorporated third-party software as a black box with unspecified requirements — severs the traceability chain from safety-critical functions to the components implementing them. When a safety-relevant function depends on a specific SOUP item's behavior, the absence of documented functional requirements means no defined basis exists for evaluating whether that SOUP item is acceptable for its role or whether a new version remains acceptable after an update. The transitive-dependency requirement reflects the structural reality that a directly-used library that itself depends on a poorly-maintained library carries security and quality risk through that indirect chain — limiting SOUP documentation to direct dependencies provides a false picture of the software composition, as demonstrated repeatedly by supply-chain incidents where compromised transitive dependencies were invisible to component owners.
What changed
The FDA's September 2023 final guidance replaced the October 2014 draft and represented a fundamental shift from voluntary best practices to mandatory, enforceable requirements backed by Section 524B of the FD&C Act (added by FDORA, enacted December 29, 2022), which became effective March 29, 2023. FDA's transitional non-enforcement policy ended October 1, 2023; submissions received after that date missing required cybersecurity documentation receive Refuse to Accept (RTA) letters.
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. Manufacturers must submit: a plan for postmarket vulnerability monitoring and patching, evidence of secure development processes (SPDF), and a machine-readable SBOM in SPDX or CycloneDX format including transitive dependencies and end-of-support dates.
FDA can now refuse to accept (RTA) premarket submissions lacking adequate cybersecurity documentation. Since October 2023, there has been a 700% increase in cybersecurity-related deficiency letters, with an average of 15 deficiencies per letter when cybersecurity is cited. Threat modeling deficiencies appear in a majority of these letters. The SBOM requirement goes significantly beyond the 2014 guidance — binary analysis is expected to find hidden components, and SBOMs must be continuously maintained, not static snapshots.
Common gaps (what we see in audits)
- SOUP list missing functional requirements and transitive dependencies — Manufacturers maintain component lists (name, version) but fail to document functional and performance requirements each SOUP item must fulfill per IEC 62304 5.3.3-5.3.4. Transitive dependencies and firmware-level SOUP are routinely omitted. The list diverges from deployed software because it is manually maintained.