CRA & automotive: the delineation

If you make or import telematics dongles, aftermarket infotainment, dashcams, OBD diagnostic tools or app-controlled vehicle accessories, you know the uncertainty: "Automotive is covered by type approval - the Cyber Resilience Act doesn't apply to us." This is a misconception. It is half right.

What is true: exempt are products to which Type-Approval Regulation (EU) 2019/2144 applies (Article 2(2)(c)). It covers vehicles and systems, components and separate technical units designed and constructed for them; cybersecurity there runs through UNECE R155 (cyber security management system) and R156 (software update management). The CRA deliberately defers to this lex specialis. What is wrong is the generalisation that "everything around the car" is therefore exempt. The exemption depends on the product, not on the sector.

That is exactly where the real pain sits: an OBD dongle with cellular, a connected dashcam or a charging adapter with a companion app is not approved together with the vehicle. Whether a retrofit or accessory part nevertheless falls under Regulation (EU) 2019/2144 is a question of interpretation; for products not designed for vehicles or working independently alongside them, such as dashcams or workshop tools, there is much to suggest the CRA applies. In that case the product is a standalone product with digital elements (PDE) - a classic CRA candidate. Those who feel "safe" behind R155 overlook that, as manufacturer of an aftermarket product, they may carry the full horizontal obligation set. This article traces the line. (It is a schematic classification, not individual legal advice.)

Where the line runs: type-approval framework vs. aftermarket/accessory

The core question is: "Does Type-Approval Regulation (EU) 2019/2144 apply to this product?" Whether it "has to do with cars" decides nothing. If the answer is "no", the CRA scope opens up, provided the product contains digital elements and is made available on the market.

• Schematically exempt (type-approval framework): vehicles and systems and components designed for them, such as factory-fitted infotainment, ECUs in the OEM vehicle, integrated telematics units.
• Question of interpretation: retrofit and accessory parts designed for vehicles, such as retrofit OBD/telematics dongles, aftermarket head units or app-paired charging adapters.
• Schematically CRA-relevant: products not designed for vehicles or working independently alongside them, such as connected dashcams, diagnostic and workshop tools, connected EV charging equipment and accessory apps.

A borderline case remains the supplier: if you supply a component designed for vehicles that falls under Regulation (EU) 2019/2144, it is exempt. If you additionally market the same technology as a standalone, general-purpose product, the CRA may apply to that variant. Same hardware, two regimes - depending on the product you place on the market.

Typical PDE products and their likely Annex III class

Aftermarket electronics that fall under the CRA and have no Annex III function are CRA standard products: the manufacturer self-assesses conformity via Module A (internal control), without a notified body. A higher classification only applies if a product's core function corresponds to an Annex III category (Article 7(1)). The table below is schematic orientation, not a binding case-by-case assignment.

Rule of thumb: connectivity alone does not make a product "important". Only a core function from Annex III (VPN, router, PKI, password manager, etc.) lifts it into Class I. Class II (Module B+C, Module H or a European scheme of at least “substantial”) concerns products whose core function is a class II category, for example a tamper-resistant microcontroller you place on the market yourself as a component. Such a component inside your own device does not raise the device's classification. The technical descriptions of the important/critical categories are set out in Implementing Regulation (EU) 2025/2392.

Sector standards and delineation from neighbouring regimes

For the type-approved vehicle, ISO/SAE 21434 (automotive cybersecurity engineering) and UNECE R155/R156 apply within the EU type-approval framework. For CRA-covered retrofit/accessory products, by contrast, the horizontal Annex I duties apply (security-by-design/default, vulnerability handling, SBOM, update capability). Both worlds can coexist in the same company.

• Type-Approval Regulation (EU) 2019/2144 (with UNECE R155/R156): applies to vehicles and to systems, components and separate technical units designed for them - exempt from the CRA (Article 2(2)(c)).
• RED Delegated Regulation 2022/30: cybersecurity of certain radio equipment, in particular equipment that can communicate over the internet; for radio-based products there may be overlaps that must be delineated cleanly. The regulation is repealed with effect from 11 Dec 2027; from then on the CRA covers these requirements.
• NIS2: addresses essential and important entities - not the product cybersecurity of the manufacturer. A fleet operator may be subject to NIS2 while its dongle supplier is subject to the CRA. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. Separate legal acts.
• AI Act: applies in addition to the CRA as soon as a product contains an AI system within the meaning of the AI Regulation (e.g. driver-assistance image analysis as a standalone product); the scope of duties depends on the risk level.

