ISO/SAE 21434 TARA: A Worked Automotive Risk Assessment and Its Limits

Covers ISO/SAE 21434:2021 (first edition) and UN Regulation No. 155 as enforced in June 2026.

TARA stands for Threat Analysis and Risk Assessment, and it is the method at the center of automotive cybersecurity engineering, defined in Clause 15 of ISO/SAE 21434. It picks up where the last two posts in this series stopped. STRIDE and LINDDUN are discovery frameworks: they help you enumerate what can go wrong. TARA assumes you have that list and forces the two questions that turn it into decisions: how bad would each scenario be for the people in and around the vehicle, and how hard would it be to pull off. The output is a risk value from 1 to 5 for every threat scenario, plus a documented decision about what you are doing in response.

This post runs a complete TARA, all seven activities, against the same telematics backend I modeled in the STRIDE and LINDDUN posts. Then it covers the part the training courses skip: where the method strains, and what it takes to keep the result alive once the system starts changing underneath it.

Two frameworks named TARA

A name collision first. MITRE also publishes a methodology called TARA, Threat Assessment and Remediation Analysis, a systems-security-engineering process from around 2010 built for US defense acquisition. It runs as two trade studies over catalogs mapped to CAPEC and CWE. That is the other TARA and it shares nothing with the automotive method beyond the acronym and the general shape of listing threats and picking countermeasures. In automotive work, TARA in a job posting, an audit finding, or a supplier questionnaire means the ISO/SAE 21434 method. It means that for the rest of this post too.

Why this one has teeth

ISO/SAE 21434, “Road vehicles - Cybersecurity engineering,” was published in August 2021 as a joint ISO and SAE standard, superseding SAE J3061 from 2016. It is a process standard. It tells you which activities and work products a development lifecycle needs and says almost nothing about how to build any specific control. The whole document is 81 pages; ISO 26262, its functional-safety sibling, runs to twelve parts.

The reason a process standard gets this much attention is UN Regulation No. 155. R155 makes cybersecurity a condition of vehicle type approval across UNECE markets, which include the EU, the UK, Japan, and South Korea. It has applied to new vehicle types since July 2022 and to all newly produced vehicles in scope since July 2024. To get a type approved, a manufacturer needs an audited Cybersecurity Management System plus per-type evidence that risks were assessed and treated. R155 never names ISO/SAE 21434, but a Clause 15 TARA is the evidence everyone brings, and the regulation’s Annex 5 carries its own threat catalog, including a back-end server section that reads like it was written about this post’s system, which the assessment has to demonstrably consider.

The United States has no equivalent gate. NHTSA’s Cybersecurity Best Practices for the Safety of Modern Vehicles, finalized in September 2022, is voluntary guidance, and it points readers at Clause 15 for risk assessment rather than defining its own. So the commercial picture is uneven: selling into UNECE markets, the TARA is homework that gets graded. Selling US-only, it is best practice with no proctor.

The seven activities

Clause 15 defines the methods. You apply them during the concept phase (Clause 9) to an “item,” the standard’s word for the system under analysis, and the assembled result becomes work product WP-09-02, with the cybersecurity goals that fall out of it as WP-09-03.

One framing difference from the earlier posts is worth noticing before we start. STRIDE and LINDDUN walk the diagram element by element. TARA is asset-centric and consequence-first: you begin from what is valuable and what its loss does to a human, and only later work out how an attacker gets there. The standard does not require a data flow diagram at all; it requires an item definition with a boundary and a preliminary architecture. A DFD happens to be a perfectly good architecture view to read assets off, and reusing the same one keeps the three posts comparable.

The telematics backend, third pass

Same system as before. A fleet of vehicles, each with a telematics control unit (TCU), checks in to a backend over cellular. The backend ingests telemetry, including precise GPS, and sends commands back down, including remote door unlock and the trigger for an over-the-air update. A fleet operator drives all of this from a web dashboard. The item boundary is the backend and its edges, same scope as the STRIDE pass.

Notation is covered in the STRIDE post: circles are processes, the cylinder is the data store, loose rectangles are external entities, dashed boxes are trust boundaries.

15.3 Asset identification

An asset, in 21434 terms, is anything with a cybersecurity property whose compromise leads to a damage scenario, and a damage scenario is always phrased as a consequence for road users, not for the architecture. That discipline is the point of the step. “The database gets popped” is not a damage scenario. “A stranger can open and start your car” is.

