TARA Threat Analysis and Risk Assessment

Reviewed September 17, 2026

Medical device manufacturers increasingly hear "TARA" from consultants and standards bodies without a clear explanation of where it came from or how it differs from the STRIDE-based threat modeling many teams already use. That confusion has a cost: choosing the wrong framing, or applying TARA terminology without its actual attack feasibility and risk treatment steps, can produce a security risk assessment that looks complete but leaves gaps a reviewer will find.

TARA did not originate in medical devices. It came from automotive cybersecurity, where ISO/SAE 21434 formalized it as the method for assessing cyber risk to connected vehicle systems. Medical device teams have since adapted the same structure because it forces a disciplined path from asset to attack path to risk decision, which aligns well with how AAMI SW96 and ISO 14971 expect security risk to be documented. This guide explains the method's origin, its steps, how it maps onto medical device standards, and when it makes more sense than a STRIDE-only approach.

Why This Matters

The FDA's premarket cybersecurity guidance, finalized February 3, 2026, requires every cyber device submission under Section 524B of the FD&C Act to include a documented threat model and a security risk assessment connected to patient harm. The guidance does not name TARA specifically, but its requirements, asset and threat identification, risk scoring tied to clinical consequence, and documented treatment decisions, map directly onto TARA's structure.

Manufacturers coming from automotive, industrial, or aerospace backgrounds often bring TARA with them because it is the risk assessment method their engineers already know from ISO/SAE 21434. The challenge is that automotive TARA scores risk against vehicle safety and financial impact, while medical device risk management under ISO 14971 requires scoring against patient harm categories, so the method needs adaptation, not a direct copy.

AAMI SW96, the software cybersecurity standard for medical devices, describes a risk management process compatible with TARA's steps: identify assets, characterize threats, assess feasibility, determine risk, and decide on treatment. Used correctly, TARA gives manufacturers a defensible, repeatable way to justify why a given vulnerability was mitigated, accepted, or transferred, which is exactly the kind of documented decision-making the FDA's reviewers expect to see in a security risk assessment rather than an unexplained risk rating.

Where Did TARA Come From?

TARA originated in automotive cybersecurity, formalized as a required process under ISO/SAE 21434 for assessing cyber risk across a vehicle's electronic systems. The automotive industry needed a method that could rate the feasibility of an attack, not just its theoretical existence, because vehicle systems face a wide range of attackers with very different capabilities.

That feasibility focus is TARA's defining trait compared to a pure threat enumeration method. Rather than just listing that a threat exists, TARA asks how feasible it actually is for a realistic attacker to execute, given the elapsed time, expertise, knowledge of the system, window of opportunity, and equipment required.

[KEY REQUIREMENT] Any TARA adapted for medical devices must replace automotive-specific feasibility factors and damage categories with equivalents grounded in clinical environments and patient safety impact, not a direct copy-paste of the ISO/SAE 21434 scoring tables.

How Does TARA Map Onto Medical Device Risk Management?

TARA maps onto medical device risk management by substituting ISO 14971 patient harm severity for automotive safety and financial impact categories, while keeping the same asset-to-treatment structure. AAMI SW96 describes a compatible process, so a manufacturer using TARA is not inventing a new risk management approach, but adapting an established one to a standard the FDA already recognizes.

The practical mapping happens at the damage scenario and risk determination steps. A damage scenario in automotive TARA might describe unintended braking; in a medical device, the equivalent describes a clinical consequence, such as unintended therapy delivery or delayed treatment. The risk determination step then uses the same ISO 14971 severity and probability matrix a manufacturer's broader risk management file already relies on.

What Are the Steps in a TARA Process?

A TARA process runs through seven steps: asset identification, damage scenario definition, threat scenario development, attack path analysis, attack feasibility rating, risk determination, and treatment decision. Each step builds on the last, so skipping one, such as attack path analysis, weakens the feasibility rating that follows it.

Asset identification lists every component and data element with security relevance, similar to the scoping step in STRIDE-based threat modeling. Damage scenarios describe what happens if an asset's security property is compromised, expressed in terms of clinical consequence for a medical device rather than a generic technical impact statement.

Threat scenarios describe how an attacker could cause that damage, and attack path analysis breaks the threat scenario into the specific steps and preconditions an attacker would need. Attack feasibility rating then scores how realistic that path actually is, considering the elapsed time, specialist expertise, knowledge of the device, window of opportunity, and equipment an attacker would need.

[KEY REQUIREMENT] Attack feasibility ratings must be documented with the specific factors that produced the score, not just a final number, so a reviewer can evaluate whether the rating is defensible.

Risk determination combines the feasibility rating with the damage scenario's severity, typically using ISO 14971's severity and probability matrix for medical devices. Treatment decisions then record whether the manufacturer will mitigate, accept, transfer, or avoid the risk, along with the rationale.

When Is TARA the Right Framing Instead of STRIDE?

