Table of Contents
Automotive cybersecurity today raises more questions than answers. How do you assess risk in a connected vehicle? What changes when threats are intentional, not accidental? And how do you ensure security across a lifecycle that continues long after production?
ISO/SAE 21434 attempts to bring clarity to these questions.
For this article, we got our in-house cybersecurity experts to answer the most pertinent questions around ISO 21434 standard.
With them, we try to break down the standard through questions that engineers, suppliers, and OEMs are actively trying to answer, and what it really means in practice.
What is ISO/SAE 21434?
Jointly developed by ISO and SAE to replace SAE J3061, ISO/SAE 21434 is an international standard governing cybersecurity risk management of road vehicles.
It is a set of principles and guidelines that defines the processes, responsibilities, and required work products that OEMs and suppliers must follow to manage cybersecurity risks across the entire lifecycle of a vehicle’s electrical and electronic (E/E) systems.
It establishes a systematic engineering framework that ensures cybersecurity is treated as a priority requirement and is built into the design of automotive systems rather than added as an afterthought.
Why is ISO 21434 Necessary? What Challenges it Solves?
A decade ago, cars were far simpler machines. However, things have certainly changed today; the dependency has shifted from just engines to software-driven features, zonal architectures, wireless interfaces, and continuous cloud connectivity. While such smart features have clearly brought multiple benefits, have also expanded attack surface for security breaches.
Before the introduction of ISO 21434 standard, the approach to automotive cybersecurity was fragmented and siloed. OEMs and Tier‑1 suppliers defined their own practices, with no shared benchmark. ISO 21434 standard sought to close this gap. The standard provides a common, process‑driven approach that organizations can rely on to integrate cybersecurity into every stage of automotive development.
The Method: TARA and Lifecycle
Every meaningful engineering decision in automotive cybersecurity begins with one task: understanding the risks. In the following sections, we will discuss how ISO 21434 standard helps identify and mitigate the risk.
What is Cyber Risk Assessment in Automotives? How does it differ from IT risk assessment?
An automotive cybersecurity risk assessment is a detailed analysis performed by experts to understand, analyse, and mitigate a deliberate attack on its system. It identifies what could go wrong in an attack scenario, how likely it is, and predicts the possible consequences.
The primary aim of this assessment is to build protective measures that can contain the attack before it spreads. In comparison to IT risk assessments, cyber risk assessments in automotives are majorly differentiated by:
- Safety: An attack on automotive systems can alter a vehicle’s physical behaviour, not just its data or services.
- Physical interfaces: The automotive attacks paths in vehicles are much broader compared to IT infrastructures including Hardware‑level access points (i.e. debug ports to bootloaders and SIM interfaces).
- Long lifecycles: Vehicles have long lifecycles approximately around 15 years. While the development of its system is concerned only till production its cybersecurity demands continuous risk evaluation and mitigation throughout its lifecycle.
So, the real question is not just how to secure a vehicle but to understand the threats and the risks associated with them. And that brings us to TARA.
What is TARA?
Threat Analysis and Risk Assessment, or TARA, is the structured cybersecurity risk assessment approach for automotives. As entailed by ISO 21434, it assesses cybersecurity threats, evaluate their risk, and determine the controls needed to address them.
It is not a one‑off exercise. TARA is performed during the concept phase for every item in scope and revisited whenever the architecture, threat landscape, or operational context changes.
While ISO 21434 does not mandate a specific tool or modelling technique, but it does define the required outputs. The process unfolds in seven steps, with each step building directly on the previous one.
To learn in detail what is TARA and the seven steps in the process you can read our article on Threat Analysis and Risk Assessment.
What tools and methodologies help with TARA for automotive systems?
ISO 21434 defines what needs to be achieved but does not prescribe the specific methods. This allows organizations to be flexible in choosing methods that match their system complexity, internal skill sets, and tooling.
In practice, three methods are most used across the industry:
- STRIDE: This method provides a structured way to enumerate threats by categorizing them into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Applied to each interface element in an architecture diagram, it ensures broad and consistent coverage. For systems with multiple external interfaces, cellular, Bluetooth, OBD‑II, OTA.
- Attack Trees: This approach helps map how an attacker could reach a specific objective by decomposing the goal into prerequisite steps and alternative paths. They excel in Step 5 of TARA, where understanding attack feasibility matters most, because they make dependencies and effort visible.
- HEAVENS and SAHARA: Methods like HEAVENS and SAHARA are focused on offering automotive‑focused risk classification models that combine impact and likelihood into a unified security level. HEAVENS, developed by a European OEM consortium, and SAHARA, adapted from ISO 26262’s ASIL structure, both deliver clear prioritization for risk treatment decisions in TARA Steps 6 and 7.
In addition to the above methodologies, various tooling solutions are also used that range from full-featured platforms like ThreatModeler and IriusRisk to lightweight options such as Microsoft’s Threat Modelling Tool or structured spreadsheets.
While these tools help identify and assess risks, cybersecurity cannot rely on tools alone. It needs to be embedded into a structured process that spans the entire vehicle lifecycle.
What is the ISO 21434 automotive cybersecurity lifecycle?
The standard ISO 21434 directs the organization to structure their cybersecurity that extends beyond production throughout the lifecycle of vehicle.
The process is structured in five phases that ensures risks identified early are managed, verified, monitored in the field, and formally closed at the end of the vehicle’s life.
| Concept | Mentioned under Clause 9 of the ISO 21434, this phase establishes the foundation where TARA is performed, and the Cybersecurity plan is also developed based on which subsequent controls are implemented. |
| Product Development | The Clause 10 and 11 highlighted under the standard translates those goals into concrete engineering measures and verifies their effectiveness. Clause 10 defines and implements controls such as secure boot chains, HSM configurations, authentication and TLS requirements, and code‑level security rules. Clause 11 validates that these controls function as intended through penetration testing, fuzzing, and vulnerability assessments. |
| Production | This step further extends the cybersecurity into manufacturing process as detailed under Clause 12. It entails how processes must prevent the introduction of vulnerabilities during build and provisioning. This includes secure key injection onto ECUs, controlled access to production tools, and disabling debug interfaces before units leave the line. |
| Post‑Production | The Clause 13 of ISO 21434 demands the vehicle’s operational security for as long as it remains in service. This phase has no predefined endpoint and continues throughout vehicle’s entire operational life. Organizations often use updates for this that enables vulnerability monitoring, incident‑response system, and keep records of security‑relevant events. |
| Decommissioning | This phase comes at the end of vehicle’s life. It ensures cybersecurity activities also must consider securely erasing personal data, protection of cryptographic keys via extraction and issuing an end‑of‑support notice to owners. |
Standards and Compliance
While ISO 21434 itself covers a broad aspect of vehicle cybersecurity challenges, it also operates within a larger ecosystem of regulations. It supports various other audit frameworks, and standards like , UN R155 that collectively define the practical requirements. Therefore, it’s important to understand how these different standards and frameworks are connected to each other.
Let’s start with ISO 26262!
How is ISO 21434 Different from ISO 26262?
Among various standards, ISO 26262 stands out as the closest to ISO 21434 in terms of scope and system overlap.
ISO 26262 addresses functional safety challenges with risks caused by accidental faults like failure of brake‑by‑wire module due to a software defect. Additionally, it also entails Hazard Analysis and Risk Assessment (HARA) that identifies safety hazards and assigns Automotive Safety Integrity Levels (ASILs) to determine how rigorously each hazard must be controlled.
ISO 21434 on the other hand, addresses cybersecurity that includes risks caused by intentional, malicious actions. For example, it comes into picture when a by‑wire system fails due to manipulation of a foreign interference. Instead of HARA and ASILs, the standard uses Threat Analysis and Risk Assessment (TARA) and defines Cybersecurity Assurance Levels (CALs).
In practice, the two standards are complementary. They often need to be applied together as a cybersecurity threat identified in a TARA may create a safety consequence that falls under ISO 26262.
To learn more about ISO 26262 and its implementation, check out our guide on: What is ISO 26262? | A Guide to Functional Safety Standard
What is the Relationship Between ISO 21434 and UNECE R155?
ISO 21434 is a technical standard. It defines the engineering processes, methods, and work products required to manage cybersecurity risks in road vehicles. Its purpose is clear to detail OEMs and suppliers how to perform cybersecurity engineering in a consistent and traceable way.
On the other hand, UNECE R155 is a regulation issued by the United Nations Economic Commission for Europe. It makes a Cybersecurity Management System (CSMS) a legal prerequisite for vehicle type approval. Any market that has adopted R155 into national law requires manufacturers to demonstrate cybersecurity capability before a vehicle can be sold.
Note: R155 does not instruct engineering methods; it mandates a functioning CSMS and points to ISO 21434 as the recognized technical foundation for proving compliance. An OEM that applies ISO 21434 across development and supplier management builds the evidence base needed to pass an R155 type approval assessment.
What is the Difference Between VCS and ISO 21434?
The difference between VCS and ISO 21434 often creates confusion for suppliers facing automotive cybersecurity requirements.
As defined previously, ISO 21434 is the engineering standard. Following it means running disciplined TARA activities, producing traceable work products, operating a CSMS, and managing cybersecurity across the supply chain.
In contrast, ENX VCS, Vehicle Cyber Security, is the audit and certification scheme that independently verifies this capability. It provides OEMs with objective proof that suppliers meet the cybersecurity expectations flowing from UNECE R155. The relationship mirrors ISO 27001 and accredited audits: the standard defines the requirements; the audit scheme validates that they are met.
VCS evaluates three areas.
- Development assesses cybersecurity engineering during product development
- Production examines manufacturing security,
- Operations and Maintenance reviews post‑production responsibilities
A Tier‑1 supplier building connected vehicle components and supporting them in the field typically requires successful evaluation of all three areas. Additionally, VCS also mandates a valid TISAX label as a prerequisite, ensuring the organization’s information‑security posture.
Does ISO 21434 cover physical layer attacks and hardware tampering?
Yes, ISO 21434 cover physical layer attacks and hardware tampering but there are limits.
ISO 21434 requires that physical attack paths be included in the TARA process. When assessing how feasible an attack is, physical access to the vehicle is treated as one of the feasibility factors.
An attacker who needs to be physically present is rated as lower feasibility than one who can attack remotely, but the threat is still assessed. In practice, this means assessing scenarios like an exposed debug port on an ECU, a SIM card being physically removed and cloned, or unauthorized firmware being loaded through a direct hardware connection.
Beyond TARA, the Clause 10 of ISO 21434 further requires two specific hardware-level controls:
- Tamper detection to be implemented where physical tampering is identified as a risk
- Cryptographic keys must be stored in hardware such as a Hardware Security Module (HSM) or secure element.
However, ISO 21434 is limited on implementation details. It defines what must be achieved at the hardware level, but not how to develop it. That is where SAE J3101 comes in.
What is SAE J3101 and how does it complement ISO 21434?
SAE J3101 is a companion standard for ISO 21434 for Hardware-Anchored Security for Road Vehicles.
While ISO 21434 details that cryptographic keys must be protected and that tamper detection must be in place, SAE J3101 tells you how to develop those protections at the hardware level. It covers three areas that ISO 21434 does not prescribe in detail.
- Hardware root of trust: It defines how a device establishes a trusted starting point at power-on, typically a piece of immutable hardware logic that verifies the integrity of everything that runs above it before execution begins.
- Secure boot: This builds on the root of trust to ensure that only cryptographically verified firmware can load at startup. Each stage of the boot process verifies the next, so that a compromised bootloader or firmware image is detected and blocked before it can execute.
- Physical attack resistance: This covers protections against side-channel attacks, fault injection, and direct hardware probing, attack techniques that target the hardware itself rather than the software running on it.
Conclusion
ISO/SAE 21434 brings structure to automotive cybersecurity, from TARA to lifecycle processes. By integrating security into each stage, it ensures that risks are addressed systematically, leading to more secure and reliable vehicle systems.
The focus is simple. Identify risks early, manage them effectively, and continue doing so throughout the vehicle lifecycle.
