ISO/SAE 21434 Guide: The Automotive Cybersecurity Engineering Standard

ISO/SAE 21434 “Road vehicles — Cybersecurity engineering” is the international standard that defines requirements for cybersecurity risk management throughout the entire vehicle lifecycle. Published jointly by ISO and SAE International on 31 August 2021 — developed by ISO/TC 22/SC 32 together with SAE — it covers concept, development, production, operation, maintenance, and decommissioning.

Its scope is the electrical and electronic (E/E) systems of series-production road vehicles, including their components and interfaces. The standard is deliberately technology-neutral: it does not prescribe cryptographic algorithms, architectures or specific security controls. What it does require is a risk-based engineering process — identify what could be damaged, how it could be attacked, how severe and how feasible that would be, decide the treatment, and prove the treatment works — documented in work products an auditor or assessor can review.

The standard is commonly used to structure cybersecurity engineering evidence that supports UNECE R155 assessment readiness, making it widely adopted by OEMs and Tier-1 suppliers selling vehicles in markets that apply R155 (which include the EU, UK, Japan, South Korea, and others).

Key areas covered by ISO/SAE 21434 include: organizational cybersecurity management, project-dependent cybersecurity management, distributed cybersecurity activities, continual cybersecurity activities, concept phase, product development, and post-development phases.

Structurally, Clauses 1–4 set out the scope, normative references, terms and general considerations; Clauses 5–15 hold the normative requirements; and informative Annexes A–H add guidance. Annex A summarises the activities and work products and Annex E introduces Cybersecurity Assurance Levels; the other annexes cover topics such as cybersecurity culture, an example interface-agreement template, cybersecurity relevance, rating guidance and a worked TARA example.

ISO/SAE 21434 plays the role for cybersecurity that ISO 26262 plays for functional safety, and the two are commonly run side by side on the same programme: a safety HARA and a cybersecurity TARA examine the same item from different angles. It is a process standard, not a product label — the standard itself does not make a vehicle or ECU “ISO 21434 certified” (see the FAQ on certification below).

The standard addresses every organisation that engineers road-vehicle E/E systems — not only vehicle manufacturers. Its obligations travel down the supply chain through contracts rather than through law, and each tier carries a different slice of the work.

The cascade.UNECE R155 regulates the vehicle manufacturer, not the supplier. But an OEM cannot evidence a vehicle type without its suppliers’ TARA inputs, test results and vulnerability handling, so it writes ISO/SAE 21434 expectations into sourcing requirements and Clause 7 cybersecurity interface agreements. Tier-1 suppliers pass the relevant parts on to Tier-2, semiconductor and software suppliers. The AIS 189 and AIS 190 guide describes the same cascade for Indian programmes.

Components without a vehicle.Suppliers often develop a component before any customer item exists. ISO/SAE 21434 handles this through components developed “out of context” — built against assumed cybersecurity requirements that the integrator later confirms — and through rules for off-the-shelf components, so reused software and hardware still arrive with evidence.

Two- and three-wheelers. In the EU, Commission Delegated Regulation (EU) 2025/1455 extends UN R155 to L-category vehicles from 11 December 2027 for new types and 11 June 2029 for existing types, so ISO/SAE 21434 now reaches motorcycle and e-scooter programmes too — see two-wheeler EV cybersecurity and R155 from 2027.

The normative content sits in eleven clauses. Clauses 5–8 apply across the organisation and the whole lifecycle; Clauses 9–14 follow the item from concept to decommissioning; Clause 15 is a toolbox of TARA methods the other clauses call on.

Two details trip teams up. First, Clause 15 defines the TARA methods, but the TARA itself is performed and recorded in the concept phase (Clause 9) and revisited whenever the design, the threat landscape or a known vulnerability changes. Second, the cybersecurity case and the cybersecurity assessment belong to Clause 6 — project management — not to development: they are the argument and the independent judgement that the project’s evidence is complete.

Activities can be tailored, but only with a documented rationale in the cybersecurity plan — for example where another party in the supply chain performs an activity under a Clause 7 agreement.

ISO/SAE 21434 defines a set of work products across the cybersecurity engineering lifecycle — Annex A summarises 42 of them, listed one by one in our ISO 21434 work products checklist. Key work products along the TARA-to-evidence chain include:

