What Is a TARA? And Why a Spreadsheet Eventually Stops Being Enough

What Is a TARA?

TARA stands for Threat Analysis and Risk Assessment. It is the central analysis method of ISO/SAE 21434, and if I have to explain it in one sentence: a TARA answers, in a structured way, what is worth protecting in a vehicle or component, how an attacker could compromise it, how severe the consequences would be, and what you do about it.

One point I think is important, and one I often see misunderstood: a TARA is not a list of identified threats. It is an auditable record of risk decisions. That distinction may sound like splitting hairs, but it is the core of the matter. Naming a threat is the first step; the decision about it, and the reasoning behind that decision, are the actual deliverable.

Why Does a TARA Matter?

The obvious reason is regulatory. For type approval under UNECE R155, an OEM must demonstrate that it has identified and addressed cybersecurity risks across the lifecycle. The TARA is the primary technical evidence you present. Without a credible TARA, there is no clean R155 type approval — and without that, no market authorization in the affected regions.

The reason I find more important: a TARA forces you to think through security early, rather than bolting it on afterward. ISO 21434 follows the V-model across the entire development lifecycle, and the TARA sits as early as the concept phase (Clause 9). If you only start thinking about attack paths after implementation, you pay for every design decision twice. Security by design is not a slogan — it is simply cheaper.

The Steps of a TARA

A TARA runs through four steps that build on each other.

• Item Definition. First, you define what is actually being analyzed: the item with its functions, data, components, channels, and data flows, plus the assumptions made and the system boundary. Without clean scoping, the analysis has no foundation.
• Asset Identification & Impact Rating. Elements become assets once a security property is attached to them — confidentiality, integrity, or availability. For the qualifying assets, you derive damage scenarios and assess how severe the harm would be, across impact categories like safety, financial, operational, and privacy consequences. The result is the Impact Level (IL).
• Threat Analysis. Now you ask how a security property can be violated. You derive threat scenarios and the corresponding attack paths, supported by a threat catalog and a control catalog, and assess the feasibility of each attack based on factors like elapsed time, expertise, window of opportunity, and equipment. The result is the Attack Feasibility Level (AFL) — derived from the method, not estimated from intuition.
• Determine Risks. Impact and Attack Feasibility together yield the Risk Level (RL) via a defined risk matrix. For each risk you then make a treatment decision: reduce, avoid, share, or accept — each with the chosen controls or a justification for risk acceptance.

One detail that often gets lost: controls you introduce are themselves new assets that need protection. A TARA is therefore iterative — you run the loop until the residual risk is acceptable.

I Have a TARA. Is That Enough?

No. And that is not a formality.

A TARA is a living document (see Living TARA). ISO 21434 addresses this through ongoing cybersecurity activities (Clause 8): monitoring, evaluating new events, vulnerability analysis across the entire lifecycle. If a new CVE surfaces in an installed component tomorrow, the question is not “is there a threat?” — there always is. The question is: does this CVE change the AFL on an attack path that was previously considered acceptable? Does it open a path the original analysis did not account for?

You can only answer that question if the original decision is documented and retrievable. Otherwise you start from scratch every time. That is precisely why R155 mandates continuous maintenance. A TARA you write once and file away is already outdated at the moment of the first new attack.

Can’t You Just Use Excel?

For getting started: yes, absolutely. If you are learning the method, analyzing a small item, or building intuition for the assessment logic, a spreadsheet gets you far. I would not recommend buying a tool for the first exercise.

The point where Excel breaks down is not the first TARA — it is the tenth change to it. Once attack paths propagate across components, once the same asset appears in multiple scenarios, once a single CVE triggers reassessments in five places at once, the spreadsheet becomes a source of errors. Maintaining consistency by hand across hundreds of rows is exactly the work humans do poorly and tools do well. And auditability — who decided what, when, and on what basis — is practically impossible to get right in a table.

For a serious, audit-ready TARA, I recommend tool support. itemis SECURE guides you through the steps, keeps the IL, AFL, and RL assessments consistent, calculates propagation across attack paths, and maintains the decision history. It does not take the analysis off your hands — it is not supposed to — but it keeps the bookkeeping clean so you can focus on the actual decisions.

What About Threat Modeling?

It is worth looking back here. Threat modeling — the systematic thinking through of attackers, targets, and attack paths — predates ISO 21434 by a long way. Approaches like STRIDE or attack trees have been around in IT security for decades, and the method that inspired the standard traces back to work like MoRA at Fraunhofer AISEC.

So the TARA does not reinvent threat modeling. It takes an established discipline and wraps it in a normative framework: defined rating scales, a fixed risk matrix, required work products, and an obligation to maintain it over the lifecycle. Threat modeling is the mindset; the TARA is the auditable, type-approval-ready form of it. If you already practice threat modeling, you have already understood the harder part — you just need to take care of the traceability that ISO 21434 requires.

Conclusion

A TARA is a structured threat analysis with a fixed framework and a clear purpose: auditable risk decisions that hold up to R155 scrutiny and are maintained over the lifecycle. It starts with item definition and never fully ends, because the threat landscape keeps shifting. For the first steps, a spreadsheet works fine; for serious, ongoing operation, it becomes a liability.

The transition from spreadsheet to tool happens for everyone at a different point. If you are right at that point now and want to talk through what a tool-supported TARA looks like in your context, you can reach me via the contact form on itemis.com or directly on LinkedIn.

Cyber Security at itemis — Systematic security engineering for automotive, IoT and Industry 4.0: Cyber Security →