# Cybersecurity für Automotive-Zulieferer: UN R155, ISO/SAE 21434 und CRA

> Automotive-Zulieferer halten selten eine Typgenehmigung, aber UN R155 und R156 erreichen sie über den OEM-Vertrag: Der OEM braucht für sein CSMS Nachweise von jedem Zulieferer, meist als ISO/SAE 21434 Arbeitsprodukte aus einem Cybersecurity Interface Agreement. Komponenten außerhalb der Typgenehmigung wie Wallboxen und Aftermarket-Telematik fallen unter den Cyber Resilience Act. In Pentests von Steuergeräten finden wir am häufigsten rekonstruierbare UDS-Security-Access-Algorithmen, aktive Debug-Ports und schwach geprüftes Flashen. Ein sinnvolles erstes Projekt ist eine TARA plus Komponenten-Pentest eines Steuergeräts.

Was Tier-1 und Tier-2 für Cybersecurity liefern müssen: UN R155 und R156 über den OEM, ISO/SAE 21434 Arbeitsprodukte, CRA für Aftermarket und ein erstes Projekt.

Source: https://zyberum.com/de/fuer/automotive-zulieferer · Updated: 2026-10-07

## Welche Regeln für dich gelten

Der Fahrzeughersteller hält die Typgenehmigung, aber die Nachweise dafür entstehen bei den Zulieferern. Vier Rahmenwerke erreichen dich.

**UN R155 und R156** sind in der EU über die Verordnung (EU) 2019/2144 verbindlich, für neue Fahrzeugtypen seit 6. Juli 2022 und für alle Neufahrzeuge seit 7. Juli 2024. R155 verlangt vom OEM ein Cybersecurity-Managementsystem, das die Lieferkette abdeckt, und für jeden Fahrzeugtyp den Nachweis, dass Risiken identifiziert, behandelt und getestet wurden. R156 tut dasselbe für Software-Updates. Ohne deinen Input kann der OEM das nicht zeigen, also kommen die Pflichten als Vertragsklauseln bei dir an.

**ISO/SAE 21434:2021** ist der Standard hinter diesen Klauseln. Kapitel 7 definiert verteilte Cybersecurity-Aktivitäten und das Cybersecurity Interface Agreement, das festlegt, wer welches Arbeitsprodukt liefert. Kapitel 15 definiert die Bedrohungsanalyse und Risikobewertung (TARA), Kapitel 9 bis 11 die Arbeitsprodukte für Konzept, Entwicklung und Validierung, Kapitel 8 das kontinuierliche Monitoring und die Schwachstellenanalyse, Kapitel 13 die Incident Response. Die meisten OEM-Fragebögen sind diese Kapitel in anderen Worten.

**Cyber Resilience Act (EU) 2024/2847.** Artikel 2 Absatz 2 nimmt Produkte aus, die von der Verordnung (EU) 2019/2144 erfasst sind, typgenehmigte Komponenten also nicht. Alles andere, was du mit Firmware oder Software verkaufst, von Wallboxen über Aftermarket-Telematik bis zu Diagnosewerkzeugen, ist drin: Meldepflichten ab 11. September 2026, volle Anforderungen ab 11. Dezember 2027.

**NIS2 über das deutsche BSIG.** Die Herstellung von Kraftwagen, Anhängern und Teilen ist ein Sektor in Anhang II der NIS2-Richtlinie. Ein Zulieferer mit 50 oder mehr Beschäftigten oder mehr als 10 Millionen Euro Umsatz und Bilanzsumme ist eine wichtige Einrichtung nach § 28 BSIG. Dazu erwarten OEMs ein TISAX-Label für die Informationssicherheit an deinen Standorten.

## Wo Angreifer anfangen

Ein Steuergerät wird über seine Schnittstellen und seine Lebensdauer angegriffen, nicht über seine Anwendungslogik.

