CRA vs UN R155: overlap, gaps and double duty for Indian exporters
Where the CRA and UN R155 overlap, where they do not, and what an exporter to the EU must do about both
Two regimes, one export programme
An Indian OEM or Tier-1 shipping into the EU now carries two files. The UN R155 cyber security regulation governs vehicle type approval; the EU Cyber Resilience Act — Regulation (EU) 2024/2847 — governs products with digital elements as a horizontal law. They are not the same instrument, they do not enforce the same way, and one does not discharge the other. But they overlap enough that treating them as unrelated is wasteful, and treating them as identical is wrong.
This piece sets out where they align, where they diverge, and what the exporter actually has to do about both. For the CRA on its own terms, start with the EU CRA for automotive; for R155 on its own terms, UN R155 explained.
The clause-level comparison
| Dimension | UN R155 | EU CRA (2024/2847) |
|---|---|---|
| Type of instrument | Type-approval regulation under the 1958 Agreement | Horizontal product regulation |
| What it regulates | The vehicle type and the manufacturer's CSMS | Any product with digital elements |
| Route to market | CoC for the CSMS (valid 3 years) + per-vehicle-type approval | Conformity assessment before placing on the market |
| Who checks | Approval authority / technical service | Market-surveillance authorities |
| Vulnerability handling | Required inside the CSMS | Required, with active reporting duties |
| SBOM | Not named explicitly | Explicit expectation |
| Coordinated disclosure | Implied by monitoring duties | Named obligation with a disclosure policy |
| Incident/vulnerability reporting | Post-production monitoring; no fixed statutory clock | Fixed windows from 11 September 2026 |
| Full application | EU: new types 6 Jul 2022, all vehicles 7 Jul 2024 | Main obligations from 11 December 2027 |
| Geographic reach | UNECE Contracting Parties | EU market, including importers of non-EU products |
Where they overlap
The honest overlap is on vulnerability handling and software transparency. A CSMS built to R155 already has to identify, assess and treat vulnerabilities across development, production and post-production, and it already leans on ISO/SAE 21434 for the engineering substance. The CRA asks for the same discipline in horizontal-product language. If your vulnerability-handling process is real — not just documented — you have most of the machinery the CRA wants.
Software transparency is the second overlap. R155 ties software configuration to the type approval through RxSWIN; the CRA formalises component transparency through the SBOM. Different mechanisms, same underlying demand: you must know what software is in your product.
Where they genuinely differ
Three differences carry real work.
Object of regulation. R155 regulates the vehicle type and the CSMS behind it. The CRA regulates products with digital elements. A connected component, a companion app or a diagnostics tool can be a CRA product in its own right even where the whole vehicle is homologated under R155. The interaction between whole-vehicle homologation and the CRA is nuanced and still being interpreted — so the scope question is answered product by product, not by a blanket exemption.
The reporting clock. R155's post-production monitoring has no fixed statutory notification window. The CRA imposes active reporting of exploited vulnerabilities and severe incidents on a defined timeline. That is an operational capability — detection, triage, decision, notify — not a documentation task.
Enforcement mode. R155 gates market access through type approval up front. The CRA runs through market surveillance across the product's supported lifetime, so a problem can surface at any point after placement, not only at homologation.
A worked example
Take a connected telematics unit built by an Indian Tier-1 and fitted to a vehicle homologated in the EU. Under R155 the unit's cybersecurity is assessed as part of the vehicle type and the OEM's CSMS: the supplier flows evidence up, the OEM carries the approval, and the RxSWIN ties the unit's regulation-relevant software to the type approval. That is a bounded, up-front exercise tied to homologation.
The CRA looks at the same unit differently. If that telematics unit — or a companion app, or a diagnostics tool sold around it — is a product with digital elements placed on the EU market in its own right, the supplier may carry CRA obligations directly: an SBOM for the unit, a vulnerability-handling process, a disclosure policy, and the reporting duty. The same component sits inside two frames at once, assessed one way for homologation and another way as a product. The supplier who assumes the R155 evidence closes out the CRA obligation has misread the boundary.
The honest position is that this boundary is still being interpreted, and the whole homologated vehicle is not the CRA's principal target. But the components and software around it are where the double duty genuinely lands, and that is precisely where an Indian exporter's products tend to sit.
What the exporter has to do
Do not build two programmes. Build one capability that satisfies both:
- Maintain a single SBOM per product and wire it into vulnerability management. It serves the CRA directly and strengthens your R155 supply-chain flow-down.
- Run one vulnerability-handling process with a coordinated disclosure policy, feeding both the CSMS and the CRA duties.
- Rehearse the CRA reporting path against the 11 September 2026 date, because that clock has no R155 equivalent to lean on.
- Assess CRA scope product by product, and document the reasoning where a product's status is uncertain rather than assuming it out.
The AutoSifu view
We carry both files as one route. Through CIRT we run compliance, solutioning and CoC/VTA support together, so the SBOM, the vulnerability-handling process and the disclosure policy are engineered once and satisfy R155 and the CRA at the same time — with the approval body in the room while the scope calls are made. For an Indian exporter that turns two overlapping regimes into one coherent programme instead of two audits.
Questions
- Does UN R155 satisfy the EU CRA?
- No. UN R155 is a vehicle type-approval regulation and the CRA is a horizontal product law; passing one does not discharge the other. They overlap on vulnerability handling and software transparency, but the CRA adds active reporting duties and applies to products with digital elements beyond the homologated vehicle. A supplier cannot assume an R155 approval closes out CRA obligations.
- Do vehicles need both CRA and R155?
- Vehicle type-approval cybersecurity in the EU runs through UN R155 via the General Safety Regulation, and the CRA is a horizontal product regulation whose interaction with vehicle homologation is still being interpreted. The whole homologated vehicle is not the CRA's principal target, but connected components, aftermarket products and companion software around the vehicle can fall under the CRA in their own right. The honest position is that the boundary is nuanced and should be assessed product by product.
- What does the CRA add over R155?
- The CRA adds an explicit software bill of materials expectation, active reporting of exploited vulnerabilities and severe incidents on a fixed clock, and coordinated disclosure as a named obligation. It also enforces through market surveillance rather than type approval, so obligations persist across the supported lifetime of the product. Much of the vulnerability-handling substance will feel familiar to a mature CSMS, but the reporting clock and SBOM discipline are genuinely new.