ISO/SAE 21434: ISO/SAE 21434 – Tutorial (about 60 minutes)

ISO/SAE 21434 is the international standard for cybersecurity engineering of road vehicles. Vehicle manufacturers, their suppliers and the companies that build vehicle software use it to manage cybersecurity risk from the first concept of a feature, through development and production, to operation in the field and final decommissioning. After this tutorial you will be able to explain what the standard asks of an organisation and a project, carry out the logic of a threat analysis and risk assessment (TARA) on a simple feature, and see how the standard connects to vehicle regulations and to other automotive standards.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current version is ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering, first edition, published in August 2021. It is a joint document of ISO (technical committee ISO/TC 22, subcommittee SC 32) and SAE International, so the same text is sold by both bodies. ISO's catalogue marks the 2021 edition as "to be revised", and a second edition has been registered as an approved work item (ISO/SAE AWI 21434). Public updates from the joint working group in late 2025 said the scope and structure will stay the same, that content from the joint projects on cybersecurity assurance levels and on verification and validation will feed in, and that development was expected to start in 2026 and take several years. Until a new edition is published, the 2021 edition is the one to apply. Verified 2026-10-29 against the ISO catalogue entries for ISO/SAE 21434:2021 and ISO/SAE AWI 21434, the SAE catalogue entry, and a December 2025 roadmap presentation by a co-convener of the ISO/SAE joint working group. The standard is paid-for and copyrighted; this course explains it in its own words and does not reproduce its text.

Who it is for: engineers, architects, testers, project and quality managers, security specialists and compliance staff at vehicle manufacturers (often called OEMs, original equipment manufacturers) and at suppliers of electronic control units, software and services, who are new to automotive cybersecurity.

Prerequisites: none. Basic familiarity with how vehicle electronics are developed helps, but every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why the standard exists, what it covers and what it deliberately leaves out.
You will be able to use its core vocabulary correctly, from item and asset to cybersecurity goal, claim and case.
You will be able to describe how its clauses are organised and which clauses apply at organisation level and which at project level.
You will be able to walk through the steps of a threat analysis and risk assessment and turn the results into goals and requirements.
You will be able to describe how cybersecurity continues after development through monitoring, vulnerability management, incident response and end of support.
You will be able to explain how conformity is judged, including the difference between a cybersecurity assessment, an audit and a regulatory approval.
You will be able to position the standard against UN R155, UN R156, ISO 26262, ISO 21448 and related documents.

Lesson 1 – Origins, purpose and scope

Why vehicles needed their own cybersecurity standard

A modern car contains dozens of electronic control units (ECUs), small computers that run braking, steering, engine management, infotainment, door locks and much more. Many of them talk to each other over in-vehicle networks such as CAN and automotive Ethernet, and a growing number talk to the outside world over cellular, Wi-Fi, Bluetooth and charging interfaces. Every external connection is a possible entry point for an attacker, and a successful attack on a vehicle can do more than leak data: it can cause a crash, stop a fleet of delivery vans or let a thief drive away.

Public research during the 2010s demonstrated remote attacks on production vehicles, and the industry realised that the methods used for office IT were not enough on their own. Vehicles have long lives (often fifteen years or more), are built by long supply chains, are hard to patch if they lack update capability, and combine security with physical safety. In 2016 SAE International published J3061, a guidebook for cybersecurity of cyber-physical vehicle systems. ISO and SAE then set up a joint working group to produce a full international standard, which became ISO/SAE 21434 in 2021.

What the standard is for

The standard has three broad aims. First, it gives the whole industry a common vocabulary, so that a vehicle manufacturer and a supplier mean the same thing when they say "threat scenario" or "cybersecurity goal". Second, it sets requirements for the processes an organisation and a project need in order to manage cybersecurity risk. Third, it asks for evidence (called work products) so that the risk decisions can be reviewed, assessed and defended later.