Reading assets off the diagram: the command authorization state (which identities may command which vehicles, integrity and authenticity), the location history and subscriber PII in the store (confidentiality), the TCU identity key material (authenticity), the command audit log (integrity), and the availability of the command path itself. From those, three damage scenarios carry the analysis:

Although this telematics back office system design doesn’t represent a real system, none of these are hypothetical for this class of system and that is exactly why I picked it. I will attach the receipts in the attack path step.

15.4 Threat scenario identification

A threat scenario names how a cybersecurity property of an asset could be compromised to cause a damage scenario. The standard deliberately does not tell you how to enumerate these. In practice most teams plug in STRIDE here, and since I already ran STRIDE on this exact system, the work is done: I am promoting findings from that post rather than inventing new ones.

The regulatory minimum requirement sits here too. R155’s Annex 5 Part A is a catalog of threats your assessment must demonstrably consider, and its back-end entries (unauthorized internet access to back-end servers, back-end systems used as a means to attack a vehicle or extract data, abuse of privileges by staff) map directly onto TS1 and TS2. Annex 5 is examples, not a method, and it is explicitly not exhaustive. Treat it as the minimum bar an auditor will check your threat list against, not as the threat list.

15.5 Impact rating

Each damage scenario gets rated in four categories, Safety, Financial, Operational, and Privacy, and each category rating is one of Severe, Major, Moderate, or Negligible. Safety is the one category with an external anchor: it derives from the severity classes in ISO 26262, the functional-safety standard, so a damage scenario that produces life-threatening injuries rates Severe and one that produces none rates Negligible. The other three categories you argue from consequences: financial cost class, disruption to operations, harm from personal-data exposure.

Walking D1: Safety lands at Moderate for me. Unlock plus remote start of a parked vehicle is theft and intrusion, not motion control; nobody is steering anything into traffic through this path as drawn. The honest caveat is that the rating is hostage to the architecture. The 2015 Jeep work showed a telematics entry point reaching brakes and steering, and if this backend’s command path could touch motion control, Safety goes to Severe and drags everything with it. Financial is Major: the cost class here is a recall-grade response, and the precedent is FCA recalling about 1.4 million vehicles over exactly this kind of remote pathway. Operational is Major, since the scenario is fleet-wide by construction. Privacy is Major, because the realistic attack bundles owner PII with the command capability.

The Overall column carries the highest of the four ratings forward, which is the dominant interpretation of the standard rather than a sentence you can quote from it. Two of these cells already show the method’s soft spots. I rated D2’s Safety as Negligible on the grounds that disclosure causes no direct injury, while the stalking pathway it enables is real; a colleague could defensibly put Moderate there. And D3’s Operational sits right on the Moderate/Major line depending on how long you assume the outage runs. Write the rationale next to the rating. A rating without its argument is just a colored cell that is hard to justify 6 months down the road without re-analysis.

15.6 Attack path analysis

Now the attacker’s half. For each threat scenario you enumerate attack paths, and the standard blesses working top-down (decompose from the threat, attack-tree style) or bottom-up (build up from known weaknesses). I am doing this bottom-up, from documented incidents, because for telematics backends the public record is generous.

The path that makes TS1 concrete is the Kia one. In June 2024, Sam Curry, Neiko Rivera, Justin Rhinehart, and Ian Carroll found that Kia’s dealer portal would let anyone register a bogus dealer account and mint a valid dealer token. With that token: resolve a license plate to a VIN, pull the owner’s name, email, and phone, silently reassign the vehicle’s “ownership” to an attacker-controlled account, and then issue lock, unlock, start, and locate commands to nearly any Kia built after 2013. The whole chain ran in about thirty seconds per car, the owner was never notified, and it worked whether or not the car had an active Connect subscription. Kia patched it in August 2024 and the team published that September. So attack path AP1 for TS1 reads: internet, to dealer self-registration, to dealer API token, to plate-to-VIN lookup, to ownership reassignment, to the command API obeying. Every hop is an authorization decision the backend got wrong; none requires touching the vehicle.

The same shape shows up across the industry. Curry’s earlier work, published January 2023 across sixteen manufacturers and suppliers, included sending vehicle commands through SiriusXM’s connected-vehicle platform knowing only a VIN, taking over MyHyundai accounts with only an owner’s email address, and reaching an admin panel at the telematics supplier Spireon that sat over roughly 15.5 million devices, most of them vehicles. A second, duller path for TS1 is worth a row of its own: AP2, credential stuffing against the operator dashboard, assuming no MFA. Where a threat scenario has several paths, the standard has you carry the most feasible one forward.

