Automotive TARA Template (ISO/SAE 21434, UN R155)

Threat Analysis and Risk Assessment (TARA): [Item name]

The threat analysis and risk assessment (TARA) for one vehicle item or component, structured on the TARA methods of ISO/SAE 21434:2021 (Road vehicles, Cybersecurity engineering, clause 15) as used in the concept phase (clause 9) and during development and operations, and written as evidence for the cybersecurity management system (CSMS) and vehicle type approval under UN Regulation No. 155, with links to software update management under UN Regulation No. 156. It covers the item definition, assets and cybersecurity properties, damage scenarios and impact ratings, threat scenarios, attack paths, attack feasibility, risk values, treatment decisions, cybersecurity goals and claims, and the traceability to requirements and to the Annex 5 threat list of UN R155. Replace every [bracketed] value and every row marked Example. ISO/SAE 21434 is a paid standard: this template cites its structure and clause numbers only and does not reproduce its text, tables or rating values.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and basis
2. Item definition
3. Rating scales and risk matrix
4. Asset identification
5. Damage scenarios and impact rating
6. Threat scenario identification
7. Attack path analysis
8. Attack feasibility rating
9. Risk value determination
10. Risk treatment decisions
11. Cybersecurity goals, claims and concept
12. UN R155 link and lifecycle
13. Traceability matrix
14. Glossary and references

1. Purpose, scope and basis

1.1 Purpose

This TARA identifies what could be harmed if the item is attacked, how it could be attacked, how feasible each attack is, and what the resulting risk is. It records the decision for each risk and derives the cybersecurity goals and claims that the cybersecurity concept and later requirements must satisfy. It is evidence for the vehicle type cybersecurity assessment and for the manufacturer's CSMS.

1.2 Basis

Clause and subclause numbers refer to the 2021 first edition; check them against your licensed copy. A second edition is at an early ISO stage (ISO/SAE AWI 21434 in the ISO catalogue data checked in October 2026); check its status before relying on this structure.

1.3 Scope and distribution of work

2. Item definition

2.1 Item and functions

2.2 Boundary and interfaces

2.3 Architecture overview

The diagram shows the preliminary architecture with the interface IDs from section 2.2. Arrows show the direction in which an attacker can reach the next element, which is the direction attack paths follow in section 7.

2.4 Operational environment and assumptions

Assumptions that the item relies on but does not control become cybersecurity claims in section 11.2 when a risk is retained or shared because of them.

3. Rating scales and risk matrix

3.1 Impact rating

ISO/SAE 21434 rates damage scenarios in four impact categories, safety, financial, operational and privacy (often abbreviated SFOP), each on four levels: severe, major, moderate and negligible. Use your organisation's criteria for each level; the descriptions below are an example calibration.

The road user is the stakeholder for impact rating. Damage to the manufacturer (warranty cost, brand) may be recorded separately but does not replace the road-user view.

3.2 Attack feasibility rating

ISO/SAE 21434 describes three approaches to rate attack feasibility: attack potential-based, CVSS-based and attack vector-based. Choose one per project and record why. This example uses the attack potential-based approach, which rates five factors: elapsed time, specialist expertise, knowledge of the item or component, window of opportunity, and equipment. Take the factor values and the mapping to the four feasibility levels (high, medium, low, very low) from your licensed copy of the standard or your CSMS procedure; this template does not reproduce them.

The attack vector-based approach (network, adjacent, local, physical) suits early concept work when attack paths are not yet detailed. Move to the attack potential-based approach once the architecture is stable.

3.3 Risk matrix (Example calibration)

Risk values range from 1 (lowest) to 5 (highest). The matrix below is a fictional calibration for the worked example: it combines impact and feasibility so that negligible impact always gives 1. Replace it with the matrix approved in your CSMS.

3.4 Treatment rule (Example)

The approval level in section 10 follows the residual risk after treatment; the decision band follows the initial risk value.

4. Asset identification

5. Damage scenarios and impact rating

Coordinate safety ratings with the functional safety team: a damage scenario rated severe for safety should map to a hazardous event in the HARA (compliance/iso-26262-hara), or the TARA should explain why not.

6. Threat scenario identification

Fill the Annex 5 reference with the row or paragraph identifiers of the version of UN R155 that applies to the type approval. Section 12.2 shows the completeness check the other way round.

7. Attack path analysis

7.1 Attack paths

7.2 Attack tree for TS-01 (Example)

Detailed trees belong in security/attack-tree; keep only the summary here and reference the tree ID.

8. Attack feasibility rating

Enter factor ratings using the scale in your licensed copy of the standard or CSMS procedure (section 3.2). Where more than one path leads to a threat scenario, the most feasible path sets the scenario's feasibility.

9. Risk value determination

Some organisations compute a risk value per impact category instead of from the highest impact. Either is acceptable if the CSMS procedure says which is used; do not mix methods inside one TARA.

10. Risk treatment decisions

Avoiding a risk means removing the function or the interface. Example: the debug port could be omitted from production boards entirely; the team kept it, locked, to support field failure analysis, and recorded that choice under TS-02.

11. Cybersecurity goals, claims and concept

11.1 Cybersecurity goals

11.2 Cybersecurity claims

11.3 Cybersecurity concept summary

Describe how the goals are met at architecture level: which element implements which control, how controls depend on each other, and which requirements in requirements/system-requirements derive from each goal. Record verification for each goal in quality/vv-plan.

12. UN R155 link and lifecycle

12.1 Regulatory context

UN Regulation No. 155 entered into force on 22 January 2021 under the 1958 Agreement. In the European Union, the General Safety Regulation (Regulation (EU) 2019/2144) made it mandatory for new vehicle types from July 2022 and for all new vehicles of the covered categories from July 2024. UN Regulation No. 156 covers software update management systems and works alongside it. Other markets reference ISO/SAE 21434 without adopting R155; for example the United States National Highway Traffic Safety Administration published non-binding Cybersecurity Best Practices for the Safety of Modern Vehicles (September 2022). Check the current amendment series and your type approval authority's interpretation documents.

12.2 Annex 5 completeness check

12.3 Monitoring and update triggers

13. Traceability matrix

14. Glossary and references

14.1 Glossary

These are original paraphrases, not the definitions of the standard.

14.2 References

Standard and licence note

Structure aligned with ISO/SAE 21434:2021 (first edition, August 2021), clauses 7, 8, 9 and 15, and based on UN Regulations No. 155 and No. 156 and Regulation (EU) 2019/2144. Clause numbers and method names are cited for orientation; all wording is original, and no definitions, tables, rating values or examples from the standard are reproduced. The rating descriptions and risk matrix are fictional calibrations for the worked example. Check the current ISO catalogue, the applicable UN R155 and R156 amendment series and your type approval authority's interpretation documents before use.

Official text: ISO and SAE International, purchase or licensed access: https://www.iso.org/standard/70918.html (also available from national standards bodies). UN Regulations: UNECE, free of charge, https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security.

All organisations, items and identifiers in the examples are fictional. Template licence: MIT.