ISO/SAE 21434 for CTOs: how does TARA fit the existing development process?

Where does the carmaker's 21434 requirement come from, and must R&D do it?

ISO/SAE 21434 itself is not legally mandatory. The requirement comes from UN R155: a whole-vehicle (carmaker) type-approval requirement that obliges the carmaker to set up a cyber security management system (CSMS) and hold its supply chain accountable; in the EU it has applied to new vehicle types since July 2022 and to all newly produced vehicles since July 2024.

The carmaker's CSMS obligations pass down the supply chain through contracts, and component makers are mostly bound by carmaker contracts; carmakers use 21434 to review suppliers' cybersecurity development capability (TARA, cybersecurity concept, development and verification, incident response). For tier-one and tier-two suppliers that want to enter the automotive supply chain, 21434 is a de facto entry requirement; the actual requirement is what the carmaker's request for quotation and contract say.

How is TARA done, and what does R&D produce?

TARA (Threat Analysis and Risk Assessment) is the technical core of 21434. The method runs in order:

1. Asset identification
2. Threat scenario identification
3. Impact rating
4. Attack path analysis
5. Attack feasibility rating
6. Risk value determination
7. Risk treatment decision

From this, cybersecurity goals and requirements are derived and carried through V-model development and verification. The CTO confirms two things: who performs TARA and with what method; and how the results become traceable cybersecurity requirements that are tested in verification.

We already have ASPICE or ISO 26262: does the R&D process need rebuilding?

No. Organisations with ASPICE or ISO 26262 processes can add 21434 incrementally to the existing development framework, and the service page notes that the cost of incremental adoption stays under control.

The two standards share the V-model and explicitly reference each other; when integrated, security analysis results feed the safety hazard analysis. Note that ISO 26262 is a functional safety standard; treating it as proof of cybersecurity exposes gaps in the carmaker's supply-chain security review under UN R155.

How are cybersecurity responsibilities split with the carmaker, and what does R&D prepare for the development project audit?

First clarify which items you are responsible for in the carmaker's development project, and agree the division of cybersecurity responsibilities with the carmaker (the cybersecurity interface agreement).

On the audit side: ISO itself does not certify or issue certificates; 21434 has no official certification scheme, and on the market certification bodies offer process conformity certification or personnel qualification under their own schemes. What matters more is passing the carmaker's development project audit, so R&D prepares a working product cybersecurity engineering process and its records (TARA, cybersecurity requirements, development and verification, incident response), not just a certificate.

After start of production, is R&D still responsible for vulnerability monitoring, incident response and updates?

It has to be planned. 21434 covers the whole lifecycle of vehicle electrical and electronic (E/E) systems, from concept and development to production, operation, maintenance and decommissioning, and incident response is one of the items carmakers review in a supplier's cybersecurity development capability.

When designing the system, the CTO should be able to answer how vulnerability monitoring, incident response and updates are handled after start of production, and who owns them. The cybersecurity of ECUs in type-approved vehicles is governed by UN R155/R156; these are whole-vehicle type-approval requirements borne by the carmaker, and component makers are mostly bound by carmaker contracts, so the scope of responsibility should be written into the agreement with the carmaker.

Where are the boundaries between 21434, TISAX and the EU CRA? Should product lines be planned separately?

Passing TISAX does not mean 21434 capability is in place, and vice versa; carmaker due diligence usually checks both. On the EU CRA: ECUs in type-approved vehicles are outside the CRA (Article 2(2)(c)), but aftermarket and separately sold connected automotive products still fall under the CRA. The CTO should separate product lines: what goes into type-approved vehicles follows 21434, while aftermarket or separately sold connected products also follow the CRA.

How does Winners Consulting help a CTO with ISO/SAE 21434?

Vice-president and director-level consultants personally lead the work end to end, never outsourced. The approach:

• Separate the three requirements: first clarify whether the carmaker wants UN R155 supply-chain requirements, TISAX or 21434 engineering capability, then decide what to do.
• TARA and cybersecurity requirements: build the TARA method and derive cybersecurity goals and requirements.
• Fit existing processes: attach to the existing ASPICE or ISO 26262 development framework, with security analysis results feeding the safety hazard analysis.
• Stand up to audit: aim to pass the carmaker's development project audit rather than only obtain a certificate.
• Plan with TISAX: the same team also advises on TISAX; named clients published with authorisation include Yi Fong Metal Industrial Co., Ltd. (TISAX assessment consulting).

Go deeper: ISO/SAE 21434 automotive cybersecurity engineering, Choosing a 21434 consultant, What a CTO builds into the R&D process, TISAX assessment consulting. Request a free mechanism diagnosis