When a carmaker asks for 21434, is that a legal requirement? Does our product have to do it?
The standard itself is not legally mandatory. UN R155 is a whole-vehicle (carmaker) type-approval requirement: the carmaker must run a vehicle cyber security management system (CSMS) and manage supply-chain risk; in the EU it has applied to new vehicle types since July 2022 and to all newly produced vehicles since July 2024. R155 and R156 are whole-vehicle requirements, and component suppliers are mostly bound by carmakers through contracts.
If you develop or supply cybersecurity-relevant automotive electrical and electronic (E/E) systems, components or software, you will usually need it; the actual requirement is set by the carmaker's request for quotation and contract.
Is our automotive product in EU CRA scope?
It depends on how the product is placed on the market:
- Outside the CRA: vehicles type-approved under (EU) 2019/2144 and their dedicated systems and components; their cybersecurity follows UN R155 and ISO/SAE 21434 and does not involve CRA CE marking. Commission (EU) 2025/1535 also excludes L-category vehicles such as motorcycles.
- Still in CRA scope: separately sold automotive digital products, such as aftermarket devices, diagnostic tools, fleet management hardware, charging equipment, and chip modules and software sold separately into the supply chain.
One company may have both kinds, so decide product line by product line and avoid wrongly applying the CRA to vehicle components.
What will a carmaker's development project ask us to deliver? How far must TARA go?
The core of 21434 is TARA (threat analysis and risk assessment): asset identification, threat scenario identification, impact rating, attack path analysis, attack feasibility rating, risk value determination and risk treatment decisions, from which cybersecurity goals and requirements are derived across V-model development and verification.
At project kick-off the product manager should confirm:
- Which items we are responsible for in the carmaker's project
- How cybersecurity responsibilities are split between the parties (the cybersecurity interface agreement)
- How post-production vulnerability monitoring, incident response and updates are handled
These three set the scope of the cybersecurity work products to deliver.
Does 21434 cover the period after production? How do we plan product support and updates?
Yes. ISO/SAE 21434 sets cybersecurity engineering requirements for road vehicle E/E systems across the whole lifecycle, from concept, development and production to operation, maintenance and decommissioning, including incident response.
For software updates, UN R156 (software update management) is likewise a whole-vehicle (carmaker) type-approval requirement, passed to the supply chain by carmakers through contracts. When answering the carmaker's RFQ and planning, the product manager should confirm who monitors vulnerabilities after production, who handles incident response and how updates are delivered, and write these into the split of work with the carmaker.
Is there a 21434 certificate? We already have TISAX; do we still need 21434?
The standard has no official certification scheme, and ISO itself neither certifies nor issues certificates. In the market, certification bodies offer process conformity assessments or personnel qualifications under their own schemes; what matters more is passing the carmaker's development audits.
With TISAX you usually still need it. The three are often confused:
| Requirement | What it covers |
|---|---|
| UN R155 | The carmaker's CSMS and type approval |
| TISAX | Information protection at your company's sites |
| ISO/SAE 21434 | How the product is developed securely |
Passing TISAX does not mean you have 21434 capability, and vice versa.
We already have ASPICE or ISO 26262. Will adding 21434 slow development down?
No separate system is needed. Organisations with ASPICE or ISO 26262 processes can attach 21434 to the existing development framework and implement it incrementally. 26262 deals with "hazards caused by failures", 21434 with "hazards caused by attacks"; the two share the V-model and reference each other, and in an integrated approach cybersecurity analysis results feed into the safety hazard analysis.
Note that ISO 26262 is a functional safety standard and cannot serve as cybersecurity proof; suppliers that treat it as such expose gaps in the supply-chain cybersecurity reviews carmakers run under UN R155.
How does Winners Consulting help product managers with ISO/SAE 21434?
Winners Consulting first clarifies whether the carmaker wants UN R155 supply-chain requirements, TISAX or 21434 engineering capability, then decides what to do:
- Build a TARA method and derive cybersecurity goals and requirements
- Attach it to the existing ASPICE or ISO 26262 framework, with cybersecurity analysis feeding the safety hazard analysis
- Aim to pass the carmaker's development audits, not just obtain a certificate
- The same team also supports TISAX; named TISAX clients published with authorisation include Yi Fong Metal Industrial
VP- and director-level consultants lead the work end to end, never outsourced. Read more: ISO/SAE 21434 consulting, Choosing a 21434 consultant, Choosing a TISAX consultant. Request a free mechanism diagnosis
How other roles see this service
Other services for this role
- EU CRA for product managers: is my product in scope, and what must be ready before launch?
- EU AI Act for product managers: what must the AI in our product complete before launch?
- ISO/IEC 29147 and 30111 for product managers: what can we promise on vulnerability disclosure and fixes?
- IEC 62443-4-2 for product managers: will industrial product certification delay our launch?
- ISO 42001 for product managers: how do we answer customer demands on AI product governance?
- TISAX prototype protection for product managers: will a missing label block a carmaker project?
- ISO 27701 and GDPR for product managers: which privacy work comes first when selling into each market?