The 2015 Jeep research is the contrast case and the reason the Safety caveat above exists. Miller and Valasek entered through the cellular side, an open D-Bus service on the Uconnect head unit reachable over Sprint’s network, then reflashed a chip to bridge onto the CAN bus and reach motion control. That path enters outside this item’s boundary, so it is out of scope here, but it is the standing reminder that the telematics channel can end at the brakes, and a backend TARA that forgets it will under-rate Safety.

15.7 Attack feasibility rating

Each path gets a feasibility rating of High, Medium, Low, or Very Low, and Clause 15.7 permits three ways to produce it: an attack-potential calculation, a CVSS-based derivation, or a coarse rating from the attack vector alone. I use attack potential, because it forces the rating into five arguable parameters instead of one gut call. The parameter set is older than the standard: it is the Common Criteria attack-potential model from ISO/IEC 18045, which reached automotive through the EVITA project and the HEAVENS method before 21434 adopted it. You score each parameter, sum the points, and a higher total means a harder attack, so it maps to a lower feasibility:

Scoring AP1 against the Kia facts: elapsed time in the low weeks (the team’s discovery effort, not the thirty-second execution), expertise of a proficient web tester, knowledge of the item public (everything was found from outward-facing endpoints), window unlimited (the portal faced the internet around the clock), equipment standard (a browser and an intercepting proxy). Every parameter sits at or near the cheap end, the sum lands in single digits, and the rating is High. One opinion from doing these for real: “knowledge of the item” is where teams flatter themselves. Scoring your own portal as confidential because the API is undocumented is self-deception; Curry’s crew had no documentation either. Rate knowledge by what a motivated outsider can recover, not by what you published.

AP2, credential stuffing without MFA, also rates High; the parameters barely move. TS2 I rate Medium: bulk exfiltration of the store needs an internal foothold and lateral movement, which pushes elapsed time and expertise up the table. TS3, a handshake flood against the gateway, rates High, since making a server start expensive TLS handshakes requires no credentials at all.

15.8 Risk value determination

Impact and feasibility combine into a risk value from 1 (lowest) to 5 (highest), usually through a matrix. The standard’s matrix is an informative example and organizations define their own, with the fixed points being that Negligible impact pins risk at 1 and Severe impact at High feasibility is a 5. With a matrix of that shape:

The numbers look authoritative and they are not measurements. They are ordinal summaries of the arguments made in 15.5 and 15.7, and they are exactly as good as those arguments. More on that below.

15.9 Risk treatment decision

For each risk you pick one of four options, aligned with ISO 31000: avoid the risk, reduce it, share it, or retain it. This little system manages to need all four.

TS1 gets reduced, and the reductions become cybersecurity goals (WP-09-03), which is how a TARA hands work to the design phase. Verified dealer onboarding with out-of-band identity checks. Step-up authentication and mandatory owner notification on any ownership change. Command tokens scoped to a single VIN and short-lived. Each goal traces back to a hop in AP1, which is what makes it defensible in review. One sub-decision is avoidance rather than reduction: the public plate-to-VIN lookup gets removed outright. It existed for convenience and it was the pivot of the whole chain. Deleting a function is the one treatment that could mitigate the risk but it should be carefully reviewed to ensure the threat is sufficiently mitigated.

TS2 also gets reduced, with the controls from the earlier posts (encryption at rest, tight access scoping, retention limits, and the LINDDUN answer of collecting coarser location in the first place). If the connected-vehicle service runs on a third-party platform, SiriusXM-style, part of this risk gets shared by contract. Worth saying plainly: sharing moves liability, not consequence. R155 holds the vehicle manufacturer answerable for the supply chain, and the headline will carry your brand, not your supplier’s.

TS3, at risk value 3, gets retained, with the rationale written down: rate limiting and load shedding exist from the STRIDE pass, a flood degrades rather than destroys, and the residual risk is accepted with a monitoring trigger attached. Retention is a legitimate outcome. An assessment where nothing is ever retained is usually an assessment where feasibility got inflated to make every mitigation look mandatory. I am all for mitigating all cybersecurity risks but in reality we have finite resources. This is why risk assessments are so important to ensuring those resources are allocated properly to maximize the protection of product.

A note on CAL, since it comes up in every 21434 conversation: Annex E sketches Cybersecurity Assurance Levels, CAL 1 through 4, a knob for how much rigor the resulting goals get in verification, conceptually parallel to ASIL in ISO 26262. It is informative, thin, and not required; follow-on work (ISO/SAE PAS 8475) is underway to firm it up. I mention it so you recognize it, not because this analysis needs it.

