The Sentence That Stops Too Soon
"We're automotive, so only UN ECE applies to us, done." You hear this sentence constantly in the industry, and it isn't wrong. UN R155 and R156 have been the governing frameworks for vehicle cybersecurity for years, they're strict, they're tightly enforced, and satisfying them gets you type approval. The Cyber Resilience Act (CRA) even explicitly exempts type-approved vehicles. At first glance, everything suggests that with R155/R156 in place, the cybersecurity regulation question is settled for automotive suppliers.
Except the sentence stops exactly where the real question begins. The CRA exemption doesn't cover "everything I manufacture as an automotive supplier." It covers a very precisely defined object — the type-approved vehicle, as the manufacturer places it on the market. For the identical control unit, sold through a different channel, an entirely different legal situation can apply. And that's exactly where many suppliers' actual due-diligence obligation begins — right where they've stopped thinking "done."
Where the Exemption Stops
Art. 2(2)(c) CRA exempts vehicles type-approved under Regulation (EU) 2019/2144 — the legal framework through which R155/R156 became EU law in the first place. That's the core the opening sentence rests on, and that core is correct.
What gets overlooked in practice: the exemption doesn't automatically extend to everything later attached to, retrofitted onto, or sold as a replacement part for the vehicle. Aftermarket devices, diagnostic tools, charging stations, separately sold components, and category L vehicles (motorcycles, mopeds, quads) all remain within CRA scope. And according to European Commission guidance, the exemption only covers a component if it's designed exclusively and solely for installation in that specific type-approved vehicle.
For suppliers, that means: whether a control unit falls under the vehicle exemption or is independently CRA-relevant depends on which channel it's sold through and what it was designed for — not on whether it can physically be installed in a vehicle. Anyone treating R155/R156 certification as a blanket CRA exemption is extending a narrowly scoped exception into territory it doesn't cover.
What UN ECE R155/R156 Actually Require
UN R155 requires a certified Cybersecurity Management System (CSMS) that covers cyber risks across the entire vehicle lifecycle — development, production, and the post-production phase. UN R156 additionally requires a Software Update Management System (SUMS), ensuring that software updates — whether delivered at a workshop or over the air — are traceable and securely delivered.
The timeline is well past being a future concern: the requirement has applied to new vehicle types since 6 July 2022, and to every newly produced vehicle in categories M, N, and O since 7 July 2024 — with no grandfathering. A vehicle type without a valid CSMS certificate simply loses its type approval. Category L vehicles have a longer transition: new types from December 2027, existing ones from June 2029.
When Regulation Took Entire Models Off the Market
The best-known effect of this deadline didn't show up in a lab — it showed up in the showroom. Because older vehicle platforms couldn't be economically retrofitted with a certified CSMS, several manufacturers discontinued entire models during 2024: the Porsche Boxster and 718 Cayman, the VW Up! and the T6.1 predecessor to the Bulli, the Audi TT and R8, the Mercedes-Benz Smart EQ Fortwo, and the Renault Zoe. None of these were security incidents. It was a business decision, because the cost of retrofitting an outgoing platform with a certified CSMS exceeded what the remaining model cycle could justify.
That shows: R155/R156 is no longer a question of whether you're affected. It's a market-access risk that becomes real even without a single attack.
Jeep Cherokee: the case that helped shape the regulation
In 2015, security researchers Charlie Miller and Chris Valasek showed that they could remotely access the CAN bus of a Jeep Cherokee through its Uconnect infotainment system — and thereby influence brakes, steering, and transmission, while the vehicle was in motion. The vulnerability was assigned CVE-2015-5611 on the very day of the public demonstration, with a CVSS score of 8.3: it was located in the radio's cellular module, which was reachable over the mobile network and lacked adequate separation between the infotainment and vehicle control networks.
Fiat Chrysler recalled 1.4 million vehicles three days after publication — not for a mechanical defect, but for what the US National Highway Traffic Safety Administration officially called a "software security defect." Notably: Miller and Valasek had informed Chrysler privately nine months before the public demonstration. It was the public demonstration — not the private disclosure — that triggered a recall within days. The case is still regarded as one of the drivers behind the development of UN R155/R156.
Bendix EC80: the vulnerability nobody called a vulnerability
The EC80 is a brake control unit for heavy trucks that governs anti-lock braking and stability functions over the J2497 data bus. In 2024, Bendix recalled around 450,000 units across three vehicle manufacturers — officially due to a signal-processing issue. It wasn't until August 2026, when NMFTA security researcher Ben Gardiner presented at Black Hat USA, that what the update actually contained came to light: faulty buffer handling that could crash the control unit, a path to remote code execution — and a hard-coded password that could disable traction control.
Unlike Jeep, none of these vulnerabilities received a CVE number at the time of the original 2024 recall. They were only assigned retroactively after the 2026 disclosure — two years later: CVE-2026-67560 (buffer overflow, CVSS 7.5), CVE-2026-68967 (out-of-bounds write, CVSS 6.5), and CVE-2026-71396 (hard-coded credentials, CVSS 5.3). Because the recall was never declared a security fix, it stayed invisible to vulnerability scanners for two years — fleet operators checking their vehicles against known CVEs would not have seen the risk.
The contrast between the two cases is itself instructive: with Jeep, the vulnerability was publicly named, documented, and tied to a recall from day one. With Bendix, it stayed invisible for two years even though the recall had long since happened. Both cases converge on the same point, though: the moment firmware is loaded onto a control unit. And both point to the same distinction that turns out to matter legally: it's not just about what happened, but about whether the programming process itself could have been tampered with without anyone noticing.
Back to the Opening Sentence: Where It Falls Apart for Suppliers
The exemption under Art. 2(2)(c) CRA applies to the type-approved vehicle. A supplier selling a control unit like the EC80 both as OEM original equipment and as a standalone aftermarket part operates in two different legal spaces at once: as original equipment, the component is part of the vehicle type approval and covered by R155/R156. As an independently sold replacement part, it can become CRA-relevant, because it's no longer "exclusively and solely" intended for installation in a specific type-approved vehicle.
For evidence purposes, that means a supplier may need not just a CSMS for original equipment, but potentially a second, CRA-compliant documentation trail for the same component type once it's sold through a different channel. This is exactly where "done" is thought too soon.
The Burden of Proof Is Shifting Here Too
The new Product Liability Directive (EU) 2024/2853 applies across industries, including automotive suppliers. Under Art. 10(2), a product's defectiveness is presumed if the defendant fails to disclose relevant evidence, if it's shown that binding safety requirements weren't met, or if there was an obvious malfunction during normal use. The Bendix case shows how relevant that can become: a recall that contains a security flaw without naming it as one is difficult to defend afterward as "properly documented."
Documentation alone isn't enough here, either. A complete record of a programming process that was technically vulnerable only answers half the question in a dispute. The other half is: how was the process itself protected against unauthorised changes — both in transit and during processing?
What btv SEEL® Delivers Here
At the interface where the actual root cause lay in both cases — the moment firmware is loaded onto the control unit — btv SEEL® steps in. The full functionality of CORE, INTERCONNECT and UNLIMITED is described on the btv SEEL® services page; here, just the points that matter most for automotive suppliers.
Firmware and keys are transferred through controlled, protected data spaces using standardised encryption protocols, and decrypted exclusively in volatile memory during programming, with no unencrypted copy ever existing on storage media — neither in transit nor during processing. Root certificates stay with the manufacturer, because the customer's own PKI infrastructure is integrated — relevant because firmware for safety-relevant control units like braking systems is part of the protected core of a supplier's intellectual property.
Every component receives an individual, automatically documented, cryptographically signed identity in series production. For a case like Bendix EC80, that would have meant: a recall could be scoped precisely to the affected firmware version and serial numbers, documented already at the moment of programming — not years later, after an external security analysis.
One point worth stating clearly: btv SEEL® doesn't make a vehicle or component "R155-compliant" or "CRA-compliant." These regulations address the manufacturer's end product, not the service provided by btv technologies. What btv SEEL® delivers is two things that belong together: a programming procedure that makes unauthorised changes harder along the entire path — from transfer through protected data spaces to processing exclusively in volatile memory — and the resulting, verifiable evidence at the component level. Evidence covering a vulnerable process would be of limited value in a dispute; a protected process without evidence can't be proven in an audit or recall. Together, they form the foundation manufacturers and suppliers need for their own conformity assessment — documented for at least 20 years, traceable back to 2006, regardless of which of the two distribution channels applies in a given case.
The Sentence, Thought Through to the End
Most automotive suppliers already have their CSMS and SUMS under control — R155/R156 have applied without grandfathering since 2022 and 2024 respectively. The real question, then, isn't whether certification exists, but how far it reaches. "We're automotive, so only UN ECE applies to us" holds true for the vehicle. It stops being true the moment the same component is sold through a different channel — as a replacement part, through a diagnostic tool, or as a retrofit solution.
That's exactly where it's worth checking — not the CRA deadlines themselves, but which distribution channels for a given component are actually covered by the vehicle exemption, and which ones require an independent CRA assessment.
Frequently Asked Questions About CRA and UN ECE R155/R156
Not for the type-approved vehicle itself. Art. 2(2)(c) CRA exempts vehicles type-approved under Regulation (EU) 2019/2144 — and that regulation is what transposes R155/R156 into EU law. But the exemption only covers the vehicle as the manufacturer places it on the market, not automatically every component installed or retrofitted later.
For the type-approved vehicle, yes. For components additionally sold as standalone replacement parts, through diagnostic tools, or as retrofit solutions, the exemption doesn't automatically extend. Those distribution channels may require a separate CRA assessment, even if the same component is covered by R155/R156 as original equipment.
No. R155/R156 and the CRA address the manufacturer's end product, not a supplier's service. btv SEEL® delivers two things that belong together: a programming procedure that makes unauthorised changes harder during both transfer and processing, and the resulting evidence at the component level — the foundation manufacturers need for their own conformity assessment.
