TARA for Medical Devices: FDA Premarket Threat Analysis

Introduction

A deficiency letter that cites "inadequate threat model" or "security risk not tied to patient harm" is the most expensive way to learn what TARA means. Under FDA Section 524B and the February 3, 2026 premarket cybersecurity guidance, a 510(k) or PMA without a defensible Threat Analysis and Risk Assessment will not clear review.

TARA is not an FDA-coined term. It comes from the automotive sector (ISO/SAE 21434) and broader systems engineering, but the underlying activities (enumerate threats, score them against safety risk, document mitigations) are exactly what the FDA, AAMI TIR57, and ISO 14971 require of a medical device manufacturer.

This guide explains what TARA looks like for a medical device, how it maps to the standards the FDA recognizes, and what a submission-ready TARA must contain.

Key Takeaways

• TARA combines threat modeling (STRIDE, PASTA, attack trees) with cybersecurity risk scoring tied to patient harm under ISO 14971.
• The FDA does not require the word "TARA," but does require both halves: a documented threat model and a security risk assessment in every premarket submission.
• AAMI TIR57:2016 is the FDA-recognized consensus standard that structures cybersecurity risk against safety risk.
• A defensible TARA links every identified threat to a control, a residual risk score, and a verification activity.
• Submissions that score cybersecurity risk in isolation from ISO 14971 patient-harm risk routinely receive deficiency letters.

Table of Contents

• Why TARA matters for FDA premarket submissions
• What is TARA in a medical device context?
• How does TARA map to AAMI TIR57 and ISO 14971?
• What does a submission-ready TARA contain?
• TARA vs threat modeling: are they the same thing?
• How Blue Goat approaches TARA
• FAQ

Why TARA matters for FDA premarket submissions

The FDA's Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final guidance, February 3, 2026) requires every cyber device submission to include a threat model and a security risk assessment that traces cybersecurity risk to patient-safety risk. FDA Section 524B made the underlying authority statutory in 2023.

AAMI TIR57:2016, Principles for medical device security: Risk management, is the FDA-recognized consensus standard for performing that work. TIR57 explicitly distinguishes security risk (probability and impact of a successful exploit) from safety risk (probability and severity of patient harm under ISO 14971) and requires teams to bridge the two.

A submission that delivers a vulnerability list without a threat model, or a threat model without ISO 14971 linkage, is the single most common cybersecurity deficiency cited in 510(k) hold letters.

What is TARA in a medical device context?

TARA is the combined activity of (1) systematically identifying threats against a device and its data flows and (2) assessing the risk each threat poses, scored in terms of impact to confidentiality, integrity, availability, and ultimately patient safety.

The first half (threat identification) uses established methods such as STRIDE, PASTA, or attack-tree analysis applied to a system context diagram. The second half (risk assessment) scores each threat using likelihood and impact factors and then maps the cybersecurity impact onto the ISO 14971 safety risk register.

For a medical device, the deliverable is a single traceable artifact: every asset, every threat, every control, every residual risk, every verification activity, all linked.

How does TARA map to AAMI TIR57 and ISO 14971?

The standards do not use the word "TARA," but they describe the same workflow:

TARA activity	AAMI TIR57 clause	ISO 14971 linkage
System & data-flow definition	Clause 4 (context)	Risk management plan inputs
Threat identification	Clause 5.4 (threat modeling)	Hazard identification
Vulnerability analysis	Clause 5.5	Hazardous-situation analysis
Risk estimation	Clause 6	Risk estimation (P1 × P2 × severity)
Risk control & residual risk	Clauses 7–8	Risk control & benefit-risk analysis

What does a submission-ready TARA contain?

A TARA the FDA will accept without follow-up questions contains, at minimum:

See also: Data Flow Diagrams for Medical Device Cybersecurity, Brainjacking: The Real Cyber-Physical Threat to NeuroTech, and Threat Modeling Connected & Implantable Devices.

• A current architecture and data-flow diagram showing trust boundaries.
• An asset inventory with confidentiality, integrity, and availability ratings.
• A threat list generated from a named methodology (STRIDE or PASTA, most commonly).
• A vulnerability assessment including known CVEs in third-party components from the SBOM.
• A risk score for each threat using a defined rubric (CVSS for vulnerabilities is acceptable; cybersecurity risk for patient harm needs a tailored rubric).
• Mapping from each cybersecurity risk to an ISO 14971 hazardous situation.
• Risk controls (design, protective, detective, response) with verification evidence.
• Residual risk justification, signed by the risk owner.

TARA vs threat modeling: are they the same thing?

No. Threat modeling is the first half of TARA: identifying what could go wrong. TARA includes threat modeling plus the risk-assessment, control-selection, and residual-risk steps that score how bad it is and what you did about it.

A team that delivers a STRIDE diagram with no risk scoring has done threat modeling but not TARA. A submission with both is what the FDA expects.

How Blue Goat approaches TARA

Our TARA engagements are led by senior security engineers with CISSP and OSCP credentials and prior offensive-security backgrounds, paired with regulatory specialists who write to AAMI TIR57 and ISO 14971 every week. We build the threat model from your architecture, score each threat against your existing ISO 14971 risk file (not a parallel register), and deliver an artifact your reviewer can read end-to-end.

Learn more about our medical device threat modeling services or our FDA premarket cybersecurity services.

If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

FAQ

Does the FDA require a TARA?

The FDA does not use the term "TARA," but the February 3, 2026 premarket cybersecurity guidance requires both a documented threat model and a security risk assessment that traces to ISO 14971 patient-safety risk. Performed together, those two artifacts are a TARA. Submissions missing either half routinely receive deficiency letters.

Is TARA the same as a vulnerability assessment?

No. A vulnerability assessment lists known weaknesses, usually scored with CVSS. TARA is broader: it identifies threats (including novel ones with no CVE), scores them against patient-safety impact, and documents the controls and residual risk. Vulnerability assessment is one input to a TARA, not a substitute for it.

Which threat-modeling methodology should we use for TARA?

STRIDE is the most common for medical devices because it maps cleanly to AAMI TIR57 and is easy for a reviewer to follow. PASTA is appropriate for higher-risk Class III devices where attacker-centric analysis adds value. The methodology must be named and applied consistently; reviewers flag ad-hoc threat lists.

How does TARA differ from automotive ISO/SAE 21434 TARA?

The methodology is similar, but the risk frame is different. Automotive TARA scores impact in terms of safety, financial, operational, and privacy damage. Medical device TARA scores cybersecurity impact in terms of patient harm under ISO 14971. Borrowing the automotive rubric without the ISO 14971 mapping will fail FDA review.

How often must TARA be updated?

TARA is a living artifact under both AAMI TIR57 and the February 3, 2026 guidance. Update it when the architecture changes, when new threats or vulnerabilities affect components in your SBOM, after every postmarket incident, and at minimum during each design review.

Ready for a defensible TARA?

If your submission needs a TARA that traces cleanly to AAMI TIR57 and ISO 14971, and a team that resolves any FDA cybersecurity deficiencies at no additional cost, book a working session with our medical device security engineers.

---

Christian Espinosa, Founder, Blue Goat Cyber (CISSP, OSCP, ex-military red team). Christian has led threat-analysis and risk-assessment engagements for Class II and Class III medical device manufacturers preparing 510(k), De Novo, and PMA submissions.