EU Cyber Resilience Act Guide for Connected Vehicle Platform & V2X Vendors
Important — Class I or Class II; V2X roadside units likely Class II
Vendors of connected vehicle telematics platforms, vehicle-to-everything (V2X) communication units, and fleet management systems sold into the EU market face CRA obligations as manufacturers of products with digital elements. The automotive sector's adoption of UNECE WP.29 Regulation 155 (vehicle cybersecurity) creates a parallel regulatory framework for type-approved vehicle systems, but aftermarket and fleet connectivity products outside the type approval scope are fully subject to the CRA. Vendors must navigate the boundary between type-approved vehicle systems and CRA-regulated aftermarket products carefully.
CRA Scope: Aftermarket Connectivity vs. Type-Approved Vehicle Systems
The CRA's relationship with automotive cybersecurity regulation requires careful scoping. Automotive systems incorporated into vehicles as part of type approval under UNECE Regulation 155 are addressed through the automotive type approval process, with cybersecurity managed under Regulation 155 CSMS (Cybersecurity Management System) requirements. However, aftermarket connected devices — OBD-II dongles, fleet telematics units, aftermarket infotainment systems, and V2X retrofit units — are products with digital elements placed on the EU market and fully subject to the CRA. Software platforms sold to vehicle manufacturers for integration into new vehicles may be exempt where they are incorporated into a type-approved system, but standalone commercial software and hardware products sold through distribution channels are in scope. Vendors of connected vehicle platforms must map each product line against this boundary to determine CRA applicability.
Technical Security for V2X and Telematics Products
Connected vehicle telematics and V2X products operate in a unique threat environment: they are mobile, physically accessible to vehicle occupants and third parties, and connected to both vehicle CAN bus networks and public cellular or DSRC networks simultaneously. Annex I requirements include: authenticating all V2X messages using the ETSI ITS PKI certificate framework; encrypting all telematics data transmissions to cloud backends; implementing tamper-resistant hardware design for physical access risks; ensuring firmware updates are authenticated and cannot be triggered remotely without authorisation; implementing network separation between vehicle network interfaces and external connectivity interfaces; and providing telematics platform operators with access controls preventing unauthorised access to vehicle location and diagnostic data. The SBOM must cover the device firmware, cellular modem firmware, and any V2X protocol stack components.
CVD Policy Requirements Under Article 13
Article 13 mandates a published CVD policy. Connected vehicle vendors face active security research from automotive cybersecurity specialists — vulnerabilities in vehicle telematics and V2X systems are regularly presented at automotive security conferences including escar and the Billington Cybersecurity Summit. The CVD policy must: maintain a dedicated security reporting channel; address researcher notification timelines compatible with automotive industry responsible disclosure norms (typically 90 days); specify how vehicle owners, fleet operators, and automotive OEM customers are notified of security updates; and coordinate with the relevant national transport CSIRT for vulnerabilities in V2X infrastructure with public road safety implications. For vendors who supply telematics platforms to fleet management companies, the CVD policy must address how fleet operators are notified when a vulnerability affects the security of their managed vehicles.
Article 14 Incident Reporting for Connected Vehicle Products
Article 14 requires CSIRT notification within 24 hours of confirmed active exploitation. For connected vehicle products, exploitation scenarios range from fleet data exfiltration to vehicle tracking by unauthorised parties, to — in the most severe cases — remote vehicle system manipulation through the telematics interface. For V2X roadside units, exploitation could affect traffic signal communications with implications for road safety. Vendors must have incident response procedures that can assess exploitation scope across the deployed fleet within the 24-hour window and generate the regulatory notification with the required information. For V2X vulnerabilities with road safety implications, simultaneous notification to relevant transport authorities and road safety agencies is appropriate alongside the CSIRT notification.
Conformity Assessment and UNECE WP.29 Coordination
CRA conformity assessment for in-scope connected vehicle products should leverage the cybersecurity evidence developed for UNECE Regulation 155 compliance where available, even though the two frameworks are distinct. CSMS documentation, threat analysis and risk assessment (TARA) reports, and security testing evidence from the WP.29 process all provide relevant inputs to the CRA technical file. V2X roadside units qualifying as Class II Important Products require notified body assessment. Aftermarket telematics units classified as Important Class I may self-declare using harmonised standards — ISO/SAE 21434 (automotive cybersecurity engineering) is the primary applicable standard, supplemented by ETSI ITS security standards for V2X components. The CE marking for CRA purposes must be affixed to the product before EU market placement.
CVD Portal handles your CRA Article 13 obligations automatically.
Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for Connected Vehicle Platform & V2X Vendors.
Start your free portalFrequently asked
We supply telematics software to an automotive OEM who integrates it into new vehicles as part of the infotainment system. Are we subject to the CRA?+
If your software is incorporated into a vehicle system that undergoes type approval under UNECE Regulation 155, and the OEM is the entity placing the completed vehicle on the market, the CRA obligations shift toward the OEM as the product manufacturer in the regulatory chain. However, your contract with the OEM should clearly establish cybersecurity obligations — including SBOM provision, vulnerability notification to the OEM, and security update support — that enable the OEM to meet their CRA obligations. If you also sell the same software as a standalone product through commercial distribution channels (for retrofitting or fleet management), that distribution is fully in CRA scope independently.
Our OBD-II telematics dongle connects to any vehicle via the OBD port. How do we address CAN bus security risks?+
The CAN bus is an inherently insecure protocol — it lacks authentication and was not designed for adversarial threat models. Annex I requires you to assess and address the risks your product introduces through the CAN bus interface. Your product should not transmit unauthenticated commands to the CAN bus; should implement filtering preventing injection of arbitrary CAN frames; should clearly document in user guidance what vehicle systems can be accessed through the product; and should implement network separation between the CAN bus interface and the external cellular interface. The technical file must include a threat model addressing the CAN bus interface specifically, with documented security controls and residual risk assessment.
How do the CRA security update requirements apply to telematics units installed in vehicles that may be active for 10–15 years?+
The CRA requires security update support for the expected product lifetime or 5 years, whichever is shorter. For vehicle telematics units with a 10–15 year vehicle lifecycle, you must declare at point of sale how long security update support will be provided — this becomes a contractual commitment. Fleet operators and automotive OEMs will increasingly require long security support commitments as procurement criteria. You must budget for security update infrastructure to be maintained throughout the declared support period. When support ends before the vehicle's operational life, customers must be given advance notice and migration pathways — which for embedded vehicle hardware typically means unit replacement or network-level isolation of end-of-support devices.
Key CRA articles for Connected Vehicle Platform & V2X Vendors
Need a CVD policy template for Connected Vehicle Platform & V2X Vendors?
Download a free CRA-compliant vulnerability disclosure policy and deploy it in minutes.