EU Cyber Resilience Act vs UNECE R155: What Automotive Companies Need to Know

Automotive companies operating in the European market face an increasingly complex regulatory landscape for cybersecurity. Two major regulations now demand attention: the EU Cyber Resilience Act (CRA), which entered into force in December 2024, and UNECE Regulation No. 155 (R155), which has been mandatory for all new vehicle type approvals in the EU since July 2024. While both regulations address cybersecurity, they operate at different levels, target different entities, and impose different obligations. Understanding their relationship is critical for OEMs, Tier-1 suppliers, and component manufacturers who may need to comply with both simultaneously.

This guide provides an in-depth comparison of the CRA and R155, clarifies their overlapping and distinct requirements, examines dual compliance challenges, and offers practical guidance for automotive companies navigating this regulatory intersection.

Understanding UNECE R155: Vehicle-Level Cybersecurity

UNECE Regulation No. 155 was adopted by the World Forum for Harmonization of Vehicle Regulations (WP.29) in June 2020 and became enforceable for new vehicle types in the EU from July 2022. Since July 2024, R155 applies to all new vehicles sold in the EU, not just new type approvals. R155 is a vehicle-level regulation: it requires the vehicle manufacturer (OEM) to demonstrate that cybersecurity has been systematically addressed throughout the vehicle lifecycle.

Scope and Applicability

R155 applies to motor vehicles of categories M (passenger vehicles), N (commercial vehicles), and O (trailers) that are equipped with at least one electronic control unit. In practice, this covers virtually all modern vehicles. The regulation addresses the complete vehicle as a system, not individual components in isolation.

The primary compliance obligation falls on the vehicle manufacturer, who must obtain type approval from a designated technical service and approval authority. However, the OEM must demonstrate that cybersecurity is managed across the entire supply chain, which creates cascading requirements for Tier-1 and Tier-2 suppliers.

Key Requirements

R155 mandates two primary deliverables:

1. Cybersecurity Management System (CSMS) Certificate: The OEM must demonstrate an organizational-level CSMS that covers cybersecurity governance, risk management processes, threat monitoring, and incident response. The CSMS certificate is valid for three years and covers the organization rather than a specific vehicle.
2. Vehicle Type Approval for Cybersecurity: Each vehicle type must demonstrate that cybersecurity risks have been identified and mitigated. This requires a threat analysis and risk assessment (TARA) for each vehicle type, documented security controls, verification and validation evidence, and a plan for monitoring and responding to threats throughout the vehicle lifetime.

R155 references ISO/SAE 21434 as the recommended standard for implementing the CSMS and performing TARA, although it does not mandate ISO/SAE 21434 compliance explicitly. The regulation provides Annex 5 with a list of threat categories and mitigations that must be considered.

Post-Production Obligations

R155 extends cybersecurity obligations beyond the point of sale. OEMs must monitor the cybersecurity posture of vehicles in the field, respond to newly discovered vulnerabilities, and provide security updates throughout the vehicle lifetime. This post-production monitoring requirement creates ongoing operational costs and necessitates infrastructure for vulnerability tracking and software update delivery.

Understanding the EU Cyber Resilience Act: Product-Level Security

The EU Cyber Resilience Act (Regulation 2024/2847) was published in the Official Journal of the EU on November 20, 2024, and entered into force on December 10, 2024. Unlike R155, the CRA is a horizontal EU regulation that applies to all products with digital elements placed on the EU market, not just vehicles. Its scope is broad, covering everything from consumer IoT devices to industrial control systems to software libraries.

Scope and the Automotive Intersection

The CRA's default scope includes any product with digital elements, defined as "any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately." However, the CRA explicitly excludes products already covered by existing sector-specific EU regulations that achieve equivalent cybersecurity outcomes. This is where the automotive intersection becomes nuanced.

Article 2(2) of the CRA exempts motor vehicles and their trailers that fall within the scope of Regulation (EU) 2019/2144 (the General Safety Regulation, which incorporates R155 requirements). This means that vehicles as whole products are excluded from CRA scope because they are already covered by R155 through the EU type approval framework.

However, this exemption applies at the vehicle level, not the component level. Vehicle components, aftermarket devices, diagnostic tools, fleet management systems, V2X communication units, and other automotive products that are placed on the market independently (i.e., not exclusively as part of a type-approved vehicle) may fall within CRA scope. This distinction is critical for Tier-1 suppliers who sell components both as integrated vehicle parts and as standalone aftermarket products.

Key Requirements

The CRA imposes obligations on manufacturers, importers, and distributors of products with digital elements:

