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 die häufigste Fehlannahme in der Zulieferer- und Aftermarket-Branche. Sie ist zur Hälfte richtig — und in der anderen Hälfte teuer.

Richtig ist: Das typgenehmigte Gesamtfahrzeug ist vom CRA ausgenommen. Seine Cybersicherheit läuft über den sektoralen EU-Typgenehmigungsrahmen mit 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 ist produktbezogen, nicht branchenbezogen: Sie greift nur für das, was Teil der Typgenehmigung ist — nicht für das, was jemand später anschließt, aufsteckt oder per App koppelt.

Genau dort liegt der reale Schmerz: Ein OBD-Dongle mit Mobilfunk, eine vernetzte Dashcam oder ein Ladeadapter mit Companion-App ist kein Teil der Fahrzeug-Typgenehmigung. Es ist ein eigenständiges Produkt mit digitalen Elementen (PDE) — und damit 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 zieht die Trennlinie sauber. (Er ist eine schematische Einordnung, keine Rechtsberatung im Einzelfall.)

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

Die entscheidende Frage ist nie „Hat es mit Autos zu tun?", sondern „Ist dieses Produkt Bestandteil der Fahrzeug-Typgenehmigung?". Fällt die Antwort auf „nein", öffnet sich in aller Regel der CRA-Anwendungsbereich, sofern das Produkt digitale Elemente enthält und selbstständig in Verkehr gebracht wird.

• Typischerweise ausgenommen (Typgenehmigung): werkseitig verbautes Infotainment, Steuergeräte (ECUs) im OEM-Fahrzeug, integrierte Telematikeinheiten, die Bestandteil des genehmigten Fahrzeugs sind.
• Typischerweise CRA-relevant (Aftermarket/Zubehör): nachrüstbare OBD-/Telematik-Dongles, Aftermarket-Infotainment und Head-Units, vernetzte Dashcams, Diagnose- und Werkstatt-Tools, App-gekoppelte Ladeadapter, EV-Ladeequipment mit Konnektivität, Zubehör-Apps.

Ein Grenzfall bleibt der Zulieferer: Liefern Sie eine Komponente, die der OEM in die Typgenehmigung integriert, ist sie über das Fahrzeug erfasst. Vermarkten Sie dieselbe Technik zusätzlich als eigenständiges Retrofit-Produkt, kann für diese Variante der CRA greifen. Dieselbe Hardware, zwei Regime — abhängig vom Inverkehrbringen.

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

Die meisten Aftermarket-Elektronikprodukte 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 ein Produkt eine Sicherheitsfunktion nach Anhang III erfüllt. Die folgende Tabelle ist eine schematische Orientierung, keine verbindliche Einzelfallzuordnung.

Faustregel: Konnektivität allein macht ein Produkt noch nicht „wichtig". Erst eine spezifische Sicherheits-/Netzwerkfunktion (VPN, Router, PKI, Passwort-Manager u. a.) hebt es in Klasse I. Klasse II (immer notifizierte Stelle) betrifft im Aftermarket eher selten Produkte — etwa manipulationssichere Mikrocontroller in Sicherheitsmodulen. 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.

• Typgenehmigung (R155/R156): greift für das Fahrzeug und seine typgenehmigten Bestandteile — Ausnahme vom CRA.
• RED-Delegierte-VO 2022/30: Funkgeräte-Cybersicherheit; bei funkgestützten Produkten kann es Überschneidungen geben, die sauber abzugrenzen sind.
• NIS2: adressiert Betreiber wesentlicher/wichtiger Einrichtungen — nicht die Produkt-Cybersicherheit des Herstellers. Ein Flottenbetreiber kann NIS2-pflichtig sein, während sein Dongle-Lieferant CRA-pflichtig ist. Getrennte Rechtsakte.
• AI Act: relevant erst, wenn ein Produkt ein KI-System im Sinne der KI-Verordnung enthält (z. B. Fahrerassistenz-Bildanalyse als eigenständiges Produkt) — ergänzt, ersetzt aber den CRA nicht.

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. Diese Komponenten werden im Automotive-Zubehör oft schlechter gepflegt als im klassischen IT-Umfeld — veraltete OpenSSL-Versionen, End-of-Life-Chipset-SDKs, ungepatchte OSS-Abhängigkeiten. Genau hier ist der CRA-Handlungsdruck am höchsten.

