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 the most common misconception in the supplier and aftermarket sector. It is half right — and expensive in the other half.

What is true: the type-approved complete vehicle is exempt from the CRA. Its cybersecurity runs through the sectoral EU type-approval framework with 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 is product-based, not sector-based: it applies only to what is part of the type approval — not to what someone plugs in, attaches or pairs via app afterwards.

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 part of the vehicle type approval. It 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 draws the line cleanly. (It is a schematic classification, not individual legal advice.)

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

The decisive question is never "Is it about cars?" but "Is this product part of the vehicle type approval?". If the answer is "no", the CRA scope usually opens up, provided the product contains digital elements and is placed on the market independently.

• Typically exempt (type approval): factory-fitted infotainment, ECUs in the OEM vehicle, integrated telematics units that are part of the approved vehicle.
• Typically CRA-relevant (aftermarket/accessory): retrofit OBD/telematics dongles, aftermarket infotainment and head units, connected dashcams, diagnostic and workshop tools, app-paired charging adapters, connected EV charging equipment, accessory apps.

A borderline case remains the supplier: if you supply a component that the OEM integrates into the type approval, it is covered via the vehicle. If you additionally market the same technology as a standalone retrofit product, the CRA may apply to that variant. Same hardware, two regimes — depending on how it is placed on the market.

Typical PDE products and their likely Annex III class

Most aftermarket electronics 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 performs an Annex III security function. 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 specific security/network function (VPN, router, PKI, password manager, etc.) lifts it into Class I. Class II (always a notified body) rarely affects aftermarket products — e.g. tamper-resistant microcontrollers in security modules. 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 (R155/R156): applies to the vehicle and its type-approved parts — exempt from the CRA.
• RED Delegated Regulation 2022/30: radio equipment cybersecurity; for radio-based products there may be overlaps that must be delineated cleanly.
• NIS2: addresses operators of essential/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. Separate legal acts.
• AI Act: relevant only where a product contains an AI system within the meaning of the AI Regulation (e.g. driver-assistance image analysis as a standalone product) — it complements, but does not replace, the CRA.

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. In automotive accessories these components are often maintained worse than in classic IT — outdated OpenSSL versions, end-of-life chipset SDKs, unpatched OSS dependencies. This is exactly where CRA pressure is highest.

The CRA requires a machine-readable SBOM as part of the technical documentation — at least the top-level dependencies. In concrete terms, per BSI TR-03183-2 (v2.1.0): format CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1, with component name, version, unique identifier and supplier. There is no general publication obligation — the SBOM is provided to authorities/notified bodies. 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

From 11 September 2026 the reporting obligations under Article 14 apply. For actively exploited vulnerabilities and severe incidents a staged cascade runs — the common shorthand "24h/72h/14 days" is incomplete:

• 24 hours — early warning from becoming aware.
• 72 hours — full notification including corrective/mitigating measures.
• 14 days — final report for an actively exploited vulnerability, counted from availability of a corrective measure.
• 1 month — final report for a severe security incident, counted from the 72-hour notification.

Reporting goes via the ENISA Single Reporting Platform (SRP), to be made available by 11 September 2026; from there the single notification is routed to the CSIRT of the main establishment and ENISA. 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 — a guideline of at least five years or the expected product lifetime.

Deadlines: what applies first

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

• 11 September 2026 — reporting obligations (Art. 14). The first hard manufacturer obligation. From here you must be able to report: PSIRT, contact channel, SRP connection, 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 is the shorter deadline and needs the most organisational lead time. Building the technical documentation and SBOM runs in parallel but must be in place by 11 December 2027. (Retention period for technical documentation: 10 years after placing on the market.)

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 part of the vehicle type approval — it is sold independently and plugged in by the end customer.

Schematically worked through: the product would be a PDE and thus likely CRA-covered. Annex III check: no core security 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: R155 does not help him — he carries the full CRA manufacturer burden.

What Blackfort Technology does for you

Blackfort Technology UG (haftungsbeschränkt) supports aftermarket and accessory manufacturers exactly at this line — schematically, manufacturer-oriented, without individual legal advice:

• Scope and applicability analysis: which of your products fall under type approval and which may fall under the CRA as a standalone PDE — including supplier borderline cases.
• SBOM setup: building machine-readable bills of materials (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) 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 SRP connection.
• Risk assessment & threat modelling: documented Annex I risk analysis for connectivity, app and backend.
• Technical documentation: building the documentation structure 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.