CRA & Automotive: die Abgrenzung

Wenn Sie Telematik-Dongles, Aftermarket-Infotainment, Dashcams, OBD-Diagnosetools oder App-gesteuertes Fahrzeugzubehör herstellen oder importieren, kennen Sie die Verunsicherung: „Automotive ist doch über die Typgenehmigung geregelt - der Cyber Resilience Act betrifft uns nicht." Das ist eine Fehlannahme. Sie ist zur Hälfte richtig.

Richtig ist: Ausgenommen sind Produkte, auf die die Typgenehmigungsverordnung (EU) 2019/2144 Anwendung findet (Art. 2 Abs. 2 Buchst. c). Sie gilt für Fahrzeuge und für Systeme, Bauteile und selbstständige technische Einheiten, die für sie konstruiert und gebaut werden; die Cybersicherheit läuft dort über UNECE R155 (Cyber Security Management System) und R156 (Software-Update-Management). Der CRA weicht bewusst dieser lex specialis. Falsch ist die Verallgemeinerung, dass damit „alles rund ums Auto" ausgenommen sei. Die Ausnahme hängt am Produkt, nicht an der Branche.

Genau dort liegt der reale Schmerz: Ein OBD-Dongle mit Mobilfunk, eine vernetzte Dashcam oder ein Ladeadapter mit Companion-App wird nicht mit dem Fahrzeug genehmigt. Ob ein Nachrüst- oder Zubehörteil dennoch unter die Verordnung (EU) 2019/2144 fällt, ist eine Auslegungsfrage; für Produkte, die nicht für Fahrzeuge konstruiert sind oder eigenständig neben dem Fahrzeug arbeiten, etwa Dashcams oder Werkstatt-Tools, spricht viel für den CRA. Dann ist das Produkt ein eigenständiges Produkt mit digitalen Elementen (PDE) - und ein klassischer CRA-Kandidat. Wer sich hinter R155 „sicher wähnt", übersieht, dass er als Hersteller eines Aftermarket-Produkts die volle horizontale Pflichtenlast tragen kann. Dieser Beitrag zeichnet die Trennlinie nach. (Er ist eine schematische Einordnung, keine Rechtsberatung im Einzelfall.)

Wo die Grenze verläuft: Typgenehmigungsrahmen vs. Aftermarket/Zubehör

Die Kernfrage lautet: „Findet die Typgenehmigungsverordnung (EU) 2019/2144 auf dieses Produkt Anwendung?" Ob es „mit Autos zu tun hat", entscheidet nichts. Fällt die Antwort auf „nein", öffnet sich der CRA-Anwendungsbereich, sofern das Produkt digitale Elemente enthält und auf dem Markt bereitgestellt wird.

• Schematisch ausgenommen (Typgenehmigungsrahmen): Fahrzeuge und für sie konstruierte Systeme und Bauteile, etwa werkseitig verbautes Infotainment, Steuergeräte (ECUs) im OEM-Fahrzeug, integrierte Telematikeinheiten.
• Auslegungsfrage: Nachrüst- und Zubehörteile, die für Fahrzeuge konstruiert sind, etwa nachrüstbare OBD-/Telematik-Dongles, Aftermarket-Head-Units oder App-gekoppelte Ladeadapter.
• Schematisch CRA-relevant: Produkte, die nicht für Fahrzeuge konstruiert sind oder eigenständig neben dem Fahrzeug arbeiten, etwa vernetzte Dashcams, Diagnose- und Werkstatt-Tools, EV-Ladeequipment mit Konnektivität und Zubehör-Apps.

Ein Grenzfall bleibt der Zulieferer: Liefern Sie eine Komponente, die für Fahrzeuge konstruiert ist und unter die Verordnung (EU) 2019/2144 fällt, ist sie ausgenommen. Vermarkten Sie dieselbe Technik zusätzlich als eigenständiges, allgemein verwendbares Produkt, kann für diese Variante der CRA greifen. Dieselbe Hardware, zwei Regime - abhängig vom Produkt, das Sie in Verkehr bringen.

Typische PDE-Produkte und ihre wahrscheinliche Anhang-III-Klasse

