IEC 62304 software architecture and design input practices, ISO 14971 hazard identification methodology — threat modeling extends both into cybersecurity.
FDA guidance V.B.2 recommends providing, at minimum, four types of security architecture views in premarket submissions: Global System, Multi-Patient Harm, Updateability/Patchability, and Security Use Case — documented with both diagrams and explanatory text.
System diagram showing trust boundaries and data flows, enumerated attack surfaces including wireless and cloud.
Maps to
FDA Cybersecurity Guidance: §V.A.1 Threat Modeling, §V.B.2 Security Architecture Views
Pre-QMSR Part 820: §820.30(c) Design input.
ISO 14971: §5.4 Identification of hazards and hazardous situations
IEC 81001-5-1: §5.3 Software architectural design
Requirement text
FDA's Premarket Cybersecurity Guidance (current edition issued February 3, 2026) recommends that the manufacturer provide a comprehensive threat model as part of premarket cybersecurity documentation. The threat model should identify medical device system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the cybersecurity risk assessment, state any assumptions about the medical device system or environment of use, and capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment process.
Why this clause exists
A threat model submitted without system-level context — no diagram, interfaces enumerated only partially, threat sources limited to abstract categories — cannot support an FDA reviewer's assessment of whether the device's attack surface is understood and defended. FDA guidance V.B.2 recommends providing, at minimum, four types of security architecture views in premarket submissions. A threat model that omits cloud connections, mobile app interfaces, or removable media leaves entire attack vectors uncharacterized. On the Multi-Patient Harm View, guidance V.B.2(b) says that when devices are capable of connecting to another product, a network, or the Internet, "there is the possibility that multiple devices can be compromised simultaneously", and "FDA recommends that manufacturers address how their device(s) and the system(s) in which they operate defend against and/or respond to attacks with the potential to harm multiple patients in a multi-patient harm view."
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)
- Incomplete threat models lacking system context — Threat models can lack system diagrams showing the device in its intended use environment, omit interfaces (wireless, cloud, removable media), or fail to identify relevant threat sources. FDA recommends that threat modeling be performed throughout the design process and "be inclusive of all medical device system elements" (V.A.1). The guidance does not name a threat modeling methodology: it says "There are a number of methodologies and/or combinations of methods for threat modeling that manufacturers may choose to use" and that "Rationale for the methodology(ies) selected should be provided with the threat modeling documentation" (V.A.1).