IEC 81001-5-1 §5.7 software system testing and ISO 13485 §7.3.6 design verification and §7.3.7 design validation — penetration testing is a specialized security verification layer on top of existing V&V activities.
FDA V.C recommends that penetration test reports state the independence and technical expertise of the testers, the scope and duration of testing, the testing methods employed, and the test results, findings, and observations. For all testing, FDA recommends that manufacturers provide their assessment of any findings, including rationales for not implementing or deferring any findings to future releases.
Scope traceability to threat model attack surfaces, tester independence documentation, and retest records for critical/high findings.
Maps to
FDA Cybersecurity Guidance: §V.C Cybersecurity Testing
ISO 13485: §7.3.6 Design and development verification, §7.3.7 Design and development validation
Pre-QMSR Part 820: §820.30(f) Design verification., §820.30(g) Design validation.
IEC 81001-5-1: §5.7 Software system testing
Requirement text
FDA's Premarket Cybersecurity Guidance recommends that penetration testing, among other types of testing, be considered for inclusion in the premarket submission. FDA recommends that penetration test reports be provided and include the independence and technical expertise of the testers, the scope of testing, the duration of testing, the testing methods employed, and the test results, findings, and observations. Manufacturers should also provide their assessment of any findings, including rationales for not implementing or deferring any findings to future releases.
Why this clause exists
Vulnerability scanning identifies known CVEs against listed components, but it cannot determine whether those vulnerabilities are exploitable in the specific product configuration or whether novel attack paths exist that no CVE database yet captures. Penetration testing occupies a structurally different role: a skilled adversary simulates realistic attack chains against the actual running system, following paths that static analysis cannot surface, and produces findings whose validity is demonstrated by working proof-of-concept rather than theoretical exposure. A generic web application test report with no connection to the device's threat model can leave the most device-specific attack surfaces, such as the wireless interface, proprietary protocol, or clinical network integration, unexamined. The guidance recommends that penetration test reports state the "Independence and technical expertise of testers", and says manufacturers "should indicate in the test reports by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices." It adds: "In some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups, such that vulnerabilities or other issues revealed during testing are appropriately addressed."
What changed
The FDA's September 2023 final guidance replaced the October 2014 final guidance 'Content of Premarket Submissions for Management of Cybersecurity in Medical Devices'. The guidance is headed 'Contains Nonbinding Recommendations' and states that, in general, FDA guidance documents 'do not establish legally enforceable responsibilities' and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited; it recommends how to meet the requirements of Section 524B of the FD&C Act (added by FDORA, enacted December 29, 2022), which became effective March 29, 2023. FDA's cybersecurity Refuse to Accept (RTA) policy for cyber devices, issued March 29, 2023, expired on October 1, 2023; from that date FDA expects sponsors of cyber devices to have had sufficient time to prepare premarket submissions that contain the information Section 524B requires (FDA CDRH webinar, November 2, 2023).
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software validated, installed, or authorized by the sponsor as a device or in a device, has the ability to connect to the internet, and contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. Under Section 524B(b), the sponsor must (1) submit a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures; (2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks; (3) 'provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components'; and (4) comply with such other requirements as the Secretary may require through regulation to demonstrate reasonable assurance that the device and related systems are cybersecure.
The statute says nothing about SBOM format, depth or end-of-support dates. Those come from the guidance (Section V.A.4), which recommends that manufacturers provide machine-readable SBOMs consistent with the NTIA minimum elements and, for each software component, the 'software level of support' and the end-of-support date, and says 'Industry-accepted formats of SBOMs are encouraged.' The guidance names no format; SPDX and CycloneDX are formats used in practice, not named by the statute or by the guidance. The guidance describes a robust SBOM as including 'the upstream software dependencies' of proprietary, purchased/licensed, and open-source software (V.A.4(a)), and recommends that an SBOM or an equivalent capability be maintained as part of configuration management and regularly updated to reflect changes to the software in marketed devices. Section V.C lists 'Software composition analysis of binary executable files' among the testing and analyses for which it recommends providing details and evidence.
Common gaps (what we see in audits)
- Penetration testing not scoped to threat model or independently performed — Pen test reports show generic web application testing not scoped to the device's threat model. Critical findings listed as 'accepted risk' without adequate justification. Testers are internal developers lacking independence.