A key design choice is that ISO/SAE 21434 is process-oriented and technology-neutral. It tells you what activities to carry out and what outcomes to reach, but it does not prescribe a particular cipher, protocol, intrusion detection product or network architecture. That makes it durable: the same process applies to a 2021 telematics unit and to a future software-defined vehicle, while the specific protective measures change as technology moves on.

Scope

The standard applies to the electrical and electronic (E/E) systems of series-production road vehicles, including their components and the interfaces between them. It covers the whole lifecycle: concept, product development, production, operation and maintenance, and decommissioning. It applies to anyone in the supply chain who engineers such systems, so a semiconductor company, a software house and a vehicle manufacturer can all claim to follow it for their part of the work.

Several things are outside its scope. It does not cover systems outside the vehicle, such as the manufacturer's back-end servers, except where they interface with the vehicle; it does not set technical security levels for specific products; and it is not, by itself, a law. Its risk view centres on harm to road users (drivers, passengers, pedestrians, vehicle owners), although an organisation may consider further impact categories if it justifies them.

How the document speaks

Each clause states objectives, inputs, requirements and recommendations, and outputs. Requirements, recommendations and permissions carry identifiers that start with RQ, RC and PM, and the outputs are numbered work products starting with WP, each tagged with the clause number. This numbering makes it easy to build a compliance matrix that links each requirement to the evidence in your project. Annex A gives a summary of all activities and work products, which many teams use as a starting checklist.

Lesson 2 – Key concepts and vocabulary

ISO/SAE 21434 builds a precise chain of terms. Learn them in the order below, because each one depends on the ones before it. The wording is ours; the standard's formal definitions are in its Clause 3.

