TARA, step by step: threat analysis and risk assessment

What a TARA is for

A TARA — threat analysis and risk assessment — is the method ISO/SAE 21434 uses to work out what could be attacked, how badly it would matter, and what to do about it. It is defined in clause 15 of the standard, and it is the single most consequential activity in the concept phase. Get the TARA right and the cybersecurity goals almost write themselves; get it wrong and every requirement downstream inherits the error.

A TARA is not a one-off document. It is a living analysis that is created early, refined as the architecture firms up, and revisited whenever the design changes, a new attack technique appears, or the field tells you something new. An assessor who opens a TARA that was written once at kick-off and never touched has already found a gap.

The seven steps

ISO/SAE 21434 breaks the method into an ordered sequence. Each step consumes the output of the last.

Step	Question it answers	Output
Asset identification	What is worth protecting, and what property matters?	Assets with cybersecurity properties (confidentiality, integrity, availability)
Threat scenario identification	What could compromise that property?	Threat scenarios per asset
Impact rating	How bad is the outcome if it happens?	Impact across safety, financial, operational, privacy
Attack path analysis	By what route could an attacker achieve it?	Attack paths
Attack feasibility rating	How hard is that route in practice?	Feasibility (e.g. high to very low)
Risk value determination	Combining impact and feasibility, how much risk?	A risk value per threat scenario
Risk treatment decision	What do we do about it?	Reduce, share, retain or avoid

Asset identification

You start by naming the assets and the property that must hold. An asset is not just a component; it is a component plus the cybersecurity property that matters — the integrity of a braking command, the confidentiality of a cryptographic key, the availability of a telematics link. Naming the property is what makes the rest of the analysis precise.

Threat scenarios

For each asset property you describe how it could be compromised. This is where UN R155 Annex 5 earns its keep as a prompt list: its high-level categories — back-end servers, communication channels, update procedures, unintended human actions, external connectivity, and the vehicle's data and code as targets — are a structured way to make sure you have not missed a class of threat. We map that catalogue to the method in UN R155 Annex 5, decoded.

Impact rating

Impact is rated across four categories: safety, financial, operational and privacy. The safety dimension is what ties automotive cybersecurity to functional safety — a spoofed sensor value can be a safety event, not merely a data event. The rating should reflect the worst credible outcome of the threat scenario, argued and recorded, not asserted.

Attack path analysis and feasibility

Next you work out how an attacker would actually get there — the chain of steps from a starting point to the compromise. Then you rate how feasible that path is. Feasibility considers things like the time, expertise, equipment, and window of opportunity an attack needs. A catastrophic impact reached only by an implausible path carries less risk than a moderate impact reached trivially; the method forces you to hold both facts at once.

Risk and treatment

Risk value combines impact and feasibility. Each risk then gets a treatment decision — reduce it (add a control), share it (push to a supplier or insurer), retain it (accept with justification), or avoid it (remove the feature). The decision, and its rationale, is the work product. A high risk that is simply retained without argument is the kind of thing that stops an assessment.

How the TARA feeds everything else

The output of the TARA is not the end of the story — it is the input to the concept phase. Risks that are to be reduced become cybersecurity goals, and those goals become the cybersecurity concept and, downstream, requirements and architecture. That handover is clauses 9.4 and 9.5 of the standard, which we cover in Goals, claims and requirements. The thread from a threat scenario to a goal to a requirement to a test is exactly the traceability an assessor follows.

The TARA also informs how much rigour a given item deserves. ISO/SAE 21434 defines the Cybersecurity Assurance Level (CAL), derived largely from impact and the attack vector, as an informative way to scale the depth of the engineering. It is not a pass/fail grade — it guides how hard you work, not whether you passed. We unpack it in Cybersecurity Assurance Level (CAL) explained.

Common failures

Three failure modes recur. The first is a TARA with no maintained link to the design — it was written, the architecture moved on, and the two no longer match. The second is impact ratings and feasibility ratings asserted without argument, so an assessor cannot see the reasoning. The third is a treatment column full of "reduce" with no corresponding requirement or evidence that the reduction was implemented and verified. All three are traceability failures, and all three are avoidable with discipline rather than tooling.

The AutoSifu view

We run the TARA as the spine of a programme, not a deliverable to be filed. It is where safety and security meet, and where the evidence chain that an R155 or AIS-189 assessment follows is first laid down. Working with CIRT (Pune) as our strategic partner, we keep one route — build the analysis and the concept, solution the controls, and prepare the CoC and type-approval evidence with the approval body in the room — so the TARA an assessor eventually opens is one they can trace end to end.