What Article 2(2)(c) actually excludes
Article 2(1) brings in products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 2(2) then switches the CRA off for products to which certain other Union acts apply — including, at (c), Regulation (EU) 2019/2144 on type-approval requirements for motor vehicles and their trailers, and systems, components and separate technical units intended for such vehicles, as regards their general safety and the protection of vehicle occupants and vulnerable road users.
Regulation (EU) 2019/2144 itself applies to vehicles of categories M, N and O (as defined in Regulation (EU) 2018/858) and to systems, components and separate technical units designed and constructed for such vehicles. Commission FAQ 1.9 asks whether products covered by other Union legislation are exempted from the CRA and answers with that list — MDR/IVDR, 2019/2144 motor vehicles, aviation products certified under Regulation (EU) 2018/1139, marine equipment under Directive 2014/90/EU, plus Delegated Regulation (EU) 2025/1535 for most products under Regulation (EU) No 168/2013. For automotive and type-approval teams, the operational consequence for reporting is simple: no CRA application → no Article 14 manufacturer duty for that product.
Article 14 only runs inside CRA scope
Article 14 obliges manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product with digital elements — early warning within 24 hours of becoming aware, fuller notification within 72 hours, then the final report on its own trigger — through ENISA's Single Reporting Platform. Those clocks presuppose a product that is in CRA scope. A product to which Regulation (EU) 2019/2144 applies is not that product for CRA purposes. Do not open an SRP case “just in case” for an excluded type-approved unit and treat it as a substitute for type-approval / UN R155–R156 processes; the recipients and legal bases differ.
If you also place non-excluded products (or you are unsure which SKUs sit under 2019/2144), keep the Article 14 reporting deadlines and becoming-aware rules ready for the in-scope lines. Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)).
The aftermarket, charger and backend traps
Teams often assume “we are an automotive company, so CRA never applies.” Article 2(2)(c) follows the Union act that applies to the product, not the OEM letterhead. A type-approved vehicle ECU inside Regulation (EU) 2019/2144 is typically out of the CRA. A consumer OBD dongle, workshop diagnostic laptop appliance, AC wallbox with cloud connectivity, aftermarket telematics box or fleet gateway placed on the market outside that type-approval coverage is not out on that ground. A mobile companion app or OTA / telematics backend that the shipped product needs may still meet remote data processing under Article 3(2) even when the type-approved vehicle beside it is excluded.
Inventory each marketed item: type-approval / STU certificate scope, intended purpose, and whether the software or accessory is placed separately. White-label or dealer branding does not by itself create a 2019/2144 exclusion — see who is the manufacturer for brand-under-name lines that are still CRA products.
L-category vehicles and the pedal exception
FAQ 1.9 also points to Delegated Regulation (EU) 2025/1535, which excludes from the CRA products with digital elements that fall within Regulation (EU) No 168/2013 on the approval and market surveillance of two- or three-wheel vehicles and quadricycles — with the exception of L1e category vehicles designed to pedal. Most mopeds, scooters and similar L-category products under 168/2013 are therefore out of CRA (and out of Article 14) on that delegated basis. An L1e pedal-designed vehicle is not carved out by that delegated act and can still be a CRA product with digital elements if Article 2(1) is met — so the Article 14 clock can still start for those lines.
Type-approval cybersecurity is not Article 14
Excluded motor-vehicle products still sit under their sectoral type-approval and cybersecurity management frameworks (including the UN R155 / R156 stack that Regulation (EU) 2019/2144 implements for the Union). Those filings and management-system duties go through the type-approval authorities and processes those acts require — not through the CRA Single Reporting Platform to a coordinating CSIRT and ENISA under Article 14. Keep CRA tooling for in-scope aftermarket and accessory lines; keep type-approval procedures for units inside 2019/2144 (and the 168/2013 carve-out where it applies).
Personal data in a connected-vehicle or fleet incident can still raise GDPR duties for whoever is the controller — CRA vs GDPR — and some manufacturers also sit in NIS2 sectors (CRA vs NIS2). Those regimes do not reopen CRA Article 14 for an Article 2(2)(c)-excluded product. For the parallel MDR/IVDR, aviation and marine exclusion patterns, see Article 14 for medical devices, Article 14 for aviation and drones and Article 14 for marine equipment.
Questions people ask
- Do motor vehicles have a CRA Article 14 reporting duty?
- Not when Regulation (EU) 2019/2144 applies to that product with digital elements. Article 2(2)(c) excludes those products from the CRA entirely. Commission FAQ 1.9 repeats the same exclusion. No CRA scope means no Article 14 early warning, 72-hour notification or final report through ENISA’s Single Reporting Platform for that type-approved vehicle, system, component or separate technical unit.
- Is there a blanket “automotive industry” CRA exemption?
- No. Article 2(2)(c) follows whether Regulation (EU) 2019/2144 applies to the product, not whether your company builds cars. Workshop diagnostic tools, OBD dongles, EV wallboxes, aftermarket telematics, fleet hardware, separately placed apps and manufacturer backends that meet the remote data processing test can still be CRA products with digital elements — with Article 14 live from 11 September 2026 when the usual scope tests are met.
- What about scooters, motorbikes and e-bikes under Regulation 168/2013?
- Delegated Regulation (EU) 2025/1535 (FAQ 1.9) excludes from the CRA most products that fall within Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles — with an explicit exception for L1e category vehicles designed to pedal. Those L1e pedal-designed products stay capable of CRA scope (and Article 14) if they otherwise meet Article 2(1). Map the approval category before you assume every light vehicle is out.
- If the vehicle is out of CRA, what cybersecurity reporting still applies?
- Type-approval and UN Regulation Nos 155/156 cybersecurity management and software-update frameworks remain for products inside that regime. Those channels are not ENISA CRA Single Reporting Platform filings under Article 14. Matching words like “incident” or “vulnerability” across regimes does not merge the clocks. Confirm live type-approval duties with counsel for your type and market.
- Does GDPR or NIS2 reopen Article 14 for an excluded vehicle?
- No for CRA scope. FAQ 1.9 / Article 2(2)(c) decide whether the CRA (including Article 14) applies to the product. Personal-data breach duties under GDPR and entity-level incident duties under NIS2 are separate regimes — they can still apply to the organisation even when the type-approved vehicle unit itself is outside the CRA. See our CRA vs GDPR and CRA vs NIS2 guides for the no-substitution framing.
- What about medical devices, aviation or marine equipment?
- FAQ 1.9 lists further CRA exclusions: MDR/IVDR (Article 2(2)(a)–(b)), products certified under Regulation (EU) 2018/1139 (civil aviation), and equipment in Directive 2014/90/EU (marine). Same logic: if the CRA does not apply, Article 14 does not either. See our medical-devices, aviation-and-drones and marine-equipment guides for those stacks; this page focuses on the motor-vehicle / L-category question manufacturers search for most often in the automotive stack.

