Der Cyber Resilience Act betrifft typgenehmigte Fahrzeuge grundsätzlich nicht. Viele Automotive-Hersteller schließen daraus: R155 und R156 gelten bereits – also gibt es nichts weiter zu tun.
Genau das ist der Denkfehler. Die CRA-Ausnahme senkt nicht die Anforderungen an Cybersicherheit. Sie verhindert nur, dass zwei Regelwerke dieselbe Aufgabe parallel regeln. UN ECE R155 verlangt bereits, Cyberrisiken über Entwicklung, Produktion und Nachserienphase zu beherrschen – einschließlich Risiken aus der Lieferkette und belastbarer Nachweise.
Für Automotive bleibt die Pflicht also dieselbe: Cybersecurity muss nicht nur vorhanden sein. Sie muss sich auch belegen lassen.
Die Ausnahme verhindert Doppelregulierung – nicht Cybersicherheit
Der Cyber Resilience Act gilt grundsätzlich für Produkte mit digitalen Elementen. Typgenehmigte Fahrzeuge nach Verordnung (EU) 2019/2144 sind jedoch vom Anwendungsbereich ausgenommen. Über diesen europäischen Rahmen wurden UN ECE R155 und R156 für die betroffenen Fahrzeugkategorien zum verbindlichen Maßstab.
Das ist keine Aussage darüber, dass Fahrzeuge weniger geschützt werden müssten. Es ist eine Abgrenzung der Rechtsregime: Die fahrzeugbezogene Cybersicherheit wird bereits über die Typgenehmigung geregelt. Wer ein Fahrzeug auf den Markt bringt, muss daher nicht beweisen, dass der CRA irrelevant ist. Er muss zeigen können, dass sein Cybersecurity Management System funktioniert.
Seit Juli 2022 gilt die R155-Pflicht für neue Fahrzeugtypen. Seit Juli 2024 betrifft sie neu produzierte Fahrzeuge der Kategorien M, N und O. Ohne gültiges Zertifikat für das Cybersecurity Management System kann ein Fahrzeugtyp seine Typgenehmigung nicht behalten.
Was UN ECE R155/R156 tatsächlich verlangen
R155 ist keine Checkliste für die Entwicklungsabteilung. Die Regelung verlangt ein Cybersecurity Management System, kurz CSMS. Dieses System muss Risiken über den gesamten Fahrzeuglebenszyklus erfassen: von der Konzeption über Entwicklung und Produktion bis in die Zeit nach dem Serienende.
Dazu gehören unter anderem:
- Cyberrisiken systematisch identifizieren und bewerten
- Risiken aus der Lieferkette berücksichtigen und behandeln
- Sicherheitsmaßnahmen in Entwicklung und Produktion nachweisbar umsetzen
- Angriffe und Auffälligkeiten erkennen können
- Vorfälle, Schwachstellen und Abhilfemaßnahmen nachvollziehbar dokumentieren
- Wirksamkeit des CSMS regelmäßig überprüfen lassen
UN ECE R156 ergänzt diesen Rahmen um das Software Update Management System, SUMS. Es regelt, wie Software-Updates nachvollziehbar, sicher und über den Fahrzeuglebenszyklus hinweg ausgerollt werden – in der Werkstatt ebenso wie over the air.
Für Hersteller ist das keine abstrakte Regulierung. Es ist eine Marktzugangsvoraussetzung.
R155 und CRA: viele gleiche Fragen, andere Rechtsmechanik
R155 und CRA sind nicht identisch. Sie richten sich an unterschiedliche Gegenstände und arbeiten mit unterschiedlichen Rechtsfolgen. Aber die operative Frage dahinter ist oft dieselbe: Ist das Produkt über seinen Lebenszyklus gegen relevante Cyberrisiken geschützt – und lässt sich das belegen?
| Thema | UN ECE R155/R156 | Cyber Resilience Act |
| Gegenstand | Typgenehmigtes Fahrzeug und seine Systeme | Produkte mit digitalen Elementen |
| Risikobewertung | Bestandteil des CSMS | Bestandteil der Cybersecurity-Anforderungen |
| Lieferkette | Lieferantenrisiken müssen identifiziert und gemanagt werden | Sorgfalt bei der Integration von Komponenten Dritter |
| Software und Updates | R156 regelt SUMS und sichere Update-Prozesse | Sicherheitsupdates und Umgang mit Schwachstellen sind Teil der Anforderungen |
| Nachweis | CSMS-/SUMS-Dokumentation für die Typgenehmigung | Technische Dokumentation und Konformitätsbewertung |
| Meldung von Vorfällen | Regelmäßige Berichterstattung im Typgenehmigungsrahmen | Engere Fristen für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle |
Die Tabelle zeigt die wichtige Nuance: Der CRA ist bei einzelnen Pflichten, etwa den Meldefristen, enger. R155 ist dafür fest im Typgenehmigungsverfahren verankert. Wer R155 erfüllt, arbeitet also bereits an vielen der Sicherheitsdisziplinen, die auch außerhalb von Automotive relevant sind. Das ist kein Grund zur Entspannung – es ist der Grund, warum die Anforderungen schon heute ernst genommen werden müssen.
Der Nachweis beginnt nicht erst beim Audit
Ein CSMS wird nicht erst dann relevant, wenn ein Auditor danach fragt. Es wird im Alltag sichtbar: bei der Bewertung eines neuen Steuergeräts, bei der Freigabe eines Lieferanten, bei einer Änderung der Firmware oder bei der Frage, welche Fahrzeuge von einer Schwachstelle betroffen sein könnten.
Gerade in der Lieferkette entscheidet sich, wie belastbar dieser Nachweis später ist. Ein Hersteller kann nur so gut dokumentieren, wie die Informationen aus Entwicklung, Produktion und Lieferantenprozess zusammenlaufen. Ist nicht nachvollziehbar, welche Firmware wann auf welches Steuergerät kam, wird aus einer klar eingrenzbaren Schwachstelle schnell ein breiter Rückruf oder eine aufwendige Rekonstruktion.
R155 verlangt deshalb nicht nur Maßnahmen gegen Angriffe. Die Regelung fordert auch, dass Informationen aus der Lieferkette erhoben und überprüft werden, damit lieferantenbezogene Risiken identifiziert und gemanagt werden können.
Eine Cybersecurity-Pflicht endet nicht am Werkstor
R155 verlangt, lieferantenbezogene Cyberrisiken zu identifizieren und zu managen. Das ist logisch: Ein Steuergerät entsteht nicht allein beim Fahrzeughersteller. Firmware, Schlüssel, Bauteile, Programmierung und Logistik durchlaufen mehrere Unternehmen, Standorte und Prozessschritte.
Im Audit, bei einem Software-Update oder im Rückruf zählt deshalb nicht nur, ob eine Maßnahme definiert wurde. Entscheidend ist, ob sich nachvollziehen lässt, welche Komponente woher kam, welche Firmware sie erhielt, welche Prozessschritte dokumentiert sind und welche Fahrzeuge oder Baugruppen betroffen sein können.
Genau hier verbindet sich Cybersecurity mit Supply Chain Management. Mit btv TAK® werden Bestände, Bewegungen und Prozessdaten je Verpackungseinheit dokumentiert. Wenn Beschaffung, Lagerung, Bauteilservices und sichere Programmierung über btv koordiniert werden, laufen die Informationen aus diesen Prozessschritten zusammen.
Das ersetzt nicht das CSMS des Herstellers. Es erleichtert jedoch, Nachweise aus der Lieferkette strukturiert bereitzustellen, statt sie erst dann zusammenzusuchen, wenn ein Auditor, ein Software-Update oder ein Rückruf sie verlangt.
Zwei Fälle, die zeigen, worauf es ankommt
2015 demonstrierten die Sicherheitsforscher Charlie Miller und Chris Valasek am Jeep Cherokee, wie ein über das Mobilfunknetz erreichbares Infotainmentsystem zum Einstiegspunkt in Fahrzeugfunktionen werden kann. Der anschließende Rückruf von rund 1,4 Millionen Fahrzeugen machte für die Branche sichtbar, dass Cybersicherheit nicht bei der Software im Fahrzeug endet. Sie betrifft Architektur, Schnittstellen, Update-Fähigkeit und die Fähigkeit, Risiken im Feld zu erkennen.
Der spätere Bendix-EC80-Fall zeigt eine andere Seite derselben Aufgabe. Bei einem Rückruf von Bremssteuergeräten standen zunächst Probleme der Signalverarbeitung im Vordergrund. Erst später wurden Sicherheitslücken öffentlich, darunter fehlerhafte Speicherbehandlung und fest hinterlegte Zugangsdaten. Entscheidend ist hier nicht, ob dieses konkrete Steuergerät unter CRA oder R155 fällt. Entscheidend ist: Wenn ein Sicherheitsproblem auftritt, müssen Hersteller nachvollziehen können, welche Firmware, welche Geräte und welche Fahrzeuge betroffen sind – und wie der Prozess abgesichert war, in dem die Firmware auf das Steuergerät gelangt ist.
Beide Fälle führen zu derselben Frage: Entsteht der Nachweis erst nach einem Vorfall, oder existiert er bereits aus dem Prozess heraus?
Wo btv SEEL® ansetzt
Eine besonders sensible Stelle liegt dort, wo Firmware und Schlüsselmaterial auf einen Mikrocontroller oder ein Steuergerät kommen. Hier treffen geistiges Eigentum, Produktsicherheit und spätere Nachweisbarkeit unmittelbar zusammen.
btv SEEL® unterstützt diesen Prozess auf Bauteilebene. Firmware wird während des Programmiervorgangs ausschließlich im flüchtigen Arbeitsspeicher verarbeitet. Unverschlüsselte Kopien entstehen nicht auf Datenträgern. Die kundeneigene PKI kann angebunden werden; Root-Zertifikate bleiben beim Hersteller. Programmierereignisse und Geräteidentitäten lassen sich dokumentieren und kryptografisch signieren.
Das macht ein Fahrzeug oder Steuergerät nicht automatisch „R155-konform“ oder „CRA-konform“. Die Konformitätsbewertung bleibt Verantwortung des Herstellers. btv SEEL® kann jedoch die Grundlage aus einem besonders kritischen Prozessschritt liefern: einen abgesicherten Programmiervorgang und einen nachvollziehbaren Nachweis darüber, was wann auf welchem Bauteil passiert ist.
Wann die CRA-Frage trotzdem geprüft werden sollte
Für das typgenehmigte Fahrzeug trägt R155 den zentralen Cybersicherheitsrahmen. Eine separate CRA-Prüfung kann dennoch sinnvoll werden, wenn ein Hersteller oder Zulieferer Produkte zusätzlich außerhalb dieses Rahmens anbietet – etwa generische Nachrüstprodukte, universelle Diagnosegeräte oder Komponenten, die über offene Vertriebskanäle an andere Zielgruppen gehen.
Das ist jedoch ein Spezialfall. Er sollte nicht die zentrale Botschaft überlagern: Auch ohne CRA-Zusatzpflicht ist Automotive-Cybersicherheit bereits verbindlich geregelt.
Häufige Fragen zu UN ECE R155, R156 und CRA
R155 verlangt, lieferantenbezogene Cyberrisiken zu identifizieren und zu managen. Dafür müssen Hersteller nachvollziehen können, woher eine Komponente stammt, welche Prozesse sie durchlaufen hat und in welcher Baugruppe sie eingesetzt wurde. btv TAK® dokumentiert Bestände, Bewegungen und Prozessdaten je Verpackungseinheit; btv SEEL® ergänzt bei der sicheren Programmierung die Nachweise auf Geräteebene.