See also: Ransomware and Medical Devices: What the FDA Expects, Data Flow Diagrams for Medical Device Security, and Brainjacking: The Real Cyber-Physical Threat to NeuroTech.

TARA is the right framing when a manufacturer needs a defensible, feasibility-driven justification for a risk treatment decision, particularly for regulatory bodies or standards that expect ISO/SAE 21434-style rigor. STRIDE, by contrast, is better suited to systematically enumerating threats across every trust boundary in a data flow diagram, which is why many teams use both rather than choosing one exclusively.

A manufacturer building a connected infusion pump might use STRIDE to walk every trust boundary and generate a full threat register, then apply TARA's attack feasibility and risk determination steps to the highest-priority threats to produce a documented, defensible treatment decision. Using TARA alone, without a systematic enumeration step like STRIDE, risks missing threats that a category-based sweep would have caught, since TARA's structure assumes threats have already been identified before feasibility scoring begins.

For a closer comparison of category-based threat modeling methods, see Comparing DREAD, STRIDE, and PASTA Threat Models, and for how failure-mode analysis compares to threat modeling generally, see FMEA vs Threat Modeling for Medical Devices.

What Attack Feasibility Factors Should a Medical Device TARA Use?

A medical device TARA should score attack feasibility using elapsed time, specialist expertise required, knowledge of the specific device, window of opportunity, and equipment needed, adapted from the automotive model but applied to clinical and home-use environments. A device used unsupervised in a patient's home, for example, has a different window-of-opportunity profile than one used only in a monitored clinical setting.

Feasibility scoring should also account for whether an attacker needs physical access to the device, since implantables and home-use devices often have different physical exposure than devices confined to a hospital network. A threat that requires extended physical possession of an implant is far less feasible for a remote attacker than one exploitable over a hospital Wi-Fi network.

How Should Risk Determination and Treatment Decisions Be Documented?

Risk determination should combine the attack feasibility rating with the ISO 14971 severity of the associated damage scenario, using the same risk matrix already defined in the manufacturer's risk management file. This keeps the TARA output consistent with the broader risk management documentation the FDA reviews, rather than introducing a second, incompatible risk scale.

Treatment decisions need to record which of four options was chosen, mitigate, accept, transfer, or avoid, along with the rationale and any residual risk. A decision to accept a risk without mitigation needs a documented justification tied to the feasibility and severity ratings, since reviewers commonly ask why a given risk was left unaddressed.

How Blue Goat Cyber Approaches This

Blue Goat Cyber builds threat analysis and risk assessments for medical device manufacturers that combine STRIDE-based threat enumeration with TARA-style feasibility scoring and ISO 14971 risk determination, producing documentation structured for AAMI SW96 alignment and FDA premarket review. The work maps damage scenarios to clinical consequences and documents attack feasibility factors specific to the device's use environment, whether that is a hospital network or unsupervised home use. For manufacturers who want this work scoped as part of an ongoing program, see Threat Modeling Services, which covers both threat enumeration and risk assessment documentation.

Frequently Asked Questions

Does the FDA require TARA by name?

No. The FDA's February 3, 2026 premarket cybersecurity guidance does not name TARA specifically, but it requires a documented threat model and a security risk assessment tied to patient harm, requirements that TARA's structure satisfies when adapted to ISO 14971 severity categories.

Can TARA replace STRIDE entirely?

TARA can replace STRIDE for the risk scoring and treatment portion of the process, but it assumes threats have already been identified. Most manufacturers use STRIDE, or a similar enumeration method, to find threats systematically and TARA's feasibility and treatment steps to finish the risk assessment.

What is the biggest difference between automotive and medical device TARA?

The biggest difference is the risk determination basis: automotive TARA scores against vehicle safety, financial, operational, and privacy impact, while medical device TARA scores against ISO 14971 patient harm severity and probability. The steps and structure carry over, but the scoring categories need to be rebuilt around clinical consequence.

Is TARA suitable for a low-risk connected accessory?

Yes, though the depth of the analysis can scale with the device's risk classification. A low-risk accessory still needs asset identification and a documented rationale for any threats rated as low feasibility or low severity, even if the full attack path analysis is lighter than it would be for an implantable device.

How does AAMI SW96 relate to TARA?

AAMI SW96 describes a software cybersecurity risk management process for medical devices that is structurally compatible with TARA's steps, including asset identification, threat characterization, and risk-based treatment decisions. It gives manufacturers a recognized standard to reference when documenting a TARA-based security risk assessment for the FDA.

CTA

If your team needs help scoping a threat analysis and risk assessment for a premarket submission or aligning an existing TARA with AAMI SW96 and ISO 14971, talk to Blue Goat Cyber about how the work fits your submission timeline.

Christian Espinosa is the founder of Blue Goat Cyber and writes on medical device cybersecurity, threat modeling, and FDA premarket strategy. Read more from him at his author page.