- **Diagnose über CAN und DoIP**: UDS Security Access mit einem Seed-and-Key-Algorithmus, der aus der Firmware rekonstruierbar ist, Diagnosesitzungen, die im Normalbetrieb erreichbar sind, Routinen und Data Identifier, die nie fürs Feld gedacht waren.
- **Debug-Ports**: JTAG, DAP oder SWD auf der Platine, oft mit nicht gesetztem Ausleseschutz des Mikrocontrollers.
- **Bootloader und Flashen**: Update-Images, die auf Format und Version, aber nicht auf Signatur geprüft werden, oder mit einem Schlüssel signiert sind, den die ganze Produktlinie teilt.
- **Fahrzeug-Ethernet**: SOME/IP- und DoIP-Dienste auf Infotainment- und ADAS-Plattformen, die unvertrauenswürdige Eingaben in C und C++ parsen.
- **Embedded Linux und Android**: Kernel-Treiber, Trusted Execution Environments, Interprozesskommunikation, schwache Mandatory-Access-Control-Profile.
- **Dein eigenes Tooling**: Band-Ende-Flashstationen, Schlüsselserver und Entwicklungswerkzeuge halten die Schlüssel, denen das Steuergerät vertraut.

## Was Assessments typischerweise finden

Typische Findings aus Pentests und Fuzzing von Steuergeräten, anonymisiert: Bei Leistungselektronik-Steuergeräten (DC/DC-Wandler, On-Board-Charger) war die Ableitung des UDS-Security-Access-Schlüssels durch Reverse Engineering der TriCore/AURIX-Firmware rekonstruierbar, und Kalibrierdaten ließen sich über UDS in einer Sitzung schreiben, die das nicht hätte erlauben dürfen; bei einem Licht-Steuergerät führte Hardware-Reverse-Engineering von einer ungeschützten Debug-Schnittstelle zu einem vollständigen Flash-Dump und von dort zu den Diagnosegeheimnissen; auf Infotainment-Plattformen erzeugte Fuzzing der TEE-Schnittstelle, der Kernel-Treiber sowie der DoIP- und SOME/IP-Stacks Crashes, die auf Speicherfehler zeigten, und AppArmor-Profile waren so locker, dass ein kompromittierter Mediendienst das Gateway zum Fahrzeugbus erreichen konnte.

Nichts davon ist exotisch. Jeder Punkt stünde in einer TARA als machbarer Angriffspfad mit hohem Schadensszenario, und jeder Punkt ist in einem normalen Release-Zyklus behebbar, wenn er vor Produktionsstart gefunden wird.

## Ein sinnvolles erstes Projekt

Fang mit einer Komponente an, für die ein Cybersecurity Interface Agreement fällig ist, oder mit der, die am längsten in Produktion sein wird.

1. **Item Definition und TARA** nach ISO/SAE 21434 Kapitel 9 und 15 für diese Komponente: Assets, Schadensszenarien, Bedrohungsszenarien, Angriffspfade, Risikowerte und Behandlungsentscheidungen, in einer Form, die dein OEM akzeptiert. Fünf bis acht Tage mit deinen System- und Softwarearchitekten.
2. **Komponenten-Pentest** in unserem Labor an einem Prüfstandsaufbau: CAN, LIN und UDS inklusive Fuzzing, Debug-Ports und Ausleseschutz, Bootloader und Flashen, Firmware-Reverse-Engineering, Ethernet-Dienste, wo vorhanden. Zwei bis drei Wochen.
3. **Cybersecurity-Konzept und Testnachweise**: die Ergebnisse gemappt auf die TARA, die Controls, die du schon hast, und die, die noch fehlen, geliefert als Arbeitsprodukte für deinen Cybersecurity Case und das CSMS-Audit deines Kunden.
4. **Fixen und Retest**, dann die Diagnose- und Fuzzing-Tests als Regressionssuite bei jedem Release laufen lassen.

Typischer Aufwand für die Schritte 1 bis 3 sind 20 bis 30 Personentage, also 25.000 bis 50.000 Euro zu Marktpreisen. Die TARA allein liegt bei 8.000 bis 15.000 Euro.

## Was Zyberum hier tut und was nicht

