What Is ISO 21434? Automotive Cybersecurity Engineering Explained

A modern passenger vehicle runs on tens of millions of lines of code and connects to cloud services, mobile apps, and over-the-air update channels every time it starts up. Every one of those connections is a potential entry point for an attacker, and the cybersecurity evidence behind each one has to hold up across the supply chain.

United Nations Regulation No. 155 (UN R155) now ties that evidence directly to vehicle type approval. Without an approved Cybersecurity Management System (CSMS), no new vehicle type gets into UNECE-regulated markets. ISO/SAE 21434 is the engineering framework most teams use to produce the evidence behind that CSMS.

What Is ISO 21434?

ISO/SAE 21434:2021 is the international cybersecurity engineering standard for road vehicles, published jointly by the International Organization for Standardization (ISO) and SAE International in August 2021. It covers cybersecurity risk management across the full lifecycle of electrical and electronic (E/E) systems, from concept and development through production, operation, maintenance, and decommissioning.

The standard applies to series production E/E systems whose development or modification began after its 2021 publication. It is technology-agnostic. It tells you what your team must achieve and leaves the specific tools and technologies up to you.

Why Connected and Software-Defined Vehicles Need ISO 21434

Software-defined vehicles have moved cybersecurity from a niche concern to a market-access requirement. The attack surface keeps growing, attacks already reach beyond IT, and regulators now tie cybersecurity evidence to whether a vehicle can be sold at all.

The Expanding Automotive Attack Surface

Every external interface on a vehicle counts as an asset that has to be listed in the item definition and analyzed in TARA. That includes telematics units, infotainment radios, charging connectors, and OTA update channels. More interfaces mean more attack paths and more risk you’ll have to document.

Real-World Consequences of Automotive Cyberattacks

Automotive cybersecurity failures rarely stay inside IT. Attackers have moved past Original Equipment Manufacturer (OEM) and dealer networks into environments where a breach can disrupt manufacturing, production data, or vehicle telematics. TARA has to account for all of that at the concept phase.

Regulatory Pressure From UN R155 and Type Approval

UN R155 makes vehicle type approval conditional on a working CSMS in UNECE-regulated markets, and it works on two layers. You need company-level CSMS certification, and you need product-level type approval, before a new vehicle type can enter those markets. ISO/SAE 21434 has no legal weight of its own here, but most assessors use it as the engineering framework for judging whether a CSMS is credible.

The Structure of ISO/SAE 21434: Clause-by-Clause Breakdown

The standard is built around normative clauses that govern lifecycle cybersecurity activities, each with its own requirements and work products. Here’s how the clauses fit together in practice.

Overall Cybersecurity Management

Clause 5 sets up the organizational CSMS. It covers governance, culture, information sharing, tool management, and internal audits. Without a documented CSMS that satisfies Clause 5, the project-level activities in later clauses have nothing to stand on. UN R155 assessors look at the same Clause 5 work when they evaluate whether your CSMS is good enough.

Project Management and Distributed Development

Clause 6 covers project-level cybersecurity management. That includes the cybersecurity plan, the cybersecurity case, and the post-development release decision. The tailoring decisions you make here decide which downstream product-development activities you actually have to do.

Clause 7 deals with distributed development across the supply chain. Its main output is the Cybersecurity Interface Agreement (CIA), which spells out who does what between customer and supplier using the RASIC model: Responsible, Approve, Support, Inform, Consult. RASIC is an automotive-industry variant of the more familiar RACI matrix.

Concept Phase and Cybersecurity Goals

Clause 9 covers the concept phase, which produces the item definition, the TARA outputs, the cybersecurity goals, and the cybersecurity concept. If the item definition is scoped poorly, TARA breaks. The item definition is what decides which assets and interfaces actually get analyzed.

Product Development and Integration

Clause 10 covers product development. Every cybersecurity specification has to trace back to a cybersecurity goal from TARA, and every verification result has to trace back to a specification. Keeping that bidirectional traceability intact is where most compliance programs lose the plot. Clause 11 then validates the fully integrated item at the vehicle level against those same cybersecurity goals.

Post-Development Lifecycle

Clauses 12 through 14 cover the work that comes after launch. Clause 12 handles production cybersecurity controls, Clause 13 covers operations, maintenance, and incident response, and Clause 14 covers the end of cybersecurity support and decommissioning.

TARA Methodology

Clause 15 defines the threat analysis and risk assessment methods that produce the cybersecurity goals every downstream clause depends on. Its work products run from asset identification, through risk value determination, to the cybersecurity goals you set for any unacceptable risk.

How to Run a TARA Under ISO 21434