• Security by design: Products must be designed, developed, and produced with appropriate cybersecurity measures. Default configurations must minimize the attack surface, and products must ship without known exploitable vulnerabilities.
• Vulnerability handling: Manufacturers must establish and operate a coordinated vulnerability disclosure process, provide security updates for at least the expected product lifetime or five years (whichever is longer), and document vulnerabilities in a machine-readable format.
• Software Bill of Materials (SBOM): Manufacturers must generate and maintain an SBOM identifying all components, including open-source libraries, in a commonly used, machine-readable format. The SBOM must be provided to regulatory authorities upon request.
• Conformity assessment: Products must undergo conformity assessment before being placed on the market. The assessment procedure depends on the product category: self-assessment for default products, third-party assessment for important products (Class I and II), and EU type examination for critical products.
• Incident reporting: Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware, with a full notification within 72 hours.
• CE marking: Compliant products carry the CE marking, indicating conformity with CRA essential requirements.

Product Classification

The CRA classifies products into three tiers with increasing scrutiny:

• Default products: Self-assessment (manufacturer's declaration of conformity). This covers the majority of products with digital elements.
• Important products (Class I): Self-assessment with reference to harmonized standards, or third-party assessment. Examples include network management systems and security gateways.
• Important products (Class II): Mandatory third-party assessment. Examples include operating systems, firewalls, microcontrollers, and hardware security modules.
• Critical products: EU type examination by a notified body. Examples include smart meter gateways and hardware devices with security boxes.

For automotive suppliers, this classification is significant. Hardware Security Modules (HSMs) used in vehicles are explicitly listed as Important Class II products requiring third-party assessment. Vehicle gateways sold as standalone products could be classified as Important Class I. ECU firmware operating systems might fall under Class II if marketed independently.

Detailed Comparison: CRA vs R155

The following table provides a side-by-side comparison across key dimensions relevant to automotive companies.

Dimension	EU Cyber Resilience Act (CRA)	UNECE R155
Legal Framework	EU Regulation (directly applicable in all EU member states)	UNECE Regulation (adopted into EU law via General Safety Regulation 2019/2144)
Geographic Scope	EU single market (products placed on EU market)	All UNECE 1958 Agreement contracting parties (EU, UK, Japan, South Korea, etc.)
Product Scope	All products with digital elements (excludes type-approved vehicles)	Motor vehicles (categories M, N, O) with electronic control units
Compliance Entity	Product manufacturer, importer, distributor	Vehicle manufacturer (OEM)
SBOM Requirement	Mandatory, machine-readable format, available to authorities	Not explicitly required (ISO/SAE 21434 references software identification)
Vulnerability Handling	Coordinated disclosure, 24/72-hour reporting to ENISA	Monitoring and response required, no specific reporting timeline to authority
Assessment Method	Self-assessment, or third-party based on product class	Third-party type approval by technical service
Organizational CSMS	Not required as separate certificate (embedded in product requirements)	Mandatory CSMS certificate (valid 3 years)
TARA Requirement	Risk assessment required (not automotive-specific TARA)	Vehicle-specific TARA per Annex 5 threat categories
Post-Market Obligations	Security updates for product lifetime or 5 years minimum	Monitoring and updates throughout vehicle lifetime
Penalties	Up to 15 million EUR or 2.5% of global annual turnover	Withdrawal of type approval (vehicle cannot be sold)
Key Dates	Entry into force: Dec 2024. Reporting obligations: Sep 2026. Full application: Dec 2027	New type approvals: Jul 2022. All new vehicles: Jul 2024

Overlap Areas: Where CRA and R155 Converge

Despite their different scopes, CRA and R155 share several conceptual requirements that create opportunities for aligned compliance efforts.

Software Security and Secure Development

Both regulations require that software is developed with security in mind. R155 requires this through the CSMS framework, which must include secure development processes. The CRA mandates security-by-design principles and requires that products ship without known exploitable vulnerabilities. Organizations already implementing ISO/SAE 21434 Clause 10 (product development) will have significant overlap with CRA's secure development requirements.

Vulnerability Handling

Both regulations require ongoing vulnerability management. R155 mandates monitoring and response capabilities as part of the CSMS. The CRA requires coordinated vulnerability disclosure, active monitoring, and time-bound reporting. The CRA's requirements are more prescriptive, with specific timelines (24-hour early warning, 72-hour full notification to ENISA). An organization's vulnerability management process can be designed to satisfy both regulations simultaneously, with the CRA's stricter timelines driving the process design.

Risk Assessment

Both regulations require risk-based approaches to cybersecurity. R155 mandates TARA for vehicle types using threat categories from Annex 5. The CRA requires manufacturers to perform a cybersecurity risk assessment and design security measures appropriate to the identified risks. While the specific methodologies differ (TARA is automotive-specific; CRA risk assessment is generic), the underlying risk management framework can be unified.

Supply Chain Security

Both regulations extend cybersecurity obligations to the supply chain. R155 requires OEMs to manage supplier cybersecurity through the CSMS, including contractual requirements and audit mechanisms. The CRA requires manufacturers to exercise due diligence when integrating third-party components, including verifying their cybersecurity properties. Tier-1 suppliers face requirements from both directions: from OEMs cascading R155 obligations downward, and from CRA obligations on their own products placed independently on the market.

Key Differences and Their Implications

The Scope Boundary Problem

The most challenging aspect of CRA/R155 coexistence is determining which regulation applies to a specific product. The CRA exempts type-approved vehicles, but the boundary is not always clear. Consider these scenarios:

• ECU sold exclusively to OEMs: Integrated into a type-approved vehicle, covered by R155 through the vehicle type approval. CRA likely does not apply.
• ECU sold as aftermarket replacement: Placed on the market independently, not covered by vehicle type approval. CRA applies.
• Telematics unit with cloud service: The vehicle-installed hardware may be covered by R155, but the cloud service component (remote data processing) falls within CRA scope.
• V2X On-Board Unit: If integrated into a type-approved vehicle, covered by R155. If sold as an aftermarket unit, CRA applies. The same product may require dual compliance depending on the sales channel.
• Diagnostic tool sold to workshops: Not part of a vehicle type approval. CRA applies as a product with digital elements that connects to vehicles.
• Fleet management platform: Software product connecting to vehicles. CRA applies. The data it processes from R155-compliant vehicles creates an intersection point.

SBOM Requirements: A Key Divergence

The CRA's explicit SBOM mandate is one of the most significant practical differences. While R155 does not specifically require SBOMs, the CRA requires manufacturers to generate and maintain an SBOM for each product in a machine-readable format. For automotive components that fall within CRA scope, this creates a concrete deliverable that does not exist under R155 alone.

However, SBOM generation is increasingly recognized as best practice for R155 compliance as well. ISO/SAE 21434 references software identification, and effective vulnerability monitoring (required by R155) is practically impossible without knowing what software components are deployed. Forward-thinking automotive companies are implementing SBOM capabilities across their product portfolio, regardless of which regulation technically requires it, because SBOMs serve both compliance frameworks effectively.

Incident Reporting: Different Authorities, Different Timelines

Under the CRA, actively exploited vulnerabilities must be reported to ENISA within 24 hours. Under R155, the OEM must monitor and respond to cybersecurity incidents as part of the CSMS, reporting to the type approval authority as required. These are different authorities with different processes and expectations.

For a Tier-1 supplier who discovers a vulnerability in a component used in type-approved vehicles (R155) and also sold as an aftermarket product (CRA), the incident triggers reporting obligations under both regulations to different authorities with different timelines. Unified incident management processes are essential to avoid compliance gaps.

Timeline Comparison and Planning

Understanding the enforcement timelines is critical for resource planning and prioritization.

UNECE R155 Timeline

• June 2020: R155 adopted by WP.29
• January 2021: R155 entered into force
• July 2022: Mandatory for new vehicle type approvals in the EU
• July 2024: Mandatory for all new vehicles sold in the EU
• Ongoing: CSMS certificates require renewal every 3 years

EU CRA Timeline

• September 2022: CRA proposal published
• March 2024: European Parliament adopted the CRA
• October 2024: Council adopted the CRA
• December 10, 2024: CRA entered into force
• September 11, 2026: Reporting obligations apply (vulnerability and incident reporting to ENISA)
• December 11, 2027: Full application (all requirements enforceable, CE marking required)

Practical Planning Implications

R155 is already fully enforced. Companies that have achieved R155 compliance have a foundation for CRA compliance but must address the gaps by the CRA application dates. The most urgent gap is SBOM generation (December 2027) and vulnerability reporting processes (September 2026). Companies should be building these capabilities now, given the organizational and technical lead time required.

Impact on Tier-1 Suppliers

Tier-1 automotive suppliers face unique challenges because they may need to comply with both regulations simultaneously, depending on their product portfolio and sales channels.

Dual Compliance Scenarios

A Tier-1 supplier manufacturing a vehicle gateway ECU faces the following compliance landscape:

• As an OEM supplier: The gateway is integrated into the vehicle and covered by the OEM's R155 type approval. The Tier-1 must provide cybersecurity evidence to the OEM (development artifacts, TARA contributions, vulnerability monitoring capabilities) as required by the OEM's CSMS.
• As an independent product: If the same gateway is sold as a standalone product (e.g., to aftermarket integrators, fleet operators, or for non-automotive applications), it falls within CRA scope and must comply independently. This includes generating SBOMs, performing conformity assessment (potentially Class I or II depending on the product), and establishing vulnerability reporting to ENISA.

The challenge is that R155 compliance evidence cannot be directly reused for CRA compliance and vice versa. The assessment frameworks, documentation formats, and compliance artifacts differ. However, the underlying security engineering work (threat analysis, secure design, testing, vulnerability management) serves both regulations.

Supply Chain Contractual Implications

OEMs are increasingly flowing down cybersecurity requirements to Tier-1 suppliers through procurement contracts. These requirements blend R155 obligations (CSMS evidence, TARA contributions) with emerging CRA obligations (SBOM delivery, vulnerability reporting coordination). Tier-1 suppliers should expect contract amendments requiring CRA-aligned deliverables, particularly SBOMs and vulnerability handling process documentation, even for components covered by R155 through vehicle type approval.

Harmonized Standards and Presumption of Conformity

The CRA allows for harmonized European standards (hENs) that provide a presumption of conformity. The European Commission has mandated CEN, CENELEC, and ETSI to develop these standards. For automotive products, alignment between these harmonized standards and ISO/SAE 21434 is being actively pursued by standards bodies. If achieved, ISO/SAE 21434 compliance could support CRA conformity assessment for automotive products, reducing duplication. However, this alignment is still in progress and automotive companies should not assume equivalence until harmonized standards are formally published and referenced in the Official Journal.

Practical Compliance Strategy

Based on the analysis above, automotive companies should consider the following compliance strategy for managing both CRA and R155.

Step 1: Product Portfolio Classification

Map every product in the portfolio against both regulations. Determine which products fall under R155 (through vehicle type approval), which fall under CRA (standalone products with digital elements), and which potentially fall under both depending on sales channel. This classification drives all subsequent compliance planning.

Step 2: Unified Cybersecurity Framework

Implement a single cybersecurity management framework that satisfies the superset of both regulations' requirements. Use ISO/SAE 21434 as the baseline (it is already required for R155) and extend it with CRA-specific requirements: SBOM generation, ENISA reporting integration, and CRA conformity assessment documentation.

Step 3: SBOM Infrastructure

Build SBOM generation and management capabilities across the organization. Even for products covered by R155 only, SBOMs improve vulnerability monitoring effectiveness. For CRA-scoped products, SBOMs are mandatory. A unified SBOM infrastructure that covers both product categories is more efficient than separate systems.

Step 4: Integrated Vulnerability Management

Design a vulnerability management process that meets both R155's monitoring requirements and CRA's reporting timelines. The process should identify the applicable regulation for each affected product, route notifications to the correct authorities (type approval authority for R155, ENISA for CRA), and maintain a unified timeline tracking system.

Step 5: Evidence Management and Traceability

Maintain a single evidence repository that produces compliance artifacts for both regulations. A threat analysis should generate both the TARA documentation required for R155 type approval and the risk assessment documentation required for CRA conformity assessment. This avoids duplication while ensuring that regulation-specific formatting and content requirements are met.

How ThreatZ Manages Multi-Regulation Compliance

ThreatZ provides an integrated platform for managing automotive cybersecurity compliance across multiple regulatory frameworks, including both UNECE R155 and the EU Cyber Resilience Act.

The ThreatZ platform maintains a unified product architecture model from which regulation-specific compliance artifacts are generated. A single TARA analysis produces both R155 Annex 5-aligned threat assessment documentation and CRA-compatible risk assessment evidence. The platform's SBOM module generates and tracks Software Bills of Materials across the product portfolio, satisfying the CRA mandate while simultaneously improving R155 vulnerability monitoring capabilities.

ThreatZ's compliance dashboard provides per-product regulatory mapping, showing which regulations apply to each product variant and tracking compliance status across both CRA and R155 requirements. Gap analysis reports identify missing evidence and upcoming deadlines, enabling proactive compliance management rather than reactive audit preparation.

For Tier-1 suppliers managing dual compliance obligations, ThreatZ's supply chain module coordinates evidence delivery to OEM customers (for R155 type approval support) and generates CRA conformity assessment documentation for independently marketed products, all from the same underlying cybersecurity engineering data.

Key Takeaways

• UNECE R155 is a vehicle-level regulation already fully enforced, requiring OEMs to demonstrate cybersecurity through CSMS certification and vehicle type approval.
• The EU Cyber Resilience Act covers products with digital elements broadly but exempts type-approved vehicles. Vehicle components sold independently may require CRA compliance.
• Tier-1 suppliers face the highest dual compliance burden: they must support OEM R155 type approval while independently complying with CRA for standalone products.
• Key overlap areas include secure development, vulnerability handling, risk assessment, and supply chain security. A unified cybersecurity framework reduces duplication.
• The CRA's SBOM mandate and 24-hour vulnerability reporting to ENISA are the most significant new requirements beyond R155.
• CRA reporting obligations begin September 2026; full application starts December 2027. Companies should be building SBOM and reporting capabilities now.
• Product portfolio classification is the essential first step: determine which products fall under R155, CRA, or both before planning compliance activities.