ISO 21434 TARA: How to Do a Threat Analysis and Risk Assessment for Automotive Cybersecurity

Why Automotive Cybersecurity Is Now Non-Negotiable

UN Regulation 155 (UN R155) mandated that from July 2024, all new vehicle type approvals in regulated markets require a certified Cybersecurity Management System (CSMS). ISO 21434 is the technical standard that defines how to build it.

For automotive safety engineers, the critical insight is this: cybersecurity and functional safety are not separate concerns. A successful cyberattack that compromises a safety-critical system is a functional safety violation — the safety mechanisms designed to prevent harm can be circumvented. ISO 21434 and ISO 26262 must be aligned, and TARA is the mechanism that makes that alignment explicit.

What Is TARA?

Threat Analysis and Risk Assessment (TARA) is the cybersecurity equivalent of HARA. Where HARA identifies hazardous events and rates their severity/exposure/controllability to derive safety goals, TARA identifies threat scenarios and rates their risk to derive cybersecurity goals.

TARA is defined in ISO 21434 Clause 15. The process has four main steps:

1. Asset identification — what does the system have that an attacker would want to compromise?
2. Threat scenario identification — how could an attacker damage, disclose, or misuse those assets?
3. Attack path analysis — what is the feasibility of each attack?
4. Risk determination — what is the risk level, and what treatment is required?

Step 1: Asset Identification

Assets are things of value that can be harmed. In automotive cybersecurity, assets fall into categories:

Cybersecurity properties (the CIA triad + authenticity):

• Confidentiality: Is the asset sensitive data that must not be disclosed? (e.g., personal driving data, cryptographic keys)
• Integrity: Must the asset's value be trustworthy? (e.g., sensor data, software, control signals)
• Availability: Must the asset be accessible when needed? (e.g., safety-critical functions, communication buses)
• Authenticity: Must the source of the asset be verified? (e.g., software updates, diagnostic commands)

Example assets for an EPS (Electronic Power Steering) system:

• Steering torque command signal on CAN (Integrity, Availability)
• Software update package (Integrity, Authenticity)
• Diagnostic access (Availability, Confidentiality)
• Cryptographic keys for secure boot (Confidentiality, Integrity)

For each asset, document the damage scenario: what bad outcome happens if this cybersecurity property is violated?

Step 2: Threat Scenario Identification

A threat scenario describes how an adversary could compromise an asset's cybersecurity property.

Example threat scenarios for EPS:

• Attacker injects false steering torque commands via OBD-II port (CAN injection) → Integrity of torque command violated → Unintended steering
• Attacker flashes modified software via unsecured OTA mechanism → Integrity/Authenticity of software violated → Persistent malicious behavior
• Attacker blocks legitimate diagnostic access via CAN flooding → Availability of diagnostic function → Prevents safety-relevant fault detection

Each threat scenario should reference:

• The asset being attacked
• The cybersecurity property being violated
• The damage scenario that results
• The attack vector (physical access, short-range wireless, remote network)

Step 3: Attack Path Analysis and Feasibility

For each threat scenario, identify one or more attack paths — sequences of steps an attacker would need to execute. Then rate the feasibility of each attack using ISO 21434's CVSS-derived approach or the Attack Feasibility Rating (AFR) method.

Attack Feasibility Rating factors:

• Elapsed time: How long would the attack take? (≤1 day / ≤1 week / ≤1 month / >1 month)
• Specialist expertise: What knowledge is needed? (Layman / Proficient / Expert / Multiple experts)
• Knowledge of item: How much access to design documents or the item itself is needed?
• Window of opportunity: Is physical/network access to the vehicle required? How restricted?
• Equipment: What tools are needed? (Standard / Specialized / Bespoke)

Lower feasibility = higher attacker effort required = lower risk (all else equal).

Step 4: Risk Determination

Risk in TARA = Impact × Attack Feasibility

Impact is rated on a scale similar to ISO 26262 severity, considering:

• Safety impact (could this harm people?)
• Financial impact (loss to OEM, supplier, or user)
• Operational impact (vehicle unavailability, service disruption)
• Privacy impact (personal data exposure)

Risk value combines impact and feasibility into a risk matrix (ISO 21434 Table B.9). The outcome is one of four risk treatment options:

• Avoid: Remove the asset or function
• Reduce: Apply cybersecurity controls to reduce impact or feasibility
• Share: Transfer risk (insurance, contractual)
• Retain: Accept the residual risk (with documented rationale)

Most cybersecurity goals come from the "Reduce" treatment path.

Connecting TARA to Functional Safety

This is where ISO 21434 and ISO 26262 must explicitly align. Cybersecurity threats that can lead to safety hazardous events need to be reflected in both:

• The Functional Safety Concept: safety mechanisms that assume authentic sensor data must consider what happens if that data is compromised
• The ISO 26262 HARA: if a cyberattack can cause a hazardous event, that hazardous event needs a safety goal that addresses both the random/systematic failure path and the attack path

ISO 21434 Clause 5.4.3 specifically requires that cybersecurity goals that impact functional safety be coordinated with the functional safety team.

In practice: every cybersecurity goal derived from a threat scenario that maps to a safety-relevant damage scenario should link to the corresponding ISO 26262 safety goal. The safety mechanisms protecting against the hazardous event must be reviewed for their cybersecurity resilience.

How ISO WIZ Handles ISO 21434 TARA

ISO WIZ includes a structured TARA workflow with asset identification, cybersecurity property documentation, threat scenario generation, attack path analysis, feasibility rating, risk determination, and cybersecurity goal derivation. All threat scenarios that map to safety-relevant damage scenarios are automatically linked to the corresponding ISO 26262 hazardous events and safety goals. Cross-standard consistency gaps — where a cybersecurity threat is unaddressed in the safety concept — are flagged in real time.