Threat Modeling for FDA Premarket Medical Device Submissions

Most compliance-adjacent threat modeling content treats the FDA connection as inferential a risk assessment “supports” a threat model, or a threat model “helps demonstrate” safety. FDA’s current guidance doesn’t leave that much room for interpretation. The February 3, 2026 guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions — which supersedes the June 2025 version, which itself superseded the original September 2023 guidance most existing compliance content still cites — contains a subsection titled, verbatim, “1. Threat Modeling,” inside Section V.A, Security Risk Management.

That subsection states that threat modeling “includes a process for identifying security objectives, risks, and vulnerabilities across the medical device system, and then defining countermeasures to prevent, mitigate, monitor, or respond to the effects of threats,” and recommends it be performed throughout the design process, inclusive of all system elements. The guidance is explicit about what the threat model itself needs to contain:

• Identification of system risks and mitigations, feeding pre- and post-mitigation risk scoring in the cybersecurity risk assessment
• Documented assumptions about the device’s environment of use FDA’s own example is assuming hospital networks are inherently hostile, with an adversary capable of altering, dropping, and replaying packets
• Risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance, and decommissioning — categories a purely technical architecture review tends to miss

This sits inside the Security Risk Management Report, which FDA recommends be structured per AAMI TIR57 and ANSI/AAMI SW96, and which should also include the SBOM, vulnerability assessments, and traceability between all of these elements. The threat model isn’t a nice-to-have attachment FDA states the report “should include the documentation elements for the system threat modeling… described in the sections below,” making it one of the report’s defined components.

FDA’s guidance recommends manufacturers adopt a Secure Product Development Framework (SPDF) — a set of processes spanning the device’s full lifecycle, from design through decommissioning — as one way to satisfy the Quality Management System Regulation (QMSR, 21 CFR Part 820, incorporating ISO 13485). FDA names several frameworks manufacturers might use to build that SPDF, including the Medical Device and Health IT Joint Security Plan (JSP2) and ANSI/ISA 62443-4-1.

PASTA fits inside that SPDF as the risk-centric methodology producing the threat model artifact FDA is asking for by name. Its decomposition stage maps to FDA’s expectation that the model cover “all medical device system elements,” not just the device in isolation — interoperability with hospital networks, third-party components, and update infrastructure are all in scope per the guidance’s Multi-Patient Harm View and Interoperability Considerations sections. Its attack-modeling and risk-analysis stages produce the pre- and post-mitigation risk scoring FDA expects to see traced into the cybersecurity risk assessment.

Where FDA’s guidance goes further than a generic secure-SDLC checklist is in asking for documented assumptions about the environment of use — not just what threats exist, but what the manufacturer is assuming about the world the device operates in. That’s a PASTA strength: the methodology treats business and operational context as a first-class input to the threat model, not an afterthought bolted on after a purely technical review.

FDA’s guidance doesn’t treat the threat model as a premarket artifact that ages out after clearance. Section V.A.6, “TPLC Security Risk Management,” recommends manufacturers update their threat modeling and risk assessment documentation “as new information becomes available, such as when new threats, vulnerabilities, assets, or adverse impacts are discovered during development and after the device is released.” For devices meeting the FD&C Act’s “cyber device” definition under Section 524B, that continuous-monitoring expectation is closer to a documentation obligation than a suggestion.

TMaaS is structured for exactly that lifecycle threat models maintained as living documentation rather than a point-in-time deliverable filed with a 510(k) or PMA and never revisited. For a device manufacturer, that means the threat model referenced in a premarket submission is the same one still being maintained postmarket, with traceability intact, rather than two disconnected artifacts.

FDA’s guidance is explicitly nonbinding — the document states plainly that it “does not establish any rights for any person and is not binding on FDA or the public,” and that “should” language throughout means recommended, not required. A manufacturer can satisfy FDA’s expectations through an alternative approach if it meets the underlying statutory and regulatory requirements. No threat model, PASTA-based or otherwise, determines premarket clearance on its own — that determination sits with FDA’s review of the complete submission, including security architecture views, testing, and labeling alongside the security risk management report.