That is the full pass. Asset to damage scenario to threat scenario to path to feasibility to risk value to a signed decision, and every column traceable to an argument.

Where TARA breaks down

The ratings are judgments wearing numbers. Severe versus Major, Medium versus High, Moderate versus Major on the D3 row above: every one is a call two competent raters can make differently, and the 1-to-5 output hides that softness behind integer confidence. STRIDE at least has published precision-and-recall studies; I have not found an equivalent inter-rater reliability study for 21434 TARA, which is itself worth knowing. Treat risk values as ordered summaries of written arguments, and refuse to accept a value that arrives without its argument.

The three feasibility methods do not agree. Attack potential, CVSS-derived, and attack-vector-based ratings of the same path can land on different feasibility levels, and published comparisons bear this out. Inside one program this is manageable: pick one method and hold it. Across organizations it means a “risk 4” is not a unit of anything, and comparing TARA outputs between suppliers without asking which method produced them is asking for misalignment.

Incentives lean on the scales. Every rating decision changes how much work follows it. Score feasibility down and a mitigation evaporates; score impact up and you look admirably cautious for the auditor. Neither pull announces itself. The working defenses are written rationale on every rating and review by another security engineer not directly involved with the project.

It discovers nothing. Clause 15 is a rating and deciding shell around whatever threat list you feed step 15.4. Feed it a shallow list and you get confidently scored, formally treated, audit-ready thin analysis. The discovery quality comes from the engine you plug in, which is why the STRIDE pass happened first and why Annex 5 is a floor and not a method.

It rots, and needs to be actively managed. The standard explicitly permits doing all this with basic office tools, and most TARAs live in spreadsheets that fork per vehicle variant, break their cross-references, and drift from the architecture within a quarter. Dedicated tools exist (Ansys medini analyze, itemis SECURE, Vector’s tooling) and they fix the bookkeeping. They do not fix the management of the TARA. A TARA is a snapshot in time for an audit. If it is not actively refreshed until the next audit it can quickly become out of date and not reflect current architectures or emergent threats.

Keeping the TARA alive

The standard’s own answer to staleness is Clause 8, the continual activities: monitor sources, evaluate cybersecurity events, analyze and manage vulnerabilities. Those exist to feed the TARA after the concept phase ends. In practice the re-run triggers worth wiring up are an architecture or interface change to the item, a vulnerability or incident in your own product, published research that names your pattern, and a change in the operating environment.

The Kia disclosure is the walkthrough of the third trigger. If you operated anything with a dealer portal in September 2024, that publication was a prompt to reopen your TARA, re-score “knowledge of the item” and “specialist expertise” on every path that assumed portal access was hard, and check whether any retained risk just changed bands. The honest test of a living TARA is whether WP-09-02 shows a diff that month. Treat the document like code: owned, versioned, reviewed, and diffed, because an approval gate two years ago is not evidence about the system you ship today.

The takeaway

TARA does not find risk and it does not remove any. What it does is force the two questions engineers skip when a threat list gets long, how bad and how hard, and make someone write the answers down in units the organization agreed on in advance, with a named decision at the end of every row. That is the generalizable lesson beyond automotive: any risk method is a protocol for arguing, and its output is worth exactly the weakest argument it contains. The frameworks from the earlier posts decide what makes it onto the list. This one decides what you do about the list, and leaves your signature on it.

Further reading

• ISO/SAE 21434:2021, Road vehicles - Cybersecurity engineering. The standard itself (paywalled). The informative annexes are where the worked material lives: Annex E (CAL), F (impact rating), G (attack feasibility), H (a full TARA on a headlamp system).
• UN Regulation No. 155, consolidated text in the EU Official Journal. Annex 5 is the threat catalog; Section 7.2.2 is where the risk-assessment obligation lives.
• NHTSA, Cybersecurity Best Practices for the Safety of Modern Vehicles (2022). The voluntary US counterpart.
• Miller and Valasek, Remote Exploitation of an Unaltered Passenger Vehicle (2015). The telematics-to-CAN pivot, and the trigger for the first cybersecurity recall.
• Curry et al., Web Hackers vs. The Auto Industry (January 2023) and Hacking Kia (September 2024). The back-office attack paths this post’s walkthrough is built on.
• ISO/IEC 18045 and the Common Criteria evaluation methodology. Where the attack-potential parameters come from.
• My STRIDE writeup and LINDDUN writeup: the discovery half, on this same system.