A threat analysis and risk assessment, or TARA, is the method automotive teams use to find what could go wrong with a vehicle function, rate the risk and decide what to do about it. Steps run from defining the item and its assets to scenarios, attack paths, a risk value and a treatment decision.
Where TARA sits
Synopsys describes TARA as its main way to manage cybersecurity risk, covering evaluation, assessment methods, treatment and planning. It says the methods align with NIST SP 800-30 and ISO/IEC 31010. Treat this as an outline and check the standard itself before building a process on it.
The steps
Synopsys summarizes TARA in three steps: asset identification with damage scenarios, threat identification, and risk calculation with a decision to avoid, reduce, transfer or accept. Teams commonly expand that into a longer working sequence:
- Item definition. Describe the system, its boundary and its interfaces.
- Asset identification. List what must be protected, such as a braking command, a key, a log or a software image.
- Damage scenarios. State what harm results if an asset loses confidentiality, integrity or availability.
- Threat scenarios. Describe how an attacker could cause that loss.
- Attack paths. Trace the steps from an entry point to the asset.
- Risk determination. Combine impact and attack feasibility.
- Treatment. Reduce, avoid, share or retain the risk, and record why.
The Synopsys summary says the methods address the likelihood and impacts of attacks. It does not give a scoring formula, so pick and document your own rating scale.
A short worked outline
Take a remote door unlock feature through the telematics unit.
- Item: telematics unit, cloud service, door control unit.
- Asset: the unlock command.
- Damage: a stranger enters a parked vehicle.
- Threat: a forged unlock command reaches the door unit.
- Path: compromised cloud account, then telematics unit, then gateway, then bus.
- Treatment: authenticate commands end to end, restrict what the gateway forwards, and monitor for unusual command rates.
The value of the exercise is that the path shows several places to break the chain, not just one.
Making it useful rather than a document
- Run it early, when a design change is still cheap.
- Keep it linked to the architecture, so a changed interface triggers a review.
- Reuse threat libraries, but have engineers who know the design challenge each entry.
- Record the reason for every accepted risk, with an owner and a review date.
What to do after a vulnerability appears
Clause 8 of ISO/SAE 21434, as summarized by UL, asks manufacturers to keep checking that risk assumptions and countermeasures stay current. A new vulnerability in a component should send you back to the TARA entries that depended on it.
Quick check
Is a TARA a one time deliverable?
No. It should be revisited when the design, the supply chain or the threat information changes.
Sources
Last reviewed: 19 October 2026.