Wir schreiben TARAs, Item Definitions, Cybersecurity-Konzepte und CSMS-Arbeitsprodukte, testen Steuergeräte und Gesamtfahrzeuge, fuzzen CAN, UDS, DoIP und SOME/IP, reverse-engineeren Firmware und härten Embedded-Linux-Plattformen. Unsere AutoST-Suite automatisiert die Diagnose- und Fuzzing-Anteile, damit du sie pro Release wiederholen kannst. Wir sind kein Technischer Dienst und stellen weder Typgenehmigungen noch ISO/SAE-21434-Zertifikate aus; wir liefern die Nachweise, die der Auditor deines Kunden liest.

## FAQ

**Wir sind Tier-2. Gilt UN R155 überhaupt für uns?**

Nicht direkt, die Regelung richtet sich an den Fahrzeughersteller. Praktisch gilt sie für dich, weil der OEM nachweisen muss, dass Cybersecurity entlang der Lieferkette gemanagt wird, und dafür seinen Tier-1 um Nachweise bittet, der dich fragt. Was du schuldest, steht im Cybersecurity Interface Agreement mit deinem Kunden, meist eine TARA für deine Komponente, ein Cybersecurity-Konzept, Testnachweise und eine Zusage zu Schwachstellenmonitoring und Incident Handling.

**Gilt der Cyber Resilience Act für unsere Steuergeräte?**

Nicht für Komponenten, die von der Fahrzeug-Typgenehmigung nach Verordnung (EU) 2019/2144 erfasst sind; Artikel 2 Absatz 2 des CRA nimmt sie aus. Er gilt für Produkte, die du außerhalb der Typgenehmigung verkaufst: Wallboxen und Ladetechnik, Aftermarket-Telematik und Dongles, Diagnosewerkzeuge, Werkstattausrüstung und eigenständige Software. Dafür gelten Meldepflichten ab 11. September 2026 und die vollen Anforderungen ab 11. Dezember 2027.

**Wie viel von einem Komponententest lässt sich automatisieren?**

Regressions- und Schnittstellentests sehr viel: Diagnosesitzungen, Security Access, Fuzzing von CAN, UDS, DoIP und SOME/IP laufen unbeaufsichtigt, und genau das macht unsere AutoST-Suite. Einen schwachen Schlüsselalgorithmus in der Firmware finden, einen Debug-Port zu einem Flash-Dump verketten oder einen Crash bewerten braucht weiterhin einen Ingenieur. Ein guter erster Test ist manuell mit automatisierter Unterstützung; spätere Releases laufen überwiegend automatisiert.

## Sources

- [UN-Regelung Nr. 155 (Cybersicherheit und Cybersicherheitsmanagementsystem), Amtsblatt L 82 vom 9. März 2021](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:42021X0387)
- [UN-Regelung Nr. 156 (Software-Aktualisierung und Software-Aktualisierungsmanagementsystem)](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:42021X0388)
- [Verordnung (EU) 2019/2144 (General Safety Regulation), Artikel 19 Anwendungsdaten](https://eur-lex.europa.eu/eli/reg/2019/2144/oj)
- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering](https://www.iso.org/standard/70918.html)
- [Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 2 Absatz 2](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [BSI-Gesetz (BSIG) in der Fassung des NIS2UmsuCG, § 28](https://www.gesetze-im-internet.de/bsig_2025/)

## Related

- [Finde die Schwachstellen in deinem Fahrzeug, bevor Angreifer es tun.](https://zyberum.com/de/automotive-security)
- [ISO/SAE 21434, die das Audit besteht und den Angreifer aushält.](https://zyberum.com/de/iso-21434-beratung)
- [Automotive Security Testing, automatisiert.](https://zyberum.com/de/autost)
- [UDS (Unified Diagnostic Services)](https://zyberum.com/de/glossar/uds)
- [TARA (Threat Analysis and Risk Assessment)](https://zyberum.com/de/glossar/tara)
- [ECU-Fuzzing erklärt: Fehler in UDS, DoIP und SOME/IP finden](https://zyberum.com/de/insights/ecu-fuzzing-erklaert)

---
Zyberum GmbH. Canonical page: https://zyberum.com/de/fuer/automotive-zulieferer