6 TARA Tools for ISO/SAE 21434: Methodology & Comparison

The cybersecurity of connected vehicles hinges on one question: how do you know which attacks on an ECU are genuinely dangerous, and which countermeasures are worth the effort? That is exactly what Threat Analysis and Risk Assessment (TARA) answers. It is the methodological heart of ISO/SAE 21434. Without a solid TARA there is neither a defensible cybersecurity concept phase nor the evidence type approval authorities expect under UNECE R155.

In practice the tooling question comes up fast. A TARA for a modern vehicle with hundreds of ECUs and more than 100 million lines of code can be started in a spreadsheet, but it is hard to maintain cleanly over years. Dedicated TARA tools promise automation, attack-tree editors, threat catalogs and audit-ready reports. But which tool fits which use case, and where does the value of automation actually end?

This article delivers both: first the TARA methodology under Clause 15 as a traceable chain of steps, complete with a worked example, then a fact-checked, critical comparison of six established TARA tools, rounded out with further market options and a concrete selection guide. If you want to place the standard itself first, our overview of ISO/SAE 21434 in the automotive industry is a good starting point.

What is TARA under ISO/SAE 21434 (Clause 15)?

TARA stands for Threat Analysis and Risk Assessment. In ISO/SAE 21434 the methodology is defined in Clause 15 and used across the entire lifecycle: in the concept phase (Clause 9), in product development (Clause 10), and in production and operations (Clauses 12 and 13). TARA is therefore not a one-off document but a living artifact that is updated with every architecture change.

An important distinction: TARA under ISO/SAE 21434 is not the same as generic IT risk management. Damage is rated consistently from the perspective of the affected road user, not the company. An attack that manipulates a braking ECU is therefore rated primarily by its threat to human life, not by the financial damage to the manufacturer.

The TARA chain of steps

The core of Clause 15 reads as a chain of steps. Consultancies and tool vendors sometimes summarize it in six steps, sometimes in nine, but the substance is the same:

1. Item Definition: What exactly is being analyzed (an ECU, a function, a subsystem)? System boundaries, interfaces and the operating environment are established.
2. Asset Identification: What is worth protecting? Functions, data (cryptographic keys, calibration data, firmware), interfaces (CAN, Automotive Ethernet, Bluetooth, OBD-II, JTAG) and hardware. Each asset is mapped to the relevant cybersecurity properties: confidentiality, integrity, availability and authenticity.
3. Threat Scenario Identification: How can a cybersecurity property be violated? Many teams use the STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
4. Impact Rating: How severe would the consequences be? Rated across four categories: Safety, Financial, Operational and Privacy, in short S/F/O/P.
5. Attack Path Analysis: Through which concrete steps can a threat scenario be realized? Often modeled as an attack tree.
6. Attack Feasibility Rating: How much effort does the attack take? ISO/SAE 21434 permits three approaches: the attack-potential-based method (derived from ISO/IEC 18045), an attack-vector-based approach, and the CVSS exploitability metric.
7. Risk Value Determination: The risk value results from combining impact severity and feasibility, usually via a matrix. The basic formula is Risk = Impact x Feasibility.
8. Risk Treatment Decision: For each risk one of four options is chosen: Avoid, Reduce, Transfer or Accept. Reduction means concrete security measures; acceptance requires formal management sign-off.

Impact Rating: the four damage categories

For the impact rating, ISO/SAE 21434 uses four levels: Negligible, Moderate, Major and Severe. The overall impact of a scenario is typically the highest single value across the four categories. The mapping below is a common practical approximation based on predecessor and reference methodologies such as HEAVENS. It is not quoted verbatim from the (paywalled) standard:

Attack Feasibility Rating: the five factors

The attack-potential-based method scores five factors and sums their points. The point values below are commonly cited secondary-source values based on the attack-potential method in ISO/IEC 18045, which ISO/SAE 21434 references. They are not verbatim standard text and serve to illustrate the underlying logic:

The summed points yield the feasibility rating. ISO/SAE 21434 uses a four-level scale: High, Medium, Low, Very Low. A low point sum means an easy-to-perform attack, that is, high feasibility. A common mapping is: 0 to 13 points = High, 14 to 19 = Medium, 20 to 24 = Low, 25 and above = Very Low. Note: some sources (for example from the EVITA lineage) use an inverse five-level naming (basic to beyond-high). To avoid confusion we stick strictly to the ISO four-level naming throughout.

Risk value and risk treatment

Impact and feasibility are combined into a risk value, usually via a risk matrix with four risk levels:

• Level 1 (acceptable): no additional measures needed.
• Level 2 (low): monitor, consider refinement.
• Level 3 (medium): security measures required, decision documented.
• Level 4 (high): security measures mandatory, risk reduction demonstrated.

