Key Takeaways
TL;DR — ISO/SAE 21434 is the international standard for cybersecurity engineering of road-vehicle electrical and electronic systems, published by ISO and SAE International in August 2021. It sets process requirements — not technology choices — across the lifecycle, organised in Clauses 5 to 15 and evidenced by 42 work products listed in Annex A. It is neither a product certification nor a law: UNECE R155 and India's AIS 189 are the regulations, and ISO/SAE 21434 is the engineering reference commonly used to produce the evidence they ask for.
- 1.Scope: series-production road-vehicle E/E systems, their components and interfaces, from concept through decommissioning — for development started or modified after publication.
- 2.Clauses 5–8 build the organisational and supply-chain machinery, Clauses 9–14 follow an item through its lifecycle, and Clause 15 supplies the TARA method used throughout.
- 3.Assessors read for traceability: policy to plan, plan to TARA, threat scenario to control to test result, published vulnerability to triage decision.
- 4.It is a process standard, not a certificate: there is no ISO-run certification scheme comparable to ISO/IEC 27001, and certification-body attestations are not type approval.
- 5.UNECE R155 does not name ISO/SAE 21434, yet its work products are the evidence CSMS assessments are commonly built on; R156 software updates have their own engineering standard, ISO 24089.
- 6.The 2021 edition is the only edition; a second edition is indicated for around 2029 without changes to scope or structure.
At a Glance
- One-Sentence Answer
- A concise explainer of ISO/SAE 21434 — what it covers, who it applies to, Clauses 5–15 in one table, what assessors read first, and how it relates to UNECE R155, R156 and AIS 189.
- Who This Is For
- Engineering managers, product-security leads, supplier-quality and programme managers who need a working understanding of the standard before a customer or assessor asks.
- Last Reviewed
- October 2026
- Primary References
- ISO/SAE 21434:2021 (Clauses 5–15, Annex A); ISO/PAS 5112:2022; ISO 24089:2023; UNECE R155 and R156; AIS 189 and AIS 190.
- Practical Use
- Use it to orient a team, to brief management on what the standard does and does not require, and to decide where to go deeper in the full guide.
Editorial Process: Written and reviewed by Agnile engineers working day-to-day in automotive cybersecurity and safety. AI tooling is used to assist with drafting, outlining, and copy-editing; every claim, standards reference, and technical statement is verified by a human engineer before publication.
ISO/SAE 21434 is the international cybersecurity engineering standard for road vehicles. Published in August 2021 jointly by ISO and SAE International under the title Road vehicles — Cybersecurity engineering, it specifies requirements for managing cybersecurity risk in a vehicle’s electrical and electronic (E/E) systems, their components and their interfaces — from concept and product development through production, operation, maintenance and decommissioning. It tells you which activities to perform and which evidence to produce. It deliberately does not tell you which cryptography, security hardware or architecture to use.
This post is the short version: what kind of standard it is, who it applies to, the clauses in a single table, what an assessor reads first, and the misreadings that cost programmes time. For the long-form treatment — the full TARA workflow, the work products and worked guidance — read our ISO/SAE 21434 guide.
What Kind of Standard It Is
ISO/SAE 21434 is a process standard. Its normative content is written as requirements, recommendations and permissions, each numbered by clause, and every activity is tied to work products — the evidence that the activity happened. Annex A lists 42 of them, numbered WP-XX-YY, where XX is the clause. A work product can be a document, a database record or a tool export; what makes it a work product is that it can be traced to the requirement that asks for it and the activity that produced it.
The standard is risk-based. Its centre of gravity is the Threat Analysis and Risk Assessment (TARA) method in Clause 15: identify what is worth protecting, how it could be attacked, how bad the damage would be and how feasible the attack is, then decide what to do about each risk. Goals, concept, specifications, verification, validation and monitoring all follow from those decisions.
It is also proportionate. Clause 6 allows activities to be tailored when the rationale is documented, and the informative Annex E describes Cybersecurity Assurance Levels (CAL) as one way to scale rigour to risk — an idea the companion document ISO/SAE 8475 develops further.
Who It Applies To
The stated scope is series-production road-vehicle E/E systems, including their components and interfaces, whose development or modification began after the standard was published. In practice that brings in:
- OEMs, who own the vehicle-level risk and the regulatory relationship;
- Tier-1 and Tier-2 suppliers, whose share of the work is fixed by a cybersecurity interface agreement under Clause 7;
- suppliers of components developed out of context — a microcontroller, a software stack or a communications module built before any specific vehicle exists — which Clause 6 handles through documented assumptions about the eventual integration;
- suppliers of off-the-shelf components, whose suitability the integrator has to evaluate.
What it does not cover is just as useful to know. Functional safety stays with ISO 26262. Software update engineering has its own standard, ISO 24089:2023. Off-board systems such as backends are considered where they interface with the vehicle, but the standard does not specify how to run their IT security. And components developed before the standard existed are not exempted by default: when they are reused, Clause 6 expects them to be evaluated.
The Clauses at a Glance
Clauses 1 to 4 set out scope, normative references, terms and general considerations. The requirements live in Clauses 5 to 15: four that build the organisational and supply-chain machinery, six that follow an item through its lifecycle, and one method library.
| Clause | Purpose in one line | Key work product |
|---|---|---|
| 5Organisational cybersecurity management | Policy, roles, culture, competence, information sharing, tool management and an independent organisational audit. | WP-05-01 Cybersecurity policy, rules and processes |
| 6Project-dependent cybersecurity management | Plan the activities for one item, tailor with rationale, handle reuse and off-the-shelf parts, build the case, assess it, release it. | WP-06-01 Cybersecurity plan; WP-06-02 Cybersecurity case |
| 7Distributed cybersecurity activities | Evaluate supplier capability and agree who performs which activity across the supply chain. | WP-07-01 Cybersecurity interface agreement |
| 8Continual cybersecurity activities | Monitor information sources, evaluate events, analyse and manage vulnerabilities for as long as the item is supported. | WP-08-06 Evidence of managed vulnerabilities |
| 9Concept | Define the item, run the TARA, set cybersecurity goals and claims, design the cybersecurity concept. | WP-09-01 Item definition; WP-09-02 TARA |
| 10Product development | Refine the concept into specifications, implement, integrate and verify; record weaknesses found along the way. | WP-10-07 Integration and verification report |
| 11Cybersecurity validation | Confirm at vehicle level that the cybersecurity goals are achieved. | WP-11-01 Validation report |
| 12Production | Carry cybersecurity requirements into manufacturing — provisioning, flashing, configuration. | WP-12-01 Production control plan |
| 13Operations and maintenance | Respond to cybersecurity incidents and deliver updates in the field. | WP-13-01 Cybersecurity incident response plan |
| 14End of cybersecurity support and decommissioning | Communicate when support ends and handle decommissioning. | WP-14-01 Procedures to communicate end of support |
| 15Threat analysis and risk assessment methods | The method library: damage scenarios, assets, threat scenarios, impact, attack paths, feasibility, risk values, treatment. | WP-15-01 to WP-15-08, rolled up into WP-09-02 |
The table names one or two representative work products per clause; the 42 work products checklist lists them all, and the ISO/SAE 21434 guide walks through each lifecycle phase in depth.
What an Assessor Actually Reads First
Three different readers look at ISO/SAE 21434 evidence, and it helps to know which one you are facing. An organisational auditor examines the cybersecurity management system against Clause 5; ISO/PAS 5112:2022 gives guidance for that audit. A cybersecurity assessor, independent of the development team, judges under Clause 6 whether an item’s cybersecurity case is convincing. And under UNECE R155, an approval authority or its technical service assesses the manufacturer’s CSMS for a certificate of compliance, then assesses each vehicle type. In India, AIS 189 assessments are carried out by CMVR test agencies, notably ARAI and iCAT.
Their reading order is consistent enough to plan for. In our experience it runs:
- Policy, rules and processes (WP-05-01) — and proof they operate: the organisational audit report and competence records.
- The cybersecurity plan for this programme (WP-06-01) — real activities, owners and dates, not a template.
- Item definition and TARA (WP-09-01, WP-09-02) — boundary, interfaces and assumptions first, because a TARA is only as good as the item it analyses. Our practical TARA guide covers the method.
- The traceability chain — goals to concept to specifications, then verification under Clause 10 and validation under Clause 11. Expect the assessor to pick one threat scenario and ask you to walk it to a control, a requirement and a test result.
- Continual activities under Clause 8 — pick a published vulnerability that touches your bill of materials and show the triage decision and what happened next.
- Supplier agreements, then the case — the Clause 7 interface agreements, followed by the cybersecurity case, its assessment report and the release for post-development (WP-06-02 to WP-06-04).
In our experience, two patterns cause more trouble than missing documents: evidence that exists but does not connect, and processes that are written down but have never run. Both show up within the first hour of reading.
Common Misreadings
“We need an ISO 21434 certificate.”
ISO/SAE 21434 was not written as a certification standard, and there is no ISO-run certification scheme for it comparable to accredited ISO/IEC 27001 certification. Some certification bodies run their own schemes and issue certificates or attestations against it; these can help a supplier answer a customer questionnaire, but they are not a type approval and not the R155 CSMS certificate of compliance, which an approval authority issues and which is valid for up to three years. What a customer or assessor ultimately wants is the evidence itself.
“ISO/SAE 21434 and R155 are the same thing.”
R155 is a regulation; ISO/SAE 21434 is an engineering standard. R155 requires the vehicle manufacturer to operate a CSMS and to identify, mitigate and test cyber risks for each vehicle type. It does not name ISO/SAE 21434, but the standard’s work products are the evidence those assessments are commonly built on. In the EU, R155 has applied to new vehicle types since 6 July 2022 and to all newly registered cars, vans, trucks and buses since 7 July 2024. The ISO/SAE 21434 compliance page maps the standard to those obligations, and ISO/SAE 21434 vs UNECE R155 compares the two in detail.
“It covers software updates too.”
Partly. ISO/SAE 21434 covers the cybersecurity of the update path as part of the item and of operations and maintenance under Clause 13. The software update management system that UNECE R156 requires — update processes, version control, RXSWIN — is the subject of ISO 24089. Programmes facing R156 need both.
“India needs a different standard.”
AIS 189 and AIS 190 are India’s counterparts to R155 and R156 and are aligned with them, so ISO/SAE 21434 evidence carries across. What changes is the assessing body and the applicability dates, which are set by MoRTH notification and are still evolving — confirm the latest notification before you plan. Our AIS 189 and AIS 190 guide tracks them.
“Doing a TARA means we comply.”
TARA is one of eleven requirement clauses. A TARA without a plan, a vulnerability-management process that actually runs, supplier agreements and a cybersecurity case is analysis, not conformance with the standard.
“Every requirement applies to every project.”
Tailoring is permitted when the rationale is documented and reviewed, and reused, out-of-context and off-the-shelf components each have their own route. Applied with judgement, the same standard scales from a single sensor to a vehicle platform.
Where to Go Next
- Orienting a team? Read the full ISO/SAE 21434 guide.
- Starting the analysis? Begin with what TARA is and how it runs.
- Planning delivery or facing an assessment date? See ISO/SAE 21434 consulting and what an engagement buys and costs.
Agnile Technologies delivers ISO/SAE 21434 consulting, TARA and assessment readiness for OEM and supplier programmes, and builds KAVACH, an ISO/SAE 21434 engineering workspace. This post summarises the standard; it does not reproduce its text. The requirements themselves are in ISO/SAE 21434:2021.
Frequently Asked Questions
What is ISO/SAE 21434?
ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering, is the international standard published jointly by ISO and SAE International that sets requirements for cybersecurity risk management of road-vehicle electrical and electronic (E/E) systems, their components and interfaces — from concept and product development through production, operation, maintenance and decommissioning. It defines activities and the work products that evidence them; it does not prescribe specific security technologies.
Is ISO/SAE 21434 mandatory?
Not on its own — it is a voluntary international standard. What is mandatory in the EU, the UK, Japan and other contracting parties that apply it is UNECE R155, which requires a Cybersecurity Management System and a cybersecurity assessment of each vehicle type; India's AIS 189 follows the same model. R155 does not name ISO/SAE 21434, but the standard is the engineering reference commonly used to produce the evidence, and OEMs frequently write it into supplier contracts.
Can a company be ISO 21434 certified?
Not in the way it can be ISO/IEC 27001 certified. ISO/SAE 21434 is an engineering standard rather than a management-system certification standard, and there is no ISO-run certification scheme for it. Some certification bodies operate their own schemes and issue certificates or attestations against it, which can be useful supplier evidence — but they are not a vehicle type approval and not the UNECE R155 CSMS certificate of compliance, which only an approval authority issues.
How is ISO/SAE 21434 different from ISO 26262?
ISO 26262 addresses functional safety — hazards caused by malfunctioning E/E systems — through hazard analysis (HARA) and ASILs. ISO/SAE 21434 addresses cybersecurity — damage caused by an attacker — through threat analysis and risk assessment (TARA). The two share a lifecycle shape and meet where a cyberattack has safety consequences: safety is one of the TARA impact categories, so safety and security teams should exchange findings rather than run unconnected analyses.
How many clauses and work products does ISO/SAE 21434 have?
Fifteen clauses. Clauses 1 to 4 cover scope, normative references, terms and general considerations; the requirements sit in Clauses 5 to 15. Annex A lists 42 work products, numbered WP-XX-YY by clause, from WP-05-01 (cybersecurity policy, rules and processes) to WP-15-08 (risk treatment decisions).
Does ISO/SAE 21434 apply to Tier-1 and Tier-2 suppliers?
Yes. It applies to organisations developing E/E systems or components for series-production road vehicles. Clause 7 distributes activities between customer and supplier through cybersecurity interface agreements, and Clause 6 covers components developed out of context and off-the-shelf components — so a supplier applies the parts of the standard its customer agreement assigns to it, not necessarily an OEM-scale programme.
What does an assessor look at first?
In our experience: the cybersecurity policy and evidence that the organisation's processes are operating, the project cybersecurity plan, the item definition and TARA, then the traceability chain from cybersecurity goals through concept, specifications, verification (Clause 10) and validation (Clause 11) — followed by vulnerability-management records, supplier interface agreements, and the cybersecurity case with its independent assessment.
Is there a new version of ISO/SAE 21434?
No. The 2021 edition is the current and only edition. It entered ISO systematic review in July 2026, and the joint ISO/SAE working group has indicated a second edition around 2029 without changes to scope or structure, so evidence built on the 2021 edition carries forward. Treat that date as indicative until a revision project is formally registered.
Need Help Applying This to a Real Programme?
Agnile supports engineering teams from architecture and requirements through implementation, validation, release, and evidence preparation.