ISO/SAE 21434 Guide: Automotive Cybersecurity Engineering

UN Regulation No. 155 tells vehicle manufacturers that they must manage cyber risk across the life of a vehicle type, but it does not say how, and ISO/SAE 21434 is the engineering standard almost every manufacturer and supplier uses to fill that gap. Published in August 2021 by ISO and SAE International, it defines the processes, the threat analysis and risk assessment (TARA) method and the work products that turn cybersecurity from a review at the end into an engineering discipline from concept to decommissioning. This guide explains its structure clause by clause, the requirements that carry the most weight, how credentials and keys appear in a TARA, how to implement it in an organisation and a project, what assessors look for, and how it maps to R155 and other frameworks. It is written for product security engineers, functional safety engineers moving into security, and supplier quality teams. For the regulation itself see the UNECE R155 Cyber Security Management System Guide; for in-vehicle controls see the Automotive Cybersecurity Guide.

Status checked 27 October 2026: ISO/SAE 21434:2021, edition 1, 81 pages, from ISO/TC 22/SC 32. The ISO catalogue shows it at stage 90.92 ("International Standard to be revised", dated 2 October 2026), with a revision registered as an approved work item (ISO/SAE AWI 21434). The 2021 edition remains the current standard until a new edition is published; avoid relying on details of the revision until a draft is circulated.

Key takeaways

Process and risk, not technology. The standard is technology-agnostic: it specifies engineering requirements for cybersecurity risk management of road vehicle electrical and electronic (E/E) systems, not which algorithms or architectures to use.
Two levels of obligation. Organisational clauses (policy, culture, processes, tools, audit) apply once to the organisation; project clauses (planning, TARA, concept, development, validation) apply to each item or component.
TARA is the engine. Clause 15 defines asset identification, threat scenarios, impact rating across safety, financial, operational and privacy, attack path analysis, attack feasibility rating, risk values and treatment decisions.
Work products are the evidence. Requirements are traced to named work products, and the cybersecurity case argues from them that the item is secure enough for release.
Suppliers are built in. Clause 7 requires a cybersecurity interface agreement that allocates activities and work products between customer and supplier, which is what R155 paragraph 7.2.2.5 asks the manufacturer to show.

What it is and who it applies to

ISO/SAE 21434 applies to road vehicles and to their E/E systems, components and interfaces, including the software, over the whole lifecycle: concept, product development, production, operations and maintenance, and decommissioning. It is a voluntary standard, but it becomes binding in practice in three ways: manufacturers use it to evidence an R155 cyber security management system, they write it into supplier contracts, and approval authorities and technical services are familiar with its vocabulary.

Organisation	Why ISO/SAE 21434 matters to it	Typical scope
Vehicle manufacturer	Evidence for the R155 CSMS and vehicle type risk assessment	All organisational clauses, vehicle-level items, supplier management
Tier 1 supplier	Contractual requirement in requests for quotation	Organisational clauses, component-level TARA and development, interface agreements
Tier 2 and software suppliers	Flowed down by Tier 1s	Development, vulnerability management, off-the-shelf and out-of-context components
Back-end and service providers	Back ends are external interfaces of the item	Usually addressed by the item's TARA and by contracts, with information security standards covering the IT side

What it does not cover: it does not specify cybersecurity technology, it does not cover software update engineering in depth (that is ISO 24089:2023), and it does not certify organisations: there is no ISO/SAE 21434 certificate defined in the standard, although assessment and audit are defined and many third parties offer attestation.

Structure and key requirements

The clause summary below is our reading of the 2021 edition; check the ISO text for exact titles and requirement wording. The normative content runs from clause 5 to clause 15. Requirements are labelled RQ, recommendations RC and permissions PM, each with clause-based numbering, and each clause lists the work products (WP) it produces.

Clause	Title	Key requirements and work products
5	Organizational cybersecurity management	Cybersecurity policy, rules and processes; cybersecurity culture and competence; management systems (quality, configuration, requirements management); tool management; information security management; organisational cybersecurity audit
6	Project dependent cybersecurity management	Responsibilities, cybersecurity plan, tailoring, reuse, out-of-context and off-the-shelf components, cybersecurity case, cybersecurity assessment, release for post-development
7	Distributed cybersecurity activities	Supplier capability evaluation, requests for quotation, alignment of responsibilities in a cybersecurity interface agreement
8	Continual cybersecurity activities	Cybersecurity monitoring, event evaluation, vulnerability analysis, vulnerability management
9	Concept	Item definition, cybersecurity goals and claims, cybersecurity concept
10	Product development	Cybersecurity specifications refined through design, integration and verification
11	Cybersecurity validation	Validation of cybersecurity goals at vehicle level
12	Production	Production control plan so that cybersecurity requirements for post-development are applied in manufacturing
13	Operations and maintenance	Cybersecurity incident response, updates
14	End of cybersecurity support and decommissioning	Communicating end of support, decommissioning procedures
15	Threat analysis and risk assessment methods	Asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination, risk treatment decision

