The Cyber Resilience Act, or CRA, is the EU's new horizontal cybersecurity regulation for hardware and software products with digital elements. Its purpose is to make cybersecurity a baseline requirement for products placed on the EU market, rather than something treated as an optional feature or post-sale support function.
For the automotive industry, the Cyber Resilience Act matters because connected vehicles are becoming software-defined products. Infotainment systems, telematics units, cloud-connected services, diagnostics tools, charging infrastructure, OTA platforms and aftermarket digital components all increase the cyber attack surface around the vehicle.
The European Commission says the CRA applies to hardware and software products with digital elements made available on the EU market, including final products and components placed separately on the market. It entered into force on 10 December 2024, with the main obligations applying from 11 December 2027 and reporting obligations applying earlier, from 11 September 2026.
The question for the automotive industry is clear: Which connected vehicle products, software components and supplier systems fall into the gap between existing automotive regulation and the CRA?
Why connected vehicles are now a cyber resilience problem
Automotive cybersecurity has already been shaped by UN R155, UN R156 and ISO/SAE 21434. These frameworks created a clearer structure for cybersecurity management systems, software update management systems and lifecycle risk management.
However, the level of connectivity in vehicles has grown quickly. Modern vehicles increasingly depend on cloud APIs, mobile apps, OTA update pipelines, third-party software libraries, aftermarket devices, infotainment platforms, V2X systems and charging infrastructure. Each of these introduces new dependencies that may sit outside traditional vehicle type approval processes.
As Automotive IQ's latest regulations report notes: "The digitalisation of vehicles including in-car gaming and entertainment, and autonomous navigation and driving capabilities, has increased the automotive sector's threat level from a cyber security point of view."
That shift is exactly why CRA compliance should be viewed as part of a wider automotive cyber resilience strategy. The regulation is not only about preventing vulnerabilities at launch. It also pushes manufacturers to manage cybersecurity across the lifecycle of products with digital elements, including design, development, production, maintenance and vulnerability handling. The EU Commission's CRA summary states that manufacturers must perform a cybersecurity risk assessment and account for cybersecurity requirements across planning, design, development, production, delivery and maintenance.
For connected vehicles, this creates a direct link between software engineering, supplier governance and post-sale security operations.
Where the CRA fits into the automotive cybersecurity stack
Does the Cyber Resilience Act apply to vehicles?
The CRA is a horizontal regulation for products with digital elements. However, products already covered by certain sector-specific EU rules may be excluded where those rules provide equivalent cybersecurity requirements.
That means the CRA is especially relevant for:
- Telematics and infotainment systems, particularly retrofit solutions.
- Aftermarket diagnostic devices, dongles and connected accessories.
- Firmware and standalone software supplied separately.
- Connected charging infrastructure and V2G communication components.
- Cloud and back-end components that communicate with vehicle functions through APIs.
- Non-road vehicles, including agricultural machinery, construction equipment and industrial transport vehicles.
The Commission summary also confirms that the CRA applies to products with digital elements where the intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. It also states that certain products may be excluded where covered by other Union legislation.
For OEMs, the practical risk is overlap. A vehicle programme may already have UN R155 and R156 evidence, but individual software products, supplier modules, cloud-linked components or aftermarket systems may still require CRA analysis.
What changes for OEMs and suppliers?
The Cyber Resilience Act shifts cybersecurity from a vehicle approval issue into a broader product compliance issue. That matters because many connected vehicle risks originate outside the core vehicle platform.
Under the CRA, manufacturers are expected to design, develop and produce products with digital elements in line with essential cybersecurity requirements. They must also maintain technical documentation, carry out conformity assessment, draw up an EU declaration of conformity and affix CE marking where applicable.
For automotive suppliers, this means cybersecurity evidence becomes part of market access. It will not be enough to say a component is "secure" or that it was developed to internal standards. Suppliers may need to prove risk assessment, vulnerability handling, software update capability, support periods, component due diligence and technical documentation.
For OEMs, the CRA creates a supplier-management challenge. If the vehicle depends on third-party software, firmware, cloud processing or connected hardware, the OEM will need confidence that the supplier's cybersecurity process can withstand regulatory scrutiny.
The automotive SBOM gap
The Software Bill of Materials, or SBOM, is becoming one of the most important tools for closing the gap between cybersecurity regulation and real-world software supply chains. An SBOM is a structured inventory of the software components, dependencies and metadata used within a product. In practice, it helps organisations identify where vulnerable libraries, outdated packages or risky dependencies exist.
This matters because connected vehicles contain a complex mix of proprietary code, open-source components, supplier software, firmware, middleware, mobile app code, cloud services and third-party APIs. Without a reliable SBOM process, it becomes difficult to answer basic security questions quickly:
- Which vehicles use this affected software component?
- Which ECU, app, cloud service or supplier module contains the vulnerability?
- Which software version is affected?
- Which markets or vehicle lines are exposed?
- Who owns the fix?
- Can the issue be patched OTA?
- Does it trigger a CRA reporting obligation?
The Commission summary does not reduce CRA compliance to SBOM creation alone. However, it does require manufacturers to exercise due diligence over third-party components so those components do not compromise the cybersecurity of the product with digital elements. It also requires vulnerability handling during the product support period.
That is where the SBOM gap becomes operational. If OEMs and suppliers cannot maintain accurate software composition data, they will struggle to prove component due diligence, assess vulnerability exposure or respond quickly to actively exploited vulnerabilities.
Secure OTA updates move from best practice to compliance evidence
Secure over-the-air updates are already central to UN R156 compliance. Under the CRA, they also become part of the wider expectation that vulnerabilities are handled effectively throughout the support period.
Automotive IQ's report lists secure OTA updates as a key compliance requirement for automotive manufacturers under the CRA, noting that manufacturers must ensure OTA capabilities are secure and efficient, and that vulnerabilities are patched in real time.
This is especially important for software-defined vehicles. A vulnerability in an infotainment system, telematics control unit or connected application may not require a recall in the traditional mechanical sense, but it may still require a rapid software remediation pathway.
That means OEMs and suppliers should be able to show:
- How vulnerabilities are identified and assessed.
- How affected software components are mapped to vehicles or products.
- How patches are developed, validated and deployed.
- How security updates are separated from feature updates where necessary.
- How end users are informed.
- How the support period is defined and communicated.
The CRA also requires manufacturers to determine a support period for products with digital elements and make the end date of that support period clear at the time of purchase.
What OEMs and suppliers should do now
The 2027 deadline may seem manageable, but the hard work sits in supplier mapping, SBOM maturity and lifecycle evidence. Automotive businesses should begin with five actions.
First, map CRA scope across the connected vehicle ecosystem. Identify which digital products, components, cloud services and aftermarket systems may fall outside sector-specific vehicle regulation.
Second, build an SBOM strategy. Define where SBOMs are required, which formats are acceptable, how supplier SBOMs are validated, and how SBOMs are linked to vehicle variants, software releases and OTA packages.
Third, align vulnerability management with CRA reporting timelines. Teams need clear workflows for assessing actively exploited vulnerabilities, severe incidents, CSIRT and ENISA reporting, and customer communication.
Fourth, review supplier contracts. Cybersecurity obligations should include vulnerability disclosure, component transparency, update support, incident cooperation, evidence retention and end-of-support expectations.
Fifth, connect CRA, UN R155, R156 and ISO/SAE 21434 evidence. The goal should be a single cybersecurity assurance model that works across type approval, product compliance, software supply chain management and post-market monitoring.
Key takeaways: what changes for connected vehicles?
The Cyber Resilience Act changes the regulatory expectations around connected vehicle software. It extends cybersecurity responsibility beyond the vehicle platform and into the wider ecosystem of digital components, supplier software, cloud services, aftermarket products and remote processing solutions.
For OEMs, the immediate challenge is identifying where CRA obligations apply alongside existing automotive frameworks. For suppliers, the challenge is proving that software and connected hardware products are secure by design, supported over time and backed by credible vulnerability handling processes.
The automotive SBOM gap is one of the most important practical issues. Without accurate software component visibility, companies will struggle to manage vulnerability exposure, support OTA updates, prove supplier due diligence and meet CRA reporting expectations.
In short: the Cyber Resilience Act turns automotive cybersecurity from a vehicle-level compliance issue into a software supply chain resilience issue. The organisations that close the SBOM gap now will be better prepared for connected vehicle compliance in 2026, 2027 and beyond.