• Asset identification report
• Threat scenario list
• Impact rating report
• Attack feasibility rating report
• Risk determination report
• Risk treatment decision report
• Cybersecurity goals
• Cybersecurity claims
• Cybersecurity concept
• Verification reports
• Cybersecurity case

Each work product must be traceable to its inputs and outputs, creating a continuous audit trail from asset identification through risk treatment and verification.

Verification reports are where testing evidence lands — Clause 10 verification and Clause 11 validation. For how penetration-test findings are structured to fill them, see automotive penetration testing and the UNECE R155 Annex 5 penetration-testing checklist.

TARA — Threat Analysis and Risk Assessment — is the core cybersecurity analysis method defined in ISO/SAE 21434 Clause 15. It is the process by which automotive teams systematically identify what can go wrong (threats), how likely it is (attack feasibility), how bad it would be (impact), and what to do about it (risk treatment).

TARA is mandatory for every “item” or “component” that has cybersecurity relevance in a vehicle. This typically includes ECUs, communication buses (CAN, Ethernet), external interfaces (OBD, V2X, Bluetooth), and data flows between components.

Clause 15 itself lists seven activities — asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination and risk treatment decision. The five steps below group them the way most teams run a workshop. For a longer walk-through with worked examples, see what TARA is in automotive cybersecurity.

A TARA tells you how much risk an item carries. A Cybersecurity Assurance Level (CAL) answers a different question: how much engineering rigour should that item receive? ISO/SAE 21434:2021 introduces the idea only in informative Annex E, as four numbered levels — CAL1 to CAL4 — derived from concept-stage information such as impact and attack vector. Because the annex is informative, it standardised neither how to assign a CAL nor what each level demands.

ISO/SAE 8475, “Road vehicles — Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility (TAF)”, is a Publicly Available Specification developed by ISO/TC 22/SC 32 jointly with SAE International that makes the scheme usable. It consolidates the four numbered levels into three named ones — Basic, Intermediate and Advanced — each scaling four dimensions: which activities are performed, how deeply, how formal the evidence is, and how independent the review is. In practice that decides how far verification and penetration testing go and who signs off.

Targeted Attack Feasibility (TAF)is the second concept. A TARA’s attack feasibility rating describes how easy an attack path is today; TAF states the attack feasibility an item is intended to present once its controls are in place — a design target that customers and suppliers can write into requirements.

Two cautions. A CAL is not a risk value and does not replace risk determination; it is the cybersecurity counterpart in spirit to an ASIL, scaling rigour rather than measuring risk. And as of our October 2026 review ISO/SAE PAS 8475 had passed its approval ballot and was under publication (stage 60.00 since 1 September 2026) — check the ISO catalogue for its current status before citing it in a contract. The full explainer is in ISO/SAE 8475: CAL and TAF explained.

ISO/SAE 21434 separates two questions. Verification — Clause 10, integration and verification — asks whether the cybersecurity specifications were implemented correctly. Validation — Clause 11 — asks, at vehicle level, whether the cybersecurity goals were the right ones and are actually achieved. Clause 9 adds review-based verification of the goals and the concept themselves, before development starts.

Verification usually combines several methods: requirements-based and interface testing, static and dynamic analysis and — to look for vulnerabilities nobody has identified yet — vulnerability scanning, fuzz testing and penetration testing. How deep this goes should follow the item’s risk and, where used, its CAL. Validation of the integrated vehicle against its cybersecurity goals commonly relies on penetration testing at vehicle level.

Test evidence only counts if it traces back. Each finding should map to a threat scenario, a cybersecurity goal or requirement and a treatment decision; findings that stay open flow into Clause 8 vulnerability management. Every engagement runs under signed authorisation and agreed rules of engagement. For how this is scoped and reported, see ECU and vehicle penetration testing and the automotive penetration-testing methodology.

Guidance here is becoming more specific. ISO/SAE TR 8477, a Technical Report on cybersecurity verification and validation, passed its approval ballot on 22 July 2026 and has since been under publication (stage 60.00); its content is planned to merge into the second edition of ISO/SAE 21434.

Whenever cybersecurity activities are split between a customer and a supplier, Clause 7 requires the split to be agreed and written down. The clause covers evaluating the supplier’s cybersecurity capability, putting cybersecurity requirements into the request for quotation, and aligning responsibilities — recorded in a cybersecurity interface agreement (CIA), the single Clause 7 work product. The standard includes an informative example template.

