# ECU-Security-Tests intern vs. externes Prüflabor

> Interne ECU-Security-Tests heißt: Deine Engineers fahren die Tests am eigenen Prüfstand, so oft es der Release-Zyklus braucht, mit den Ergebnissen in der eigenen Hand. Ein externes Prüflabor bringt unabhängige Assessoren, Spezialwerkzeuge und Hardware, die du nicht besitzt, und einen Bericht, der bei OEM oder Assessor Gewicht hat. Das Labor ist die bessere Wahl für Unabhängigkeit und den ersten Blick auf eine neue Plattform; der eigene Prüfstand ist die bessere Wahl für alles, was bei jedem Build passieren muss.

ECU-Tests am eigenen Prüfstand bringen Tempo und Kontrolle; ein externes Labor bringt Unabhängigkeit, Spezialisten und Hardware. Was zu Zulieferer oder OEM passt.

Source: https://auto-st.com/de/vergleich/ecu-tests-intern-vs-prueflabor · Updated: 2026-10-07

## Was ist der Unterschied?

Interne Tests heißt: Steuergerät, Prüfstand und Engineer gehören dir. Du entscheidest, wann ein Test läuft, du siehst das Ergebnis am selben Nachmittag, und nichts von Firmware oder Diagnosebeschreibung verlässt das Haus. Die Grenzen sind Expertise und Unabhängigkeit: Dein Team kennt dein Steuergerät, aber vielleicht nicht, was Angreifer mit den Steuergeräten anderer Leute machen, und ein Zulieferer, der sein eigenes Produkt bewertet, ist nicht das, was ein OEM unter Validierung versteht.

Ein externes Prüflabor ist von Haus aus unabhängig. Es bringt Leute mit, die das ganze Jahr Steuergeräte vieler Zulieferer testen, Hardware, die du nicht besitzt (Klimakammern, Busanalysatoren für jeden Transport, Seitenkanal- und Fault-Injection-Aufbauten, wo nötig), und einen Bericht, den OEM oder Assessor als Nachweis Dritter akzeptieren. Die Grenzen sind Zeit und Kosten: Ein Laborauftrag ist ein Projekt mit Scope, Starttermin und Lieferergebnis, und das Steuergerät, das du schickst, ist eine Momentaufnahme. Sechs Wochen später gibt es eine neue Firmware, und der Bericht beschreibt die alte.

## Nebeneinander

| | Interne Tests | Externes Prüflabor |
|---|---|---|
| Findet | Alles, was deine Tools und Leute abdecken, bei jedem Build: Diagnoseoberfläche, SecurityAccess-Schwächen, Robustheit beim Fuzzing, Ethernet-Exposition, IVI-Härtung, Regressionen | Alles, was ein erfahrener Außenstehender an einer Momentaufnahme findet: das oben Genannte plus Schwächen auf Firmware-Ebene, verkettete Angriffe, Hardware-Angriffe, Vergleich mit dem, was andere Zulieferer tun |
| Übersieht | Blinde Flecken eines Teams, das das Produkt zu gut kennt; die Unabhängigkeit, die ein Assessor für die Validierung will | Regressionen nach dem Bericht; deinen internen Kontext; alles außerhalb von Scope und gebuchten Wochen |
| Wer macht es | Deine Test- und QA-Engineers, idealerweise mit einem Security-affinen Verantwortlichen | Die Security Engineers des Labors, unter einer Vereinbarung mit Scope und Spielregeln |
| Prüfstandszeit | Minuten bis Stunden pro Lauf, sobald ein Build fertig ist | Zwei bis sechs Wochen pro Auftrag inklusive Bericht, plus Versand der Muster |
| Kosten | Prüfstandshardware, die du meist hast, Engineer-Zeit, eine Tool-Lizenz pro Komponente | Projektpreis pro Auftrag; ECU-Penetrationstests typischerweise 20.000 bis 45.000 Euro in Deutschland und der EU, kein Angebot |
| Passt in den Release-Zyklus | Ja, das ist der Sinn der Sache | Nein; einmal pro Plattformgeneration, vor SOP und nach großen Änderungen |
| Verlangt von | Die Verifikation nach ISO/SAE 21434 Clause 10.4.2 ist Aufgabe des Zulieferers selbst; das CSMS nach UN R155 verlangt vom Hersteller, Tests entlang der Lieferkette zu steuern | Unabhängigkeit für die Validierung (Clause 11) verlangen viele OEM-Anforderungskataloge und in der Praxis die Assessoren der Typgenehmigung |
| Ergebnis | Scan-Historie, PDF und SARIF pro Lauf, ein Fix Plan, den deine Engineers abarbeiten | Ein unterschriebener Bericht mit Methode, Findings, Reproduktion und Empfehlungen; Präsentation und Retest |

## Nimm interne Tests, wenn

- du öfter als einmal im Jahr Firmware freigibst oder ein Steuergerät in mehreren Varianten auslieferst. Jedes Release braucht dieselben Checks, und ein Labor lässt sich nicht jeden Sprint buchen.
- Vertraulichkeit streng ist. ODX- und CDD-Dateien, Vorserien-Firmware und Seed/Key-Material bleiben auf deinen eigenen Servern; nichts muss verschickt oder hochgeladen werden.
- Findings gefixt werden sollen, solange der Entwickler die Änderung noch im Kopf hat. Ein Ergebnis am selben Tag ist mehr wert als ein besseres in sechs Wochen.
- dein Team lernen soll. Engineers, die jede Woche Enumeration fahren und Negative Response Codes lesen, werden zu den Leuten, die das nächste Steuergerät besser entwerfen.
- die Checks wiederholbarer Art sind: Sessions, Services, DIDs, SecurityAccess-Zähler, Fuzzing-Robustheit, DoIP-Routing, SOME/IP-Exposition. Tools können das gut, und ein Labor würde auch Tools nehmen.

