What Is TARA in Automotive Cybersecurity? A Practical Guide

TARA (Threat Analysis and Risk Assessment) is the systematic Cybersecurity Engineering analysis methodology defined in ISO 21434 Clause 15. It is the process by which automotive engineering teams identify cybersecurity threats to vehicle systems, assess the feasibility and impact of each threat, determine risk levels, and define appropriate risk treatments. TARA is widely considered the backbone of automotive cybersecurity engineering — without it, there is no structured basis for making cybersecurity decisions.

Every vehicle system that falls within the scope of ISO/SAE 21434 requires a TARA. This includes ECUs, communication interfaces, external connectivity modules, sensor systems, and any component that processes, stores, or transmits data relevant to vehicle cybersecurity. For a modern connected vehicle with 50-100+ ECUs, this means dozens of TARAs must be performed across the vehicle program.

Why TARA Is Mandatory

TARA is not optional under ISO/SAE 21434. Clause 15 explicitly requires that a Threat Analysis and Risk Assessment be performed for each item or component within the cybersecurity scope. The results of the TARA drive all downstream cybersecurity activities: Cybersecurity Goals, cybersecurity requirements, verification criteria, and validation test cases.

Beyond ISO/SAE 21434, TARA results are essential for UNECE R155 compliance. When an OEM submits evidence for Vehicle Type Approval, the type approval authority expects to see structured threat analysis results that demonstrate systematic identification and treatment of cybersecurity risks. TARA Work Products serve as that evidence.

For Tier-1 suppliers, OEMs increasingly require TARA deliverables as part of the component or system delivery package. The Cybersecurity Interface Agreement (CIA) between OEM and supplier — defined in ISO/SAE 21434 Clause 7 — typically specifies TARA responsibilities and expected Work Products.

The 5 Steps of TARA in Detail

ISO/SAE 21434 Clause 15 defines seven TARA activities (15.3 to 15.9), each producing a work product. In practice, teams run them as five steps, grouping the activities that are always done together. The diagram and the steps below use the same five, with the clause and work products for each, so every step traces back to the standard and builds on the outputs of the one before.

Step 1: Assets and Damage Scenarios (15.3).The first step is to identify the cybersecurity-relevant assets within the system under analysis. An asset is anything that has value and requires protection — this includes data (firmware, calibration data, cryptographic keys, personal data), functions (diagnostic services, OTA update mechanisms, safety-critical control functions), and interfaces (CAN bus connections, Ethernet ports, Bluetooth, Wi-Fi, OBD-II). Each asset is characterized by the cybersecurity properties worth protecting — typically confidentiality, integrity and availability, often extended with authenticity. Alongside each asset, the team records the damage scenarios its compromise could cause: the adverse consequences for the vehicle, its occupants or other road users, such as unintended braking or exposure of personal data. Damage scenarios (WP-15-01) and assets (WP-15-02) are identified together, because an asset matters through the damage its compromise leads to.

Step 2: Threat Scenarios (15.4).For each identified asset, the team identifies threat scenarios — the ways a cybersecurity property of the asset could be compromised, leading to a damage scenario (WP-15-03). Threat identification can be performed using structured methodologies such as STRIDE, attack trees, or catalog-based approaches. A comprehensive threat library is critical here — experienced teams maintain catalogs of hundreds of known automotive threats mapped to specific asset types and architectures.

Step 3: Impact Rating (15.5). Each damage scenario is rated for its impact in four categories: safety (potential for physical harm), financial (economic loss to stakeholders), operational (disruption of vehicle functions), and privacy (exposure of personal data). Each category is rated as severe, major, moderate or negligible (WP-15-04). Where a damage scenario affects several categories, teams commonly carry the highest rating into the risk calculation.

Step 4: Attack Paths and Attack Feasibility (15.6–15.7).For each threat scenario, the team analyses the attack paths that could realise it — the sequence of steps from an entry point, such as a wireless interface or the diagnostic port, to the targeted asset (WP-15-05). Each attack path is then rated for feasibility (WP-15-06). ISO/SAE 21434 provides several approaches, with the attack potential-based approach the most commonly used. It evaluates elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment. The result is a feasibility rating of high, medium, low or very low.

