Cybersecurity for Automotive Suppliers: UN R155, ISO/SAE 21434 and the CRA

Which rules apply to you

The vehicle manufacturer holds the type approval, but the evidence for it is produced by suppliers. Four frameworks reach you.

UN R155 and R156 are mandatory in the EU through Regulation (EU) 2019/2144 for new vehicle types since 6 July 2022 and for all new vehicles since 7 July 2024. R155 requires the OEM to run a cybersecurity management system covering the supply chain and to show, for every vehicle type, that risks were identified, treated and tested. R156 does the same for software updates. The OEM cannot show that without your input, so the duties arrive as contract clauses.

ISO/SAE 21434:2021 is the standard behind those clauses. Clause 7 defines distributed cybersecurity activities and the cybersecurity interface agreement that says who delivers which work product. Clause 15 defines the threat analysis and risk assessment (TARA), clauses 9 to 11 the concept, development and validation work products, clause 8 continual monitoring and vulnerability analysis, clause 13 incident response. Most OEM questionnaires are these clauses rephrased.

Cyber Resilience Act (EU) 2024/2847. Article 2(2) excludes products covered by Regulation (EU) 2019/2144, so type-approved components are out. Everything else you sell with firmware or software, from wallboxes and aftermarket telematics to diagnostic tools, is in: reporting duties from 11 September 2026, full requirements from 11 December 2027.

NIS2 via the German BSIG. Manufacturing of motor vehicles, trailers and parts is a sector in Annex II of the NIS2 Directive. A supplier with 50 or more employees or more than 10 million euros in turnover and balance sheet total is an important entity under § 28 BSIG. On top, OEMs expect a TISAX label for information security at your sites.

Where attackers start

An ECU is attacked through its interfaces and its service life, not through its application logic.

• Diagnostics over CAN and DoIP: UDS security access with a seed-and-key algorithm that can be recovered from the firmware, diagnostic sessions reachable in normal operation, routines and data identifiers that were never meant for the field.
• Debug ports: JTAG, DAP or SWD on the board, often with the microcontroller’s read-out protection unset.
• Bootloader and flashing: update images that are checked for format and version but not for a signature, or signed with a key shared across the whole product line.
• In-vehicle Ethernet: SOME/IP and DoIP services on infotainment and ADAS platforms, parsing untrusted input in C and C++.
• Embedded Linux and Android platforms: kernel drivers, trusted execution environments, inter-process communication, weak mandatory access control profiles.
• Your own tooling: end-of-line flashing stations, key servers and development tools hold the keys the ECU trusts.

What assessments typically find

Typical findings from ECU penetration tests and fuzzing, anonymised: on power-electronics ECUs (DC/DC converter, on-board charger) the UDS security access key derivation was recoverable by reverse engineering the TriCore/AURIX firmware, and calibration data could be written over UDS in a session that should not have allowed it; on a lighting ECU, hardware reverse engineering led from an unprotected debug interface to a full flash dump and from there to the diagnostic secrets; on infotainment platforms, fuzzing of the TEE interface, kernel drivers, DoIP and SOME/IP stacks produced crashes that pointed to memory corruption, and AppArmor profiles were loose enough to let a compromised media service reach the vehicle bus gateway.

None of this is exotic. Every item would appear in a TARA as a feasible attack path with a high damage scenario, and every item is fixable in a normal release cycle if found before start of production.

A sensible first project

Start with one component that has a cybersecurity interface agreement due, or one that will be in production for the longest.

1. Item definition and TARA per ISO/SAE 21434 clauses 9 and 15 for that component: assets, damage scenarios, threat scenarios, attack paths, risk values and treatment decisions, in a form your OEM accepts. Five to eight days with your system and software architects.
2. Component penetration test in our lab on a bench setup: CAN, LIN and UDS including fuzzing, debug ports and read-out protection, bootloader and flashing, firmware reverse engineering, Ethernet services where present. Two to three weeks.
3. Cybersecurity concept and test evidence: the results mapped to the TARA, the controls you already have and the ones still missing, delivered as work products for your cybersecurity case and your customer’s CSMS audit.
4. Fix and retest, then run the diagnostic and fuzzing tests as a regression suite on every release.

Typical effort for steps 1 to 3 is 20 to 30 person-days, which is 25,000 to 50,000 euros at market rates. The TARA alone is 8,000 to 15,000 euros.

What Zyberum does and does not do here

We write TARAs, item definitions, cybersecurity concepts and CSMS work products, test ECUs and complete vehicles, fuzz CAN, UDS, DoIP and SOME/IP, reverse engineer firmware and harden embedded Linux platforms. Our AutoST suite automates the diagnostic and fuzzing parts so you can rerun them per release. We are not a technical service and do not issue type approvals or ISO/SAE 21434 certificates; we produce the evidence your customer’s auditor reads.