Aftermarket-Elektronikprodukte, die unter den CRA fallen und keine Anhang-III-Funktion haben, sind CRA-Standardprodukte: Der Hersteller bewertet die Konformität selbst über Modul A (interne Kontrolle), ohne notifizierte Stelle. Eine höhere Einstufung greift nur, wenn die Kernfunktion eines Produkts einer Kategorie nach Anhang III entspricht (Art. 7 Abs. 1). Die folgende Tabelle ist eine schematische Orientierung, keine verbindliche Einzelfallzuordnung.

Faustregel: Konnektivität allein macht ein Produkt noch nicht „wichtig". Erst eine Kernfunktion aus Anhang III (VPN, Router, PKI, Passwort-Manager u. a.) hebt es in Klasse I. Klasse II (Modul B+C, Modul H oder ein europäisches Schema mindestens „mittel“) betrifft Produkte, deren Kernfunktion eine Klasse-II-Kategorie ist, etwa ein manipulationssicherer Mikrocontroller, den Sie selbst als Bauteil in Verkehr bringen. Ein solcher Baustein im eigenen Gerät stuft das Gerät nicht hoch. Die technischen Beschreibungen der wichtigen/kritischen Kategorien stehen in der Durchführungsverordnung (EU) 2025/2392.

Branchennormen und Abgrenzung zu Nachbarregimen

Für das typgenehmigte Fahrzeug gelten ISO/SAE 21434 (Automotive Cybersecurity Engineering) sowie UNECE R155/R156 im EU-Typgenehmigungsrahmen. Für CRA-erfasste Nachrüst-/Zubehörprodukte gelten dagegen die horizontalen Anhang-I-Pflichten des CRA (Security-by-Design/Default, Schwachstellenbehandlung, SBOM, Update-Fähigkeit). Beide Welten können bei demselben Unternehmen nebeneinander bestehen.

• Typgenehmigungsverordnung (EU) 2019/2144 (mit UNECE R155/R156): gilt für Fahrzeuge und für sie konstruierte Systeme, Bauteile und selbstständige technische Einheiten - Ausnahme vom CRA (Art. 2 Abs. 2 Buchst. c).
• RED-Delegierte-VO 2022/30: Cybersicherheit bestimmter Funkanlagen, vor allem solcher, die über das Internet kommunizieren können; bei funkgestützten Produkten kann es Überschneidungen geben, die sauber abzugrenzen sind. Die VO wird zum 11.12.2027 aufgehoben, ab dann deckt der CRA diese Anforderungen ab.
• NIS2: adressiert wesentliche und wichtige Einrichtungen - nicht die Produkt-Cybersicherheit des Herstellers. Ein Flottenbetreiber kann NIS2-pflichtig sein, während sein Dongle-Lieferant CRA-pflichtig ist. Hersteller elektronischer Erzeugnisse oder elektrischer Ausrüstungen können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. Getrennte Rechtsakte.
• AI Act: gilt zusätzlich zum CRA, sobald ein Produkt ein KI-System im Sinne der KI-Verordnung enthält (z. B. Fahrerassistenz-Bildanalyse als eigenständiges Produkt); der Umfang der Pflichten hängt von der Risikostufe ab.

SBOM- und Lieferketten-Realität im Aftermarket

Aftermarket-Elektronik nutzt fast denselben Software-Stack wie Consumer-IoT: Embedded-Linux oder ein RTOS, ein BLE-/WLAN-/Mobilfunk-Stack, MQTT/TLS-Bibliotheken, ein Cloud-Backend und eine Companion-App. Prüfen Sie diese Komponenten im Automotive-Zubehör auf Pflegerückstände: veraltete OpenSSL-Versionen, End-of-Life-Chipset-SDKs, ungepatchte OSS-Abhängigkeiten. Hier liegt der Handlungsdruck.

Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Praktisch sinnvoll sind Komponentenname, Version, eindeutiger Identifier und Lieferant. Eine allgemeine Veröffentlichungspflicht besteht nicht - die SBOM ist der Marktüberwachung auf begründetes Verlangen bereitzustellen. Praktisch ist die SBOM das Frühwarnsystem der Lieferkette: Erst wenn Sie wissen, welches Log4j/OpenSSL in welcher Firmware steckt, können Sie bei einer neuen CVE überhaupt reagieren.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt

