Vehicle software now sits under three overlapping regimes plus type approval. What each one asks, what transfers between them, and where the CRA carve-out ends.
---
The short answer
The automotive industry has the most mature cybersecurity type approval regime in the world, and it does not cover everything the EU now requires.
UNECE R155 CSMS — cyber security management system, type approval
UNECE R156 SUMS — software update management system, type approval
EU 2019/2144 General Safety Regulation, makes R155/R156 mandatory in the EU
CRA products with digital elements, market surveillance
RED 3(3) radio equipment, applicable since 1 August 2025The instinct across the industry is that R155 and R156 discharge the rest. That instinct is right about the vehicle and wrong about almost everything else the industry sells.
---
Where R155 and R156 actually apply
They apply to vehicle type approval. Their scope is the vehicle as a type, and the manufacturer's management systems behind it.
R155 requires the manufacturer to hold a cyber security management system for which the approval authority has issued a certificate of compliance, covering risk assessment across the vehicle lifecycle, supplier management, and monitoring of the vehicle fleet in the field.
R156 requires a software update management system: configuration control, update integrity, and — the demanding part — the ability to demonstrate that an update does not invalidate the type approval.
These are strong regimes. A manufacturer with a working CSMS holds most of the substance the CRA asks for. The question is not quality; it is boundaries.
---
Where the boundary actually falls
Type approval covers the vehicle. It does not cover everything a vehicle manufacturer or its suppliers place on the market.
in the vehicle type approval the vehicle, its ECUs as approved
outside it, and in CRA scope the companion mobile application
the fleet management portal
the aftermarket telematics unit
the diagnostic tool sold to workshops
the charging accessory
the developer SDK given to integratorsEvery item in the second column is a product with digital elements placed on the EU market, and none of them is inside the vehicle's type approval.
The companion app is the clearest case and the most commonly missed. It is downloaded by consumers, it authenticates to the vehicle, it holds personal data, and it is not a vehicle. It sits squarely in CRA scope on its own terms.
---
RED 3(3), which arrived a year ago
A modern vehicle is radio equipment several times over: cellular modem, Wi-Fi, Bluetooth, tyre pressure sensors, keyless entry.
RED Article 3(3) points (d), (e) and (f) have applied since 1 August 2025 — network protection, personal data safeguards, and protection against fraud.
Keyless entry systems are the uncomfortable case. Relay attacks against them are well documented and long-standing. Point (f), protection against fraud, is not an abstract requirement here — it names a failure mode the industry has lived with for a decade.
And the harmonised standards EN 18031 were cited with restrictions, meaning conformity via the standard is not automatically sufficient for the restricted clauses. A supplier who answered "we follow EN 18031" has not necessarily closed the requirement.
---
What genuinely transfers between the regimes
This is the useful part, and there is a lot of it.
The risk assessment. R155 requires threat analysis and risk assessment across the lifecycle. That artefact answers CRA Annex I Part I risk assessment obligations for the same components, and feeds the RED 3(3) analysis.
Supplier management. R155 already requires the manufacturer to manage supplier cybersecurity. This is substantively what NIS2 Article 21(2)(d) asks of regulated buyers and what CRA supply chain expectations assume.
The update mechanism. R156 requires update integrity and rollback control. CRA Annex I requires secure update delivery. One mechanism, correctly documented, answers both.
Field monitoring. R155 requires monitoring vehicles in service. That is post-market surveillance under the CRA, under a different name.
A manufacturer with a mature CSMS is much closer to CRA readiness than to zero. The work is mapping and documenting the boundary, not rebuilding.
---
Where it stops, and these are the expensive ones
1. The 24-hour reporting clock has no type approval equivalent
CRA Article 14 requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability, from 11 September 2026.
R155 requires monitoring and response. It does not impose a 24-hour notification to an EU authority. This is a genuinely new obligation with a new recipient, a new clock, and a new decision-rights problem — and automotive incident processes are typically built around type approval authorities and product safety recall paths, not around a same-day cyber notification.
2. The SBOM, at supplier depth
The CRA requires component identification in machine-readable form, covering at least top-level dependencies.
Automotive supply chains are unusually deep: OEM, tier 1, tier 2, silicon vendor, and the open source inside each. A top-level SBOM listing "tier 1 module 3.4" answers nothing when the vulnerability is in a TLS library four levels down.
The question you will be asked is: which shipped vehicle software versions contain the affected component? Only an archive of per-version SBOMs answers it, and only if suppliers provided theirs.
3. The support period, over an automotive lifetime
The CRA requires a support period reflecting the expected product lifetime. For vehicles this is a decade or more in production and longer in the field.
Technical documentation must be retained for ten years after placing on the market, or the support period, whichever is longer. For a model launched in 2027 and supported for fifteen years, that is an obligation running into the 2050s — declared at placement, decided now.
4. Aftermarket and independent operators
Diagnostic tools, telematics dongles and workshop equipment reach the EU market outside vehicle type approval, from companies that have often never engaged with automotive regulation at all.
These are products with digital elements, and their manufacturers carry full CRA obligations.
---
What this means for a tier 1 supplier specifically
Your OEM customers cannot meet their obligations without evidence from you, and they now have a regulatory reason to ask rather than a commercial preference.
per-release SBOM, archived which versions are affected
published disclosure policy verifiable from outside, in ten seconds
stated support period they cannot declare theirs until you declare yours
dated CRA classification per product line, with reasoningThe support period is the item most likely to be missing today, and it is the one that blocks your customer. It is not a technical decision — it is a commercial commitment with a fifteen-year tail, and it usually has no owner.
There is a window here. Suppliers who can produce this evidence become easier to design in. In two years it will be table stakes and its absence will simply be disqualifying.
---
Six decisions worth making this quarter
- 1Draw the boundary explicitly. List every product you place on the EU market that is not inside a vehicle type approval. The list is longer than expected, every time.
- 2Map your CSMS artefacts to CRA Annex I. Most of the substance exists; the mapping is the deliverable.
- 3Check your EN 18031 reliance against the published restrictions, particularly on keyless entry and telematics.
- 4Build the 24-hour path, with a named person who can notify without convening a committee.
- 5Push SBOM depth down the supply chain, per release, archived — not on request.
- 6Decide and declare support periods. Your customers are blocked until you do.
---
Check what reaches your product line — free, no account
- [Free readiness assessment](/assess) — which regimes apply, and to which of your products
- [Compliance responsibility mapper](/resources/responsibility-mapper) — a RACI by role
- [Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover
---
Further reading
→ Products with digital elements, defined → How to build an SBOM → CRA Article 14 incident reporting → Important versus critical under the CRA → Audit-ready evidence for the CRA → One evidence set across five EU regulations
---
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Type approval scope, CRA applicability and the boundary between them are determinations on the facts of specific products. Verify against the current texts and consult your competent authority, your type approval authority, or a qualified adviser.*