Step 5: Risk Value and Risk Treatment (15.8–15.9).The impact rating and the attack feasibility rating combine into a risk value for each threat scenario, from 1 (minimal) to 5 — commonly through a risk matrix (WP-15-07). For each risk, the team then records a Risk Treatment decision (WP-15-08): avoid (remove the risk source), reduce (implement cybersecurity controls), share (for example with a supplier or through insurance), or retain (accept and document the residual risk). Decisions to reduce a risk become Cybersecurity Goals in the concept phase (Clause 9), which flow into cybersecurity requirements for development; decisions to share or retain a risk are recorded as cybersecurity claims.

TARA Inputs and Outputs

A high-quality TARA requires well-defined inputs. The most critical input is the item definition — a comprehensive description of the system under analysis, including its boundaries, interfaces, functions, data flows, and operational context. Other inputs include the system architecture description, relevant cybersecurity information from vulnerability databases and threat intelligence sources, and any prior TARA results from related systems.

The outputs of a TARA are the eight Clause 15 work products, which serve as both engineering artifacts and compliance evidence:

• Damage scenarios (WP-15-01): The adverse consequences a compromise could cause for the vehicle, its occupants or other road users.
• Assets with cybersecurity properties (WP-15-02): The catalog of cybersecurity-relevant assets and the properties worth protecting for each.
• Threat scenarios (WP-15-03): How each asset’s properties could be compromised, linked to the damage scenarios they lead to.
• Impact ratings (WP-15-04): Safety, financial, operational and privacy ratings for each damage scenario.
• Attack paths (WP-15-05): The sequences of steps that could realise each threat scenario.
• Attack feasibility ratings (WP-15-06): High, medium, low or very low, with the supporting rationale for each attack path.
• Risk values (WP-15-07): A value from 1 to 5 for each threat scenario, combining impact and feasibility.
• Risk treatment decisions (WP-15-08): Avoid, reduce, share or retain for each risk, with justification.

Downstream, decisions to reduce a risk become Cybersecurity Goals and decisions to share or retain it become cybersecurity claims (Clause 9). The goals drive the cybersecurity requirements for development.

Common Challenges in Performing TARA

Despite its systematic structure, TARA is one of the most challenging activities in Automotive Cybersecurity Engineering. Teams frequently encounter the following difficulties:

• Incomplete asset identification: Teams often miss assets because the system boundary is poorly defined, or because they focus only on obvious data assets while overlooking functional and interface assets.
• Inconsistent threat identification:Without a structured methodology and comprehensive threat catalog, the threats identified depend heavily on the individual engineer's experience and knowledge. Two engineers analyzing the same system may produce very different threat lists.
• Subjective ratings: Impact and feasibility assessments involve engineering judgment, and different assessors often arrive at different ratings for the same threat. This inconsistency undermines the credibility of the TARA results.
• Traceability gaps: Maintaining full traceability from assets through threats, impacts, feasibility, risks, and treatment decisions to Cybersecurity Goals is complex, especially in spreadsheet-based workflows.
• Scale: A single ECU TARA can involve 20-50 assets, 100-300 threats, and corresponding impact and feasibility assessments. Across a vehicle program with dozens of systems, the total volume of TARA work products is enormous.

Manual TARA vs Automated TARA

Historically, TARA has been performed manually using spreadsheets, documents, and workshops. A typical manual TARA for a single system takes several weeks of engineering effort, involving multiple workshops, iterations, and review cycles.

The limitations of manual TARA are well-documented: inconsistency between analysts, difficulty maintaining traceability, high effort per system, and challenges in updating TARAs when system designs change. These limitations have driven the development of automated TARA tools that use structured databases, AI-powered threat identification, and automated report generation. For a deeper comparison, see our article on manual TARA vs automated TARA.

For more information on the ISO/SAE 21434 standard and its requirements, explore our comprehensive ISO/SAE 21434 guide.

Agnile Technologies specializes in Automotive Cybersecurity Engineering, including TARA. Learn more about our Cybersecurity services.