The EU Cyber Resilience Act for automotive: what changes

The CRA is a product law, not a vehicle law

The EU Cyber Resilience Act — Regulation (EU) 2024/2847, in force since December 2024 — sets horizontal cybersecurity requirements for "products with digital elements" placed on the EU market. That phrase is deliberately broad. It covers software and hardware that can connect to a device or network, and it reaches the manufacturer wherever they sit, including an Indian supplier exporting into the Union.

For automotive teams the first instinct is to ask whether the CRA replaces or duplicates UN R155. It does neither cleanly. Vehicle type-approval cybersecurity is already handled by UN R155, applied in the EU through the General Safety Regulation (EU) 2019/2144 — new types from 6 July 2022 and all new vehicles from 7 July 2024. The CRA sits alongside that regime as general product law. The interaction between the two is nuanced, still settling in interpretation, and worth watching rather than assuming away.

What the CRA actually asks for

Strip the regulation to its obligations and four themes stand out.

• Secure-by-design and secure-by-default. Products must be designed, developed and produced to limit attack surfaces and ship in a secure configuration, not one the buyer has to harden.
• A software bill of materials. Manufacturers must know and document the components in their product. The SBOM becomes the backbone of vulnerability management, not an optional artefact.
• Vulnerability handling and coordinated disclosure. A defined process to identify, triage, remediate and disclose vulnerabilities across the supported lifetime, with a coordinated disclosure policy.
• Reporting. Active reporting of exploited vulnerabilities and severe incidents to the authorities within tight windows once those duties commence.

These are obligations of process and evidence, held by the manufacturer, sustained over the product's life. They are not a one-off certificate.

Where the CRA and R155 meet — and diverge

The two regimes rhyme on some controls and part company on others. The table sets out the shape of it; a fuller clause-level treatment lives in CRA vs UN R155.

Dimension	UN R155	EU CRA
Legal nature	Type-approval regulation (1958 Agreement, via EU GSR)	Horizontal product regulation
Object	Vehicle type + the CSMS	Products with digital elements
Route to market	Certificate of Compliance for CSMS (3 years) + per-type approval	Conformity assessment before placing on market
Enforcement	Approval authority / technical service	Market surveillance authorities
Vulnerability handling	Required within the CSMS	Required, with active reporting duties
SBOM	Not named explicitly	Explicit expectation
Incident reporting	Post-production monitoring, no fixed clock	Fixed reporting windows once obligations apply

The practical reading: if you already run a mature CSMS to R155, much of the CRA's vulnerability-handling and disclosure machinery will feel familiar. What is genuinely new is the active reporting clock and the explicit SBOM discipline, both of which demand tooling and rehearsed process rather than good intentions.

What is new for an automotive supplier

Three shifts matter most for a Tier-1 or a connected-product vendor.

First, scope by product, not by vehicle. R155 thinks in vehicle types. The CRA thinks in products with digital elements. A telematics unit, a companion app, a charging controller or a diagnostics tool may each be a CRA product in its own right, with its own conformity obligations, even where the whole vehicle is governed elsewhere.

Second, the SBOM stops being optional. You cannot report on, or patch, components you have not inventoried. The CRA turns component transparency into a compliance artefact, which in turn pulls on your supply-chain flow-down: a component you cannot see in a supplier's bill of materials is a component you cannot defend.

Third, the reporting duty is active, not passive. Under the CRA a manufacturer must notify authorities of actively exploited vulnerabilities and severe incidents on a defined timeline once those duties commence. That is an operational capability — detection, triage, decision, notification — closer to a security operations function than to a documentation exercise.

Timing, in brief

The CRA entered into force in December 2024, but its duties phase in. The vulnerability and incident reporting obligations apply from 11 September 2026; the main body of obligations applies from 11 December 2027. Programmes should plan against those two dates rather than treating the CRA as immediately binding in full. The dated detail is set out in the EU CRA timeline.

How to approach it

Do not build a parallel CRA programme bolted onto the side of your R155 work. The overlap is large enough that a single, well-run vulnerability-handling and software-transparency capability can feed both. Start from the SBOM, wire it into a vulnerability-handling process with a coordinated disclosure policy, rehearse the reporting path, and keep the evidence in a form an assessor or a market-surveillance authority can open. Where a product's CRA status is genuinely uncertain, document the reasoning rather than assuming the exemption.

The AutoSifu view

We treat the CRA and R155 as one engineering problem, not two compliance silos. Through CIRT we run a single route — compliance, solutioning, and CoC/VTA support — so the SBOM, the vulnerability-handling process and the disclosure policy are built once and serve both regimes, with the approval body in the room while decisions are made. For an Indian supplier exporting into the EU, that is the difference between two overlapping audits and one coherent capability.