CAL and the link to UNECE R155/R156

A frequently misunderstood term is the Cybersecurity Assurance Level (CAL). Analogous to ASIL in functional safety (ISO 26262), the CAL expresses the rigor with which cybersecurity activities for a given item should be carried out and verified. Crucially, the CAL is not a direct output of the risk assessment and does not replace it. CAL and its associated verification and validation are also subject to ongoing standardization work at ISO/SAE. The work item originally tracked as PWI 8475 has left PWI status and progressed as ISO/SAE PAS 8475 (Cybersecurity Assurance Levels and Targeted Attack Feasibility), accompanied by the related ISO/SAE TR 8477. GlobalPlatform is at most a forum discussing the topic, not the publisher. The concept is therefore still maturing. For a deeper treatment, see our article on the Cyber Security Assurance Level.

In regulatory terms, TARA operates within two UN regulations: UNECE R155 requires a certified Cybersecurity Management System (CSMS) as a precondition for vehicle type approval, and UNECE R156 a Software Update Management System (SUMS) for over-the-air updates. R155 requires a structured TARA against the threat catalog in Annex 5 of the regulation, but does not prescribe a specific method. The Clause 15 methodology of ISO/SAE 21434 is regarded as the most widely accepted basis for defensible evidence. Key point: ISO/SAE 21434 conformity is not automatically the same as R155 certification, even though the standard is the de facto evidence framework.

Worked example: an ADAS camera ECU

Theory becomes tangible with a concrete case. Consider the ECU of an ADAS front camera that feeds driver-assistance systems with object detection. The example is deliberately simplified to illustrate the methodology; the point values rely on the secondary-source tiers cited above.

Steps 1 and 2 (item and assets): The item is the camera ECU. Assets include the object-detection function, the calibration parameters, the firmware image, the CAN and Ethernet interfaces, and the JTAG debug interface.

Step 3 (threat scenario): We pick a tampering scenario per STRIDE: an attacker manipulates the calibration parameters via the diagnostic interface so that object detection misplaces obstacles. The violated property is integrity.

Step 4 (impact rating): Faulty object detection can lead to a missed emergency braking maneuver, so the safety impact is Severe (life-threatening). Recalls and liability yield a financial impact of Major. Operational and privacy are lower here. The overall impact equals the highest value, so Severe.

Steps 5 and 6 (attack path and feasibility): The attack path runs via physical or logical access to the diagnostic interface. Scoring the five factors:

21 points fall in the 20 to 24 band, corresponding to a feasibility rating of Low: the attack is demanding, but not impossible.

Step 7 (risk value): A Severe impact meets Low feasibility. In a typical matrix this still yields an elevated risk value (Level 3, medium), because the potential damage is so high. The risk must be treated and the decision documented.

Step 8 (risk treatment): The choice is Reduce. Concrete measures mapped one-to-one to the threat:

• Secure Onboard Communication (SecOC) for CAN messages against spoofing and tampering
• certificate-based authentication of diagnostic access
• secure boot with measured boot for firmware integrity
• TLS encryption of the Ethernet communication
• disabling the JTAG interface in series production
• audit logging to secure storage

This example shows the decisive point: the numbers are only as good as the engineering judgment behind them. That is exactly where the tools come in, they structure and automate the assessment, but they do not replace expert judgment.

The 6 TARA tools at a glance

The following six tools are established in the automotive sector. For each we state the current product and vendor status (July 2026), a brief classification and the current link. None of these tools has a public price list; all vendors point to a quote or demo on request.

AVL ThreatGuard

• Vendor: AVL (Austria)
• Status: active, complemented by the sister product AVL ComplyGuard for compliance and documentation management under ISO 21434 and ISO 26262
• Best for: automated generation of threat scenarios, impact analyses and attack trees directly from the system architecture; import of existing MBSE models; integration with Jira, ALM, PLM and ReqIF

ThreatGuard targets teams that want to couple architecture and TARA closely. Trial access runs through AVL's Experience portal. Note: the exact product link in the portal contains a Salesforce ID that can change, so verify it before use.

ESCRYPT CycurRISK (ETAS)

• Vendor: ETAS GmbH (a Bosch subsidiary). ESCRYPT is now part of ETAS, but the product is still officially called ESCRYPT CycurRISK.
• Status: active. The formerly used product URL now redirects; the current address is etas.com/.../escrypt-cycurrisk.
• Best for: workflow-oriented TARA creation with an integrated attack-tree editor, variant management and collaborative analysis on on-premise servers; the "Automotive Threat Matrix" (ATM) threat library; conformity claim for ISO/SAE 21434 and UN R155

CycurRISK suits organizations with on-premise requirements and multiple product variants. The vendor cites high usage figures (a marketing claim, not independently verified).

itemis SECURE