TARA is the main risk-analysis method in ISO 21434. It turns system architecture into measurable cybersecurity risk through a seven-step process, and the output feeds every cybersecurity goal you’ll later have to defend.

Walk Through the Seven TARA Steps

The TARA process moves through seven steps. Each one produces something the next step needs:

1. Asset identification: Pin down each asset and its cybersecurity properties.
2. Threat scenario identification: Work out how those properties could be compromised.
3. Impact rating: Rate severity across safety, financial, operational, and privacy dimensions.
4. Attack path analysis: Map the steps an attacker would take to realize a threat scenario.
5. Attack feasibility rating: Score attacker difficulty across elapsed time, expertise, target knowledge, window of opportunity, and equipment.
6. Risk value determination: Combine impact and feasibility into a risk level that drives your Cybersecurity Assurance Level (CAL) assignments.
7. Risk treatment: Pick one of four documented response options.

For example, a TARA on a CAN-bus gateway typically identifies the gateway as an asset with integrity and availability properties, then walks attack paths starting from the OBD-II port and the telematics unit before arriving at a risk value.

Choose a Risk Treatment Option

Risk treatment is where the analysis turns into engineering decisions. You have four options:

• Avoidance: Drop the feature or function that creates the risk.
• Reduction: Add controls to lower the impact or feasibility.
• Transfer: Hand the risk to another party through contract or insurance.
• Acceptance: Keep the risk and document why.

If you pick reduction, the output is a set of cybersecurity goals. Those goals feed into the cybersecurity concept and into the traceable requirements that follow.

Map the Three Cybersecurity Properties

Assets carry three core cybersecurity properties: confidentiality, integrity, and availability. Confidentiality keeps the asset from being disclosed to anyone who shouldn’t see it. Integrity keeps it from being modified, and availability keeps it accessible when something critical needs it. A single asset can carry more than one of these at once.

Decide When to Rerun a TARA

TARA is a living analysis that gets revisited throughout the program. The first pass happens during the concept phase to set initial cybersecurity goals, even before the design is detailed enough to build against. More passes happen during design, and post-production activities pick up any incidents that surface after vehicles enter service.

A few triggers force you to redo the analysis. New features or interfaces that change the item definition, fresh threat intelligence that invalidates a prior risk-acceptance rationale, post-incident response obligations under Clause 13, and end-of-cybersecurity-support planning under Clause 14 all require an updated TARA before the cybersecurity case can be revalidated.

ISO 21434 vs. Adjacent Standards and Regulations

ISO 21434 sits alongside several related standards and regulations, each with its own scope and legal status. Here’s how it compares to the ones you’ll deal with most.

ISO 21434 vs. ISO 26262 (Cybersecurity vs. Functional Safety)

ISO 26262 covers accidental system failures, and ISO 21434 covers intentional attacks. The two work with different threat models. ISO 26262 uses Hazard Analysis and Risk Assessment (HARA) paired with Automotive Safety Integrity Level (ASIL) classifications, and ISO 21434 uses TARA paired with Cybersecurity Assurance Level (CAL) assignments.

In practice, the two analyses end up depending on each other. HARA results feed into TARA, and cybersecurity threats that affect safety feed back into HARA. Most teams maintain both as living documents for that reason.

ISO 21434 vs. UN R155 and UN R156

UN R155 is a legally binding UNECE regulation, and ISO 21434 is a voluntary international standard. Complying with ISO 21434 won’t get you R155 certification on its own. R155 auditors still use it as the reference framework when they judge whether a CSMS is good enough. UN R156 covers software update management systems (SUMS) and references ISO 24089 rather than ISO 21434.

ISO 21434 and SAE J3061

SAE J3061 was the automotive industry’s interim cybersecurity guidebook before ISO/SAE 21434. The newer standard builds on J3061’s concepts and replaces it for new development. Some legacy programs still cite both.

Who Needs to Comply With ISO 21434

ISO 21434 obligations apply to every tier in the supply chain. The deeper a tier sits in cybersecurity-relevant work, the more evidence it has to produce.

OEMs and Vehicle Manufacturers

OEMs carry most of the regulatory weight under R155. They have to set up a CSMS, get it assessed for type approval, run cybersecurity validation at the vehicle level, and evaluate suppliers’ cybersecurity during sourcing. If any of that breaks down, type approval is at risk.

Tier 1 and Tier 2 Suppliers

Tier 1 suppliers hand over TARAs, cybersecurity concepts, and test evidence with their project proposals. They play both sides of the CIA, acting as supplier to the OEM upstream and as customer to their own sub-suppliers downstream. Tier 2 suppliers hand over component-level cybersecurity documentation, and the more critical the component, the deeper that documentation has to go.

Semiconductor and Software Vendors

