IEC 62304 software problem resolution and existing functional testing activities for component and system behavior.
Five required test categories: abuse case and fuzz testing, attack surface analysis, closed-box vulnerability scanning, SCA on release binaries with SBOM comparison, and dynamic security testing.
Vulnerability test reports covering all five categories per release — automated scanning alone without fuzz testing and manual attack surface analysis does not satisfy 5.7.3.
Maps to
IEC 81001-5-1: §5.7.3 VULNERABILITY testing
Requirement text
The manufacturer shall establish an activity (or activities) for performing tests that focus on identifying and characterizing potential security vulnerabilities in the health software. Known vulnerability testing shall be based upon, at a minimum, recent contents of an established, industry-recognized, public source for known vulnerabilities. Testing shall include: a) abuse case/fuzz/network traffic testing on all external interfaces and protocols; b) attack surface testing (ingress/egress, weak ACLs, exposed ports, elevated privileges); c) closed-box known vulnerability scanning of hardware, host, interfaces, or software items; d) software composition analysis on all binary executable files including embedded firmware (known CVEs, vulnerable libraries, security rule violations, compiler settings, SBOM comparison); and e) dynamic security testing (fuzz, DoS, memory leaks, shared memory access without authentication) — shall be applied if tools are available.
Why this clause exists
Vulnerability testing — systematic examination of the software and its dependencies for known and novel vulnerabilities — operates in the space between requirements-based testing and adversarial penetration testing. Requirements testing verifies that specified controls work; penetration testing attacks the system as an adversary would; vulnerability testing systematically identifies weaknesses that may not have been specified as requirements at all — vulnerabilities introduced by third-party components, implementation errors that static analysis missed, or configuration weaknesses in the deployment environment. IEC 81001-5-1:2021 clause 5.7.3 requires vulnerability testing as a distinct activity from requirements testing and penetration testing, using methods such as dynamic analysis and fuzz testing that exercise the system with unexpected inputs and execution paths. DAST tools and fuzz testing discover vulnerability classes — memory corruption, unexpected error handling, parsing failures — that do not surface in functional or requirements-based test suites because they arise from execution paths not defined in the requirements.
What changed
IEC 81001-5-1:2021 is the first standalone cybersecurity standard purpose-built for health software and medical device software. Published in December 2021, it was adapted from IEC 62443-4-1 (industrial control systems security) to address the unique safety and regulatory context of medical devices — adding health-specific requirements that account for patient safety, clinical workflows, and the manufacturer-HDO relationship.
The standard mirrors IEC 62304's lifecycle structure but adds security-specific activities at every phase — planning, development, testing, release, and maintenance. It requires security risk management to be integrated with ISO 14971 safety risk management, not treated as a separate IT concern. FDA formally recognized it as Consensus Standard 13-122 on December 19, 2022 and references it as providing one acceptable framework for satisfying the cybersecurity requirements of Section 524B(b)(2), which requires manufacturers to design, develop, and maintain processes and procedures to provide a reasonable assurance that cyber devices and related systems are cybersecure.
EU MDR harmonization was originally targeted for May 2024 but postponed to May 2028. Despite this delay, Notified Bodies and Competent Authorities universally recognize it as "state of the art" for health software cybersecurity under MDR GSPR Annex I, Section 17.2. Missing or inadequate cybersecurity documentation is already a top cause of Notified Body major non-conformities for SaMD. A December 2025 Interpretation Sheet (ISH1:2025) clarified software item classification into maintained, supported, and required software categories, affecting risk transfer and post-market obligations.
Common gaps (what we see in audits)
- Vulnerability testing limited to automated scanning — Vulnerability testing consists solely of running automated scanners without manual analysis of results, verification of exploitability, or testing of vulnerability classes specific to the device's technology stack and threat model.