Item – a component or set of components that implements a function at vehicle level, for example "remote door unlocking" or "headlamp control". The item is the unit you analyse in the concept phase.
Component – a part of an item that can be logically or technically separated, such as an ECU, a software module or a sensor. Suppliers often develop components rather than whole items.
Cybersecurity property – the attributes worth protecting: confidentiality, integrity and availability. Authenticity, authorisation and non-repudiation are often added in practice.
Asset – something of value whose cybersecurity property can be compromised and so lead to damage. A firmware image (integrity), a stored location history (confidentiality) or a brake command message (integrity and availability) are typical assets.
Damage scenario – an adverse consequence at vehicle or road-user level, such as "the vehicle is unlocked and stolen" or "the driver's journeys are exposed to a stranger".
Threat scenario – a potential cause of the compromise of a cybersecurity property of an asset that leads to a damage scenario, for example "spoofing of the unlock command leads to loss of integrity of the lock state".
Attack path – the set of deliberate steps an attacker would take to realise a threat scenario, starting from an entry point such as a cellular link or the diagnostic port.
Attack feasibility – how easily an attack path can be carried out, rated high, medium, low or very low.
Impact rating – an estimate of how severe a damage scenario is, in the categories safety, financial, operational and privacy, rated severe, major, moderate or negligible.
Risk value – a number from 1 (lowest) to 5 (highest) derived from the impact of a damage scenario and the feasibility of its attack paths.
Cybersecurity goal – a concept-level requirement that protects an asset against a threat scenario where the decision is to reduce the risk.
Cybersecurity claim – a documented statement about a risk that is retained or shared rather than reduced, with the reasoning behind it.
Cybersecurity concept – the set of cybersecurity requirements on the item, together with requirements on its operational environment, that together achieve the cybersecurity goals.
Cybersecurity case – a structured argument, backed by work products, that the item or component is cybersecurity-adequate.
Cybersecurity assessment – an independent judgement of the cybersecurity of an item or component, based on the cybersecurity case and the evidence behind it.
Cybersecurity information – any security-related information collected by monitoring (an advisory, a researcher's report, a news item) whose relevance to the item has not yet been decided.
Cybersecurity event, weakness and vulnerability – an event is cybersecurity information that has been judged relevant to an item or component; a weakness is a defect or characteristic that could lead to undesirable behaviour; a vulnerability is a weakness that can actually be exploited as part of an attack path.
Cybersecurity incident – a situation in the field that may involve one or more vulnerabilities being exploited.
CAL – cybersecurity assurance level, an informative scale (CAL 1 to CAL 4) that sets how much rigour and independence the engineering of a goal needs.

Two distinctions trip up beginners. First, a damage scenario describes harm, while a threat scenario describes a cause; you rate impact on the damage scenario and feasibility on the attack paths of the threat scenario. Second, a goal and a claim are different answers to a risk: a goal says "we will reduce this risk with measures", a claim says "we accept or transfer this risk, and here is why".

Lesson 3 – Structure of the standard

The body of the standard has fifteen clauses. Clauses 1 to 4 are the usual introductory material (scope, normative references, terms and abbreviations, and general considerations that explain the vehicle ecosystem and how the parts fit together). The requirements live in clauses 5 to 15, which fall into four groups.

Figure 1 – The requirement clauses of ISO/SAE 21434: management clauses frame supporting activities that serve the lifecycle phases from concept to decommissioning.

Overall management: clauses 5 and 6

Clause 5, organisational cybersecurity management, is about the company, not a single product. It expects a cybersecurity policy endorsed by leadership, rules and processes that implement it, clear responsibilities and authority, a cybersecurity culture, competence and awareness management, information sharing with external parties, supporting management systems (quality, configuration, change and requirements management), management of the tools used in development, an information security management system that protects engineering data, and organisational cybersecurity audits that check whether the processes really meet the standard's objectives.

Clause 6, project dependent cybersecurity management, applies to each development project. It covers assigning responsibilities, writing a cybersecurity plan that lists the activities, their owners and timing, tailoring activities with a documented rationale, handling reuse of existing items and components, components developed "out of context" (without a specific vehicle in mind, using assumptions), and off-the-shelf components. It also defines the cybersecurity case, the cybersecurity assessment and the release for post-development, the formal gate that says the item or component is ready for production and the field.

Activities that span the lifecycle: clauses 7, 8 and 15

Clause 7, distributed cybersecurity activities, deals with the supply chain. It covers evaluating a supplier's cybersecurity capability, including cybersecurity requirements in requests for quotation, and agreeing who does what in a cybersecurity interface agreement between customer and supplier.

Clause 8, continual cybersecurity activities, runs from the start of development until end of support. It describes cybersecurity monitoring (collecting information from inside and outside the organisation and triaging it to identify cybersecurity events), evaluation of those events, vulnerability analysis of weaknesses, and vulnerability management.

Clause 15, threat analysis and risk assessment methods, is a toolbox. It describes the building blocks of a TARA (asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination and risk treatment decision). Other clauses call these blocks whenever they need a risk view: in the concept phase, when a vulnerability is reported, or when a design changes.

The lifecycle phases: clauses 9 to 14

Clause 9, concept: define the item, run the TARA, set cybersecurity goals and claims, and write the cybersecurity concept.
Clause 10, product development: refine the concept into architecture, design and implementation, and verify that the cybersecurity specifications are met during integration and testing.
Clause 11, cybersecurity validation: confirm at vehicle level that the goals are adequate and achieved, and that the claims and assumptions still hold.
Clause 12, production: make sure manufacturing does not introduce vulnerabilities, using a production control plan.
Clause 13, operations and maintenance: respond to incidents and manage updates in the field.
Clause 14, end of cybersecurity support and decommissioning: decide and communicate when support ends, and make it possible to decommission without exposing data or keys.

Annexes

The informative annexes help with application. Annex A summarises activities and work products. Other annexes give examples of a cybersecurity culture, an example of an interface agreement, criteria for deciding whether something is cybersecurity-relevant, guidance on cybersecurity assurance levels (Annex E), approaches to attack feasibility rating, and a worked TARA example for a headlamp system (Annex H). Informative means they explain and illustrate; they do not add requirements.

Lesson 4 – How it works in practice

Step 1: build the organisational foundation

Before any project can follow the standard efficiently, the organisation needs the clause 5 basics. In practice that means a short policy signed by leadership, a process handbook that maps every RQ to a company procedure and template, a named cybersecurity function with the authority to stop a release, training paths for engineers, testers and managers, a tool qualification approach, a secure engineering environment and a regular internal audit. Many companies reuse their existing quality management system (often certified to IATF 16949 or ISO 9001) and their information security management system (often certified to ISO/IEC 27001 or assessed under TISAX) instead of inventing parallel ones.

Step 2: plan the project

Each project starts with a cybersecurity plan. It states which item or component is being developed, whether it is new or reused, which activities apply, who is responsible, and which work products will be produced. If an activity is skipped or reduced (tailoring), the plan must say why. A supplier developing a generic ECU platform before any customer exists works out of context: it documents assumptions about how the platform will be used, and later checks those assumptions against each real vehicle project.

Step 3: concept and TARA

The concept phase starts with the item definition: the item's boundary, its functions, its preliminary architecture, its interfaces and the assumptions about its operating environment. Then comes the TARA, the analytical heart of the standard.

Figure 2 – The TARA flow: impact comes from damage scenarios, feasibility from attack paths, and the combined risk value drives the treatment decision.

The steps work like this:

Asset identification. List what in the item has value and which cybersecurity property matters for each: the integrity of a command, the confidentiality of personal data, the availability of a function. For each asset, ask what harm would follow if that property were lost; those are the damage scenarios.
Threat scenario identification. For each asset and property, describe how it could be compromised. Many teams use STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a prompt, or a catalogue of known automotive threats.
Impact rating. Rate each damage scenario in four categories: safety, financial, operational and privacy (often abbreviated SFOP), using the four levels severe, major, moderate and negligible. Safety impact is usually aligned with the severity scale used in functional safety (ISO 26262), so the two teams speak the same language.
Attack path analysis. For each threat scenario, find realistic sequences of attacker steps, top-down (starting from the goal, as in attack trees) or bottom-up (starting from known vulnerabilities and entry points).
Attack feasibility rating. Rate each path high, medium, low or very low. The standard describes three families of method. The attack-potential approach scores factors such as elapsed time, specialist expertise, knowledge of the item, window of opportunity and equipment, an idea borrowed from security evaluation of IT products. The CVSS-based approach reuses the exploitability metrics of the Common Vulnerability Scoring System. The attack-vector approach is the simplest: it rates by how remote the entry point is, so a network attack is more feasible than one needing physical access. Early in the concept phase, when details are thin, teams often start with the attack-vector approach and refine later.
Risk value determination. Combine impact and feasibility, typically through a risk matrix that the organisation defines, into a value from 1 to 5. If a threat scenario has several attack paths, the most feasible one usually drives the result.
Risk treatment decision. Choose one or more options for each threat scenario: avoid the risk (remove the feature or the entry point), reduce it (add measures), share it (for example through a contract or with the vehicle user), or retain it (accept it, with justification). The organisation's own risk acceptance criteria tell the team which risk values may be retained.

The outputs of the concept phase are cybersecurity goals for every reduced risk, cybersecurity claims for every shared or retained risk, and the cybersecurity concept: requirements on the item and on its environment that, taken together, achieve the goals. A requirement on the environment might be "the back-end shall only send unlock commands for authenticated users", which the item itself cannot guarantee and which therefore becomes an assumption to validate later.

Step 4: product development and verification

In clause 10 the concept is refined level by level, from system architecture down to hardware and software design. At each level the team writes cybersecurity specifications, checks that the design does not introduce new weaknesses, applies secure coding and design principles, and verifies the result through reviews, static analysis, testing (functional security tests, fuzzing, vulnerability scanning) and, where useful, penetration testing. Any weakness found during development goes through the same analysis as a weakness found in the field.

Figure 3 – From goals to release: requirements are refined and verified, the item is validated, and the evidence is argued in a case that is independently assessed before release.

Step 5: validation, case and release

Verification asks "did we build it to the specification?"; validation asks "does the specification achieve the goals in the real vehicle?". In clause 11, the integrated item is examined in its vehicle configuration, for example by penetration testing against the threat scenarios and by checking that the environmental assumptions are met. The project then compiles the cybersecurity case: an argument, supported by the work products, that the residual risk is acceptable. An independent cybersecurity assessment judges the case, and the release for post-development records the decision to move into production.

Step 6: production, operation and end of life

Production has its own cybersecurity concerns: injecting cryptographic keys securely, programming the right software version, locking debug interfaces, and protecting production tools and data. These are captured in a production control plan.

Once vehicles are on the road, clause 8 and clause 13 take over. The organisation monitors sources such as vulnerability databases, security researchers, supplier notices, its own vehicle security operations centre (VSOC) and threat intelligence. Each piece of collected information is first triaged against defined triggers: does it concern our item at all? Only information judged relevant becomes a cybersecurity event. The event is then evaluated to see whether it reveals a weakness, and the weakness is analysed to decide whether it is a vulnerability in this context. Vulnerabilities are then managed through the TARA methods and treated, for instance by a software update or a change to the back-end, or retained with a documented reason. If exploitation is actually happening or likely, the incident response plan is triggered.

Figure 4 – Continual activities: monitored information is triaged into events, which are analysed for weaknesses and vulnerabilities; vulnerabilities are treated through the TARA methods and, if exploited, through incident response.

Finally, the organisation defines when cybersecurity support for an item will end and tells customers, so that nobody assumes indefinite patching. Decommissioning procedures make sure that personal data and keys can be removed when a vehicle or component leaves service, for example when a car is scrapped or a module is replaced at a workshop.

Roles you will meet

Cybersecurity manager – owns the plan and the case for a project.
Cybersecurity architect or engineer – runs the TARA and designs the measures.
Security tester – performs verification and validation testing, including penetration tests.
Independent assessor – reviews the case and evidence; independence from the project team is the point.
Product security incident response team – handles events, vulnerabilities and incidents in the field.

Lesson 5 – Assessment, certification and compliance

Conformance is about evidence

The standard is written so that conformity can be shown with work products. A team that "does security" but cannot show its item definition, TARA, goals, verification reports and case will struggle in any review. The flip side is that the standard does not require a particular document format: an engineering tool, a database or a wiki can hold the evidence if it is controlled and traceable.

Three different kinds of review

Cybersecurity assessment (clause 6). A judgement of the cybersecurity of one item or component, made by someone independent of the development team. It looks at the cybersecurity case and the work products and concludes whether the residual risk is acceptable and the activities were done properly. It is a product-level review.
Organisational cybersecurity audit (clause 5). A check that the organisation's processes meet the objectives of the standard. It is a process-level review, independent of any single product. ISO/PAS 5112:2022 gives guidelines for auditing a cybersecurity management system built on these processes, as a supplement to the general audit guidance of ISO 19011.
Process capability assessment. Some customers ask for an Automotive SPICE for Cybersecurity assessment, which rates how capable the supplier's cybersecurity engineering processes are, using a capability-level scale. This is related to, but distinct from, the standard itself.

Is there an "ISO/SAE 21434 certificate"?

ISO and SAE do not certify anyone, and ISO/SAE 21434 was not written as a classic certifiable management system standard. Several certification bodies and test laboratories nevertheless offer audits and certificates or attestations under their own programmes, for organisations (process conformity) or for specific products. Such a certificate is the opinion of that body under its scheme; it is useful evidence for customers, but it is not an official ISO certification and it is not a legal approval. Read the scope of any such certificate carefully: it may cover one site, one process area or one product only.

The regulatory link: UN R155

The legal driver in many markets is UN Regulation No. 155, adopted under the UNECE 1958 Agreement. It requires a vehicle manufacturer to hold a certificate of compliance for its cybersecurity management system (CSMS) and to obtain cybersecurity type approval for each vehicle type. In the EU it became mandatory for new vehicle types from July 2022 and for all newly registered vehicles from July 2024. R155 does not mandate ISO/SAE 21434, but approval authorities and technical services widely accept processes based on the standard as a way to show that the regulation's requirements are met. Manufacturers then flow those expectations down to suppliers, which is why supplier contracts often ask for conformity with ISO/SAE 21434.

Cybersecurity assurance levels

Annex E describes cybersecurity assurance levels, CAL 1 to CAL 4, as an informative way to scale rigour. A CAL is usually assigned per cybersecurity goal from the impact of the related damage scenarios and the attack vector of the threats. A higher CAL calls for more thorough methods, more independence in reviews and deeper testing. A CAL does not say which security measures to build; it says how much assurance the engineering of those measures must give. Because the annex is informative, companies use CALs in different ways; a separate ISO/SAE publicly available specification on CALs and targeted attack feasibility (ISO/SAE PAS 8475) has been in development to harmonise this; it was still a draft (DPAS) when this course was checked in October 2026.

Lesson 6 – Worked example

Consider a fictional vehicle manufacturer, Northbridge Motors, that adds a feature to a new model: owners can unlock their car from a smartphone app. The app talks to Northbridge's back-end, which sends a command over the cellular network to the car's telematics control unit (TCU). The TCU forwards the command through the central gateway to the body control module, which drives the door locks. The TCU is supplied by a tier-1 supplier, Corvale Electronics.

Organisation and project setup

Northbridge already has a clause 5 framework: a cybersecurity policy, a process handbook, a product security incident response team and an information security management system that protects its engineering servers. It writes a cybersecurity plan for the "remote unlock" item and names a cybersecurity manager. Because Corvale develops the TCU, the two companies sign a cybersecurity interface agreement. It states that Northbridge owns the item-level TARA and the vehicle validation, Corvale owns the TCU component TARA, design, verification and vulnerability handling for the TCU software, and both share information on vulnerabilities within agreed time limits.

Item definition

The item boundary includes the TCU, gateway and body control module functions involved in unlocking. The app and back-end are outside the boundary, but their interfaces are described and assumptions are written for them, for example that the back-end authenticates users and signs commands with a key held in a hardware security module.

TARA (simplified)

Asset and property	Damage scenario	Threat scenario	Impact	Feasibility	Risk	Treatment
Unlock command (integrity, authenticity)	Car is unlocked and goods or the car are stolen	Forged unlock command injected over cellular	Financial major; privacy moderate	High (remote network vector)	4	Reduce
TCU firmware (integrity)	Attacker gains a foothold to send messages onto vehicle networks; safety impact possible	Malicious firmware installed through the debug port	Safety severe	Low (physical access, specialist tools)	3	Reduce
Owner location history (confidentiality)	Owner's movements exposed	Data extracted from a scrapped TCU	Privacy major	Medium	3	Reduce
Owner's phone credentials (confidentiality)	Car unlocked by someone who stole the phone	Use of an unlocked stolen phone	Financial major	Medium	3	Share

The numbers come from Northbridge's own risk matrix; another company could reasonably end up one level higher or lower. What matters is that the reasoning is consistent and recorded.

Goals, claims and concept

From the reduced risks, the team writes cybersecurity goals in plain terms: the remote unlock function is protected against unauthorised commands; TCU software cannot be replaced by unauthenticated software; personal data in the TCU is protected against disclosure at end of life. For the stolen-phone risk, the team writes a cybersecurity claim: the risk is shared with the owner, who is told in the app's terms to protect the phone with a screen lock, and the app requires the phone's biometric or PIN confirmation before an unlock.

The cybersecurity concept then sets requirements. Unlock messages carry a cryptographic signature and a freshness value so that replayed or forged messages are rejected; the TCU uses secure boot and only accepts signed updates; debug interfaces are locked in production; personal data is encrypted with a device key; and the gateway only forwards unlock messages from the TCU when the vehicle is parked. Requirements on the environment state that the back-end authenticates users strongly and that signing keys stay in a hardware security module. Using its own CAL table, built from the guidance in Annex E, Northbridge gives the remote-command goal (network attack vector) a higher CAL than the end-of-life data goal (physical access only); the higher CAL leads to independent code review and penetration testing by an external lab.

Development, validation and release

Corvale refines the requirements into TCU architecture and software design, runs its own component TARA, applies a secure coding standard, fuzzes the cellular and gateway interfaces and fixes two weaknesses found during testing. Northbridge integrates the TCU and runs vehicle-level validation: a penetration test tries replay, forged messages and debug-port access, and the back-end assumptions are checked with the back-end team. The cybersecurity case argues each goal with its evidence; an assessor from Northbridge's independent product security department reviews it, requests one missing test report, and then recommends release. The release for post-development is signed.

Production and the field

The production control plan covers key injection at the end of the TCU line, locking the debug port and recording each unit's key identifiers. Eighteen months after launch, a vulnerability is published in an open-source TLS library used by the TCU. Monitoring picks up the advisory; triage confirms the TCU uses the affected version, so the advisory is recorded as a cybersecurity event; evaluation and analysis show that the flaw could be reached from the cellular network, so it is a vulnerability. The TARA is updated (risk value 4), the treatment is to reduce the risk, and Corvale delivers a fixed library that Northbridge rolls out as an over-the-air update through its software update management system. No exploitation is observed, so the incident response plan is not activated, but the event and decisions are recorded.

End of support

Northbridge announces in the owner documentation how long cybersecurity updates will be provided for the model. Its workshop procedure for replacing a TCU includes a function that erases personal data and revokes the unit's keys in the back-end, which closes the third risk in the table.

Lesson 7 – Relationship to other standards and frameworks

ISO/SAE 21434 is one piece of a larger set of documents that together cover safety, security, software updates and process quality in vehicles. Knowing where each one starts and stops avoids duplicated work and gaps.

Document	Type	Main question it answers	Relationship to ISO/SAE 21434
UN Regulation No. 155	Legal regulation (type approval)	Does the manufacturer have an approved CSMS, and is this vehicle type adequately protected?	Sets the legal obligation; ISO/SAE 21434 supplies widely accepted engineering processes to meet it.
UN Regulation No. 156 and ISO 24089	Regulation and standard for software updates	Can the manufacturer update vehicle software safely and securely?	Updates are a key treatment for vulnerabilities; ISO 24089 is designed to be applied together with 21434 for the cybersecurity of updates.
ISO 26262	Functional safety standard	What if an E/E component fails?	Similar lifecycle shape; safety impact ratings in a TARA are aligned with its severity scale; the two analyses should exchange results.
ISO 21448 (SOTIF)	Safety of the intended functionality	What if the function works as built but is insufficient for the situation?	Complementary: attacks belong to 21434, insufficiencies without an attacker to SOTIF.
ISO/IEC 27001 and TISAX	Information security management and its automotive assessment scheme	Is the organisation's information protected?	Can provide the information security management that clause 5 expects for the engineering environment; it does not cover vehicle product security.
Automotive SPICE for Cybersecurity	Process assessment model	How capable are the supplier's cybersecurity engineering processes?	Assesses processes that implement 21434 activities; it gives capability ratings, not a product verdict.
ISO/PAS 5112	Audit guidelines	How should a CSMS be audited?	Guides audits of the organisational processes described in 21434; it does not cover product assessments.

A helpful way to remember the split in the vehicle world: ISO 26262 asks what happens when something breaks, ISO 21448 asks what happens when it works but the world is harder than expected, and ISO/SAE 21434 asks what happens when someone deliberately attacks. Many organisations run combined safety and security workshops, keep one requirements database and one change process, and hold joint reviews where a security measure could affect safety (for example, a message that is rejected because of a failed signature check must not leave the vehicle in an unsafe state).

Outside the vehicle, related documents include the UNECE interpretation documents for R155, guidance from ENISA (the EU Agency for Cybersecurity) on smart-car security, and threat catalogues such as the list of threats in Annex 5 of R155, which many teams use as an input to threat scenario identification.

Common pitfalls and best practices

Pitfalls seen in real programmes:

Treating the TARA as a one-off document. A TARA written for a milestone and never updated quickly becomes wrong as the design, threats and vulnerabilities change.
Drawing the item boundary too narrowly. Leaving out interfaces to the back-end, the app or the diagnostic tester hides the very attack paths that matter most.
Confusing verification with validation. Passing all component tests does not show that the goals are achieved in the vehicle or that environmental assumptions hold.
Retaining risks without criteria. Accepting a high risk value because a deadline is near, without risk acceptance rules or management sign-off, undermines the whole case.
Vague interface agreements. If nobody is named for vulnerability monitoring of a supplier's software, events fall into the gap between companies.
Buying a certificate instead of building capability. A third-party certificate with a narrow scope does not replace working processes and evidence.
Forgetting the end of life. Keys and personal data left in scrapped or replaced units are a real exposure.

Best practices:

Start the TARA early and keep it alive. Use a simple feasibility method in the concept phase and refine it as the design matures; re-run it for every significant change and every relevant vulnerability.
Write clear risk acceptance criteria. Define the risk matrix, the values that may be retained and who may approve them before the first project starts.
Integrate with safety engineering. Share item definitions, align impact scales and review security measures for safety side effects.
Make supplier responsibilities explicit. Use a responsibility matrix in the interface agreement and agree on time limits for sharing vulnerability information.
Build traceability from goal to test. Link every goal to requirements, design elements, verification and validation evidence so the case almost writes itself.
Keep the assessor independent. Choose someone outside the development team and give them access to all evidence.
Plan for updates from the start. A secure update capability is the most powerful treatment for vulnerabilities found after launch.
Use tools wisely. TARA tools help consistency and reuse, but the quality of the analysis still depends on people who understand the system and the attackers.

Summary and key takeaways

ISO/SAE 21434:2021 is the joint ISO and SAE standard for cybersecurity engineering of road vehicle E/E systems, covering the lifecycle from concept to decommissioning; a second edition is in the works but the 2021 edition is current.
It is process-oriented and technology-neutral: it defines activities, outcomes and work products, not specific security technologies.
Clauses 5 and 6 set organisational and project management, clauses 7 and 8 cover supply chain and continual activities, clauses 9 to 14 follow the lifecycle, and clause 15 provides the TARA methods.
The TARA links assets, damage scenarios, threat scenarios, impact (safety, financial, operational, privacy), attack feasibility and a risk value from 1 to 5 to a treatment decision.
Reduced risks become cybersecurity goals; shared or retained risks become cybersecurity claims; the cybersecurity concept turns goals into requirements on the item and its environment.
Monitoring, event evaluation, weakness analysis, vulnerability management and incident response keep the item secure in the field until end of support.
Conformity is shown with evidence and judged by independent cybersecurity assessments and organisational audits; there is no official ISO certification, though third parties offer their own schemes.
UN R155 is the legal driver in many markets, and the standard is the main engineering route to meeting it, alongside ISO 26262, ISO 21448, ISO 24089 and UN R156.

Reflection questions

Pick a connected feature in a vehicle you know, such as keyless entry or remote climate control. Where would you draw the item boundary, and which interfaces outside it would you write assumptions for?
For that feature, name two assets, the cybersecurity property that matters for each, and one damage scenario per asset. How would you rate their impact in the four categories?
Think of a risk that your organisation might decide to retain or share. What evidence and approval would you want before writing a cybersecurity claim for it?
If your company supplies a component to several vehicle manufacturers, how would you split responsibilities for vulnerability monitoring and updates in the interface agreements?
Your management asks whether getting a third-party "ISO/SAE 21434 certificate" would be enough to satisfy a customer's UN R155-driven requirements. How would you answer, and what else would you recommend?