Stronger component-level cybersecurity documentation from chip and software vendors makes OEM compliance easier. Several semiconductor suppliers, including NXP, Infineon, and Renesas, have already announced ISO 21434-related certification work for that reason.

Common Challenges in Implementing ISO 21434

A few things usually trip teams up once they try to apply the standard. Most of them show up at the boundaries between teams, tools, and companies rather than inside any single engineering group.

Bridging Engineering Silos Between Safety and Security Teams

Safety and cybersecurity work often happens in separate silos with no co-analysis at the concept phase. Both standards say the two teams have to talk and share information. Neither tells you how to make that coordination actually happen day to day.

Maintaining Traceability From Cybersecurity Goals to Verification

Documentation volume grows fast once items are outsourced, and every link in the trace chain crosses a company boundary. Clause 10 requires bidirectional traceability among cybersecurity goals, specifications, and verification results, which is hard enough inside one organization, let alone across three.

Clause 15’s TARA rules don’t pin down what level of detail you have to analyze at. When OEMs and suppliers work at different levels, their outputs don’t line up. Static traceability matrices can’t keep pace with the changes, which is why live traceability is now the baseline in regulated programs.

Sustaining Compliance Across the Vehicle Lifecycle

ISO 21434 compliance falls apart when teams treat it as a launch-gate activity. Cars stay on the road for ten years or more while threats keep evolving, so the evidence you produced at launch goes stale faster than people expect. Post-production monitoring depends on telemetry that was designed into the vehicle from the start, since retrofitting it later is rarely practical.

How Jama Connect® Supports ISO 21434 Compliance

Jama Connect® is a requirements management and traceability platform used by automotive, aerospace, medical device, and other regulated engineering teams to manage requirements, risk, and verification evidence in one connected system. Jama Connect® for Automotive ships with frameworks aligned to ISO 21434, ISO 26262, and Automotive SPICE (ASPICE), plus built-in cybersecurity risk management and TARA templates that map directly to the work products ISO 21434 asks for.

Live Traceability™ keeps cybersecurity goals connected to specifications and verification evidence in one chain, and suspect link notifications flag downstream artifacts whenever an upstream cybersecurity requirement changes. Jama Connect® Interchange™ supports Requirements Interchange Format (ReqIF) exchange between OEMs and suppliers, so traceability holds up across company boundaries as the supply chain changes.

Building ISO 21434 Evidence Across the Supply Chain

ISO/SAE 21434 treats automotive cybersecurity as engineering work that runs from concept through end-of-cybersecurity-support planning. For OEMs and suppliers under UN R155 pressure, the question has shifted from whether teams can spot cyber risk to whether they can prove their risk decisions, cybersecurity goals, and verification results stay aligned across the whole supply chain.

Jama Connect is the single chain that keeps your TARAs, cybersecurity goals, requirements, and verification evidence connected as the program changes, which keeps the cybersecurity case current whenever an assessor asks. Start a free 30-day trial to see how it handles ISO 21434 evidence across the lifecycle.

Frequently Asked Questions About ISO 21434

Is ISO 21434 mandatory?

ISO 21434 is technically voluntary. In practice, you have to comply with it anyway. The standard is an international engineering reference rather than a regulation, but it becomes legally relevant once laws or contracts, like UN R155, incorporate it by reference. OEMs ask suppliers for ISO 21434-aligned cybersecurity evidence during sourcing, so the standard has become a real requirement across the automotive supply chain.

What is TARA in ISO 21434?

TARA, or Threat Analysis and Risk Assessment, is the structured method ISO 21434 uses to turn system architecture into engineering-grade risk decisions. The seven steps are usually the easier part. The harder part is keeping the analysis aligned as the item definition changes, which is where Jama Connect® for Automotive helps. You can try it free for 30 days to see how it handles ongoing TARA work.

Who is responsible for ISO 21434 compliance in the supply chain?

The obligation flows through every tier that touches a cybersecurity-relevant component. Tier 1 and Tier 2 suppliers provide cybersecurity evidence showing their requirements have been implemented, and OEM verification scales with how critical the component is.

The Cybersecurity Interface Agreement (CIA) is the formal mechanism for assigning those responsibilities. Tools that support cybersecurity case management matter most when one supplier has obligations running both up to the OEM and down to its own sub-suppliers.

When was ISO 21434 published?

ISO/SAE 21434:2021 was published in August 2021 and applied immediately to series production E/E systems whose development began after that date. Programs already in flight had to either retrofit to meet the new clauses or close out under prior SAE J3061 practice. That choice still affects how legacy cybersecurity cases are audited today.

This article was authored by Mario Maldari and published on May 15, 2026.