CRA Compliance Checklist: Automotive Electronics & In-Vehicle Systems
Complex intersection with UN R155/R156 (UNECE WP.29) — vehicles and vehicle systems covered by type approval under R155 may be excluded from CRA; standalone aftermarket electronics are in full CRA scope
Automotive electronics face a complex regulatory landscape. Vehicles and vehicle-integrated systems subject to UNECE WP.29 type approval (UN Regulations R155 and R156) may be excluded from CRA scope, as these regulations provide equivalent cybersecurity requirements. However, standalone aftermarket automotive electronics, diagnostic tools, and fleet telematics devices placed on the market independently are fully in CRA scope. Manufacturers must carefully map each product to determine applicable regulations.
1. Scope & Classification
Determine whether each product is covered by UN R155/R156 type approval — if so, assess whether this constitutes equivalent sectoral regulation excluding CRA
UN R155 (Cybersecurity Management System) and R156 (Software Update Management System) apply to vehicle type approval. The CRA may not apply to systems within the scope of R155/R156 — but this exclusion must be formally assessed per CRA Article 3(2) criteria.
Identify standalone automotive electronics (aftermarket OBD dongles, fleet trackers, in-car infotainment retrofit) that are not covered by vehicle type approval
Aftermarket electronics not integrated into vehicle type approval are standalone products with digital elements fully in scope for CRA. Map each product type carefully.
Assess Annex III Class I for safety-critical automotive electronics (ADAS systems, gateway ECUs, V2X communication modules)
Safety-critical automotive electronics not covered by type approval exclusion are likely Annex III Class I given their vehicle safety implications.
Compile SBOM for all in-scope automotive electronics covering ECU firmware, AUTOSAR layers, middleware, and telematics software
Automotive software stacks are complex: AUTOSAR BSW, middleware, application software, and telematics. All must be tracked. Align with SBOM requirements emerging from automotive industry standards (NTIA, ISO/SAE 21434).
2. Product Security (Annex I Part I)
Implement secure boot and code signing for all ECU firmware — prevent unauthorised firmware loading
Secure boot is a fundamental automotive cybersecurity control. Align with ISO/SAE 21434 requirements and UNECE R155/R156 obligations. Hardware Security Modules (HSM) in ECUs should hold signing keys.
Implement authentication and integrity protection for all OTA software update packages
OTA updates to vehicle software must be cryptographically signed and verified before installation. UN R156 provides detailed requirements for software update management systems.
Implement network segmentation within the vehicle using a gateway ECU — isolate safety-critical networks from infotainment and telematics
Vehicle networks (CAN, LIN, Ethernet) must be segmented. The central gateway must enforce strict domain separation between powertrain, chassis, safety, and infotainment domains.
Encrypt all external communications — V2X, telematics, remote diagnostics, and OTA — using appropriate automotive cryptographic standards
External vehicle communications must be encrypted. V2X uses IEEE 1609.2 PKI. Telematics and OTA use TLS. Align with ETSI ITS and SAE J3101 specifications.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy aligned with ISO/SAE 21434 vulnerability management requirements
ISO/SAE 21434 Section 10 addresses vulnerability management. Aligning your CVD policy with ISO/SAE 21434 ensures compliance with both automotive industry standards and CRA requirements.
Establish a vehicle cybersecurity incident response process aligned with UNECE WP.29 CSMS requirements
UNECE R155 requires a Cybersecurity Management System covering incident response. Align your CRA CVD process with your CSMS to avoid duplicate processes.
Define long-term security support periods reflecting automotive product lifecycles — minimum 10 years from vehicle production end
Vehicles remain in use for 15–20 years. Automotive electronics security support must reflect this. Commit to security support for the expected vehicle use life.
4. Article 14 Incident Reporting
Align Article 14 reporting with UNECE R155 cybersecurity incident reporting to type approval authorities
R155 requires reporting cybersecurity incidents to type approval authorities. CRA Article 14 requires reporting to ENISA. For type-approval-excluded systems, R155 may be the primary obligation. For in-scope products, both may apply.
Pre-prepare Article 14 notification templates for automotive-specific incidents — focus on safety-critical system compromise and fleet-scale exploitation
Fleet-scale automotive cyber incidents (e.g. mass OTA compromise) are high-severity Article 14 triggers. Templates should address the fleet dimension — how many vehicles affected, geographic spread.
5. CE Marking & Technical Documentation
For type-approval-excluded systems, maintain R155 CSMS and R156 SUMS documentation as the primary compliance evidence
If R155/R156 provide equivalent requirements, this evidence base supports the CRA exclusion claim. Maintain it rigorously and ensure it covers all cybersecurity obligations.
For standalone in-scope automotive electronics, prepare full CRA technical file and issue EU Declaration of Conformity
Aftermarket and fleet telematics products must have CRA technical files and DoCs. Align documentation with ISO/SAE 21434 to demonstrate systematic cybersecurity management.
Track your Automotive Electronics & In-Vehicle Systems compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
Does the CRA apply to OBD-II diagnostic dongles and fleet telematics units?+
Yes. OBD-II dongles, fleet telematics units, and other aftermarket automotive electronics that plug into vehicles but are sold independently as standalone products are fully in scope for the CRA. They are not covered by vehicle type approval (UN R155 applies to the vehicle manufacturer's type approval, not third-party accessories). These products are Default or Class I products with digital elements.
We are a Tier 1 supplier providing ECUs to OEMs — does CRA apply to us or the OEM?+
As a Tier 1 supplier, if you place ECUs on the market as standalone products, you hold CRA obligations for those products. If the OEM integrates your ECUs and places the vehicle under type approval, the type approval framework governs the vehicle, and the OEM manages the overall CSMS under R155. In practice, OEMs will impose contractual obligations on Tier 1 suppliers to provide cybersecurity support, SBOMs, and vulnerability information to support the OEM's compliance.
How does ISO/SAE 21434 relate to CRA compliance for automotive electronics?+
ISO/SAE 21434 is the primary automotive cybersecurity standard covering the full vehicle development lifecycle. It overlaps significantly with CRA Annex I requirements. When ISO/SAE 21434 is adopted as a harmonised standard under the CRA (which is anticipated), compliance with it will provide a presumption of conformity with CRA requirements. Implementing ISO/SAE 21434 now is strongly recommended for all automotive electronics manufacturers.
Need a CVD policy for Automotive Electronics & In-Vehicle Systems?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.