ISO 21434 Compliance: Requirements, TARA, and Evidence

TL;DR: ISO/SAE 21434 is the international standard for building cybersecurity into road vehicles across their whole lifecycle. It tells automotive OEMs and suppliers how to manage cyber risk, run threat analysis, and document the proof. The hard part isn't the process. It's proving that what you actually shipped matches what you designed, and that's where Finite State comes in.

Modern vehicles are computers on wheels. They run on connected software, take over-the-air updates, and talk to everything around them. That connectivity is also an attack surface, and the industry now has one standard that defines how to engineer against it. This guide explains what ISO 21434 requires, how compliance is assessed, and how to back it all up with evidence grounded in what you ship.

What is the ISO/SAE 21434:2021 standard?

ISO/SAE 21434:2021 is the international standard for automotive cybersecurity engineering. It defines how to manage cyber risk across a vehicle's entire lifecycle, from concept to decommissioning.

Published in August 2021 by ISO and SAE International, a worldwide association of over 128,000 engineers, the standard carries the official title "Road Vehicles: Cybersecurity Engineering." It targets the electrical and electronic (E/E) systems inside road vehicles: their components, their interfaces, and the software running on them. It supersedes the earlier SAE J3061 guidebook and gives the whole supply chain a shared vocabulary and a shared set of requirements. For the wider regulatory picture, see our primer on automotive cybersecurity standards.

Who needs to comply with ISO 21434?

ISO 21434 applies to automotive OEMs and their suppliers: any organization designing, developing, or maintaining the electrical and electronic systems inside road vehicles.

The standard isn't a law on its own, but it has become a practical requirement. Regulations like the UNECE WP.29 framework and UN Regulation No. 155 (R155) effectively require a Cyber Security Management System (CSMS) of the kind ISO 21434 describes. [verify outbound URL before publishing] If you build or supply anything that ships inside a connected vehicle, this standard reaches you. Our connected vehicles industry page walks through where it lands across the supply chain.

ISO/SAE 21434 scope, key terms, and objectives

The official scope is short. ISO/SAE 21434 sets engineering requirements for cybersecurity risk management across concept, product development, production, operation, maintenance, and decommissioning of E/E systems in road vehicles, including their components and interfaces.

Three limits in that scope matter:

1. It applies to series production road vehicle E/E systems.
2. It covers systems whose development or modification began after publication in August 2021. Legacy platforms enter scope when they're modified.
3. It prescribes no specific technology or solution. You choose the controls; the standard asks you to justify them.

Key terms

The standard's second goal is a common language across OEMs and suppliers. These terms show up in every work product:

What's the difference between ISO 26262 and ISO 21434?

ISO 26262 covers functional safety: failures that happen by accident. ISO 21434 covers cybersecurity: failures caused on purpose by an attacker. They are complementary and usually run together.

For years the automotive industry managed safety through ISO 26262, which handles the risk of a system malfunctioning on its own. It was never built to handle an attacker who makes a system fail deliberately. ISO 21434 fills that gap. The two standards share a lot of structure, which is why teams often implement them side by side.

What is the ISO 21434 TARA methodology?

TARA, or Threat Analysis and Risk Assessment, is the core method in ISO 21434. It identifies assets, threats, and attack paths, then scores the risk so teams know what to treat first.

TARA lives in Clause 15 of the standard and feeds the concept phase. The job of TARA is to figure out how badly a road user could be affected by a given threat, then decide what to do about it. The steps are well known to anyone who has run one:

1. Asset identification: list what needs protecting (data, functions, interfaces).
2. Threat scenario identification: derive how each asset could be attacked. Methods like STRIDE apply here.
3. Impact rating: judge the safety, financial, operational, and privacy impact if the threat lands.
4. Attack path analysis: map how an attacker would actually reach the asset.
5. Attack feasibility rating: judge how hard that path is to pull off.
6. Risk determination: combine impact and feasibility into a risk value.
7. Risk treatment: decide to reduce, share, retain, or avoid each risk.

Most TARA noise comes from threats that look scary on paper but aren't reachable in the shipped build. Reachability analysis cuts that noise by showing which vulnerable code an attacker can actually get to, so your team spends its time on real exposure instead of theoretical findings.

Attack feasibility (step 5) is where TARA ratings get argued over, because a rating is only as good as the reasoning behind it. Evidence from the shipped build helps. Reachability analysis shows whether vulnerable code in a component can be reached from an exposed interface, which gives your feasibility rating something concrete to stand on. Teams that automate threat modeling from the product architecture can keep those ratings current as the design changes.