Der CRA verlangt eine maschinenlesbare SBOM als Teil der technischen Dokumentation — mindestens die Top-Level-Abhängigkeiten. Konkret bedeutet das nach BSI TR-03183-2 (v2.1.0): Format CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1, mit Komponentenname, Version, eindeutigem Identifier und Lieferant. Eine allgemeine Veröffentlichungspflicht besteht nicht — die SBOM ist Behörden/notifizierten Stellen 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

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

• 24 Stunden — Frühwarnung ab Kenntnisnahme.
• 72 Stunden — vollständige Meldung inkl. Korrektur-/Minderungsmaßnahmen.
• 14 Tage — Abschlussbericht bei einer aktiv ausgenutzten Schwachstelle, gerechnet ab Verfügbarkeit einer Korrekturmaßnahme.
• 1 Monat — Abschlussbericht bei einem schweren Sicherheitsvorfall, gerechnet ab der 72-Stunden-Meldung.

Gemeldet wird über die ENISA Single Reporting Platform (SRP), die zum 11.09.2026 bereitzustellen ist; von dort geht die Einmalmeldung an das CSIRT der Hauptniederlassung und ENISA. 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 Support-Zeitraum — Richtwert mindestens fünf Jahre bzw. die erwartete Produktlebensdauer.

Fristen: was zuerst greift

Zwei Daten sind für Aftermarket-Hersteller entscheidend, und sie fallen nicht zusammen:

• 11.09.2026 — Melde-/Berichtspflichten (Art. 14). Die erste harte Herstellerpflicht. Ab hier müssen Sie meldefähig sein: PSIRT, Kontaktkanal, SRP-Anbindung, 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 ist die kürzere Frist und braucht organisatorisch am meisten Vorlauf. Der Aufbau der technischen Dokumentation und der SBOM läuft parallel, muss aber zum 11.12.2027 sitzen. (Aufbewahrungsfrist der technischen Doku: 10 Jahre nach Inverkehrbringen.)

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 ist nicht Teil der Fahrzeug-Typgenehmigung — er wird eigenständig verkauft und vom Endkunden aufgesteckt.

Schematisch durchgespielt: Das Produkt wäre ein PDE und damit voraussichtlich CRA-erfasst. Anhang-III-Prüfung: keine Kernsicherheitsfunktion 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 Support-Zeitraum; PSIRT mit Eingangskanal und Art.-14-Fristen-Uhr; technische Doku plus EU-Konformitätserklärung und CE-Kennzeichnung. Ergebnis: R155 hilft ihm nicht — er trägt die volle Herstellerlast des CRA.

Was Blackfort Technology für Sie tut

Blackfort Technology UG (haftungsbeschränkt) begleitet Aftermarket- und Zubehörhersteller genau an dieser Trennlinie — schematisch, herstellerorientiert, ohne Rechtsberatung im Einzelfall:

• Betroffenheits- und Scope-Analyse: welche Ihrer Produkte über die Typgenehmigung fallen und welche als eigenständiges PDE unter den CRA fallen können — inklusive Zulieferer-Grenzfälle.
• SBOM-Setup: Aufbau maschinenlesbarer Stücklisten (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) für Ihre Firmware- und App-Stacks, EOL-/OSS-Risiko-Screening.
• PSIRT & CVD: Aufbau eines Produkt-Sicherheitsprozesses mit Art.-14-konformer Fristen-Kaskade und SRP-Anbindung.
• Risikobewertung & Threat-Modeling: dokumentierte Risikoanalyse nach Anhang I für Konnektivität, App und Backend.
• Technische Dokumentation: Aufbau der Doku-Struktur 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.