The informative annexes include a summary of activities and work products, examples of cybersecurity culture, a cybersecurity interface agreement example, cybersecurity relevance criteria, cybersecurity assurance levels (CAL), guidelines for impact and attack feasibility rating, and a worked TARA example.

The TARA in more detail

Step	Output	Practical notes
Asset identification	Assets with cybersecurity properties (confidentiality, integrity, availability) and damage scenarios	Include keys, certificates and credentials as assets, not just functions and data
Threat scenario identification	Threat scenarios linked to damage scenarios	STRIDE is commonly used; R155 Annex 5 Part A is a useful completeness check
Impact rating	Impact ratings in safety, financial, operational and privacy categories	Safety ratings are usually aligned with ISO 26262 severity
Attack path analysis	Attack paths realising each threat scenario	Top-down (attack trees) or bottom-up from known vulnerabilities
Attack feasibility rating	Attack feasibility on a graded scale	Attack potential based (elapsed time, expertise, knowledge of the item, window of opportunity, equipment), CVSS based, or attack vector based approaches
Risk value determination	Risk value on a defined scale	Combination of impact and feasibility, typically through a matrix the organisation defines
Risk treatment decision	Avoid, reduce, share or retain	Reduce leads to cybersecurity goals; share and retain lead to cybersecurity claims that must be justified

Cybersecurity assurance levels

Cybersecurity assurance levels, described in an informative annex, express the level of rigour applied to engineering activities for a component or cybersecurity goal, typically derived from impact and attack vector. A CAL does not describe the strength of the technical controls; it scales the depth of verification, review and independence. Many manufacturers use CAL to decide, for example, whether a component needs penetration testing by an independent team.

Identity and NHI requirements

ISO/SAE 21434 has no clause titled identity, but credentials run through every stage, and treating them as first-class assets is what separates a strong TARA from a superficial one.

Keys and certificates as assets: ECU identity keys, secure onboard communication (SecOC) keys, TLS client certificates for back ends, V2X and charging certificates, and software signing keys each need confidentiality and integrity properties in the asset list, and damage scenarios for their compromise. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Key provisioning in production (clause 12): the production control plan should specify how unique keys are injected, how injection stations authenticate to key management systems, and how key material is protected at the line.
Diagnostic and security access (clauses 10 and 13): UDS security access seeds and keys, and authenticated diagnostics, are classic attack paths. Avoid static or shared secrets across a vehicle line.
Back-end credentials: telematics and app back ends are external interfaces of the item. Their service accounts and API keys should appear in the TARA as attack paths, with controls and ownership defined in the interface agreement or IT security policy. See the Secrets Management Guide.
Update signing keys (clause 13 and ISO 24089): Uptane-style designs separate an Image repository from an online Director repository and use root, targets, snapshot and timestamp roles, so that one key compromise does not become a fleet compromise.
Tool management (clause 5): CI/CD pipelines, flashing tools and test benches hold credentials to repositories and ECUs. Tool qualification and management should cover how those credentials are stored and rotated.
AI agents and assistants: an in-vehicle assistant that can call vehicle functions is an item interface for clause 15, and AI agents used in engineering (generating code, triaging vulnerabilities) are tools under clause 5 with access to sensitive repositories. Both need scoped credentials and logged actions.

Implementation steps

Gap-assess the organisation. Compare existing quality, safety and information security processes against clause 5 and decide where cybersecurity processes plug in rather than duplicating them.
Write policy, rules and processes. Define the cybersecurity policy, the TARA method (rating scales, risk matrix, acceptance criteria), the CAL scheme, vulnerability management and incident response.
Set up tooling and competence. Choose a TARA tool or template, train engineers, and establish a cybersecurity culture with clear escalation paths.
Pilot on one item. Run the full project flow (plan, item definition, TARA, goals, concept, development, verification, validation, case, assessment, release) on one ECU or feature before rolling out.
Agree interface agreements. For each supplier, define who produces which work products, how vulnerabilities are reported and how long support lasts.
Connect continual activities. Feed vulnerability intelligence, field monitoring and supplier reports into clause 8 vulnerability analysis and management, and connect it to clause 13 incident response.
Audit and improve. Run organisational cybersecurity audits and project cybersecurity assessments, and feed findings back into processes.