How do you implement ISO 21434 across the automotive supply chain?

Implementing ISO 21434 means assigning cybersecurity responsibilities between OEMs and suppliers in writing, then verifying every party's work against the standard's clauses and work products.

No single company builds an entire vehicle. The standard handles that reality in Clause 7 with distributed cybersecurity activities: OEMs and suppliers spell out who owns what in a Cybersecurity Interface Agreement, and each party evaluates the cybersecurity capability of the parties below it. The standard is modular on purpose. A Tier 2 supplier can't validate a component at the vehicle level, so it implements the clauses that apply to its role and hands defensible evidence up the chain. The practical work is the same at every tier: define responsibilities, do the engineering, and produce the work products that prove it.

What are the benefits of ISO 21434 certification for Tier 1 suppliers?

For Tier 1 suppliers, ISO 21434 certification proves cybersecurity maturity to OEMs, shortens supplier audits, and turns security into a competitive reason to win contracts.

OEMs are under regulatory pressure, and they push that pressure down to their suppliers. A Tier 1 that can show certified processes and product-level evidence gets through supplier assessments faster and with less back-and-forth. The benefits stack up quickly:

• Faster onboarding: less time spent answering OEM security questionnaires from scratch.
• Fewer surprises late in a program: risk is found in the concept phase, not at vehicle validation.
• Stronger negotiating position: security becomes a reason to win the business, not a box to check.
• Regulatory readiness: alignment with UN R155 and related rules is already in place.

What's on an ISO 21434 compliance checklist?

An ISO 21434 checklist covers organizational controls, project planning, TARA, requirements, verification, and post-production monitoring, each backed by documented work products for assessors.

The standard organizes everything into clauses, and each clause produces "work products," its term for the evidence you'll be asked to show. Here's how the core obligations and deliverables map out.

Clauses 10 and 11 expect testing as evidence, typically including vulnerability scanning, fuzz testing, and penetration testing against the implemented component. Our penetration testing service runs those tests against shipped binaries, and our certification accelerator assembles the resulting work products for assessment.

How is ISO 21434 compliance assessed?

ISO 21434 compliance is assessed two ways: an audit of your cybersecurity management system, and a product-level assessment of a specific item or component.

The CSMS audit checks that your organization has the policies, roles, and processes in place. The product-level assessment checks one actual item against the standard. Both depend on evidence. You can describe a sound process in a binder, and an assessor will still ask to see proof that the product in front of them was engineered and verified the way you say it was.

How does Finite State help with ISO 21434?

Finite State supports ISO 21434 by analyzing the firmware you ship, prioritizing real vulnerabilities for TARA, and generating evidence mapped to the standard's work products.

Here's the gap most teams hit. ISO 21434 tells you how to manage risk, but it leaves the what to you, and a lot of compliance work is built on design documents and source code. The software that rolls off the line is the binary inside the ECU, and that's what an attacker sees. If your evidence describes the design but never checks the shipped build, you have a process story without a product story.

Finite State closes that gap by grounding compliance in what actually ships:

• Analysis of the real build. Our software inventory analyzes firmware, binaries, and supplier SBOMs to show what's inside the component, including the parts no one documented.
• Prioritization that matches TARA. We use reachability and exploit context to surface the vulnerabilities that represent real exposure, so your team rates feasibility on evidence from the build.
• Evidence that maps to the standard. We produce reporting that lines up with ISO/SAE 21434 work products and supports your CSMS, with export formats shaped to your reporting requirements.

We work alongside your team and keep that reporting current as the standard and your program evolve. Your engineers own the fixes and the sign-off; we make sure the evidence behind them describes the product you shipped.

Want to see what's really inside your firmware before an assessor does? Request a demo and we'll walk through it with your own build.

Related reading on automotive cybersecurity

Standards and regulations

• A primer on automotive cybersecurity standards
• Exploring standards and regulations for automotive cybersecurity
• Navigating automotive regulatory compliance in the age of connected devices
• What's next for automotive cybersecurity
• China GB 44495 and GB 44496 compliance guide

UN R155 and the U.S. Connected Vehicle Rule

• A look at the UN R155 regulation for connected vehicles
• Understanding the Connected Vehicle Rule
• Connected Vehicle Rule compliance

SBOMs in automotive

• SBOMs and their role in connected automotive cybersecurity
• Requesting, acquiring, and getting value from SBOMs in automotive
• The role of SBOMs in CASE vehicles

Broader connected-device security

• Connected device security challenges

Datasheets and resources

• Automotive compliance and security management datasheet
• Supply chain transparency, risk management, and compliance for the auto sector