# 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.

<!--
Guidance: How to use this template
- Start from a stable item definition (section 2). A TARA on a moving
  boundary produces threats nobody can trace to an interface.
- Work in the order of ISO/SAE 21434 clause 15: assets, damage
  scenarios, impact, threat scenarios, attack paths, feasibility, risk,
  treatment. Do not jump to controls; the TARA rates the design as it is
  and the treatment decision says what changes.
- Write the rationale for every rating. A rating without a reason is
  the most common finding in CSMS audits and type approval assessments.
- Calibrate the rating scales and the risk matrix once per organisation
  (section 3) and reuse them across items, so that risk values compare.
  The scales below are fictional examples; use the values your licensed
  copy of the standard and your CSMS procedures set.
- Re-run the TARA when the item changes, when a new vulnerability or
  attack technique appears in monitoring, and before each release
  (section 12).
- The worked example is fictional: Varnholt Mobility GmbH, a vehicle
  manufacturer, assessing remote unlock and climate pre-conditioning
  through a telematics control unit (TCU). Delete it.
- Related templates: Hazard Analysis and Risk Assessment
  (`compliance/iso-26262-hara`), SOTIF Analysis
  (`compliance/sotif-analysis`), Threat Model
  (`security/threat-model`), Attack Tree (`security/attack-tree`),
  Software FMEA (`ops/fmea-software`), PSIRT Vulnerability Handling
  (`security/psirt-vulnerability-handling`), SBOM and VEX Policy
  (`security/sbom-vex-policy`), System Requirements
  (`requirements/system-requirements`), Traceability Matrix
  (`requirements/traceability-matrix`), Verification and Validation Plan
  (`quality/vv-plan`).
-->

## Document control

<!-- Guidance: The TARA is a work product of the cybersecurity case. Record the item version it applies to and an independent reviewer; type approval authorities and CSMS auditors check both. -->