Seit dem 11.09.2026 gelten die Melde- und Berichtspflichten nach Artikel 14. Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle läuft eine gestufte Kaskade - die Kurzformel „24h/72h/14 Tage" ist unvollständig:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
• 1 Monat - Abschlussbericht bei einem schwerwiegenden Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Gemeldet wird über die einheitliche Meldeplattform, die ENISA nach Art. 16 CRA einrichtet und betreibt, über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. Für einen Zubehörhersteller heißt das: Sie brauchen einen funktionierenden Produkt-Sicherheitsprozess (PSIRT) mit Eingangskanal, Triage, Fristen-Uhr und einer Coordinated-Vulnerability-Disclosure-Policy (CVD) über den gesamten Unterstützungszeitraum - in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer (Art. 13 Abs. 8).

Fristen: was zuerst greift

Zwei Daten zählen für Aftermarket-Hersteller, und sie fallen nicht zusammen:

• 11.09.2026 - Melde-/Berichtspflichten (Art. 14). Die erste harte Herstellerpflicht. Seitdem müssen Sie meldefähig sein: PSIRT, Kontaktkanal, Anbindung an die einheitliche Meldeplattform, Fristen-Prozess.
• 11.12.2027 - volle Anwendbarkeit aller Produktanforderungen. Ab hier müssen neue Produkte CE-konform sein: Security-by-Design, SBOM, Risikobewertung, technische Doku, EU-Konformitätserklärung.

Praktisch zuerst dran: die Meldefähigkeit. Sie gilt bereits und braucht organisatorischen Vorlauf. Der Aufbau der technischen Dokumentation und der SBOM läuft parallel, muss aber zum 11.12.2027 sitzen. (Aufbewahrung der technischen Doku: mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum, Art. 13 Abs. 13.)

Durchgespieltes Szenario: der OBD-Telematik-Dongle

Ein mittelständischer Anbieter vertreibt einen nachrüstbaren OBD-Telematik-Dongle: Mobilfunkmodul, GPS, BLE-Kopplung zur Fahrer-App, Cloud-Backend für Fahrtenbuch und Diagnose. Der Dongle wird nicht mit dem Fahrzeug genehmigt - er wird eigenständig verkauft und vom Endkunden aufgesteckt.

Schematisch durchgespielt: Ob der Dongle als für Fahrzeuge konstruiertes Bauteil unter die Verordnung (EU) 2019/2144 fällt, ist eine Auslegungsfrage, die der Anbieter klärt; er plant vorsorglich für den CRA. Dann wäre das Produkt ein PDE. Anhang-III-Prüfung: keine Kernfunktion wie VPN/Router → voraussichtlich Standardprodukt, Konformität über Modul A. To-dos: SBOM des Firmware-Stacks (Embedded-Linux, Mobilfunk-SDK, TLS-Bibliothek) in CycloneDX 1.6; Risikobewertung/Threat-Modeling für die Angriffsflächen Mobilfunk, BLE, App, Backend; sicheres OTA-Update über den Unterstützungszeitraum; PSIRT mit Eingangskanal und Art.-14-Fristen-Uhr; technische Doku plus EU-Konformitätserklärung und CE-Kennzeichnung. Ergebnis: Findet die Typgenehmigungsverordnung keine Anwendung, trägt er die Herstellerpflichten des CRA; R155 ersetzt sie nicht.

Was Blackfort Technology für Sie tut

Blackfort Technology begleitet Aftermarket- und Zubehörhersteller genau an dieser Trennlinie - schematisch, herstellerorientiert, ohne Rechtsberatung im Einzelfall:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, welche Ihrer Produkte unter die Typgenehmigung fallen und welche als eigenständiges PDE unter den CRA fallen können - inklusive Zulieferer-Grenzfälle, zur Prüfung durch Ihre Rechtsabteilung.
• SBOM-Setup: Aufbau maschinenlesbarer Stücklisten, etwa in CycloneDX oder SPDX, für Ihre Firmware- und App-Stacks, EOL-/OSS-Risiko-Screening.
• PSIRT & CVD: Aufbau eines Produkt-Sicherheitsprozesses mit Art.-14-konformer Fristen-Kaskade und Anbindung an die einheitliche Meldeplattform.
• Risikobewertung & Threat-Modeling: dokumentierte Risikoanalyse nach Anhang I für Konnektivität, App und Backend.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung.

Starten Sie mit dem Betroffenheits-Check, lesen Sie die Grundlagen im CRA-Überblick, und für kleinere Teams die Hinweise für KMU. Konkrete Fragen zu Ihrem Zubehörprodukt? Kontaktieren Sie uns.