Embedded-Cybersecurity für Steuergeräte nach R155 — kein CSMS, keine Typgenehmigung.
UNECE R155 hat Cybersecurity zur Homologationshürde gemacht. Hier ist das STS-Framework, mit dem wir ein Steuergerät von der TARA bis zur belastbaren Nachweisakte führen — die Architekturmaßnahmen, die Verifikation und der Teil des CSMS, der nach dem Zertifikat still verkümmert.
Veröffentlicht 2026-06-03 · Adrian Valea, Geschäftsführer, STS.
1. Was R155 tatsächlich vorschreibt
Das Erste, was wir einem Tier-1-Cybersecurity-Team vermitteln, ist: UNECE R155 ist keine technische Norm, die man implementiert — es ist eine Verordnung, an der man gemessen wird, und sie wirkt auf zwei Ebenen zugleich. Auf Organisationsebene fordert sie ein zertifiziertes Cyber Security Management System (CSMS): ein Prozessrahmenwerk, das von einer Genehmigungsbehörde oder ihrem technischen Dienst auditiert wird und nachweist, dass der Hersteller Cyber-Risiken über den gesamten Fahrzeuglebenszyklus identifizieren, bewerten und behandeln kann. Auf Fahrzeugtyp-Ebene fordert sie ein nachgewiesenes Cybersecurity-Engineering für genau diesen Typ — den Beleg, dass die Risiken für dieses Fahrzeug tatsächlich bewertet und behandelt wurden.
Die Reihenfolge ist nicht verhandelbar. Ohne gültige CSMS-Konformitätsbescheinigung wird keine Typgenehmigung erteilt — der Antrag kann nicht einmal weitergeführt werden. Wir haben Programme erlebt, die das CSMS als Dokumentationsübung behandelten, die man kurz vor Serienanlauf bereinigt, und dann feststellten, dass das Zertifikat genau den Homologationsmeilenstein versperrt, den sie dem Kunden bereits zugesagt hatten. Das CSMS ist die Eintrittskarte; der typspezifische Nachweis ist das, was man zeigt, sobald man durch die Tür ist.
Für einen Zulieferer hat das eine scharfe Konsequenz. Sie selbst halten die Typgenehmigung selten — das tut der Fahrzeughersteller —, aber Sie sind die Quelle eines Großteils der Nachweise, von denen das CSMS des Herstellers abhängt. R155 erwartet ausdrücklich, dass der Hersteller die aus Zulieferern entstehenden Cyber-Risiken managt. In der Praxis wird diese Pflicht über Verträge und Schnittstellenvereinbarungen an Sie weitergereicht, und die Qualität Ihrer Nachweise wird zum Audit-Risiko des Herstellers.
2. R155 und ISO/SAE 21434 — das „Was“ und das „Wie“
R155 sagt Ihnen, welche Ergebnisse gefordert sind, bleibt bei der Methode aber bewusst dünn. ISO/SAE 21434:2021 — Straßenfahrzeuge — Cybersecurity-Engineering — ist das anerkannte Wie. Die Verordnung und ihre Auslegungsdokumente verweisen darauf als Weg, die Angemessenheit eines CSMS und der typspezifischen Arbeit nachzuweisen, und unserer Erfahrung nach stellt eine Genehmigungsbehörde bei einer sauberen 21434-Arbeitsergebniskette deutlich weniger Rückfragen.
Die Zuordnung ist recht direkt, sobald man aufhört, beide als Konkurrenten zu lesen. Die organisatorischen CSMS-Anforderungen aus R155 entsprechen den Management-Kapiteln der 21434 — dem organisationsweiten Cybersecurity-Management (Kapitel 5) und dem projektabhängigen Cybersecurity-Management (Kapitel 6) —, während die Zuliefererbeziehung in den verteilten Cybersecurity-Aktivitäten (Kapitel 7) verankert ist. Die Forderung nach Risikoidentifikation und -bewertung wird durch die Bedrohungsanalyse und Risikobewertung (Kapitel 15, TARA) erfüllt. Die Kapitel zu Konzept, Produktentwicklung, Validierung, Produktion, Betrieb und Instandhaltung sowie Supportende (9 bis 14) liefern den typspezifischen Engineering-Nachweis. Und die Lebenszyklus- und Überwachungserwartungen aus R155 landen bei den fortlaufenden Cybersecurity-Aktivitäten (Kapitel 8) der 21434 — Cybersecurity-Monitoring, Schwachstellenanalyse und -management sowie Incident-Response.
Wir behandeln 21434 als Rückgrat und R155 als Abnahmekriterium. Erstellen Sie die 21434-Arbeitsergebnisse ehrlich, fügt sich die R155-Akte weitgehend von selbst zusammen; arbeiten Sie nur gegen die R155-Checkliste, erzeugen Sie tendenziell Nachweise, die vorhanden, aber nicht nachverfolgbar sind — und genau das prüft ein Assessor.
3. Das CSMS als Voraussetzung
Ein belastbares CSMS ist kein Aktenordner. Es ist ein lebendiges Geflecht aus Prozessen, Rollen und einem Nachweiskatalog, das ein Auditor von Anfang bis Ende durchschreiten kann. Konkret achten wir auf: definierte Cybersecurity-Rollen mit echter Befugnis (einen Cybersecurity-Manager, der ein Release tatsächlich stoppen kann); einen Risikomanagementprozess, der die TARA mit Entscheidungen verbindet; eine definierte Struktur des Cybersecurity-Case; ein Konfigurations- und Änderungsmanagement, das die Security-Baseline aktuell hält; sowie einen dokumentierten Schwachstellenmanagement- und Incident-Response-Prozess, der nach Serienanlauf läuft, nicht nur während der Entwicklung.
Der am häufigsten an Tier-1 weitergereichte Baustein ist die Zuliefererschnittstelle. 21434 fasst sie im Cybersecurity Interface Agreement zusammen, dem einzigen Arbeitsergebnis von Kapitel 7 (verteilte Cybersecurity-Aktivitäten) — dem Cybersecurity-Pendant des Development Interface Agreement, das Funktionale-Sicherheit-Teams aus ISO 26262 kennen. Die Erwartung aus R155, dass der Hersteller das Zuliefererrisiko managt, wird darüber operationalisiert. Eine gute Vereinbarung legt fest, wer welches Arbeitsergebnis verantwortet, wer die TARA in welchem Umfang durchführt, wie Cybersecurity-Anforderungen zu Ihnen fließen, welche Nachweise Sie zurückliefern und — entscheidend — wie nach SOP gefundene Schwachstellen in beide Richtungen und innerhalb welcher Fristen gemeldet werden. In unseren Assessments scheitern rund 60 % der erstmaligen Zuliefererpakete nicht am Engineering, sondern an dieser Naht: ungeklärte Verantwortung für eine geteilte Annahme oder eine TARA, deren Grenze die des Herstellers am Stecker nicht trifft.
4. Von der TARA über Cybersecurity-Ziele zu Anforderungen
Die Engineering-Kette, die ein Assessor nachverfolgt, beginnt bei der TARA (Kapitel 15). Wir definieren das Item und seine Grenze, erfassen Assets und ihre Cybersecurity-Eigenschaften (Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität), identifizieren Schadensszenarien und bewerten deren Auswirkung über die Kategorien Sicherheit, Finanzen, Betrieb und Datenschutz, leiten daraus Bedrohungsszenarien und Angriffspfade ab. Die Angriffsmachbarkeit wird bewertet — wir nutzen den auf Angriffspotenzial basierenden Ansatz — und mit der Auswirkung zu einem Risikowert je Bedrohungsszenario verknüpft. Für jedes signifikante Risiko entscheiden wir eine Behandlung: reduzieren, teilen, akzeptieren oder vermeiden.
Durch Reduktion behandelte Risiken werden zu Cybersecurity-Zielen — den übergeordneten Sicherheitszielen des Item, dem Cyber-Pendant der Sicherheitsziele. Die Ziele werden anschließend zu Cybersecurity-Anforderungen verfeinert und der Architektur zugeordnet: Systemebene, dann Hardware und Software. Ein Ziel wie „das Steuergerät weist nicht authentisierte Firmware ab“ wird zu Secure-Boot-Anforderungen in HW/SW; „sicherheitsrelevante Busbotschaften sind gegen Spoofing und Replay zu schützen“ wird zu SecOC-Anforderungen. Worauf es ankommt — und was auditiert wird — ist die bidirektionale Nachverfolgbarkeit: jede Anforderung verweist nach oben auf ein Ziel und ein TARA-Risiko und nach unten auf ein Designelement, einen Test und ein Verifikationsergebnis. Eine Anforderung ohne übergeordnetes Risiko ist Scope Creep; ein Risiko ohne untergeordnete Anforderung ist ein offener Befund.
5. Architekturmaßnahmen, die wirklich in der Nachweisakte auftauchen
Über Steuergeräte-Programme hinweg taucht dieselbe Gruppe von Mechanismen in der Nachweisakte auf, weil sie sich sauber auf die häufigsten Bedrohungsszenarien abbilden lässt. Keine davon ist optionale Folklore — jede schließt einen konkreten Angriffspfad, den die TARA zutage gefördert hat.
- Secure Boot — ein Hardware-Vertrauensanker verifiziert vor der Ausführung eine Signatur oder einen MAC über jede Boot-Stufe und schließt den Pfad „Angreifer ersetzt Firmware“. Wir prüfen, ob die Kette echt in unveränderlicher Hardware verankert ist und nicht eine Softwareprüfung, die derselbe Kompromiss umgeht.
- SecOC (AUTOSAR Secure Onboard Communication) — Authentizität und Frische sicherheits- und securityrelevanter Busbotschaften über einen gekürzten MAC plus Frischewert, womit Spoofing und Replay auf CAN/CAN-FD vereitelt werden. Das Management des Frischewerts und die Schlüsselverteilung sind die üblichen Schwachstellen.
- Sichere Diagnose — UDS SecurityAccess (Dienst 0x27) sperrt privilegierte Dienste, zunehmend ergänzt durch Authentication (Dienst 0x29) mit zertifikatsbasiertem, asymmetrischem Challenge-Response anstelle schwacher fester Seed-Key-Verfahren. Die geschützten Dienste — Routine Control, Write-by-Identifier, Einstieg in die Programmiersitzung — müssen tatsächlich hinter der Sperre liegen und nicht nur als geschützt deklariert sein.
- HSM-/SHE-Schlüsselmanagement — Schlüssel liegen in einem Hardware-Security-Modul oder SHE, nie in vom Applikationscode lesbarem Flash; Bereitstellung, Speicherung, Rotation und die kryptografischen Operationen sind in Hardware verankert. Ein „sicheres“ Design, dessen Wurzelschlüssel aus einem Flash-Dump rekonstruierbar ist, ist ein Befund, keine Maßnahme.
- Sicheres / authentisiertes Flashen — der Reprogrammierpfad verifiziert Authentizität und Integrität jedes Updates, bevor es akzeptiert wird, sodass Diagnose- und Update-Kanal nicht zum Installationsvektor werden.
- Anti-Rollback — monotone Versionszähler verhindern das Herabstufen auf ein älteres, verwundbares, aber noch gültig signiertes Image. Dies ist die am häufigsten gänzlich fehlende Maßnahme und hebt Secure Boot still auf, sobald sich eine bekannt verwundbare Altversion zurückflashen lässt.
Worüber wir berichten, ist nicht das Vorkommen dieser Namen auf einer Folie, sondern ob jede korrekt an ihr Bedrohungsszenario gebunden, korrekt verschlüsselt und durch Test verifiziert ist — siehe Software-Engineering zur Implementierung gegen den Anforderungssatz.
6. Verifikation und Penetrationstests
Anforderungen ohne Verifikation sind Behauptungen. Jede Cybersecurity-Anforderung braucht eine Verifikationsmethode — Review, Analyse oder Test —, und das Ergebnis wird Teil der Nachweise. Über den Unit- und Integrationstests steht die Cybersecurity-Validierung und der Penetrationstest, bei dem wir aufhören, das korrekte Designverhalten anzunehmen, und versuchen, es zu brechen.
Auf Methodenebene — und wir halten dies strikt defensiv — heißt das Pen-Testen eines Steuergeräts, die von der TARA vorhergesagten Angriffe zu versuchen: Brute-Forcing und Replay des UDS SecurityAccess (0x27) gegen den Diagnose-Stack; Fuzzing der CAN-/UDS-/Netzwerkschnittstellen, um nicht behandelte Zustände aufzudecken; Sondieren von Secure Boot und Flash-Pfad auf Downgrade und Akzeptanz unsignierter Images; Prüfen der SecOC-Frischebehandlung auf Replay-Fenster; und, wo das Hardware-Bedrohungsmodell es rechtfertigt, Fault-Injection- und Seitenkanal-Bewertung gegen Schlüsselspeicher und Boot-Kette. Wir beschreiben, was versucht wird und warum, keine waffenfähigen Schritt-für-Schritt-Rezepte. Das für den Assessor entscheidende Ergebnis ist reproduzierbarer Nachweis: Werkzeuge, Konfiguration und ein Befund, den ein Dritter erneut ausführen und bestätigen kann. Unser vollständiges Vorgehen findet sich in unserer Methodik für Steuergeräte-Penetrationstests und im Service ECU-Penetrationstest.
7. R156 / SUMS und RXSWIN
Empfängt das Steuergerät Software-Updates — over the air oder über Servicewerkzeuge —, greift eine zweite Verordnung. UNECE R156 fordert ein zertifiziertes Software Update Management System (SUMS), das Lebenszyklus-Pendant zum CSMS aus R155. Es regelt, wie Updates entwickelt, validiert, abgesichert und ausgeliefert werden — einschließlich Update-Integrität und Rollback-Behandlung — und wie sich das Fahrzeug bei einem fehlgeschlagenen Update verhält.
Der Mechanismus, der dies an die Homologation rückbindet, ist die RXSWIN — die Regulation X Software Identification Number. Jede RXSWIN identifiziert die typgenehmigungsrelevante Software für eine gegebene Verordnung und ist an die Typgenehmigung gebunden. Die Regel, auf die wir Teams verpflichten, ist einfach: jedes Update, das typgenehmigungsrelevante Software ändert, muss sich in seiner RXSWIN niederschlagen, damit die im Feld tatsächlich laufende Software weiterhin dem genehmigten Typ entspricht. Eine Over-the-Air-Kampagne, die geregeltes Verhalten still ändert, ohne die RXSWIN zu aktualisieren — oder ohne sie erneut zu prüfen —, bringt das Fahrzeug außer Konformität mit seiner eigenen Genehmigung. Auf Zuliefererseite heißt das: Ihr Release- und Konfigurationsmanagement muss eine saubere, abfragbare Verknüpfung von einem gelieferten Binary zu der RXSWIN halten, zu der es gehört, und Ihre Mechanismen für sicheres Flashen und Anti-Rollback (Abschnitt 5) sind genau das, was die Integritäts- und Rollback-Zusagen des SUMS wahr statt nur angestrebt macht.
8. Die Nachweisakte
Wenn der technische Dienst und die Genehmigungsbehörde prüfen, lesen sie nicht Ihren Code — sie lesen die Akte, und sie lesen sie auf Kohärenz. Was sie zu finden erwarten und was wir zusammenstellen, ist eine zusammenhängende Kette: das CSMS-Zertifikat und die Prozessnachweise; die Item-Definition und der Scope; die TARA mit Assets, Schadens- und Bedrohungsszenarien, Machbarkeits- und Risikobewertungen sowie Behandlungsentscheidungen; die Cybersecurity-Ziele und die daraus zugeordneten Anforderungen; die Architektur und die Zuordnung jeder Maßnahme zu der Anforderung, die sie erfüllt; die Verifikations- und Validierungsergebnisse einschließlich des Penetrationstestberichts; sowie den Nachserienplan für Monitoring, Schwachstellenmanagement und Incident-Response.
Das wiederkehrende Versagen ist kein fehlendes Dokument — es ist eine gebrochene Verknüpfung. Eine Maßnahme in der Architektur, die keine Anforderung verlangt; ein hochriskantes Bedrohungsszenario, dessen Behandlung sich nicht auf ein Ziel zurückführen lässt; ein Testbericht, der die verifizierte Anforderung nicht referenziert. Die Vorbereitung auf die Prüfung ist in unserer Praxis vor allem ein Nachverfolgbarkeits-Audit: wir durchschreiten die Akte so, wie es ein Assessor tun wird — von jedem TARA-Risiko vorwärts zu seiner verifizierten Behandlung und von jeder Maßnahme rückwärts zu ihrer Begründung — und schließen die Nähte, bevor der technische Dienst sie findet. Eine Akte, die diesen internen Durchgang übersteht, übersteht meist auch den externen.
9. Das CSMS zwischen Audits glaubwürdig halten
Das Zertifikat ist eine Momentaufnahme; die Pflicht ist fortlaufend. R155 erwartet Monitoring und Management des Cyber-Risikos über den Lebenszyklus, und die fortlaufenden Cybersecurity-Aktivitäten der 21434 (Kapitel 8) machen dies konkret — und genau dieser Teil verkümmert still, sobald das Programm ausgeliefert ist und das Team weiterzieht. Ein beim Audit glaubwürdiges CSMS kann achtzehn Monate später hohl sein, wenn niemand die Arbeit tut.
Die Arbeit ist konkret. Sie pflegen eine Zuordnung von Ihren eingesetzten Komponenten — Bibliotheken, Bootloader, Krypto-Stack, Kommunikations-Stack, Silizium — zu den dagegen offengelegten Schwachstellen, indem Sie CVE- und Threat-Intelligence-Feeds einlesen und auf Ihre Stückliste filtern. Trifft eine relevante Schwachstelle ein, muss sie einen definierten Pfad auslösen: die betroffene TARA neu bewerten, entscheiden, ob sich das Risiko geändert hat, und eine Entscheidung — patchen, mitigieren, akzeptieren oder aktualisieren — zurück in dieselbe Ziel-und-Anforderungs-Struktur führen, wobei das Update über das SUMS fließt und sich in der RXSWIN niederschlägt, falls es geregelte Software berührt. Dieser Auslöser — neue Schwachstelle zu neu bewerteter TARA zu nachverfolgter Entscheidung — ist der Herzschlag eines lebendigen CSMS, und sein Fehlen ist das, was ein Audit zwei Jahre später tatsächlich offenlegt. Wir bauen und betreiben diese Monitoring-Schleife im Rahmen unserer Cybersecurity-Praxis und stimmen sie mit der Sicherheits- und Prozessarbeit in funktionale Sicherheit und Training & Consulting ab, damit der Security-Case so lebendig bleibt wie das Produkt, das er schützt.
Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?
Keine NDA nötig. Sagen Sie uns die Norm, das Item bzw. Asset, den Assessor und Ihre Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Punkte — Ihre, ob Sie uns beauftragen oder nicht.
Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-06-03.