| Field | Value |
|---|---|
| Document ID | [TARA-NNN] |
| Item or component | [Name, variant, hardware and software baseline] |
| Vehicle programme and type | [Programme, vehicle type, model year] |
| Lifecycle phase | [Concept / Product development / Post-development update] |
| Cybersecurity plan reference | [CSP-ID] |
| CSMS certificate of compliance | [Certificate number, issuing approval authority, expiry] |
| Version | [0.1] |
| Status | [Draft / In review / Released / Superseded] |
| Owner | [@cybersecurity-engineer] |
| Approvers/reviewers | [@cybersecurity-manager], [@system-architect], [@functional-safety-manager], [@supplier-cybersecurity-contact] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential, restricted distribution] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Item cybersecurity manager | [@name] | [Approved / Approved with conditions] | YYYY-MM-DD |
| Independent reviewer (cybersecurity assessment) | [@name] | [Accepted / Findings] | YYYY-MM-DD |
| Functional safety manager (safety impacts) | [@name] | [Consulted] | YYYY-MM-DD |
| Supplier cybersecurity lead (distributed activities) | [@name] | [Agreed per interface agreement] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for concept phase |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Released with cybersecurity goals CG-01 to CG-05 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* TS-02 feasibility re-rated after public debug-port attack technique reported in monitoring |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Purpose, scope and basis](#1-purpose-scope-and-basis)
2. [Item definition](#2-item-definition)
3. [Rating scales and risk matrix](#3-rating-scales-and-risk-matrix)
4. [Asset identification](#4-asset-identification)
5. [Damage scenarios and impact rating](#5-damage-scenarios-and-impact-rating)
6. [Threat scenario identification](#6-threat-scenario-identification)
7. [Attack path analysis](#7-attack-path-analysis)
8. [Attack feasibility rating](#8-attack-feasibility-rating)
9. [Risk value determination](#9-risk-value-determination)
10. [Risk treatment decisions](#10-risk-treatment-decisions)
11. [Cybersecurity goals, claims and concept](#11-cybersecurity-goals-claims-and-concept)
12. [UN R155 link and lifecycle](#12-un-r155-link-and-lifecycle)
13. [Traceability matrix](#13-traceability-matrix)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and basis

<!-- Guidance: Say which item and which phase this TARA covers, and which external obligations it serves. Pitfall: a TARA scoped to one ECU when the threat enters through the backend. Include off-board interfaces that reach the item. -->

### 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

| Source | What it provides | Where used |
|---|---|---|
| ISO/SAE 21434:2021, clause 9 (concept phase: item definition, cybersecurity goals, cybersecurity concept) | Work products derived from the TARA | Sections 2, 11 |
| ISO/SAE 21434:2021, clause 15 (TARA methods: asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination, risk treatment decision; subclauses 15.3 to 15.9) | Method structure | Sections 4 to 10 |
| ISO/SAE 21434:2021, clause 8 (continual cybersecurity activities) | Monitoring and vulnerability analysis that trigger TARA updates | Section 12.3 |
| ISO/SAE 21434:2021, clause 7 (distributed cybersecurity activities) | Supplier interface agreement and shared TARA work | Sections 1.3, 10 |
| UN Regulation No. 155 (cyber security and CSMS) | CSMS certificate, vehicle type requirements, Annex 5 threats and mitigations | Section 12 |
| UN Regulation No. 156 (software update and SUMS) | Update path security as an attack surface and a treatment | Sections 4, 11 |

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

| Item | In scope | Responsible party | Interface agreement |
|---|---|---|---|
| TCU hardware and firmware *(Example)* | Yes | Tier 1 supplier, TARA input on component level | CIA-014 |
| Remote services backend and mobile app *(Example)* | Yes, as attack entry points | Varnholt Mobility connected services | Internal |
| Central gateway and body controller *(Example)* | Yes, as targets reached from TCU | Varnholt Mobility E/E | Internal |
| Cellular network operator *(Example)* | No, assumption only (section 2.4) | Operator | Contract |
| [Element] | [Yes / No] | [Party] | [Reference] |

## 2. Item definition

<!-- Guidance: Clause 9.3 asks for the item boundary, functions, preliminary architecture and operational environment. List every external interface; each is an entry point in section 7. -->

### 2.1 Item and functions

| Function ID | Function | Description |
|---|---|---|
| F-01 *(Example)* | Remote unlock and lock | Owner sends lock or unlock from the mobile app; backend signs a command; TCU verifies and forwards to body controller through the gateway |
| F-02 *(Example)* | Climate pre-conditioning | Owner schedules cabin heating or cooling; TCU wakes the vehicle and requests the thermal system |
| F-03 *(Example)* | Vehicle status and location | TCU reports lock state, battery level and position to the backend for display in the app |
| F-04 *(Example)* | Over-the-air update of TCU firmware | Signed update packages through the SUMS process under UN R156 |
| [F-NN] | [Function] | [Description] |

### 2.2 Boundary and interfaces

| Interface ID | Interface | Direction | Protocol or medium | Exposure |
|---|---|---|---|---|
| IF-01 *(Example)* | Cellular link TCU to backend | Both | LTE, mutual TLS | Remote |
| IF-02 *(Example)* | TCU to central gateway | Both | CAN FD | Internal vehicle network |
| IF-03 *(Example)* | Debug and programming port on TCU board | Inbound | JTAG, UART | Physical, requires disassembly |
| IF-04 *(Example)* | Mobile app to backend | Both | HTTPS, OAuth 2.0 | Remote, internet |
| IF-05 *(Example)* | Diagnostic connector (OBD) to gateway | Both | UDS over CAN | Physical, cabin access |
| [IF-NN] | [Interface] | [Direction] | [Protocol] | [Exposure] |

### 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.

```mermaid
flowchart LR
    APP["Mobile app"] -->|"IF-04"| BE["Remote services backend"]
    BE -->|"IF-01 cellular"| TCU["Telematics control unit"]
    DBG["Debug port"] -->|"IF-03"| TCU
    TCU -->|"IF-02 CAN FD"| GW["Central gateway"]
    OBD["Diagnostic connector"] -->|"IF-05"| GW
    GW --> BCM["Body controller: locks"]
    GW --> TH["Thermal system"]
```

### 2.4 Operational environment and assumptions

| ID | Assumption | Owner | Verified by |
|---|---|---|---|
| ASM-01 *(Example)* | The backend is operated under the manufacturer's information security management system and is in scope of the CSMS | Connected services | CSMS audit |
| ASM-02 *(Example)* | The cellular operator provides no confidentiality; all protection is end to end | E/E architecture | Design review |
| ASM-03 *(Example)* | Workshops use authenticated diagnostic tools with role-based access | Aftersales | Process audit |
| [ASM-NN] | [Assumption] | [Owner] | [Evidence] |

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

<!-- Guidance: Clause 15 lets the organisation define its scales and risk matrix. Write the organisation's calibrated scales once and reference them; the values below are a fictional calibration for illustration, not values from the standard. -->

### 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.

| Level | Safety *(Example)* | Financial *(Example)* | Operational *(Example)* | Privacy *(Example)* |
|---|---|---|---|---|
| Severe | Life-threatening or fatal injuries possible | Loss threatening the road user's livelihood | Loss of a core vehicle function affecting safe use | Highly sensitive data linked to the person, significant harm |
| Major | Severe injuries possible | Substantial loss for the road user | Loss of an important function, vehicle still usable | Personal data linked to the person, serious harm |
| Moderate | Light injuries possible | Inconvenient but manageable loss | Partial degradation of a function | Personal data with limited harm |
| Negligible | No injury | No or trivial loss | No noticeable effect | No or trivial privacy effect |

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.

| Impact / Feasibility | Very low | Low | Medium | High |
|---|---|---|---|---|
| Severe | 3 | 4 | 5 | 5 |
| Major | 2 | 3 | 4 | 5 |
| Moderate | 1 | 2 | 3 | 4 |
| Negligible | 1 | 1 | 1 | 1 |

### 3.4 Treatment rule *(Example)*

| Risk value | Default decision | Approval |
|---|---|---|
| 4 or 5 | Reduce (cybersecurity goal); retain or share only with a claim and manager approval | Item cybersecurity manager and programme lead |
| 3 | Reduce where practical; otherwise retain or share with a claim | Item cybersecurity manager |
| 1 or 2 | Retain with rationale | Cybersecurity engineer |

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

## 4. Asset identification

<!-- Guidance: Subclause 15.3. An asset is something whose compromise leads to a damage scenario. Name the cybersecurity property (confidentiality, integrity, availability) at stake for each asset. Pitfall: listing every ECU as an asset; list the data, functions and keys that matter. -->

| Asset ID | Asset | Cybersecurity property | Why it matters |
|---|---|---|---|
| AS-01 *(Example)* | Remote unlock command message | Integrity, authenticity | Forged or altered commands unlock the vehicle |
| AS-02 *(Example)* | TCU firmware | Integrity | Modified firmware gives control over IF-02 |
| AS-03 *(Example)* | Vehicle position data | Confidentiality | Reveals the owner's movements |
| AS-04 *(Example)* | TCU remote service availability | Availability | Owner cannot lock or pre-condition remotely |
| AS-05 *(Example)* | Update signing key (backend HSM) | Confidentiality, integrity | Key compromise allows malicious updates to the fleet |
| AS-06 *(Example)* | Pre-conditioning command | Integrity, freshness | Replayed commands drain the traction battery |
| [AS-NN] | [Asset] | [C / I / A] | [Reason] |

## 5. Damage scenarios and impact rating

<!-- Guidance: Subclause 15.3 links assets to damage scenarios; subclause 15.5 rates their impact. Write the damage at vehicle and road-user level. Rate all four categories, then carry the highest to the risk step and keep the others for traceability. -->

| DS ID | Damage scenario | Assets | Safety | Financial | Operational | Privacy | Highest | Rationale |
|---|---|---|---|---|---|---|---|---|
| DS-01 *(Example)* | Vehicle unlocked without the owner's consent, contents or vehicle stolen | AS-01 | Negligible | Major | Moderate | Moderate | Major | Theft of vehicle or contents is a substantial loss; locks do not affect driving |
| DS-02 *(Example)* | Attacker injects messages on the vehicle network that affect driving functions | AS-02 | Severe | Major | Major | Negligible | Severe | Gateway filtering is not yet a validated barrier at concept stage |
| DS-03 *(Example)* | Owner's movements disclosed to an unauthorised party | AS-03 | Negligible | Negligible | Negligible | Major | Major | Location history enables stalking and profiling |
| DS-04 *(Example)* | Remote services unavailable | AS-04 | Negligible | Negligible | Moderate | Negligible | Moderate | Inconvenience; vehicle usable with the key |
| DS-05 *(Example)* | Malicious update installed across the fleet | AS-05 | Severe | Major | Severe | Major | Severe | Fleet-wide effect; worst case reaches driving functions |
| DS-06 *(Example)* | Battery drained by repeated pre-conditioning | AS-06 | Negligible | Moderate | Moderate | Negligible | Moderate | Vehicle not available at departure; roadside assistance cost |

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

<!-- Guidance: Subclause 15.4. Each threat scenario names the asset, the property compromised and the cause. Use a structured catalogue (for example STRIDE) and the UN R155 Annex 5 threat list as a completeness check. -->

| TS ID | Threat scenario | Asset and property | Damage scenario | Threat category | R155 Annex 5 reference |
|---|---|---|---|---|---|
| TS-01 *(Example)* | Attacker abuses a flaw in the backend API to issue a signed unlock command for a vehicle they do not own | AS-01, integrity | DS-01 | Spoofing, elevation of privilege | Back-end server threats [Annex 5 row ref] |
| TS-02 *(Example)* | Attacker with physical access reflashes the TCU through the debug port and sends crafted CAN frames | AS-02, integrity | DS-02 | Tampering | Threats to vehicle data or code; potential vulnerabilities [ref] |
| TS-03 *(Example)* | Attacker intercepts position reports on the cellular link | AS-03, confidentiality | DS-03 | Information disclosure | Communication channel threats [ref] |
| TS-04 *(Example)* | Attacker jams the cellular link near the vehicle | AS-04, availability | DS-04 | Denial of service | Communication channel threats [ref] |
| TS-05 *(Example)* | Insider or intruder extracts the update signing key from the backend | AS-05, confidentiality | DS-05 | Information disclosure, tampering | Update procedure threats [ref] |
| TS-06 *(Example)* | Attacker records and replays a pre-conditioning command | AS-06, integrity, freshness | DS-06 | Spoofing (replay) | Communication channel threats [ref] |

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

<!-- Guidance: Subclause 15.6. For each threat scenario, describe the steps from an entry point (section 2.2) to the asset. Top-down (attack trees) suits early phases; bottom-up from known vulnerabilities suits later phases. -->

### 7.1 Attack paths

| AP ID | Threat scenario | Entry point | Steps | Preconditions |
|---|---|---|---|---|
| AP-01 *(Example)* | TS-01 | IF-04 | 1. Register an app account. 2. Find an object-level authorisation flaw in the vehicle pairing endpoint. 3. Pair victim VIN to own account. 4. Request unlock; backend signs and sends over IF-01 | Internet access, knowledge of the API |
| AP-02 *(Example)* | TS-02 | IF-03 | 1. Remove TCU from vehicle. 2. Connect to debug port. 3. Bypass debug lock. 4. Flash modified firmware. 5. Reinstall and send crafted frames on IF-02 | Physical access for about one hour, specialist tools |
| AP-03 *(Example)* | TS-03 | IF-01 | 1. Operate a rogue base station. 2. Downgrade link. 3. Attempt to intercept TLS session | Proximity, radio equipment; mutual TLS must be broken |
| AP-04 *(Example)* | TS-04 | IF-01 | 1. Operate a jammer near the parked vehicle | Low-cost equipment, proximity |
| AP-05 *(Example)* | TS-05 | Backend administration | 1. Phish an administrator. 2. Escalate in backend network. 3. Export key material from signing service | Backend compromise and access to the signing service |
| AP-06 *(Example)* | TS-06 | IF-01 or IF-04 | 1. Capture a valid command. 2. Replay it repeatedly | Ability to capture traffic or app session |

### 7.2 Attack tree for TS-01 *(Example)*

```mermaid
flowchart TD
    G["TS-01: forged remote unlock"] --> O1["Abuse backend authorisation flaw"]
    G --> O2["Steal owner's app session"]
    G --> O3["Forge command without backend"]
    O1 --> A1["Pair foreign VIN to own account"]
    O2 --> A2["Phish owner credentials"]
    O2 --> A3["Malware on owner phone"]
    O3 --> A4["Obtain TCU command verification key"]
```

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

## 8. Attack feasibility rating

<!-- Guidance: Subclause 15.7. Rate each attack path, then take the most feasible path per threat scenario. Record the factor ratings and the reason, so a reviewer can repeat the rating. -->

| AP ID | Elapsed time | Expertise | Knowledge of item | Window of opportunity | Equipment | Feasibility | Rationale |
|---|---|---|---|---|---|---|---|
| AP-01 *(Example)* | [Factor rating] | [Factor rating] | [Factor rating] | Unlimited, remote | Standard | Medium | Web API flaws of this class are well documented; requires finding one in this backend |
| AP-02 *(Example)* | [Factor rating] | [Factor rating] | [Factor rating] | Physical access to vehicle | Specialised | Low | Disassembly and debug-lock bypass need specialist skill and tools |
| AP-03 *(Example)* | [Factor rating] | [Factor rating] | [Factor rating] | Proximity | Specialised | Low | Mutual TLS with pinned certificates; downgrade alone does not reveal content |
| AP-04 *(Example)* | [Factor rating] | [Factor rating] | [Factor rating] | Proximity | Standard | High | Jamming equipment is cheap; no skill needed |
| AP-05 *(Example)* | [Factor rating] | [Factor rating] | [Factor rating] | Remote, needs insider or deep intrusion | Specialised | Low | Keys sit in a backend HSM, but key export settings and dual control are not yet specified at concept stage |
| AP-06 *(Example)* | [Factor rating] | [Factor rating] | [Factor rating] | Remote | Standard | Medium | Concept design has no freshness value in the command |

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

<!-- Guidance: Subclause 15.8. Combine the highest impact (section 5) with the feasibility (section 8) using the matrix in section 3.3. Show both inputs so the value can be rechecked. -->

| TS ID | Highest impact | Feasibility | Risk value | Treatment band (section 3.4) |
|---|---|---|---|---|
| TS-01 *(Example)* | Major | Medium | 4 | Reduce |
| TS-02 *(Example)* | Severe | Low | 4 | Reduce |
| TS-03 *(Example)* | Major | Low | 3 | Reduce where practical |
| TS-04 *(Example)* | Moderate | High | 4 | Reduce, or retain with claim and approval |
| TS-05 *(Example)* | Severe | Low | 4 | Reduce |
| TS-06 *(Example)* | Moderate | Medium | 3 | Reduce where practical |

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

<!-- Guidance: Subclause 15.9. The four options are avoiding, reducing, sharing and retaining the risk. Each decision needs a rationale and, for retain or share, a cybersecurity claim. Re-rate the residual feasibility after the planned controls and show the residual risk. -->

| TS ID | Decision | Treatment | Goal or claim | Residual feasibility | Residual risk | Approved by |
|---|---|---|---|---|---|---|
| TS-01 *(Example)* | Reduce | Object-level authorisation checks, ownership proof at pairing, owner confirmation in app for new pairings | CG-01 | Very low | 2 | Cybersecurity engineer |
| TS-02 *(Example)* | Reduce | Debug port locked in production, secure boot, gateway message filtering and authentication on IF-02 | CG-02, CG-03 | Very low | 3 | Item cybersecurity manager |
| TS-03 *(Example)* | Reduce | Keep mutual TLS with certificate pinning; minimise position precision and frequency | CG-04 | Very low | 2 | Cybersecurity engineer |
| TS-04 *(Example)* | Retain | No feasible in-vehicle control against radio jamming; user can operate with physical key | CL-01 | High | 4 | Item cybersecurity manager and programme lead |
| TS-05 *(Example)* | Share and reduce | HSM with export disabled and dual control (reduce); key custody obligations in backend operations agreement (share) | CG-05, CL-02 | Very low | 3 | Item cybersecurity manager |
| TS-06 *(Example)* | Reduce | Command freshness (counter and expiry), rate limit on pre-conditioning | CG-01 | Very low | 1 | Cybersecurity engineer |

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

<!-- Guidance: Clause 9.4 derives cybersecurity goals from reduced risks and cybersecurity claims from retained or shared risks. Goals are top-level requirements at item level; the cybersecurity concept (clause 9.5) allocates them. Optionally assign a cybersecurity assurance level (CAL, informative in the standard) to scale the rigour of later activities. -->

### 11.1 Cybersecurity goals

| Goal ID | Goal | Threat scenarios | CAL (optional) | Allocated to |
|---|---|---|---|---|
| CG-01 *(Example)* | Only the authorised owner can cause a lock, unlock or pre-conditioning command to be executed, and each command is executed at most once | TS-01, TS-06 | [CAL n] | Backend, TCU |
| CG-02 *(Example)* | Only authentic firmware runs on the TCU | TS-02 | [CAL n] | TCU |
| CG-03 *(Example)* | Messages from the TCU cannot affect driving functions | TS-02 | [CAL n] | Gateway |
| CG-04 *(Example)* | Vehicle position is disclosed only to the authorised backend and owner | TS-03 | [CAL n] | TCU, backend |
| CG-05 *(Example)* | Update packages accepted by vehicles can only be produced by the authorised signing process | TS-05 | [CAL n] | Backend, TCU, SUMS |
| [CG-NN] | [Goal] | [TS] | [CAL] | [Element] |

### 11.2 Cybersecurity claims

| Claim ID | Claim | Threat scenario | Basis | Owner |
|---|---|---|---|---|
| CL-01 *(Example)* | Loss of remote services through jamming does not prevent use of the vehicle with its physical key, and the owner's manual explains this | TS-04 | Retained risk, user information | Product owner |
| CL-02 *(Example)* | The backend operator keeps signing keys under dual control and reports key incidents within 24 hours | TS-05 | Shared risk, operations agreement | Connected services lead |

### 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

<!-- Guidance: UN R155 requires a certified CSMS (paragraph 7.2) and vehicle type measures (paragraph 7.3), with Annex 5 as a reference list of threats and mitigations. Show how this TARA feeds both. Check paragraph numbers against the version that applies to your approval. -->

### 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.

| R155 expectation (paraphrase) | Evidence from this TARA |
|---|---|
| CSMS processes identify risks to vehicle types, assess, categorise and treat them | Sections 4 to 10, using the CSMS rating procedure |
| Risks are assessed considering the threats in Annex 5 Part A and other relevant threats | Section 12.2 |
| Vehicle type is protected against identified risks with proportionate mitigations, considering Annex 5 mitigations | Sections 10, 11 |
| Risks from suppliers and service providers are managed | Sections 1.3, 11.2 |
| Monitoring, detection and response to attacks continue after production | Section 12.3 |
| Testing verifies the effectiveness of measures | Section 13 |

### 12.2 Annex 5 completeness check

| Annex 5 threat group (summary) | Considered in | Not applicable because |
|---|---|---|
| Back-end server threats | TS-01, TS-05 | |
| Communication channel threats | TS-03, TS-04, TS-06 | |
| Update procedure threats | TS-05 | |
| Unintended human actions | [TS or reason] | [Reason] |
| External connectivity threats | TS-01 | |
| Threats to vehicle data or code | TS-02, TS-03 | |
| Potential vulnerabilities that could be exploited if not sufficiently protected | TS-02 | |
| [Group] | [TS] | [Reason] |

### 12.3 Monitoring and update triggers

| Trigger | Action | Owner |
|---|---|---|
| New vulnerability in a component (CVE, supplier notice, PSIRT report) | Vulnerability analysis; re-rate affected attack paths | `security/psirt-vulnerability-handling` owner |
| New attack technique reported in monitoring or research | Re-rate feasibility of matching paths | Cybersecurity engineer |
| Change to item, interfaces or software baseline | Impact analysis; update affected sections | Item cybersecurity manager |
| Field incident or attempted attack | Incident response; TARA update and lessons learned | Vehicle security operations |
| Planned software update under UN R156 | Check update content against TARA before release | SUMS owner |

## 13. Traceability matrix

<!-- Guidance: One row per threat scenario, from asset to verification. Reviewers use this table to check that nothing is orphaned: every severe or major damage scenario has a goal or claim, every goal has requirements and tests. -->

| TS ID | Asset | Damage scenario | Risk value | Decision | Goal or claim | Requirements | Verification | Residual risk |
|---|---|---|---|---|---|---|---|---|
| TS-01 *(Example)* | AS-01 | DS-01 | 4 | Reduce | CG-01 | SYS-SEC-010, SYS-SEC-011 | Penetration test PT-03, API authorisation tests | 2 |
| TS-02 *(Example)* | AS-02 | DS-02 | 4 | Reduce | CG-02, CG-03 | SYS-SEC-020 to SYS-SEC-023 | Secure boot test, debug lock test, gateway fuzzing | 3 |
| TS-03 *(Example)* | AS-03 | DS-03 | 3 | Reduce | CG-04 | SYS-SEC-030 | TLS configuration review | 2 |
| TS-04 *(Example)* | AS-04 | DS-04 | 4 | Retain | CL-01 | USR-DOC-005 | Owner's manual review | 4 |
| TS-05 *(Example)* | AS-05 | DS-05 | 4 | Share and reduce | CG-05, CL-02 | SYS-SEC-050, OPS-AGR-002 | HSM configuration audit | 3 |
| TS-06 *(Example)* | AS-06 | DS-06 | 3 | Reduce | CG-01 | SYS-SEC-012 | Replay test | 1 |

## 14. Glossary and references

<!-- Guidance: Define the terms readers from safety, IT and procurement may not share. Keep standard names and editions exact. -->

### 14.1 Glossary

| Term | Meaning in this document |
|---|---|
| Item | The vehicle-level function and the components that realise it, taken as the unit this TARA analyses |
| Asset | Data, function, key or component worth protecting, because harm to it leads to a damage scenario |
| Damage scenario | What goes wrong for the road user when an asset loses a cybersecurity property |
| Threat scenario | How an asset could lose a cybersecurity property, linked to the damage scenario it would cause |
| Attack path | The sequence of steps an attacker takes from an entry point to carry out a threat scenario |
| Attack feasibility | How hard or easy an attack path is for a capable attacker, rated on four levels |
| Cybersecurity goal | Concept-level requirement tied to one or more threat scenarios |
| Cybersecurity claim | Recorded statement that justifies retaining or sharing a risk, with its basis |
| CAL | Cybersecurity assurance level, an informative way to scale the rigour of activities |
| CSMS | Cyber security management system under UN R155 |
| SUMS | Software update management system under UN R156 |

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

### 14.2 References

| Reference | Edition or date | Use |
|---|---|---|
| ISO/SAE 21434, *Road vehicles, Cybersecurity engineering* | 2021 (first edition); second edition in development | Clauses 7, 8, 9 and 15 |
| UN Regulation No. 155, Cyber security and cyber security management system | In force 22 January 2021; check the current amendments | Section 12 |
| UN Regulation No. 156, Software update and software update management system | Check the current amendments | Sections 2, 12.3 |
| Regulation (EU) 2019/2144 (General Safety Regulation) | Check the consolidated text | EU application dates |
| ISO 24089, *Road vehicles, Software update engineering* | 2023, with Amd 1:2024 | Update process context |
| NHTSA, *Cybersecurity Best Practices for the Safety of Modern Vehicles* (US) | September 2022 | Non-binding US guidance |
| ISO 26262-3, *Road vehicles, Functional safety, Part 3: Concept phase* | 2018 | Safety interface with HARA |

## 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.