In automotive, cybersecurity isn't a market differentiator — it's a homologation condition. UNECE R155 makes a certified cybersecurity management system the ticket to sell vehicles, and 21434 is how the entire supply chain, down to the chip, speaks the same language.
At a glance
Owner
Published 2021; the automotive sector’s engineering standard
Regulatory hook
CSMS + software-update management as type-approval conditions
Core method
Threat analysis and risk assessment driving goals, claims and controls
Scope
Concept to decommissioning, item level to component level
Supply chain
OEM CSMS obligations flow to Tier-1s, Tier-2s and silicon via interface agreements
CRA note
Type-approval law covers them — but your non-vehicle products aren’t exempt
What it is
ISO/SAE 21434 defines cybersecurity engineering across the vehicle lifecycle: organisational capability (the CSMS), item-level TARA, cybersecurity goals and claims, product development controls, validation, incident response and end-of-support decisions. Its enforcement mechanism is what makes it unusual — UNECE R155 requires OEMs to run an audited CSMS and demonstrate vehicle-type cybersecurity to a type-approval authority. No CSMS, no homologation, no market. R156 does the same for software update management.
The consequence is contractual gravity: OEMs discharge their obligations downward through cybersecurity interface agreements (CIAs), making 21434 conformance a de-facto condition of supply for Tier-1s, Tier-2s and increasingly chip vendors. Distributed TARA — whose analysis covers which attack surface, who owns which control — is where supply-chain relationships now succeed or sour.
For the certification world, automotive is a distinct continent: assessment is done by type-approval technical services and CSMS auditors rather than CC-style labs, and the CRA deliberately leaves type-approved vehicles to this regime. But the toolboxes interconnect — automotive secure elements carry CC/EUCC certificates, HSM firmware carries SESIP-style claims, and a chip vendor’s 21434 work package increasingly cites both.
When it's the right tool
The question is not whether but how efficiently — a CSMS that produces R155 evidence as an engineering by-product, not as an audit-season sprint.
CIAs push TARA participation, vulnerability handling and evidence obligations down the chain. A reusable 21434 work-product package beats renegotiating per customer.
Products outside type approval — chargers, fleet tools, aftermarket devices — may fall under the CRA instead. The scoping question decides your entire compliance route.
CC/EUCC-certified secure elements and SESIP-evaluated HSMs slot into 21434 arguments as trusted components — if the claims were written to compose.
Where it matters
Chip vendors serve 21434 CIAs with CC/EUCC and SESIP evidence — one hardware evaluation feeding the automotive work package.
Chargers, telematics add-ons and fleet devices straddle the R155/CRA boundary — the scoping decision that defines their conformity route.
Automotive plants combine 62443 OT programmes with 21434 product obligations — two TARAs, ideally one threat model discipline.
In-car payment, mDL and vehicle-to-cloud identity bring eIDAS-world credentials into 21434-governed architectures.
Expert notes
Distributed development means distributed TARA, and the interface agreement decides who analyses what, who owns which control, and whose evidence satisfies whose auditor. The failure pattern is symmetrical: OEMs receiving component TARAs they cannot integrate, suppliers receiving assumptions they cannot verify. The work products travel well only when the assumptions, claims and out-of-scope declarations are explicit enough to be audited by a stranger.
Our position: negotiate the CIA and the TARA split before development starts, with the same care as the commercial terms. Retrofitting analysis boundaries at validation time is the most expensive meeting in automotive security.
Suppliers serving automotive plus industrial or consumer markets face 21434, 62443-4-1 and CRA process demands that overlap at roughly the 70% level — vulnerability management, secure development, incident response. Running three parallel process frameworks triples audit surface for no security gain; running one engineering system with regime-specific mappings is entirely feasible and increasingly common among the well-advised.
Our position: build the unified SDL once, map outward to 21434, 62443 and CRA Annex I. The mapping table costs a workshop; the parallel-framework alternative costs a team.
CSMS design, TARA methodology, CIA negotiation support, silicon evidence reuse — thirty minutes to a plan.
We’ll send you access by email.
