The Cyber Resilience Act generally does not apply to type-approved vehicles. Many automotive manufacturers conclude: R155 and R156 already apply — so there is nothing more to do.
That is where the mistake begins. The CRA exemption does not reduce cybersecurity requirements. It only prevents two regulatory regimes from governing the same task in parallel. UN ECE R155 already requires cyber risks to be managed across development, production and the post-production phase — including supply-chain risk and reliable evidence.
For automotive, the obligation remains the same: cybersecurity must not only exist. It must be demonstrable.
The Exemption Prevents Double Regulation — Not Cybersecurity
The Cyber Resilience Act generally applies to products with digital elements. Type-approved vehicles under Regulation (EU) 2019/2144 are excluded from its scope. This European framework is also what made UN ECE R155 and R156 binding for the vehicle categories concerned.
That does not mean vehicles need less protection. It separates legal regimes: vehicle cybersecurity is already governed through type approval. A company placing a vehicle on the market therefore does not need to prove that the CRA is irrelevant. It needs to be able to show that its Cybersecurity Management System works.
R155 has applied to new vehicle types since July 2022. Since July 2024, it has applied to newly produced vehicles in categories M, N and O. Without a valid Cybersecurity Management System certificate, a vehicle type cannot retain its type approval.
What UN ECE R155 Already Requires
R155 is not a checklist for the engineering department. It requires a Cybersecurity Management System, or CSMS. This system must address risk across the vehicle lifecycle: from concept and development through production and into the post-production phase.
This includes, among other things:
- Identifying and assessing cyber risks systematically
- Taking supplier-related risks into account and managing them
- Demonstrating security measures in development and production
- Being able to detect attacks and anomalies
- Documenting incidents, vulnerabilities and remedial measures in a traceable way
- Having the effectiveness of the CSMS reviewed regularly
UN ECE R156 complements this framework with a Software Update Management System, or SUMS. It governs how software updates are rolled out safely and traceably across the vehicle lifecycle — in workshops as well as over the air.
For manufacturers, this is not abstract regulation. It is a condition of market access.
R155 and CRA: Many of the Same Questions, Different Legal Mechanisms
R155 and the CRA are not identical. They address different objects and use different legal consequences. But the operational question behind them is often the same: is the product protected against relevant cyber risks across its lifecycle — and can that be demonstrated?
| Topic | UN ECE R155/R156 | Cyber Resilience Act |
| Object | Type-approved vehicle and its systems | Products with digital elements |
| Risk assessment | Part of the CSMS | Part of the cybersecurity requirements |
| Supply chain | Supplier-related risks must be identified and managed | Due diligence when integrating third-party components |
| Software and updates | R156 governs SUMS and secure update processes | Security updates and vulnerability handling are part of the requirements |
| Evidence | CSMS/SUMS documentation for type approval | Technical documentation and conformity assessment |
| Incident reporting | Regular reporting in the type-approval framework | Tighter deadlines for actively exploited vulnerabilities and severe incidents |
The table illustrates the important nuance. The CRA is more prescriptive for certain obligations, such as reporting deadlines. R155, in turn, is embedded directly in type approval. A manufacturer meeting R155 therefore already works on many of the security disciplines that matter outside automotive as well. That is not a reason to relax. It is why the requirements already need to be taken seriously.
Evidence Starts Before the Audit
A CSMS does not become relevant only when an auditor asks for it. It shows up in day-to-day work: when a new control unit is assessed, a supplier is approved, firmware is changed, or a company needs to establish which vehicles are affected by a vulnerability.
This is where the supply chain determines how resilient the evidence will be later. A manufacturer can only document as well as the information flowing from development, production and supplier processes. If it is not traceable which firmware was loaded onto which control unit, a vulnerability that could have been scoped precisely can turn into a broad recall or a costly reconstruction exercise.
R155 therefore does not just require measures against attacks. It also requires information from the supply chain to be gathered and verified so that supplier-related risks can be identified and managed.
A Cybersecurity Obligation Does Not End at the Factory Gate
R155 requires supplier-related cyber risks to be identified and managed. That is only logical: a control unit is not created by the vehicle manufacturer alone. Firmware, keys, components, programming and logistics pass through several companies, locations and process steps.
In an audit, during a software update or in a recall, it is therefore not enough that a measure has been defined. What matters is whether it can be traced where a component came from, which firmware it received, which process steps are documented, and which vehicles or assemblies may be affected.
This is where cybersecurity connects with supply chain management. With btv TAK®, inventory, movements and process data are documented per packaging unit. Where procurement, storage, component services and secure programming are coordinated through btv, information from these process steps can be brought together in one place.
That does not replace the manufacturer's CSMS. It does, however, make it easier to provide supply-chain evidence in a structured way instead of collecting it only when an auditor, a software update or a recall requires it.
Two Cases That Show What Matters
In 2015, security researchers Charlie Miller and Chris Valasek demonstrated on a Jeep Cherokee how an infotainment system reachable via the mobile network could become an entry point into vehicle functions. The subsequent recall of around 1.4 million vehicles made it clear to the industry that cybersecurity does not end with the software in the vehicle. It concerns architecture, interfaces, update capability and the ability to recognise risks in the field.
The later Bendix EC80 case highlights another side of the same task. A recall of brake control units initially focused on signal-processing issues. Security vulnerabilities, including faulty memory handling and hard-coded credentials, became public only later. The important point is not whether this specific control unit falls under the CRA or R155. The point is that, when a security issue emerges, manufacturers need to know which firmware, which devices and which vehicles are affected — and how the process that loaded firmware onto the control unit was protected.
Both cases lead to the same question: does the evidence only emerge after an incident, or does it already exist because the process produced it?
Where btv SEEL® Fits In
One particularly sensitive point lies where firmware and key material are loaded onto a microcontroller or control unit. This is where intellectual property, product security and future traceability meet directly.
btv SEEL® supports this process at component level. During programming, firmware is processed exclusively in volatile memory. Unencrypted copies are not created on storage media. The customer's own PKI can be integrated, while root certificates remain with the manufacturer. Programming events and device identities can be documented and cryptographically signed.
That does not make a vehicle or control unit automatically “R155-compliant” or “CRA-compliant.” Conformity assessment remains the manufacturer's responsibility. btv SEEL® can, however, provide the foundation from a particularly critical process step: a protected programming process and traceable evidence of what happened, when and on which component.
When the CRA Question Still Needs a Separate Review
For the type-approved vehicle, R155 provides the central cybersecurity framework. A separate CRA assessment can nevertheless be appropriate where a manufacturer or supplier also offers products outside that framework — for example, generic retrofit products, universal diagnostic devices or components sold through open channels to other target groups.
That is a special case. It should not overshadow the main message: even without an additional CRA obligation, automotive cybersecurity is already binding.
Frequently Asked Questions About UN ECE R155, R156 and the CRA
Cyber risks do not arise only at the vehicle manufacturer. Control units, firmware, keys, development and production processes often span several tiers of the supply chain. R155 requires supplier-related risks to be identified and managed.
For this, manufacturers need to be able to trace where a component came from, which processes it has passed through and in which assembly it was used. btv TAK® documents inventory, movements and process data at packaging-unit level. For programmable components, btv SEEL® adds the evidence for firmware, programming process and device identity.
End-product conformity remains the manufacturer's responsibility. Information from agreed btv process steps can, however, help bring together the manufacturer's own CSMS, audit and recall documentation.
