If you build software or electronics for vehicles, someone has probably asked you for a TARA. It's the threat analysis and risk assessment that ISO/SAE 21434 expects for every item in scope, and it's the evidence behind the cybersecurity management system that UN Regulation No. 155 makes a condition of type approval. The standard is clear about what a TARA must produce and much less clear about how to get there, which is why so many end up as spreadsheets with hundreds of rows nobody can defend.
This guide walks through the seven TARA steps on one concrete item, a connected car's remote services, with real ratings at each step. By the end you'll have three fully worked threat scenarios, from asset to treatment decision, and a clear picture of where the standard leaves the judgement to you.
The short version: a TARA identifies assets and their cybersecurity properties, describes what damage a compromise would cause (rated for safety, financial, operational and privacy impact), finds the threat scenarios and attack paths that lead there, rates how feasible each attack is, combines impact and feasibility into a risk value, and records a treatment decision: avoid, reduce, share or retain. ISO/SAE 21434 describes these methods in clause 15.
What a TARA is, and where it sits
ISO/SAE 21434:2021, "Road vehicles — Cybersecurity engineering", is the engineering standard for automotive cybersecurity across a vehicle's whole lifecycle. A TARA is the risk analysis at its centre. It's first done in the concept phase, on the item (a function or system at vehicle level, such as remote unlock or the braking system), and it's revisited whenever the design changes or a new vulnerability turns up.
The regulatory pull comes from UN R155, adopted under the UNECE WP.29 forum. Since July 2022 new vehicle types, and since July 2024 all newly registered vehicles in the countries that apply it (including the EU, the UK and Japan), need a manufacturer with a certified cybersecurity management system and a risk assessment for the vehicle type. ISO/SAE 21434 isn't legally required by R155, but it's the standard most manufacturers and suppliers use to meet it, and its TARA is what assessors expect to see. If you're new to the idea, our comparison of threat modeling methodologies shows where TARA fits beside STRIDE and PASTA.
The worked example: remote services on a connected car
Our item is the remote services feature of a connected car: the owner's phone app sends commands (unlock, start climate control, locate the car) through the manufacturer's telematics backend to the telematics control unit (TCU) over cellular. Inside the car, a central gateway separates the connected units, the TCU and the infotainment head unit, from the chassis and powertrain buses where the brake and engine ECUs live.
That boundary is the first thing to draw. A data flow diagram with a trust boundary around the manufacturer's cloud and another around the vehicle network makes every flow that crosses into the car explicit, and those crossings are where most of the threat scenarios will come from.
Step 1: Asset identification
An asset in ISO/SAE 21434 is anything whose compromise can lead to damage, together with the cybersecurity properties that matter for it: confidentiality, integrity, availability, and often authenticity. Name the property, not just the component. "Brake ECU" isn't an asset statement; "integrity of brake commands on the chassis bus" is.
- A1: integrity and authenticity of remote commands (unlock, start).
- A2: confidentiality of vehicle location history.
- A3: integrity of brake and powertrain messages on the safety buses.
- A4: integrity of ECU firmware and the keys that sign it.
Step 2: Damage scenarios and impact rating
A damage scenario describes the consequence for the road user: what happens to the driver, passengers, other road users or the owner if an asset is compromised. Each is rated in four impact categories, safety, financial, operational and privacy, on a four-point scale: severe, major, moderate or negligible. Safety ratings typically borrow the severity classes from ISO 26262 functional safety, so the two analyses use the same language.
| ID | Damage scenario | Safety | Financial | Operational | Privacy |
|---|---|---|---|---|---|
| D1 | Car is unlocked and driven away by someone who isn't the owner | Negligible | Major | Moderate | Moderate |
| D2 | Brakes are applied or released unexpectedly while driving | Severe | Major | Severe | Negligible |
The overall impact of a damage scenario is usually its highest rating across the four categories: D1 is major, D2 is severe.
Step 3: Threat scenario identification
A threat scenario is the potential cause of a damage scenario: which property of which asset is compromised, and how. STRIDE is a common way to generate them systematically, one element and one flow at a time (see what STRIDE is), and UN R155 Annex 5 lists threats and mitigations that assessors will expect you to have considered.
- R1 (spoofing, leads to D1): an attacker sends unlock and start commands for someone else's car through the remote services API.
- R2 (spoofing, leads to D1): thieves relay the radio signal between a key fob inside the house and the car, so it unlocks and starts as if the key were next to it.
- R3 (tampering, leads to D2): an attacker who controls the infotainment unit injects brake messages onto the chassis bus.
Write each threat scenario so it names the asset property and the damage it leads to. That traceability, asset to damage to threat, is what an assessor will follow.
Step 4: Attack path analysis
An attack path is the sequence of steps that realises a threat scenario. This is where attack trees earn their place: the threat scenario is the goal, and the tree breaks it into steps joined by AND (all needed) and OR (any one works) gates. ISO/SAE 21434 allows a top-down approach (start from the damage and work down), a bottom-up approach (start from known vulnerabilities and work up), or both.
For R3 the tree has an AND gate with two children: gain code execution on the head unit (through its Bluetooth, media or browser code) and the gateway forwards frames from the infotainment bus to the chassis bus without filtering. Seeing the AND is useful straight away: fix either child and the whole path closes. The 2015 Jeep Cherokee research, which reached the CAN bus remotely through the head unit, is the reason manufacturers now treat that separation as a primary control.
Step 5: Attack feasibility rating
ISO/SAE 21434 offers three ways to rate how feasible an attack path is: the attack potential approach, a CVSS-based approach and an attack-vector-based approach. Attack potential is the most common in practice. It scores five factors, borrowed from the Common Criteria evaluation methodology, and adds them up: the lower the total, the easier the attack.
| Factor | R1: VIN-only API | R2: Key fob relay | R3: Brake injection |
|---|---|---|---|
| Elapsed time | ≤ 1 week (1) | ≤ 1 day (0) | ≤ 6 months (17) |
| Specialist expertise | Proficient (3) | Proficient (3) | Expert (6) |
| Knowledge of the item | Public (0) | Public (0) | Restricted (3) |
| Window of opportunity | Unlimited (0) | Moderate (4) | Unlimited (0) |
| Equipment | Standard (0) | Specialised (4) | Specialised (4) |
| Total | 4: High | 11: Medium | 30: Very low |
In the standard's example mapping, a total of 0 to 9 is high feasibility, 10 to 13 medium, 14 to 19 low and 20 or more very low. The numbers come out of argument, not measurement, so record why you chose each value. "Public: the API is documented in the app's traffic and VINs are visible through the windscreen" is a rating an assessor can check; "0" on its own isn't.
Step 6: Risk value determination
The risk value combines the impact of the damage scenario with the feasibility of the attack path, usually through a matrix that gives a value from 1 (lowest) to 5 (highest). The standard's informative annex includes an example matrix; organisations are expected to define and justify their own.
- R1: major impact, high feasibility, risk value 4.
- R2: major impact, medium feasibility, risk value 3.
- R3: severe impact, very low feasibility, risk value 2.
That last line surprises people, and it's the most important lesson in this guide. A risk value says how likely an outcome is to be achieved, not how bad it would be. A safety-critical scenario can legitimately score low if today's attack path is very hard. That's why ISO/SAE 21434 also has cybersecurity assurance levels (CALs): an informative annex suggests determining CAL from impact and attack vector, so a severe outcome reachable over the network still demands the highest rigour (CAL 4) in development and testing, whatever its current risk value. Never use a low risk value as a reason to skip the gateway filtering that makes R3 hard in the first place.
Step 7: Risk treatment decision
Every threat scenario ends with one of four risk treatment options: avoid (remove the feature or design that creates the risk), reduce (add controls), share (for example with a supplier or insurer) or retain (accept it). Reducing a risk leads to cybersecurity goals and, from them, cybersecurity requirements. Retaining or sharing one needs a cybersecurity claim explaining why that's adequate.
| Scenario | Risk value | Treatment | Resulting goal or control |
|---|---|---|---|
| R1 VIN-only API | 4 | Reduce | Remote commands are only accepted from accounts bound to the vehicle; the backend checks ownership on every command and requires re-authentication for unlock and start. |
| R2 Key fob relay | 3 | Reduce | Passive entry uses ultra-wideband distance bounding; the fob sleeps when it hasn't moved. |
| R3 Brake injection | 2 | Reduce (CAL 4) | The gateway forwards only allowlisted message IDs between domains; safety-relevant signals carry message authentication (for example AUTOSAR SecOC). |
Then re-rate. After the controls, R1's attack path needs a compromised owner account, which pushes its feasibility down and its risk value with it. The difference between the rating before and after controls is your residual risk, and it's what the risk owner signs off.
What makes a TARA defensible
- Traceability: every row links asset → damage scenario → threat scenario → attack path → rating → decision. If an assessor picks any line, they can follow it both ways.
- Written rationale: the reason behind each impact and feasibility value, not just the number.
- A defined item boundary: what's in scope, what the operational environment is, and what you assume about it.
- A living document: a TARA is revisited when the design changes, when a vulnerability is reported against a component, and during operations. A spreadsheet that was correct at SOP and never opened again won't pass a CSMS audit.
- Supplier alignment: suppliers do TARAs for their components, and the interfaces between yours and theirs need agreed assumptions. ISO/SAE 21434 handles this through a cybersecurity interface agreement.
Common mistakes
- Hundreds of generic threat rows. A TARA copied from a catalogue, with no attack paths, can't be prioritised or defended. Fewer, specific scenarios beat many generic ones.
- Rating impact on the component, not the road user. Damage scenarios describe consequences for people and the owner, not "ECU compromised".
- Treating a low risk value as safe. As R3 shows, severe outcomes behind hard attack paths still need high assurance. That's what CAL is for.
- Feasibility ratings nobody can explain. If the team can't say why a factor got its value, the rating won't survive review.
- Doing it once. New vulnerabilities change feasibility. Plan to update the TARA, not just to finish it.
Frequently asked questions
What does TARA stand for?
Threat Analysis and Risk Assessment. In automotive it refers to the method described in ISO/SAE 21434: identify assets, damage scenarios and threat scenarios, analyse attack paths, rate impact and attack feasibility, determine a risk value and decide on a treatment.
Is a TARA required by UN R155?
UN R155 requires vehicle manufacturers to have a certified cybersecurity management system and to assess and treat risks for each vehicle type, including the threats in its Annex 5. It doesn't mandate ISO/SAE 21434 by name, but a TARA following ISO/SAE 21434 is the most common way to provide that risk assessment.
How is attack feasibility rated in ISO/SAE 21434?
The standard describes three approaches: attack potential, CVSS-based and attack-vector-based. The attack potential approach scores elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment, and maps the total to high, medium, low or very low feasibility.
What is the difference between a risk value and a CAL?
A risk value combines impact and attack feasibility for a specific threat scenario and drives the treatment decision. A cybersecurity assurance level (CAL) sets how much rigour development and verification need, and is usually derived from impact and attack vector. A severe scenario can have a low risk value today and still need CAL 4.
Can you do a TARA with STRIDE and attack trees?
Yes. STRIDE is a practical way to generate threat scenarios element by element, and attack trees are a natural form for attack path analysis. ISO/SAE 21434 doesn't prescribe a specific technique, only the work products the analysis must produce.
Building for vehicles? See threat modeling for automotive for how the TARA work products map to ThreatTree, and the threat modeling knowledge base for the concepts behind each step.