SBOM and supply-chain reality in the aftermarket

Aftermarket electronics use almost the same software stack as consumer IoT: embedded Linux or an RTOS, a BLE/Wi-Fi/cellular stack, MQTT/TLS libraries, a cloud backend and a companion app. Check these components in automotive accessories for maintenance gaps: outdated OpenSSL versions, end-of-life chipset SDKs, unpatched OSS dependencies. This is where the pressure to act sits.

The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. Component name, version, unique identifier and supplier are useful in practice. There is no general publication obligation - the SBOM must be provided to market surveillance on reasoned request. In practice the SBOM is the supply chain's early-warning system: only when you know which Log4j/OpenSSL sits in which firmware can you react to a new CVE at all.

Reporting capability and PSIRT: the Article 14 cascade, correctly

Since 11 September 2026 the reporting obligations under Article 14 have applied. For actively exploited vulnerabilities and severe incidents a staged cascade runs - the shorthand "24h/72h/14 days" is incomplete:

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware.
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
• 14 days - final report for an actively exploited vulnerability, counted from availability of a corrective or mitigating measure.
• 1 month - final report for a severe incident, counted from the 72-hour notification.

Reporting goes via the single reporting platform, which ENISA sets up and operates under Art. 16 CRA, through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. For an accessory manufacturer this means: you need a working product security process (PSIRT) with an intake channel, triage, a deadline clock and a coordinated vulnerability disclosure (CVD) policy across the entire support period - as a rule at least five years, shorter only where the expected period of use is shorter (Article 13(8)).

Deadlines: what applies first

Two dates count for aftermarket manufacturers, and they do not coincide:

• 11 September 2026 - reporting obligations (Art. 14). The first hard manufacturer obligation. Since then you must be able to report: PSIRT, contact channel, connection to the single reporting platform, deadline process.
• 11 December 2027 - full applicability of all product requirements. From here new products must be CE-conform: security-by-design, SBOM, risk assessment, technical documentation, EU declaration of conformity.

First in practice: reporting capability. It already applies and needs organisational lead time. Building the technical documentation and SBOM runs in parallel but must be in place by 11 December 2027. (Retention of technical documentation: at least ten years after placing on the market or for the longer support period, Article 13(13).)

Worked scenario: the OBD telematics dongle

A mid-sized provider sells a retrofit OBD telematics dongle: cellular module, GPS, BLE pairing to a driver app, cloud backend for logbook and diagnostics. The dongle is not approved together with the vehicle - it is sold independently and plugged in by the end customer.

Schematically worked through: whether the dongle, as a component designed for vehicles, falls under Regulation (EU) 2019/2144 is a question of interpretation that the provider settles; as a precaution it plans for the CRA. In that case the product would be a PDE. Annex III check: no core function such as VPN/router → likely a standard product, conformity via Module A. To-dos: SBOM of the firmware stack (embedded Linux, cellular SDK, TLS library) in CycloneDX 1.6; risk assessment/threat modelling for the cellular, BLE, app and backend attack surfaces; secure OTA updates across the support period; PSIRT with intake channel and Art. 14 deadline clock; technical documentation plus EU declaration of conformity and CE marking. Outcome: if the Type-Approval Regulation does not apply, he carries the manufacturer duties of the CRA; R155 does not replace them.

What Blackfort Technology does for you

Blackfort Technology supports aftermarket and accessory manufacturers exactly at this line - schematically, manufacturer-oriented, without individual legal advice:

• Scope and applicability analysis: a technical assessment of which of your products fall under type approval and which may fall under the CRA as a standalone PDE - including supplier borderline cases, for review by your legal department.
• SBOM setup: building machine-readable bills of materials, for example in CycloneDX or SPDX, for your firmware and app stacks, EOL/OSS risk screening.
• PSIRT & CVD: building a product security process with an Art. 14-compliant deadline cascade and connection to the single reporting platform.
• Risk assessment & threat modelling: documented Annex I risk analysis for connectivity, app and backend.
• Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity.

Start with the applicability check, read the basics in the CRA overview, and for smaller teams the SME notes. Specific questions about your accessory product? Contact us.