# UN-R155-Audits: was Tester liefern müssen

Was ein UN-R155-Assessment von der Testseite erwartet: nachverfolgbare Testfälle, versionierte Nachweise, Abdeckung, saubere Ergebnisse, Restrisiko, Lieferungen.

Source: https://auto-st.com/de/insights/un-r155-audit-was-tester-brauchen · Updated: 2026-10-07

Für ein UN-R155-Assessment muss die Testseite drei Dinge zeigen: dass jedes relevante Risiko aus der Risikobewertung getestet wurde, dass die Tests belegen, dass die Sicherheitsmaßnahmen wirken, und dass die Ergebnisse nachverfolgbar und reproduzierbar sind. Die Regelung schreibt keine Testmethoden vor. Verlangt wird vom Hersteller, Risiken zu identifizieren, zu behandeln und die Wirksamkeit der Maßnahmen zu verifizieren, und der Assessor folgt dann der Kette von Risiko zu Maßnahme zu Test zu Ergebnis. Tester, die Testfälle mit Kennungen liefern, verknüpft mit Bedrohungsszenarien, mit datierten und versionierten Nachweisen und einer klaren Aussage, was nicht getestet wurde, machen diese Kette leicht nachvollziehbar. Tester, die ein PDF mit "keine kritischen Findings" liefern, machen sie schwer.

## Was R155 verlangt, kurz

UN R155 hat zwei Teile, die hier zählen. Absatz 7.2 betrifft das Cyber Security Management System (CSMS) des Herstellers: die Prozesse für Risikoidentifikation, Bewertung, Behandlung, Test und Überwachung. Absatz 7.3 betrifft den Fahrzeugtyp: der Hersteller muss eine Risikobewertung für den Typ durchführen, ihn mit angemessenen Maßnahmen gegen die identifizierten Risiken schützen und die Wirksamkeit dieser Maßnahmen vor der Typgenehmigung testen. Annex 5 listet Bedrohungen und Maßnahmen, die die Risikobewertung berücksichtigen muss.

ISO/SAE 21434 ist der übliche Engineering-Rahmen dahinter. Die Testpflichten stehen in Clause 10 (Integration und Verifikation), Clause 11 (Cybersecurity-Validierung) und der TARA in Clause 15. Die verteilte Entwicklung mit Zulieferern regelt Clause 7.

## Die Kette, der ein Assessor folgt

| Glied | Was der Tester liefert |
| --- | --- |
| Bedrohungsszenario (TARA, Annex-5-Bezug) | Die Testfall-Kennungen, die es adressieren |
| Cybersecurity-Anforderung | Das Pass-Kriterium, das zeigt, dass sie erfüllt ist |
| Testfall | Schritte, Vorbedingungen, erwartetes Ergebnis, Abdeckung |
| Ergebnis | Datum, Softwarestand, Tester, Tool-Version, Rohnachweis |
| Finding | Bewertung mit Begründung, Fix-Status, Restrisiko-Entscheidung |

Fehlt ein Glied, fragt der Assessor nach. Die häufigste Lücke, die wir in der Audit-Unterstützung sehen, ist der Rückbezug vom Testfall zum Bedrohungsszenario: die Tests liefen, aber niemand kann zeigen, welches Risiko jeder Test adressiert hat.

## Nachweise, die tragen

Ein Nachweis für ein Audit ist roh, datiert und zuordenbar. Halte je Testfall fest:

- Den Software- und Hardwarestand des getesteten Items, wie das Steuergerät ihn meldet, zum Beispiel aus `22 F1 89` und `22 F1 91`.
- Den Request und die Response oder das Log der Kampagne, nicht nur das Urteil. Eine Zeile wie `2E F1 8C ... -> 7F 2E 33` belegt, dass ein Schreiben abgelehnt wurde.
- Das Datum, den Tester, das Tool und seine Version, die Prüfstandskonfiguration.
- Für Fuzzing: Seed, Iterationszahl, Services im Scope, verwendete Monitore. Eine Kampagne, die sich nicht wiederholen lässt, ist ein schwacher Nachweis.

Saubere Ergebnisse zählen. "SecurityAccess Level 1: Lockout nach drei ungültigen Keys (`7F 27 36`), Verzögerung durchgesetzt (`7F 27 37`), Seed hat die Zufallsprüfungen bestanden" ist der Nachweis, dass die Brute-Force-Maßnahme wirkt. Assessoren lesen negative Ergebnisse als Beleg der Abdeckung.

## Abdeckung und Grenzen

Nenne die Abdeckung in Zahlen und die Grenzen in Worten. "Alle Service Identifier `0x00` bis `0xFE` in den Sessions `01`, `02` und `03`" oder "DID-Bereich `0xF100` bis `0xF1FF`" sagt dem Assessor, wie weit der Test ging. Ausschlüsse sind genauso wichtig: waren Hardware-Angriffe, Firmware-Extraktion oder das Telematik-Backend außerhalb des Scopes, schreib es auf, mit Verweis darauf, wo diese Risiken abgedeckt sind.

