ISO 14971 §5.4 hazard identification and IEC 62304 §5.3.3 SOUP anomaly evaluation — SOUP risk assessment applies the existing safety risk process to third-party component known anomalies.
IEC 62304 Class C SOUP requires enhanced anomaly review with version-specific CVE and errata searches; components contributing to safety-critical functions must be explicitly classified and documented with proportionate risk controls.
Version-specific anomaly review for safety-critical SOUP, ISO 14971 file integration, and vendor support adequacy — generic rationale without anomaly review fails IEC 62304.
Maps to
Pre-QMSR Part 820 (legacy QSR): §820.30(g) Design validation.
ISO 14971: §5.4 Identification of hazards and hazardous situations
IEC 62304: §5.3.3 Specify functional and performance requirements of soup item
Requirement text
The manufacturer shall evaluate the risk associated with each SOUP item, including assessment of known anomalies (published bugs, errata, known limitations) and their potential impact on the medical device software. The risk assessment shall consider the SOUP item's safety classification contribution, its known anomaly list, and the adequacy of documentation and community/vendor support.
Why this clause exists
Selecting a SOUP item based on reputation, community size, or general reliability is not the same as evaluating whether the specific version in use, with its specific known defects, introduces an unacceptable risk in the specific safety context where it is deployed. IEC 62304 section 5.3.3 establishes the anomaly-review obligation because safety-critical functions implemented through SOUP carry the risk of the SOUP item's own known failure modes into the device's safety profile — a bug in a cryptographic library fulfilling authentication requirements for access-controlled device functions is a different risk category than the same bug in a UI formatting utility. The vendor support adequacy evaluation exists to surface a frequently overlooked risk: an abandoned or community-maintained SOUP item with no active maintainer will not receive security patches for newly discovered vulnerabilities, converting it into a permanently accumulating risk source. This failure mode — a device's safety-critical function depending on an unmaintained library accumulating unaddressed CVEs — was observable in pre-2023 device field populations and is directly addressed by the requirement to evaluate support adequacy as a risk factor at the time of SOUP selection and at each review cycle.
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 risk assessment ignores known anomalies for specific versions — Risk assessments evaluate general risk ('is this a reputable library?') rather than reviewing specific known anomalies — published bugs, CVE entries, errata, and security advisories for the exact version in use. Safety-critical SOUP does not receive enhanced scrutiny.