• Vendor: itemis AG (Germany)
• Status: active, substantially evolved. New additions include AI assistants for automated attack-tree generation, community-driven threat catalogs (including ASRG), CVE integration, and a compliance claim that now covers, alongside ISO/SAE 21434 and IEC 62443, the Cyber Resilience Act (CRA).
• Best for: browser-based, model-centric TARA with component and data-flow diagrams, attack trees and audit-ready reporting

itemis SECURE is one of the most mature standalone workbenches and partners with Cybellum for a combined CSMS solution. Cited reference customers include ZF Group and Knorr-Bremse.

Ansys medini analyze for Cybersecurity / Ansys Medini Cybersecurity SE

• Vendor: Ansys, Inc.
• Status: active, evolving. The established name is "Ansys medini analyze for Cybersecurity"; in 2025 Ansys introduced a web-based evolution named Ansys Medini Cybersecurity SE (version 2025 R2, web-based, with TARA automation and connectivity to a Vehicle Security Operations Center, VSOC). Before a purchasing decision, verify the current feature set directly with Ansys.
• Best for: TOE modeling, attack trees, threat analysis and risk assessment; especially interesting for teams already using medini analyze for functional safety (ISO 26262) that want to bundle safety and security in one tool

The tool aligns with ISO/SAE 21434 and UN R155 and supports established rating methodologies such as HEAVENS and the SAE J3061 lineage.

Vultara

• Vendor: Vultara, Inc. (a specialized provider)
• Status: active, positioning unchanged as a pure TARA automation tool
• Best for: a drag-and-drop interface, automatic threat and risk generation via a rules engine, direct editing of architecture diagrams with automatic result updates on design changes

Vultara explicitly distinguishes itself from pure management tools that only structure data entry, emphasizing the active generation of threats and risks. Pricing is only available on request via a free demo.

AUTOThreat PRO (Upstream Security)

• Vendor: Upstream Security (Israel)
• Status: active, but an important qualification is needed. In its market presentation, AUTOThreat PRO is primarily a Cyber Threat Intelligence product with deep and dark web monitoring, real-time IOC/IOA alerts and supply-chain risk analysis, not a classic TARA authoring workbench like the other five tools. Upstream offers a separate standalone TARA calculator aligned with ISO/SAE 21434, but under a different name and URL.
• Best for: continuous threat intelligence and enriching an existing TARA with real, current threat data, less as a standalone tool to produce the TARA itself

This honest classification matters: if you need a workbench to run the Clause 15 chain of steps, the other tools serve you better. If you want to enrich an existing TARA with threat intelligence, this is the more fitting approach.

Comparison table of the 6 TARA tools

The following overview classifies the tools by the criteria that matter most in practice. It is based on publicly available vendor information (as of July 2026) and does not replace your own evaluation.

Further relevant TARA tools on the market

The market is considerably larger than six vendors. To make a well-founded choice, you should also know these options:

• Cybellum Product Security Platform: primarily SBOM and vulnerability management that consumes TARA results rather than producing them; complements itemis through a partnership.
• C2A Security (EVSec): a risk-driven DevSecOps platform with a TARA module, positioned explicitly as an alternative to spreadsheet-based TARA, with compliance tracking for WP.29 and ISO/SAE 21434.
• Vector COMPASS: a tool for planning, performing and evaluating threat assessments plus vulnerability management; a complete audit trail and the ability to combine component TARAs into a product TARA (details from vendor sources, verify live before purchase).
• PlaxidityX Security AutoDesigner: AI-assisted TARA automation. Important: PlaxidityX is the successor brand of Argus Cyber Security, renamed since 2024; older sources still list the offering under "Argus".
• EnCo SOX: an ISO 21434 TARA workbench with templates, workflows and traceability; the vendor also publishes some of the most methodologically detailed freely available TARA guides.
• SystemWeaver and No Magic (Cameo): MBSE-integrated cybersecurity extensions for teams already working in a systems-engineering suite that would rather not introduce an additional standalone tool.

One trend stands out that older tool lists ignore: modern TARA tools increasingly position themselves multi-regulatory, that is, beyond ISO 21434 and R155 also for the EU CRA or the Chinese standard GB/T 44495.

Which tool for which case?

Since there are no public prices, the fit to your use case decides. These criteria have proven useful in practice:

• Standalone or MBSE-integrated? If you already work with Cameo or an MBSE suite, an integrated module (No Magic, SystemWeaver) reduces friction. Without an MBSE base, a dedicated workbench (itemis SECURE, CycurRISK) is usually the faster route.
• Safety and security in one tool? If you want to bundle ISO 26262 and ISO 21434, consider Ansys Medini.
• On-premise or cloud? Strict IP requirements favor on-premise-capable tools such as CycurRISK; distributed teams tend toward browser-based solutions such as itemis SECURE or Vultara.
• Degree of automation: Vultara and PlaxidityX emphasize active, automated generation of threats and risks; other tools mainly structure the manual assessment.
• Threat intelligence rather than authoring? For continuous threat data, AUTOThreat PRO is the fit, not for producing the TARA itself.

