EU Cyber Resilience Act Guide for Automotive OEMs & Tier-1 Suppliers

The EU Cyber Resilience Act applies to any product with digital elements placed on the EU market — including electronic control units (ECUs), telematics control units (TCUs), gateway modules, in-vehicle infotainment systems, and V2X communication hardware. Under Annex III, products that can directly or indirectly affect vehicle safety functions or that provide a network interface into safety-critical systems are classified as Important Class I.

OEMs must evaluate each product line independently. A passive CAN-bus sensor with no external network interface may qualify as Default Class; a TCU with LTE/5G connectivity and remote update capability will almost certainly be Class I. Tier-1 suppliers placing components directly on the EU market — rather than supplying exclusively to an OEM — are independently liable for compliance. The classification determination must be documented in the technical file and reviewed whenever the product scope changes.

Annex I Part I of the CRA defines the essential cybersecurity requirements that automotive products must satisfy before CE marking. For OEM and Tier-1 products, the most operationally demanding obligations include:

• Secure by default: No unnecessary network services enabled at shipment; default credentials prohibited.
• Attack surface minimisation: Each ECU must expose only the interfaces required for its documented function.
• Secure update mechanism: Over-the-air (OTA) updates must use authenticated, integrity-verified delivery. Rollback protection is required.
• Confidentiality of data in transit: Cryptographic protection on all external interfaces, including V2X, Bluetooth, and cellular.
• Vulnerability management: A documented process to monitor, assess, and remediate vulnerabilities throughout the product's supported lifetime — typically aligned with the vehicle model lifecycle, which may extend 10–15 years.

Annex I Part II further requires a software bill of materials (SBOM) to be maintained for each product, covering all third-party and open-source components.

Article 13 of the CRA requires manufacturers to establish, operate, and publicly disclose a coordinated vulnerability disclosure (CVD) policy for every product with digital elements. For automotive OEMs, this means publishing a security.txt file or equivalent disclosure contact point that external researchers and customers can use to report vulnerabilities in vehicle firmware, telematics, or connected services.

• The scope of products covered
• The preferred submission channel (e.g., encrypted email, web form, CVD Portal)
• Acknowledgement timelines and researcher expectations
• The manufacturer's remediation and public disclosure process

CVD Portal automates this infrastructure: a single CVD Portal account can generate compliant security.txt files, manage incoming disclosures, and produce CSAF 2.0 advisory records for each resolved vulnerability. For OEMs managing 50–200+ distinct product lines, this centralised approach is essential for maintaining programme consistency across model years.

Article 14 mandates that manufacturers report actively exploited vulnerabilities in their products to ENISA within 24 hours of becoming aware. For automotive products, the concept of 'active exploitation' encompasses scenarios where a third party is using a known vulnerability to compromise vehicle systems in the field — whether for theft, safety interference, or data extraction.

OEMs must therefore maintain monitoring capabilities that can detect exploitation signals: telemetry from connected vehicle platforms, threat intelligence feeds covering automotive attack toolkits, and PSIRT intake processes that can triage disclosures within hours rather than days. The 24-hour initial notification to ENISA need not include full technical detail, but must confirm the affected product, the nature of the vulnerability, and any known mitigating measures. A fuller incident report is due within 72 hours, with a final report within 30 days.

CVD Portal's Article 14 timeline tool helps PSIRT teams track these deadlines automatically from the moment a report is flagged as actively exploited.

Class I products require third-party conformity assessment conducted by a notified body accredited under the CRA framework. OEMs should initiate notified body engagement no later than Q1 2026 to avoid bottlenecks as assessment capacity becomes constrained across all Class I sectors.

1. The product's security architecture against Annex I requirements
2. The manufacturer's vulnerability management process (Annex I Part II)
3. The CVD policy and its operational maturity
4. The technical file and SBOM completeness
5. The OTA update mechanism's integrity controls

For OEMs already certified under UNECE WP.29 R155 (Cybersecurity Management System) or ISO/SAE 21434, a significant portion of the technical evidence required for CRA assessment will already exist. Notified bodies are expected to accept WP.29 CSMS certificates as supporting evidence, though not as a full substitute for CRA conformity assessment. Maintaining alignment between CSMS and CRA technical files will minimise duplication of effort.

Tier-1 suppliers face a dual compliance burden under the CRA. When supplying components exclusively to an OEM for integration into that OEM's product, the OEM assumes primary market-placement responsibility. However, suppliers who sell independently to the aftermarket, fleet operators, or distributors are independently responsible for CRA compliance on those placements.

• Provide the OEM with all security-relevant information required to satisfy the OEM's technical file obligations
• Disclose vulnerabilities discovered in their components to the OEM promptly so the OEM can meet Article 14 reporting timelines
• Maintain an SBOM for their components and make it available on request

Contracts between OEMs and Tier-1 suppliers should be updated to include CRA obligations explicitly, including notification timelines, SBOM delivery requirements, and coordinated disclosure commitments.