Software-Update-Management und sichere OTA-Updates nach UN R156

Problem in der Praxis

Software-Updates galten historisch als Werkstatt- oder IT-Thema. OTA verschiebt diese Logik grundlegend, weil ein Hersteller nun direkt und in großer Zahl in das Verhalten zugelassener Fahrzeuge eingreift, teils sicherheits- oder typgenehmigungsrelevant.

In der Praxis behandeln Teams OTA oft weiter wie eine reine Feature-Pipeline. Es fehlt eine durchgängige Konfigurationskontrolle, die HW-/SW-Stände je Fahrzeugtyp mit Integritätsdaten verknüpft, und die RxSWIN-Pflege ist lückenhaft. Dann bleibt unklar, welches Update eine Typgenehmigung berührt, wann eine erneute Bewertung nötig ist und wie Abhängigkeiten, Integrität und Rückfallebene gesichert sind. Spätestens bei einer Auditfrage zeigt sich die Lücke: Wer hat welche Version auf welcher Bewertungsgrundlage und mit welchem Nachweis von Echtheit und Unversehrtheit freigegeben?

CISO-Einordnung

UN R156 verlangt zwei Dinge, die der CISO klar trennen sollte. Erstens ein SUMS als Managementsystem auf Organisationsebene: Konfigurationskontrolle der Versionsstände, RxSWIN-Pflege, Abhängigkeits- und Kompatibilitätsprüfung, die Bewertung, ob ein Update Typgenehmigungen berührt, sowie die sichere Durchführung inklusive OTA. Zweitens die fahrzeug- und typbezogene Umsetzung, in der diese Prozesse je Release wirksam werden.

Wichtig ist die Abgrenzung zur Schwesterregelung UN R155: R155 verlangt ein Cyber Security Management System (CSMS), R156 das SUMS. Beide sind Managementsysteme unter dem Dach der UNECE-WP.29 und werden auditiert, sind aber nicht deckungsgleich; ein CSMS-Nachweis deckt das SUMS nicht ab. Ebenso wenig ersetzt ein ISMS nach ISO/IEC 27001 das SUMS oder TISAX die Pflicht: ISMS und TISAX adressieren Organisations-Informationssicherheit, Prototypenschutz und Datenschutz, nicht die produkt- und typgenehmigungsbezogene Cybersecurity des Fahrzeugs.

Umsetzungsperspektive

ISO 24089 beschreibt Engineering-Prozesse für Software-Updates und korrespondiert mit den SUMS-Anforderungen aus R156. Ein belastbares SUMS sollte folgende Bausteine im Regelbetrieb verbinden:

• Konfigurationsmanagement als verlässliche Quelle für HW-/SW-Stände je Fahrzeugtyp samt Integritätsdaten.
• RxSWIN-Governance, die typgenehmigungsrelevante Software eindeutig identifiziert und fortschreibt.
• Eine verpflichtende Impact-Bewertung je Update: Berührt es Typgenehmigung, Funktionssicherheit oder Cybersecurity, und ist eine erneute Bewertung nötig?
• Eine abgesicherte Auslieferungskette mit Signatur, Integritätsprüfung, Rückfallebene und sicherem Zustand.
• Fahrzeugseitige Vorbedingungen für OTA, etwa Ausschluss kritischer Betriebszustände während der Installation.
• Backend- und Lieferketten-Sicherheit, da das Update-Backend selbst eine Angriffsfläche ist.

Aus jedem Schritt sollten Nachweise als Nebenprodukt entstehen, nicht erst kurz vor einem Audit.

Typische Fehler

1. OTA wird als reine Feature-Pipeline betrieben, ohne regulatorisches Freigabe-Gate.
2. Die RxSWIN wird nicht gepflegt oder nicht sauber mit der Typgenehmigung verknüpft.
3. Es fehlt eine dokumentierte Impact-Bewertung je Update.
4. Integrität und Echtheit werden nur auf der Transportstrecke gesichert, nicht durchgängig bis ins Steuergerät.
5. Rückfallebene und sicherer Zustand bei fehlgeschlagenem Update sind nicht definiert.
6. Das CSMS-Konformitätszertifikat wird fälschlich so behandelt, als decke es auch das SUMS ab.

Risiken und Trade-offs

Der zentrale Trade-off liegt zwischen Geschwindigkeit und Steuerung. OTA erlaubt schnelle Korrekturen, auch sicherheitsrelevante Patches im Zusammenspiel mit R155, doch jedes Update bleibt eine Änderung am zugelassenen Produkt. Ein zu starres Gate verzögert wichtige Sicherheits-Updates; ein zu lockeres Vorgehen riskiert nicht bewertete typgenehmigungsrelevante Änderungen. Hinzu kommt: heterogene Flotten erschweren Rollback, das Update-Backend ist ein Angriffsziel mit Flottenreichweite, und die Abhängigkeit von Zulieferern verlagert Nachweislast in die Lieferkette.

Entscheidungspunkte

• Welche Update-Klassen sind typgenehmigungsrelevant und damit im RxSWIN-Geltungsbereich?
• Welche Kriterien lösen eine erneute Bewertung oder Genehmigung aus?
• Welche Updates erfolgen OTA, welche bleiben werkstattgebunden?
• Wie werden Echtheit und Integrität durchgängig bis ins Zielsteuergerät sichergestellt?
• Welche Rückfall- und Safe-State-Strategie gilt bei Fehlern?
• Wer verantwortet die Sicherheit des Update-Backends und der Lieferkette?

Praktische Empfehlungen

1. Bauen Sie das SUMS als betriebenen Prozess auf, nicht als Dokumentensammlung für das Audit.
2. Etablieren Sie eine einzige verlässliche Quelle für Fahrzeug-Konfiguration und RxSWIN.
3. Machen Sie die Impact-Bewertung zum verbindlichen Gate vor jedem Release.
4. Sichern Sie Updates durchgängig: Signatur, Integrität, Rückfallebene, Vorbedingungen.
5. Erfassen Sie Zulieferer-Beiträge vertraglich und mit nachvollziehbaren Nachweisen.
6. Stimmen Sie SUMS und CSMS aufeinander ab, halten Sie beide aber als eigenständige Systeme.

Relevante Normreferenzen

• UN-Regelung Nr. 156: Software Update und SUMS (Anhang zum UNECE-1958er-Abkommen, WP.29/GRVA; frei über unece.org).
• UN-Regelung Nr. 155: Cybersecurity und CSMS (Schwesterregelung; frei über unece.org).
• VO (EU) 2019/2144 (General Safety Regulation, CELEX 32019R2144, vom 27.11.2019): macht R155/R156 im EU-Typgenehmigungsrecht verbindlich; neue Fahrzeugtypen ab 6. Juli 2022, alle neu zugelassenen Fahrzeuge ab Juli 2024.
• ISO 24089:2023 (mit Amd 1:2024): Software update engineering (kostenpflichtig, reference-only).
• ISO/SAE 21434:2021: Cybersecurity engineering (kostenpflichtig, reference-only).
• ISO/IEC 27001: ISMS-Referenz zur Abgrenzung (reference-only).