Automotive-Cybersecurity: R155, R156 und ISO/SAE 21434 im Überblick

Problem in der Praxis

Viele Organisationen behandeln Automotive-Cybersecurity wie ein weiteres ISMS-Projekt und merken erst spät, dass die eigentliche Hürde eine behördliche Genehmigung ist. Die Verwechslung von Organisations- und Produktsicherheit ist der häufigste Fehler. Typische Symptome: ein zertifiziertes ISMS, aber kein auditiertes CSMS gegenüber der Behörde; ein gelebter Engineering-Prozess, während R156 organisatorisch fehlt, sodass Over-the-Air-Updates die Typgenehmigung unbemerkt berühren können; oder Zulieferer, die TISAX nachweisen, was die R155-Produktpflichten nicht abdeckt.

CISO-Einordnung

Regelungsgegenstand: R155 und R156 sind Anhänge zum UNECE-1958er-Abkommen (WP.29 / GRVA) und betreffen das Fahrzeug und die Managementsysteme des Herstellers. In der EU werden sie über die General Safety Regulation, Verordnung (EU) 2019/2144 vom 27.11.2019, im Typgenehmigungsrecht verbindlich; adressiert sind die Fahrzeugkategorien M, N und O sowie zugehörige Systeme und Bauteile.

Behörde: In Deutschland ist das Kraftfahrt-Bundesamt (KBA) die zuständige Typgenehmigungsbehörde für R155/R156; es auditiert CSMS und SUMS, erteilt die Typgenehmigung und nutzt Technische Dienste für Prüfungen. Das BSI ist hier nicht die Genehmigungsbehörde.

Organisationssicherheit: Ein ISO/IEC-27001-ISMS oder IT-Grundschutz liefert Organisations-Informationssicherheit. Das CSMS ist verwandt, aber produkt- und typgenehmigungsbezogen und gesetzlich verbindlich; ein ISMS ersetzt CSMS und Typgenehmigung nicht.

Umsetzungsperspektive

R155 hat zwei Ebenen. Organisatorisch weist der Hersteller ein CSMS über den gesamten Lebenszyklus nach (Entwicklung, Produktion, Post-Produktion); die Behörde auditiert es und stellt ein Konformitätszertifikat aus. Fahrzeugbezogen ist pro Typ eine Risikobewertung mit angemessenen Maßnahmen nachzuweisen; der frei zugängliche UNECE-Text strukturiert dies in einem Referenzkatalog (Annex 5) aus Bedrohungen, Maßnahmen am Fahrzeug und Maßnahmen außerhalb des Fahrzeugs (z. B. Backend).

R156 verlangt ein SUMS auf Organisationsebene: Konfigurationskontrolle je Fahrzeugtyp, Identifikation typgenehmigungsrelevanter Software über die RxSWIN, Abhängigkeits- und Kompatibilitätsprüfung, Bewertung der Typgenehmigungsrelevanz eines Updates und sichere Durchführung auch von Over-the-Air-Updates.

ISO/SAE 21434 (Cybersecurity-Engineering-Lebenszyklus) und ISO 24089 (Software-Update-Prozesse) sind die korrespondierenden Referenzen zu R155 bzw. R156. Beide sind kostenpflichtig und werden nur konzeptionell referenziert, nicht im Volltext oder als Anforderungslisten.

Typische Fehler

1. Organisations- und Produktsicherheit werden gleichgesetzt; ein ISMS-Zertifikat wird fälschlich als R155-Nachweis gewertet.
2. R156 wird unterschätzt; OTA-Updates werden technisch gelöst, ohne ihre Typgenehmigungsrelevanz zu bewerten.
3. Die falsche Behörde wird adressiert; das KBA wird mit Aufsichtsbehörden anderer Regime verwechselt.
4. TISAX wird als Abdeckung von R155 missverstanden.
5. Nachweise entstehen erst kurz vor dem Audit statt aus dem laufenden CSMS- und SUMS-Betrieb.

Risiken und Trade-offs

Das Hauptrisiko ist regulatorisch: Ohne nachgewiesenes CSMS und fahrzeugbezogene Bewertung drohen Verweigerung oder Verzögerung der Typgenehmigung und damit ein Markteintrittsrisiko. Dem steht der Aufwand für zwei Managementsysteme über den Lebenszyklus gegenüber; OEM tragen die Pflicht, sind aber auf Zuliefernachweise angewiesen.

Zur Abgrenzung benachbarter Regime: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ergänzt das Bild; typgenehmigte Kraftfahrzeuge unter Verordnung (EU) 2019/2144 sind grundsätzlich vom CRA ausgenommen. Achtung: dieselben Komponenten, separat außerhalb des Typgenehmigungsregimes vertrieben, können wieder unter den CRA fallen. NIS2 (Richtlinie (EU) 2022/2555) kann den OEM als Einrichtung treffen, betrifft aber Risikomanagement und Meldepflichten, nicht die Produkt-Typgenehmigung.

Entscheidungspunkte

• Trennen wir Organisationssicherheit (ISMS) und Produkt-Cybersecurity (CSMS/SUMS) organisatorisch klar?
• Wer ist Owner der Typgenehmigungs-Schnittstelle zum KBA und zu den Technischen Diensten?
• Wie prüfen wir Software-Updates vor Auslieferung auf Typgenehmigungsrelevanz (RxSWIN, Konfigurationskontrolle)?
• Welche Cybersecurity-Nachweise verlangen wir vertraglich von Zulieferern, abgegrenzt von TISAX?
• Wie behandeln wir Komponenten, die auch außerhalb des Typgenehmigungsregimes vertrieben werden, mit Blick auf den CRA?

Praktische Empfehlungen

1. Betreiben Sie CSMS und SUMS als laufende Regelkreise mit klaren Ownern, nicht als einmalige Auditvorbereitung.
2. Verankern Sie eine Update-Bewertung, die vor jedem Software-Update die Typgenehmigungsrelevanz prüft und die RxSWIN sauber führt.
3. Definieren Sie die Schnittstellen explizit: KBA als Typgenehmigungsbehörde, Technische Dienste für Prüfungen.
4. Formulieren Sie Lieferantenanforderungen produktbezogen und stellen Sie klar, dass TISAX die R155-Pflichten nicht ersetzt.
5. Nutzen Sie ISO/SAE 21434 und ISO 24089 als Engineering-Nachweisbasis, behandeln Sie sie aber als lizenzpflichtige Referenz.

Relevante Normreferenzen

• UN-Regelung Nr. 155 (UNECE, 1958er-Abkommen): Cybersecurity und CSMS; frei zitierbar über UNECE.
• UN-Regelung Nr. 156 (UNECE, 1958er-Abkommen): Software-Update und SUMS; frei zitierbar über UNECE.
• Verordnung (EU) 2019/2144 (General Safety Regulation): macht R155/R156 im EU-Typgenehmigungsrecht verbindlich; frei über EUR-Lex.
• Verordnung (EU) 2024/2847 (Cyber Resilience Act): ergänzendes Regime mit Ausnahme für typgenehmigte Kraftfahrzeuge; frei über EUR-Lex.
• ISO/SAE 21434, ISO 24089: Engineering-Referenzen zu R155 bzw. R156; kostenpflichtig, nur konzeptionelle Referenz.
• ISO/IEC 27001: Referenz für Organisations-ISMS; ersetzt das CSMS nicht; kostenpflichtig, nur Referenz.