## Nimm ein externes Prüflabor, wenn

- Unabhängigkeit die Anforderung ist. Der eigene Bericht eines Zulieferers erfüllt selten die Validierungsklausel eines OEM, und ein Assessor für die UN-R155-Typgenehmigung wird fragen, wer getestet hat.
- die Plattform neu ist und intern noch niemand so eine angegriffen hat. Ein erster externer Pentest setzt die Basis, die die interne Suite später schützt.
- du Hardware oder Fähigkeiten brauchst, die du für ein Projekt nicht aufbaust: Firmware-Extraktion aus einem gesperrten Mikrocontroller, Fault Injection, Seitenkanäle, Umwelttests.
- du noch keinen Prüfstand hast. Ein Laborauftrag ist auch ein Weg zu lernen, wie ein Prüfstand für dieses Steuergerät aussehen sollte.

## Beides zusammen

Die Kombination, die funktioniert: Ein externes Labor testet jede neue Plattform einmal, tief und unabhängig, vor SOP. Der interne Prüfstand fährt ab dann die wiederholbare Suite bei jedem Build und verhindert, dass die Labor-Findings zurückkommen. Wenn der nächste Laborauftrag ansteht, bekommt der Tester die interne Scan-Historie und steckt die Tage in das, was Automatisierung nicht sehen kann.

AutoST bedient beide Seiten davon. Zulieferer und OEMs fahren es an eigenen Prüfständen; Prüflabore fahren es an den Steuergeräten ihrer Kunden, um den wiederholbaren Teil über Aufträge hinweg gleich zu halten und PDF und SARIF mit dem Bericht zu übergeben. Die Penetrationstester von Zyberum sind in diesem Sinn ein Labor, und wir sagen klar: AutoST ist das Werkzeug für ihren ersten Tag, kein Ersatz für die folgenden Wochen.

## FAQ

**Akzeptiert ein OEM interne Testergebnisse?**

Als Verifikationsnachweis während der Entwicklung meist ja, sofern Methode und Ergebnisse nachvollziehbar sind: was wurde getestet, mit welcher Tool-Version, wann, und was ist aus jedem Finding geworden. Für die Validierung der Cybersecurity-Ziele verlangen viele OEM-Anforderungskataloge einen unabhängigen Test, und da kommt das Labor ins Spiel. Schau ins Cybersecurity Interface Agreement; ISO/SAE 21434 Clause 7 ist der Ort, an dem diese Aufteilung dokumentiert wird.

**Was kostet ein Laborauftrag im Vergleich zum eigenen Aufbau?**

Ein Labor rechnet pro Projekt ab: Ein ECU-Penetrationstest liegt typischerweise bei 20.000 bis 45.000 Euro, eine typische Marktspanne für Deutschland und die EU, kein Angebot, plus Hardware- oder Umwelttests, falls nötig. Ein eigener Aufbau kostet den Prüfstand, den du meist schon hast, die Zeit deiner Engineers und eine Tool-Lizenz. Für einen Test ist das Labor günstiger; ab dem zweiten Firmware-Release der Prüfstand.

**Kann ein Prüflabor AutoST einsetzen?**

Ja. Labore nutzen es, um den wiederholbaren Teil (Enumeration, SecurityAccess, Fuzzing, DoIP, SOME/IP, IVI) an jedem Kunden-Steuergerät gleich zu fahren und die Zeit ihrer Experten in den manuellen Teil zu stecken. Bericht und SARIF-Export gehen in das Laborergebnis ein.

## Sources

- [ISO/SAE 21434:2021 Straßenfahrzeuge, Cybersecurity Engineering, Clause 7 (verteilte Cybersecurity-Aktivitäten) und Clause 11 (Cybersecurity-Validierung)](https://www.iso.org/standard/70918.html)
- [UN-Regelung Nr. 155, Absatz 7.2 (CSMS-Anforderungen, inklusive lieferantenbezogener Risiken) und Absatz 7.3 (Anforderungen an den Fahrzeugtyp)](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)
- [ISO 14229-1:2020 Unified diagnostic services (UDS), Teil 1: Anwendungsschicht](https://www.iso.org/standard/72439.html)

## Related

- [AutoST für Prüflabore: Eine wiederholbare Baseline für jedes Kundensteuergerät](https://auto-st.com/de/fuer/prueflabore)
- [AutoST für Tier-1-Zulieferer: Teste dein Steuergerät, bevor der OEM es tut](https://auto-st.com/de/fuer/tier-1-zulieferer)
- [Automatisierter ECU-Security-Test vs. manueller Penetrationstest](https://auto-st.com/de/vergleich/automatisierter-ecu-test-vs-manueller-pentest)
- [So schreibst du einen Security-Testplan für ein Steuergerät](https://auto-st.com/de/insights/ecu-security-testplan)
- [Spricht die Busse, die deine ECUs sprechen.](https://auto-st.com/de/protokolle-hardware)
- [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/vergleich/ecu-tests-intern-vs-prueflabor