Rolling out in rings works: pilot project, then all new projects, then carry-over items as they are modified. For reused components (clause 6), perform an analysis of the reused item's work products rather than repeating the full lifecycle.

Evidence and assessment

Activity	Who performs it	What it examines
Organisational cybersecurity audit (clause 5)	Independent auditor, internal or external	Whether organisational processes meet the standard's objectives
Cybersecurity assessment (clause 6)	Independent assessor	Whether the item's work products and the cybersecurity case give adequate confidence
Cybersecurity case (clause 6)	Project	Argument, built on work products, that the item's cybersecurity is achieved
Release for post-development (clause 6)	Project and management	Case and assessment complete, post-development requirements accepted
R155 CSMS and type assessment	Approval authority or technical service	Whether processes and the vehicle type meet R155, often by reviewing 21434 work products

Assessors repeatedly ask for: traceability from damage scenarios through goals to requirements and tests; justification of retained risks and claims; evidence that TARA was updated after design changes; supplier work products received under the interface agreement; and vulnerability management records after release.

Metrics

TARA currency: share of items whose TARA was updated after the last architecture change.
Traceability: share of cybersecurity goals with linked requirements, verification and validation results.
Supplier coverage: share of suppliers with a signed cybersecurity interface agreement.
Vulnerability throughput: median days from vulnerability intake to risk treatment decision.
Credential assets: share of items whose asset list includes all keys, certificates and service credentials.

Mapping to other frameworks

ISO/SAE 21434 clause	UN R155 paragraph	NIST CSF 2.0	NIST SP 800-53 Rev 5
5 Organizational management	7.2.2.2(a)	GV.RM-01	PM-9
7 Distributed activities	7.2.2.5, 7.3.2	GV.SC-05, GV.SC-07	SR-3, SR-6
8 Continual activities	7.2.2.2(f), (g), 7.2.2.3	ID.RA-01, DE.CM-01	RA-5, SI-4
9 and 15 Concept and TARA	7.2.2.2(b), (c), 7.3.3	ID.RA-05	RA-3
10 Product development	7.3.4, 7.3.8	PR.PS-01	SA-8, SC-13
10 and 11 Verification and validation	7.2.2.2(d), (e), 7.3.6	ID.IM-01	SA-11
13 Operations and maintenance	7.2.2.2(g), (h), 7.3.7	RS.MA-01	IR-4

Related standards: ISO 24089 for software update engineering (supporting R156), ISO 26262 for functional safety, and IEC 62443 for industrial systems, which some suppliers also follow for production equipment. See the UNECE R156 Software Update Management System Guide and the IEC 62443 Guide.

Common pitfalls

TARA as a spreadsheet exercise: threat scenarios are copied from a template, not derived from the item's architecture, so attack paths miss the real interfaces.
Keys missing from the asset list: functions and data are rated but credentials are not, so key compromise never gets a damage scenario.
Interface agreements without teeth: agreements list work products but not vulnerability notification timelines or support periods.
Continual activities that stop at release: clause 8 monitoring is staffed during development and fades after start of production.
Retained risks without claims: risks are accepted without a documented cybersecurity claim and rationale, which assessors flag.
Back ends out of scope: the item stops at the vehicle boundary, while the Toyota T-Connect key exposure shows how a back-end access key in a supplier's repository can expose connected-car customer data for years.

Practitioner checklist

Track the ISO/SAE 21434 revision (AWI stage in October 2026) and plan a transition review.
Define one TARA method with rating scales, risk matrix and acceptance criteria for all projects.
List keys, certificates and service credentials as assets in every TARA.
Sign a cybersecurity interface agreement with each supplier, including vulnerability notification and support period.
Maintain traceability from damage scenarios to goals, requirements and tests.
Specify key injection and protection in the production control plan.
Run clause 8 vulnerability monitoring for the whole support period, not only development.
Prepare the cybersecurity case and independent assessment before release for post-development.
Map work products to R155 paragraphs so the CSMS audit reuses them.

ISO/SAE 21434 Automotive Cybersecurity Engineering Guide: TARA, CAL Levels and Lifecycle Work Products