# TARA step by step: a worked threat analysis for an ECU

How to run a TARA under ISO/SAE 21434: asset identification, threat scenarios, attack paths, feasibility and risk, worked through for a single diagnostic ECU.

Source: https://auto-st.com/insights/tara-step-by-step · Updated: 2026-10-07

A TARA (Threat Analysis and Risk Assessment) is the structured way ISO/SAE 21434 asks you to decide what to protect and how hard. Clause 15 lays out the steps; this guide works them through for a single diagnostic ECU so the method is concrete. The output is a set of cybersecurity requirements you can test against, not a document that sits on a shelf. It is engineering judgement, supported by evidence, not a tool output.

## The steps, in order

ISO/SAE 21434 Clause 15 defines a chain where each step feeds the next:

1. **Asset identification** with cybersecurity properties (confidentiality, integrity, availability).
2. **Damage scenarios**: what harm follows if a property is lost.
3. **Threat scenarios**: how an asset's property could be compromised.
4. **Attack path analysis**: the concrete routes to realise a threat.
5. **Attack feasibility rating**: how hard each path is.
6. **Impact rating**: how bad the damage is, across safety, financial, operational and privacy.
7. **Risk value**: impact combined with feasibility.
8. **Risk treatment**: reduce, share, retain or avoid.

## Worked example: a diagnostic ECU

Take an ECU that controls an actuator and exposes UDS diagnostics over CAN.

### Assets and damage scenarios

| Asset | Property | Damage scenario |
| --- | --- | --- |
| Actuator control logic | Integrity | Unauthorised actuation, a possible safety event |
| Calibration data | Integrity | Altered behaviour outside the validated envelope |
| Firmware | Integrity | Persistent malicious code via the flashing path |
| Identification data (serial, fingerprint) | Integrity | Component cloning or anti-theft bypass |

### Threat scenarios

For the calibration asset: "An attacker modifies calibration data by writing a calibration DID without authorisation." That is a precise, testable statement, which is the point of a good threat scenario.

### Attack path analysis

Break the threat into a path. For the calibration write:

```
1. Reach the ECU on the CAN bus (physical or via a gateway)
2. Enter the session that exposes the write service:   10 03
3. Attempt the calibration write:                      2E F1 A0 <data>
4. If 0x33 securityAccessDenied, defeat SecurityAccess: 27 01 / 27 02
5. Write accepted:                                      6E F1 A0
```

Each step is a point where a control either stops the attacker or does not. The path is a hypothesis about what the ECU allows.

### Attack feasibility rating

ISO/SAE 21434 offers an attack-potential approach based on elapsed time, expertise, knowledge of the item, window of opportunity and equipment. Rate each path from those factors into a feasibility level (very low to high). A write that needs only bus access and a standard tester rates far higher than one that needs recovered firmware and a lab.

This is exactly where testing changes the number. The path above assumes `0x27` can be defeated. If a bench test shows the SecurityAccess seed is constant and there is no lockout, the step "defeat SecurityAccess" is trivial, and the feasibility jumps. If the test shows the write is simply not reachable without a valid key, the path is far harder. An estimated feasibility becomes an observed one.

### Impact rating

Rate the damage across the four categories. An unauthorised actuation on a safety-relevant ECU is a high safety impact; altered identification data may be low safety but higher financial and operational.

### Risk value and treatment

Combine impact and feasibility into a risk value, then decide treatment. For the calibration path, if feasibility is high because SecurityAccess is weak, the sensible treatment is to reduce risk: fix the seed/key gate and add a lockout, which drops the feasibility and the risk. Each treatment decision becomes a cybersecurity requirement, for example "the calibration write service shall require an unlocked SecurityAccess level with a random seed and a brute-force lockout".

## From TARA to testable requirements

The value of the chain is that it ends in requirements you can verify. "SecurityAccess shall have a random seed and a working lockout" is a sentence a test can confirm or refute on the bench. The TARA names the attack paths; testing measures how open they really are; the verification evidence then feeds back into the risk picture. On a full TARA we wrote for an ADAS Tier-1, the diagnostic write paths were the ones that moved most once real feasibility replaced assumptions.

## Where AutoST fits, and where it does not

AutoST does not write your TARA. A TARA is an engineering judgement about assets, damage and attackers, and no scanner produces that. What AutoST does is test the attack paths a TARA identifies: whether services are reachable without authentication, whether SecurityAccess holds, whether identification DIDs are writable, whether the flashing path is exposed. Those results turn estimated feasibility into observed feasibility, which is the input a TARA most often lacks. The TARA, the cybersecurity concept and the risk treatment are consulting work, which Zyberum offers alongside the tool.

## FAQ

**What are the steps of a TARA under ISO/SAE 21434?**

Clause 15 defines them: asset identification, damage scenarios, threat scenarios, attack path analysis, attack feasibility rating, impact rating, risk determination, and the risk treatment decision. Each step feeds the next, and the output drives your cybersecurity requirements.

**How does security testing relate to a TARA?**

The attack paths in a TARA are hypotheses. Testing confirms or refutes them: a path like 'write a calibration DID without authentication' is either reachable on the bench or it is not. Test results turn an estimated feasibility into an observed one.

**Who should write the TARA?**

Someone who understands both the item's function and the attacker's options, usually a cybersecurity engineer working with the function owner. A test team can supply feasibility evidence, but the TARA itself is an engineering judgement, not a tool output.

## Sources

- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, Clause 15 Threat analysis and risk assessment](https://www.iso.org/standard/70918.html)
- [UN Regulation No. 155, Cyber security and cyber security management system](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)

## Related

- [TARA (Threat Analysis and Risk Assessment)](https://auto-st.com/glossary/tara)
- [ISO/SAE 21434](https://auto-st.com/glossary/iso-sae-21434)
- [ECU (Electronic Control Unit)](https://auto-st.com/glossary/ecu)
- [Evidence for your 21434 work, on tap.](https://auto-st.com/iso-21434-testing)
- [Does your seed/key actually hold?](https://auto-st.com/security-access-testing)
- [ISO/SAE 21434 verification evidence from security testing](https://auto-st.com/insights/iso-21434-verification-evidence)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/insights/tara-step-by-step