A defensible CIA typically names:

• Points of contact on both sides for cybersecurity matters
• Who is responsible, accountable, supporting, informed and consulted (a RASIC matrix) for TARA, verification and validation, vulnerability handling, incident response and release decisions
• What information is shared, in which format, and how confidentiality is protected
• Audit and assessment rights, including at sub-tier suppliers
• Response times for vulnerabilities and incidents, and the end of the cybersecurity support period

The most expensive failure mode is vagueness — “supplier shall ensure cybersecurity” — which collapses under audit and during the first real incident. Our Clause 7 cybersecurity interface agreement template and negotiation guide walks through each section.

Cybersecurity does not end at start of production — the threat landscape keeps moving while the vehicle is on the road.

• Clause 8 — continual cybersecurity activities. Monitor defined sources (supplier advisories, vulnerability databases, researcher reports, internal findings), evaluate cybersecurity events against triggers, analyse vulnerabilities and manage them to closure. These activities run throughout the lifecycle, development included. See vulnerability monitoring.
• Clause 12 — production. A production control plan applies the cybersecurity requirements for post-development on the line — for example how keys are provisioned and how development access is closed — so manufacturing does not introduce vulnerabilities.
• Clause 13 — operations and maintenance. A cybersecurity incident response plan, plus the handling of updates in the field — the point where ISO/SAE 21434 meets UNECE R156 software-update management.
• Clause 14 — end of cybersecurity support and decommissioning. Procedures to communicate when cybersecurity support ends, so customers are not left assuming protection that no longer exists.

UNECE R155 makes this regulatory as well as good practice: the CSMS must include processes to monitor for, detect and respond to cyber-attacks and threats on approved vehicle types, and the manufacturer reports the outcome of its monitoring to the approval authority or technical service at least once a year.

ISO/SAE 21434 and UNECE R155 are complementary but distinct. ISO 21434 defines how to do cybersecurity engineering — the processes, methods, and work products. UNECE R155 is a regulation that requires OEMs to demonstrate they have a Cybersecurity Management System (CSMS) for vehicle type approval.

In practice, ISO/SAE 21434 is the widely used way to satisfy UNECE R155 requirements. The TARA outputs and work products from ISO/SAE 21434 serve as the evidence package for the R155 CSMS certificate of compliance — valid for up to three years — and for each vehicle-type approval.

UNECE R155. The regulation is outcome-oriented: it asks for a CSMS, a risk assessment that considers the Annex 5 threat examples, appropriate mitigations and appropriate and sufficient testing — and leaves the method to the manufacturer. That is why ISO/SAE 21434 work products are the natural evidence. See the UNECE R155 compliance page and the side-by-side ISO/SAE 21434 vs UNECE R155 comparison.

UNECE R156. R156 governs the Software Update Management System. It is a separate regulation, but the security of the update channel — signing, authenticity, rollback protection — is analysed in the same TARA, so CSMS and SUMS evidence are usually built together. See UNECE R156 and SUMS.

AIS 189 and AIS 190.India’s standards are aligned with R155 and R156, and the TARA methodology expected in AIS 189 submissions is aligned with ISO/SAE 21434:2021 — an organisation with a mature ISO/SAE 21434 CSMS can reuse the same evidence base with modest adaptation. India is not a party to the 1958 Agreement, so Indian approvals do not carry mutual recognition with UNECE markets, and applicability and dates are set by MoRTH notification. See the AIS 189 compliance page and the AIS 189 and AIS 190 guide.

ISO/SAE 21434:2021 is still the current and only published edition. On 15 July 2026 it entered ISO’s routine systematic review (stage 90.20). The review closed on 2 October 2026 with the standard at stage 90.92 — to be revised — and ISO registered the second-edition project, ISO/SAE AWI 21434 (Edition 2), the same day at stage 20.00, the first step of ISO development. ISO has announced no publication date.

The joint ISO/SAE working group has shared a public roadmap: industry comments collected in August 2024, scope decisions taken in November 2025, development expected to start in 2026 (borne out by the October 2026 registration) and an estimated publication around 2029 — an estimate, not an ISO date. The decided direction is continuity — no change in scope or structure, ISO/PAS 5112 remaining a separate audit document, and ISO/SAE TR 8477’s verification and validation content merging in. The Clauses 5–15 organisation, the work products and the TARA method carry forward.