## Restrisiko und Re-Test

Jedes Finding braucht einen Endzustand: behoben und verifiziert auf einem benannten Softwarestand, durch eine andere Maßnahme mitigiert oder als Restrisiko akzeptiert von einer benannten Rolle an einem Datum. Offene Findings ohne Entscheidung sind die zweithäufigste Audit-Frage. Plane den Re-Test von Anfang an und halte die Testfall-Kennungen stabil, damit der Re-Test auf dem neuen Softwarestand denselben Fall als bestanden zeigt.

## Was Zulieferer übergeben sollten

Ein Tier-1, der die R155-Genehmigung eines OEM unterstützt, wird meist nach der TARA oder ihrem relevanten Teil gefragt, nach den umgesetzten Cybersecurity-Anforderungen, der Testspezifikation und den Ergebnissen mit Nachverfolgbarkeit, offenen Findings mit Status und der Vulnerability-Management-Regelung nach dem Produktionsstart. Vereinbare das Format früh im Cybersecurity Interface Agreement. Ein PDF ohne Testfall-Kennungen zu übergeben zwingt den OEM, die Zuordnung neu zu machen, und daher kommen Audit-Findings.

## Wie AutoST das unterstützt

AutoST erzeugt den wiederholbaren Teil dieser Nachweise: Testläufe mit dem Scope aus Steuergerät, Schnittstelle und Session, Abdeckungszahlen, jedes Finding mit Request- und Response-Bytes, einen PDF-Bericht und einen SARIF-Export pro Lauf und einen Fix Plan, der Status, Verantwortlichen, Risikoakzeptanz und eine ALM/PLM-Referenz pro Finding über Re-Tests hinweg führt. Es betreibt kein CSMS, schreibt die TARA nicht und stellt keine Genehmigung aus, und es ersetzt nicht den Penetrationstest, den die Validierung nach Clause 11 meist einschließt. Seine Aufgabe ist, die Testergebnisse nachverfolgbar und wiederholbar zu machen, Release für Release.

## FAQ

**Schreibt UN R155 bestimmte Security-Tests vor?**

Nein. Die Regelung verlangt vom Fahrzeughersteller, die Wirksamkeit der umgesetzten Sicherheitsmaßnahmen zu testen und die identifizierten Risiken zu behandeln; Annex 5 listet Bedrohungen und Maßnahmen zum Berücksichtigen. Welche Tests das belegen, bleibt dem Hersteller überlassen, und genau deshalb sind nachverfolgbare Testfälle so wichtig.

**Wird ein Zulieferer nach UN R155 auditiert?**

Die Genehmigung erhält der Fahrzeughersteller, nicht der Zulieferer. Zulieferer werden einbezogen, weil der Hersteller Zuliefererrisiken managen muss und deren Nachweise braucht; ein Tier-1 wird also nach Testergebnissen, Nachverfolgbarkeit und eigenen Cybersecurity-Arbeitsergebnissen gefragt.

**Kann ein Test-Tool ein Fahrzeug R155-konform machen?**

Nein. Ein Tool erzeugt Testergebnisse und Nachweise. Konformität kommt aus dem Cybersecurity-Managementsystem des Herstellers und seiner Typgenehmigung, die ein technischer Dienst und eine Genehmigungsbehörde bewerten.

## Sources

- [UN-Regelung Nr. 155: Cyber security and cyber security management system](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)
- [ISO/SAE 21434:2021 Straßenfahrzeuge, Cybersecurity-Engineering, Clauses 7, 10, 11 und 15](https://www.iso.org/standard/70918.html)
- [ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1](https://www.iso.org/standard/72439.html)

## Related

- [UN R155 (UN-Regelung Nr. 155, Cyber Security)](https://auto-st.com/de/glossar/un-r155)
- [CSMS (Cybersecurity Management System)](https://auto-st.com/de/glossar/csms)
- [Nachverfolgbarkeit im ISO 21434 Audit: Fuzzing zählbar machen](https://auto-st.com/de/insights/traceability-iso-21434-audit)
- [ISO/SAE 21434 Verifikationsnachweise aus Security-Tests](https://auto-st.com/de/insights/iso-21434-verifikationsnachweise)
- [AutoST für ISO/SAE-21434-Compliance-Manager: Nachvollziehbare Testnachweise](https://auto-st.com/de/fuer/iso-21434-compliance-manager)
- [Nachweise für deine 21434-Arbeit, auf Abruf.](https://auto-st.com/de/iso-21434-tests)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/insights/un-r155-audit-was-tester-brauchen