Step 1: Scope and Item Definition

Before identifying threats, you need a precise definition of what you are analyzing — the item in ISO 21434 terms. The item definition specifies:

  • The functions the item performs
  • The external interfaces (what the item connects to and what protocols it uses)
  • The operational environment (where the item is deployed, who interacts with it, and under what conditions)
  • Boundary conditions (what is inside the item's scope and what is external)

For an ECU with vehicle-to-cloud connectivity, the item definition must explicitly include the cloud backend as an external entity with which the item communicates — even if the cloud backend is not in your system boundary. The interface between the ECU and the cloud is in scope.

Common scoping failures:

  • Excluding the telematics interface because it is managed by a different supplier. If your ECU receives commands over the telematics channel, that channel is an attack surface regardless of who owns the telematics module.
  • Excluding the OBD-II port because it requires physical access. Physical access attacks are in scope for ISO 21434, with appropriate feasibility ratings.
  • Defining too broad a scope (the entire vehicle) without the resources to analyze it. The TARA scope should match the item being certified.

Step 2: Asset Identification

An asset in ISO 21434 is anything of value that could be harmed by a cybersecurity attack. Assets have properties — confidentiality, integrity, availability, or authenticity — whose violation would constitute a cybersecurity impact.

Asset identification is not brainstorming. It is a structured derivation from the item's functions and their safety, financial, operational, and privacy implications.

For an ADAS processing unit, assets include:

  • Perception algorithm parameters and calibration data (integrity asset: if modified, object detection may fail)
  • Safety mechanism enable signals (availability and authenticity assets: if blocked or spoofed, safety functions may not activate)
  • Software update package (authenticity and integrity assets: if a malicious update is installed, the ECU behavior is compromised)
  • Sensor data streams (integrity asset: if manipulated, the system's environmental model is incorrect)
  • Diagnostic access (availability asset: if blocked, legitimate diagnostics cannot be performed; authenticity asset: if accessed without authorization, proprietary data is exposed)

The safety relevance of each asset must be assessed. Assets whose compromise could cause a hazardous event (as defined in the ISO 26262 HARA) are safety-relevant assets and require the highest cybersecurity assurance.

This is where TARA connects directly to HARA. If the HARA identifies unintended acceleration as a hazardous event with S3 severity, the asset analysis must identify what can be attacked to cause unintended acceleration — and those assets inherit the S3 safety impact.

Step 3: Threat Scenario Construction

A threat scenario describes a specific attack against a specific asset that causes a specific impact. It has the form:

[Attacker] attacks [asset] via [interface] to [violate asset property], resulting in [impact].

For the safety mechanism enable signal asset:

A remote attacker injects a falsified CAN message that spoofs the safety mechanism enable signal as active, while the safety mechanism is actually disabled, preventing the AEB system from engaging during a collision scenario.

Threat scenarios must be specific enough to enable attack path analysis. "Hacker compromises ECU" is not a threat scenario. "Attacker with remote access exploits an unauthenticated UDS diagnostic session to overwrite calibration data in flash memory, modifying the AEB activation threshold" is a threat scenario.

The ISO 21434 standard does not mandate a specific methodology for threat scenario construction, but common approaches include STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) applied to each asset-interface combination, and PASTA (Process for Attack Simulation and Threat Analysis) for more complex systems.

Step 4: Attack Path Analysis

For each threat scenario, the attack path analysis traces the specific technical steps an attacker must follow to realize the threat. The attack path consists of attack steps, each with a feasibility assessment.

An attack path for the diagnostic session threat scenario above might be:

Each step has a feasibility assessment based on the CVSS-derived metrics in ISO 21434 Clause 15.6: elapsed time, specialist expertise required, knowledge of the item, window of opportunity, and equipment required.

The total attack path feasibility is the product of the feasibility of each step. A path with one difficult step and three easy steps may still be overall feasible — the easy steps must be weighted appropriately.

Step 5: Impact Assessment

Impact is assessed for each threat scenario across four impact categories defined in ISO 21434 Clause 15.5:

  • Safety impact: Does the attack cause a hazardous event? Use the ISO 26262 severity scale: S0 (no injuries) to S3 (life-threatening or fatal)
  • Financial impact: What is the cost of the attack to the OEM, supplier, and customer? (vehicle recall, liability, repair)
  • Operational impact: Does the attack affect vehicle usability or functionality?
  • Privacy impact: Does the attack expose personal data?

The overall impact rating is the most severe across all four categories. Safety impact at S3 produces the highest overall impact rating regardless of other categories.

Step 6: CAL Assignment and Risk Treatment

The Cybersecurity Assurance Level (CAL) is determined from the combination of impact and attack feasibility. ISO 21434 Clause 15.8 maps these two dimensions to CAL 1 through CAL 4, where CAL 4 represents the highest cybersecurity assurance requirement.

(Simplified; actual ISO 21434 Annex E table should be used for normative assessment.)

Each threat scenario with CAL 1 or higher requires a risk treatment decision: accept the risk with justification (rare, for low-impact scenarios), avoid the risk by removing the functionality or interface, share the risk through insurance or contractual arrangements (limited applicability), or reduce the risk by implementing cybersecurity controls.

CAL-4 threat scenarios drive the most stringent controls: SecOC with strong MACs, hardware security modules for key storage, secure boot chains, and intrusion detection systems.

Common TARA Mistakes

Conflating attack feasibility with attacker motivation. ISO 21434 assessment is based on what is technically feasible for an attacker with appropriate skills — not on whether you believe attackers would be motivated to attempt it. Motivation is not a TARA input.

Omitting physical access attack paths. Physical access to the OBD-II port or direct hardware access requires specific expertise and equipment, but it is a credible attack path. The feasibility is lower than remote access, but the impact may be higher (direct flash access, bypassing all software controls). It must be in the TARA.

Deriving cybersecurity requirements without CAL assignment. A list of security controls without documented CAL derivation fails the traceability requirement of ISO 21434. Every security requirement must trace to a threat scenario, which traces to a CAL, which traces to a risk treatment decision.

Treating TARA as a one-time deliverable. ISO 21434 requires TARA updates when the item definition changes, when new vulnerabilities are discovered, or when the operational environment changes. A TARA last updated at SOP is not compliant for a vehicle with a 10-year operational life.

TARA in ISO WIZ

ISO WIZ structures the TARA as a live analysis — assets, threat scenarios, attack paths, impact assessments, and CAL ratings are all linked objects with bidirectional traceability to the ISO 26262 HARA and to the cybersecurity requirements they generate.

When the HARA severity rating for a hazardous event changes, ISO WIZ automatically flags the linked TARA damage scenarios for impact re-assessment. When a new threat scenario is added, the system prompts for attack path entries and generates a draft cybersecurity requirement based on the CAL assignment.

This makes the TARA a living document rather than a development-phase artifact.