When does a spreadsheet still suffice?

An honest look is part of the picture: not every project needs a specialized tool right away. In practice, some organizations return to spreadsheet-based TARA despite expensive solutions because the added value of the software stayed low for their use case (an observation from the field, not a statistic). For very small, stable items in the early concept phase, a structured spreadsheet can be enough.

Beyond a certain size, however, spreadsheets clearly hit their limits. The typical weaknesses: no version control across collaborative files, poor scalability and data integrity with manual updates, weak visualization of complex attack trees, little integration with threat-intelligence feeds or asset management, and no built-in guidance for standards such as WP.29 or ISO/SAE 21434. It is precisely at these points that dedicated tools deliver value, provided they are used with discipline.

The limits of automation

Tools do not solve every problem. Three known pitfalls are worth knowing:

1. Faulty aggregation of attack paths: automated tools sometimes sum or combine the feasibility of multi-step attacks naively and thereby systematically overestimate the risk. That wastes resources on countermeasures against attacks that are far harder in reality than the tool suggests.
2. Threat-oriented instead of attack-path-based goals: if a tool derives cybersecurity goals from abstract threats, generic requirements emerge such as "prevention of malicious software modification". Attack-path-based, this becomes something actionable: "protection against manipulation via insecure debug interfaces".
3. Competence beats tooling: the quality of a TARA depends above all on the engineers' expertise, a deep understanding of automotive systems, current attack knowledge, and collaboration between security, development and safety teams. A tool accelerates good work but does not replace it. More on this in our article on the challenges of ISO 21434.

FAQ

What is TARA under ISO/SAE 21434?

TARA stands for Threat Analysis and Risk Assessment. In ISO/SAE 21434 the methodology is defined in Clause 15. It identifies assets worth protecting, derives threat scenarios, rates the severity of damage and the feasibility of attacks, and ends in a documented risk treatment. TARA is not a one-off document but a living artifact maintained across the entire lifecycle.

Is a TARA tool mandatory for ISO/SAE 21434?

No. Neither ISO/SAE 21434 nor UNECE R155 prescribes any specific software. What is required is a structured, traceable TARA, not a particular tool. For small, stable items a disciplined spreadsheet can suffice. As complexity, variant count and audit requirements grow, a dedicated tool makes maintenance and evidence considerably easier.

How much does TARA software cost?

None of the established TARA tools publishes a price list. All vendors point to an individual quote or a demo on request. Cost depends on the licensing model, number of users, deployment mode (on-premise or cloud) and support scope. For a reliable estimate, contact several vendors directly and compare them along your specific use case.

Can you do TARA in a spreadsheet?

Yes, in the early concept phase and for very small, stable items a structured spreadsheet can be enough. But spreadsheets hit their limits quickly: no real version control, weak data integrity with manual updates, little visualization of complex attack trees, and no threat-intelligence integration. Beyond a certain size, dedicated tools deliver their value.

What is the difference between TARA and HARA?

HARA (Hazard Analysis and Risk Assessment) comes from functional safety under ISO 26262 and rates hazards from random faults and malfunctions. TARA under ISO/SAE 21434 rates deliberate cybersecurity attacks. HARA asks "what happens on a failure?", TARA asks "what can an attacker deliberately cause?". Both complement each other in vehicle development.

Conclusion

A good TARA tool is valuable, but it is a means to an end, not an end in itself. What matters first is understanding the Clause 15 methodology: the clean chain of steps from asset identification through impact and feasibility rating to a documented risk treatment, embedded in the regulatory frame of UNECE R155 and R156.

On that basis, the tooling question can be answered soberly. The six tools presented cover different priorities, from architecture-driven automation (AVL ThreatGuard) through mature workbenches (itemis SECURE, ESCRYPT CycurRISK) and the safety coupling (Ansys Medini) to pure automation (Vultara) and the threat-intelligence complement (AUTOThreat PRO). Alongside them stands a broader market with Cybellum, C2A, Vector, PlaxidityX, EnCo and MBSE-integrated options.

You will make the best decision by sharpening your use case along the criteria above (standalone or integrated, cloud or on-premise, degree of automation, multi-regulatory scope) and by keeping a critical eye on automation. Because the hardest requirement for a defensible TARA remains a human one: expertise, diligence, and the willingness to keep the artifact alive across the entire lifecycle. To see how TARA fits into the broader cybersecurity planning, read our article on the Cyber Security Plan based on ISO 21434.