Maps to
IEC 81001-5-1: §5.7.3
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.
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 64 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-112 in December 2022 and references it as providing a framework for the Secure Product Development Framework (SPDF) required by Section 524B.
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.
Atomic constraints
- •Known vulnerability testing must be based on at least one established, industry-recognized, public vulnerability source.
- •Abuse case testing including fuzz testing and network traffic testing must be performed on all external interfaces and protocols.
- •Attack surface testing must be performed covering ingress/egress paths, weak ACLs, exposed ports, and services with elevated privileges.
- •Closed-box known vulnerability scanning must be performed.
- •Software Composition Analysis (SCA) must be performed on all binary executables including embedded firmware.
- •SCA must check for known CVEs, vulnerable libraries, security rule violations, compiler settings, and SBOM comparison.
- •Dynamic security testing (fuzz, DoS, memory leaks, shared memory access) must be applied if tools are available.
Common gaps
Vulnerability testing limited to automated scanning
moderateVulnerability 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.
Evidence signals
- •
FILE_EXISTS
Vulnerability.*Scan|Fuzz.*Test|SCA.*Report|Software.*Composition.*Analysis|Penetration.*Test|Security.*Test.*Report
- •
CONTENT_MATCH
Does this document describe vulnerability testing including fuzz testing, attack surface analysis, known vulnerability scanning, software composition analysis on binaries, and dynamic security testing with results and dispositions?
Audit defense
The Vulnerability Testing report for [your product] (Doc ID: [your document ID]) documents abuse case testing, attack surface analysis, known vulnerability scanning, and SCA on release binaries using industry-recognized public vulnerability sources, with all findings dispositioned prior to release.