What is ISO 21434?
ISO/SAE 21434 is the international standard for cybersecurity engineering of road vehicles, setting out how manufacturers and suppliers manage the cybersecurity risks of electrical and electronic (E/E) systems throughout the entire lifecycle, from concept to decommissioning. It was published on 31 August 2021 as a joint publication of ISO (TC 22/SC 32/WG 11) and the US-based SAE, succeeding the SAE guidebook J3061 from 2016. ISO 21434 does not prescribe specific technologies or cryptography; instead it requires a demonstrable process with documented work products.
ISO 21434 is complementary to ISO 26262 (functional safety) but focuses on intentional attacks rather than unintended faults.
🧠 Why is ISO 21434 important?
A modern car contains dozens to more than a hundred ECUs (Electronic Control Units) and many millions of lines of code. That turns the vehicle into a moving network of embedded systems, comparable to a small factory full of controllers. Three developments make that network attractive to attackers:
- External interfaces - Wifi, Bluetooth, cellular connections, V2X communication, charging stations and OTA (over-the-air) updates make the vehicle reachable remotely
- Software-driven functions - steering, braking and ADAS (driver assistance) are increasingly controlled by software, so an attack can directly affect safety
- Long service life - a vehicle is often on the road for fifteen years or more, while threats change considerably over that period
This makes vehicles vulnerable to cyberattacks such as Man-In-The-Middle, Spoofing, a replay attack on keyless entry or message injection on the CAN bus, which has no built-in authentication.
In addition, ISO 21434 is the common way to comply with UN Regulation UNECE R155, which makes cybersecurity mandatory for vehicle type approval.
🧱 How is ISO 21434 structured?
ISO 21434 is a single document divided into fifteen clauses and eight informative annexes. The substantive requirements are in clauses 5 to 15:
| Clause | Topic | Core |
|---|---|---|
| 1-4 | Scope, references, terms, general considerations | Scope: E/E systems of series-production road vehicles, including components and interfaces |
| 5 | Organisational cybersecurity management | Policy, cybersecurity culture, competences, audits, information security of the organisation |
| 6 | Project-dependent cybersecurity management | Cybersecurity plan, cybersecurity case, assessment and release for post-development |
| 7 | Distributed cybersecurity activities | Agreements with suppliers through a cybersecurity interface agreement |
| 8 | Continual cybersecurity activities | Monitoring, event evaluation, vulnerability analysis and management |
| 9 | Concept phase | Item definition, cybersecurity goals and cybersecurity concept |
| 10 | Product development | Design, implementation, integration and verification |
| 11 | Cybersecurity validation | Validation at vehicle level, for example with penetration tests |
| 12 | Production | Preventing vulnerabilities from being introduced in the factory |
| 13 | Operations and maintenance | Incident response and updates in the field |
| 14 | End of support and decommissioning | Communicating the end of cybersecurity support |
| 15 | TARA methods | The building blocks of the threat analysis and risk assessment |
Annexes A to H include an overview of all work products, an example cybersecurity interface agreement, guidelines for impact and feasibility rating, the Cybersecurity Assurance Levels (CAL) in Annex E and a fully worked TARA example of a headlamp system.
🔐 Which concepts are essential in ISO 21434?
| Term | Meaning |
|---|---|
| Item | The subject of the analysis: a system or combination of components implementing a function at vehicle level |
| Asset | Something of value, such as a function, key or data set, with security properties (confidentiality, integrity, availability) |
| Damage scenario | The adverse consequences if an asset is compromised |
| Threat scenario | A potential cause of the loss of a security property |
| Attack path | The sequence of steps an attacker takes to realise a threat scenario |
| Cybersecurity goal | Concept-level requirement to protect assets against a threat scenario |
| Cybersecurity claim | Documented statement about a risk that is deliberately retained or shared |
| Cybersecurity concept | Measures and requirements through which the cybersecurity goals are achieved |
| CAL | Cybersecurity Assurance Level 1-4: the level of confidence needed that a goal has been achieved |
🔧 How do you carry out a TARA under ISO 21434?
The TARA (Threat Analysis and Risk Assessment) is the heart of the standard and an automotive form of threat modelling and cybersecurity risk assessment. Clause 15 describes seven steps:
- Identify assets - which functions, data and keys are valuable, and which security property matters?
- Identify threat scenarios - for example with STRIDE: how can each property be lost?
- Rate the impact - in four categories: safety, financial, operational and privacy (SFOP), on the scale severe, major, moderate or negligible
- Analyse attack paths - through which interface and which intermediate steps can the attacker reach the goal?
- Rate attack feasibility - high, medium, low or very low, based on attack potential (elapsed time, expertise, knowledge of the item, window of opportunity and equipment), CVSS or the attack vector
- Determine the risk value - a value from 1 to 5 derived from impact and feasibility
- Decide on risk treatment - avoid, reduce, share or retain; reducing leads to cybersecurity goals, sharing or retaining to a cybersecurity claim
Example: in a keyless entry system, the unlock function is an asset whose relevant property is integrity. The threat scenario “relay attack on the key signal” has a major financial impact (theft). Because the equipment needed is cheap and readily available, feasibility is high. The risk value comes out high, so the team chooses to reduce it, for instance with ultra-wideband distance measurement instead of relying on signal strength alone.
🚗 What risks exist in vehicles?
| Component | Possible attack | Impact | Typical measure |
|---|---|---|---|
| Infotainment system | Malware via USB or Bluetooth | Access to the CAN bus | Gateway ECU with filtering, network separation |
| Over-the-air updates | Spoofed server or fake firmware | Remote code execution | Signed firmware, Secure Boot |
| Keyless entry | Replay attack, signal relaying | Vehicle theft | Rolling codes, distance measurement |
| V2X communication | Spoofed messages, DoS attack | Traffic manipulation | Certificates and message signing |
| Diagnostic port (OBD) | Unauthorised diagnostic or programming commands | Altered ECU functions | Authentication of diagnostic sessions |
| Internal CAN bus | Message injection | Interference with braking or steering functions | Message authentication (SecOC), intrusion detection |
🔄 How does ISO 21434 relate to other standards and regulations?
| Standard / regulation | Relation |
|---|---|
| ISO 26262 | Functional safety; addresses unintended faults. An attack can violate a safety goal, which is why teams align the HARA with the TARA |
| UNECE R155 | UN regulation requiring a certified Cyber Security Management System (CSMS) and cybersecurity type approval; it does not mandate ISO 21434 by name, but ISO 21434 is the common way to demonstrate the CSMS |
| UNECE R156 and ISO 24089 | Requirements for a Software Update Management System (SUMS) and the related engineering standard for software updates (2023) |
| ISO 21448 (SOTIF) | Safety of the Intended Functionality; risks without a defect, such as sensor limitations |
| ISO/SAE PAS 8475 | Supplementary specification for CAL and Targeted Attack Feasibility (TAF); in 2026 still a draft in its final approval stage, which reduces the number of CAL levels from four to three |
| IEC 62443 / IEC 62443-4-1 | Industrial counterpart with a comparable approach: secure development lifecycle, risk analysis and security levels |
| ISO 27001 | Information security management system; covers the organisation’s IT, not the vehicle itself |
ISO 21434 itself is under revision. According to the working group, the second edition keeps the scope and structure but absorbs the work on verification and validation (ISO/SAE TR 8477). Until it is published, the 2021 edition applies.
🏭 What does ISO 21434 mean in the Netherlands and the EU?
Since July 2022, UNECE R155 has been mandatory in the EU for new vehicle types, and since July 2024 for all newly registered vehicles, through the General Safety Regulation (EU) 2019/2144. In the Netherlands, the RDW, as type-approval authority, assesses manufacturers’ CSMS. The CSMS certificate is valid for up to three years, after which a new assessment follows. Because motor vehicles are already covered by these sector rules, they are excluded from the Cyber Resilience Act.
For Dutch suppliers of ECUs, sensors, charging systems or software, this means OEMs contractually request ISO 21434 work products: a TARA, a cybersecurity case, an SBOM and a vulnerability management process. A practical approach in five steps:
- Gap analysis - compare the existing development process with clauses 5 to 15
- Organisation - assign responsibilities, train engineers and build a cybersecurity culture
- Supply chain - record roles in an interface agreement and assess supplier security
- Products - perform a TARA per item and embed security by design with encryption, authentication and secure boot
- Field phase - monitor vulnerabilities and keep an incident response plan and update process ready
The cyberattack on Jaguar Land Rover in 2025 hit the manufacturer’s IT rather than its vehicles, but showed how vulnerable the automotive chain is. ISO 21434 is about the product; the organisation itself additionally needs measures from frameworks such as ISO 27001.
❓ Frequently asked questions
Is ISO 21434 legally mandatory?
ISO 21434 as a standard is not legally mandatory. However, UNECE R155 requires a cybersecurity management system for type approval, and ISO 21434 is the common way to demonstrate it. In practice, vehicle manufacturers therefore require ISO 21434 compliance from their suppliers.
What is the difference between ISO 21434 and ISO 26262?
ISO 26262 covers functional safety against unintended faults in hardware and software, whereas ISO 21434 focuses on deliberate attacks. Both standards share a comparable lifecycle structure built around the V-model, and they have to work together because a cyberattack can violate a safety goal.
What is a TARA in ISO 21434?
A TARA (Threat Analysis and Risk Assessment) is the threat and risk analysis defined in clause 15 of ISO 21434. The team identifies assets and threats, rates impact and attack feasibility, determines a risk value from 1 to 5 and decides on risk treatment.
Can you get certified for ISO 21434?
ISO 21434 is not a certifiable management system standard like ISO 27001, and there is no formal accredited certification scheme for it. Inspection bodies do offer assessments and statements of conformity, and under UNECE R155 the type-approval authority certifies the manufacturer’s CSMS.
What are Cybersecurity Assurance Levels (CAL)?
Cybersecurity Assurance Levels are four levels (CAL 1 to CAL 4) from the informative Annex E of ISO 21434 that indicate how much confidence is needed that a cybersecurity goal has been achieved. The level depends on the impact and the attack vector, and it determines the rigour of verification and testing.
Does ISO 21434 also apply to industry?
ISO 21434 is intended for road vehicles, their components and their interfaces. For industrial automation, IEC 62443 is the counterpart, with a comparable secure development lifecycle in IEC 62443-4-1. Suppliers serving both markets often align their development process with both standards.
📌 In summary
ISO/SAE 21434 is the cybersecurity standard for road vehicles: it requires a demonstrable process, with the TARA at its core, to manage digital threats throughout the entire lifecycle.
The standard works alongside ISO 26262 for safety and is the basis on which manufacturers comply with UNECE R155. Anyone developing vehicle components therefore has to design securely and also keep monitoring and fixing vulnerabilities in the field.