The practical conclusion: do not wait. UNECE R155 already applies, and evidence built on the 2021 edition will not be discarded. The dates and decisions are covered in ISO/SAE 21434 second edition: what is changing and when.

In the EU, UNECE R155 and R156 apply through the type-approval framework of Regulation (EU) 2019/2144. In Germany the approval authority is the KBA; designated technical services such as TÜV SÜD and TÜV Rheinland assess the CSMS and the vehicle-type evidence and report to it. R155 does not name ISO/SAE 21434, but technical services read the evidence against it — so a TARA, cybersecurity case and test reports structured to the standard shorten the assessment conversation. For test evidence written to that expectation, see automotive penetration testing in Germany and Europe.

German and other European OEMs pass the expectation down their supply chains through sourcing requirements and Clause 7 interface agreements, which is how Tier-1 and Tier-2 suppliers inside and outside Europe meet ISO/SAE 21434 first.

Three neighbouring regimes are often confused with it:

• NIS2.Germany’s NIS2 implementation law, the NIS2UmsuCG, has been in force since 6 December 2025. It covers the security of a company’s own networks and information systems — not the vehicle — and brings manufacturers of motor vehicles and parts with 50 or more employees, or annual turnover and balance-sheet total each above EUR 10 million, under BSI supervision. Incident response, vulnerability management and supplier management built for an ISO/SAE 21434 CSMS can be reused. See NIS2 for automotive suppliers.
• Cyber Resilience Act. Article 2(2)(c) excludes products covered by Regulation (EU) 2019/2144, so type-approved vehicles and their systems stay under R155 / R156. Aftermarket devices, charging equipment and standalone components can still fall in CRA scope — see the Cyber Resilience Act and automotive scope.
• TISAX.TISAX assesses information security in the supplier’s organisation, against the VDA ISA catalogue. It answers a different question from ISO/SAE 21434, which is about the cybersecurity of the product being engineered.

Whether you are an OEM preparing a CSMS audit or a supplier answering a customer’s first cybersecurity questionnaire, the sequence below gets to defensible evidence fastest.

1. Scope and gap assessment. Map what exists today against Clauses 5–15, and note which customers, markets and programmes drive the requirement.
2. Organisational foundation (Clause 5). Policy, roles, competence, tool management, information sharing and an organisational audit — ISO/PAS 5112 gives audit guidance.
3. Pilot one item (Clauses 9 and 15). Item definition, TARA, cybersecurity goals and concept on one representative system, and a decision on how you will assign CALs, before scaling to the portfolio.
4. Agree interfaces early (Clause 7). Interface agreements take months to negotiate; start with your largest customers and suppliers.
5. Plan verification and validation from the TARA (Clauses 10 and 11). Derive test scope from goals and attack paths, not from a generic checklist.
6. Build the cybersecurity case (Clause 6). Assemble the argument and evidence, have it assessed, and release for post-development.
7. Stand up continual activities before SOP (Clauses 8 and 13). Monitoring, vulnerability management and incident response must work before the first vehicle ships.

There is no fixed timeline. A gap assessment usually takes weeks; a manual TARA typically several weeks per system; and an organisational CSMS with a first fully evidenced project commonly takes six to 18 months, depending on starting maturity.

For a shorter primer to share with colleagues, read ISO/SAE 21434 explained. If you want engineers who do this work every day to run the gap assessment, TARA or work-product authoring with your team, see our ISO 21434 consulting.

Manual TARA using spreadsheets faces several critical challenges:

• Time: A single TARA typically takes several weeks per system, with significant engineering hours consumed by documentation.
• Consistency: Risk ratings vary between engineers and across projects, creating audit vulnerabilities.
• Scalability:Modern vehicles have 100+ ECUs. Manual TARA doesn't scale across platforms and variants.
• Traceability: Maintaining continuous asset-to-verification traceability across lifecycle work products in spreadsheets is error-prone and fragile.
• Threat coverage: Manual research cannot systematically cover the full landscape of automotive threats across EMB3D, AutoISAC, NVD, and other databases.