ISO/SAE 21434: Der Engineering-Lebenszyklus als Nachweisbasis

Problem in der Praxis

Viele Programme behandeln ISO/SAE 21434 als Zertifizierungsaufgabe: Ein Prozessrahmen wird abgearbeitet, TARA-Dokumente entstehen, und man hofft auf die Genehmigung. Im Behördenaudit zeigt sich die Lücke. Gefragt wird nicht, ob ein Prozess existiert, sondern ob die Cybersecurity-Aktivitäten über Konzept, Entwicklung, Produktion und Betrieb zusammenhängen und durch belastbare Nachweise gestützt sind.

Hinzu kommen zwei Verwechslungen: Ein ISO-27001-ISMS oder ein TISAX-Label wird als Beleg für Produkt-Cybersecurity präsentiert, obwohl ein ISO-27001-ISMS nur die Organisations-Informationssicherheit und TISAX zusätzlich Prototypen- und Datenschutz adressiert, nicht das typgenehmigte Fahrzeug. Und Engineering-Artefakte entstehen, ohne zu einer durchgängigen, vorlegbaren Nachweisspur zusammengeführt zu werden.

CISO-Einordnung

ISO/SAE 21434 ist wirksam, weil sie den Lebenszyklus in Phasen ordnet, in denen Nachweise entstehen: Governance und Management, Risikobewertung (TARA), Konzept- und Produktentwicklung, Verifikation und Validierung, Produktion, Betrieb mit Monitoring und Incident Response sowie Außerdienststellung.

Drei Einordnungen sind maßgeblich:

• ISO/SAE 21434 liefert Methode und Arbeitsergebnisse; R155 liefert die Pflicht und zwei Prüfebenen: das CSMS, das die Behörde auditiert und mit einem Konformitätszertifikat bestätigt, und die fahrzeugbezogene Bewertung pro Typ. Der frei zugängliche UNECE-Anhang 5 strukturiert dabei den Referenzkatalog aus Bedrohungen und Maßnahmen.
• Der Lebenszyklus erzeugt genau die Nachweise, auf die sich die Genehmigung stützt: Entstehen sie im Regelbetrieb, ist das Audit eine Bestätigung, sonst ein Risiko.
• Konformität ist notwendig, aber nicht hinreichend. R155 wird zudem über R156 (Software-Update-Management, Engineering-Norm ISO 24089) ergänzt; beides gehört im Lebenszyklus zusammen.

Umsetzungsperspektive

Aus CISO-Sicht beginnt die Umsetzung nicht mit Dokumentenvorlagen, sondern mit einer durchgängigen Nachweislogik:

• Governance verankern: klare Rollen und Entscheidungswege für Produkt-Cybersecurity, verzahnt mit dem ISMS.
• Risiko zuerst: eine wiederholbare TARA-Praxis, deren Ergebnisse Anforderungen, Maßnahmen und Restrisikoentscheidungen treiben.
• Nachweise als Nebenprodukt: Arbeitsergebnisse so erzeugen, dass sie ohne Nacharbeit auditierbar sind.
• Lieferkette einbinden: Cybersecurity-Verantwortung zwischen OEM und Zulieferern vertraglich und nachweisseitig klären, da der OEM die Genehmigung trägt.
• Betrieb mitdenken: Monitoring, Schwachstellen- und Vorfallmanagement sowie sichere, auch drahtlose Software-Updates.

Das CSMS-Konformitätszertifikat ist zeitlich befristet und durch Re-Audit zu erneuern; der Lebenszyklus läuft über den Start of Production hinaus als Regelkreis weiter.

Typische Fehler

1. ISO/SAE 21434 wird als Zertifizierungsprojekt statt als laufende Nachweisbasis für die Typgenehmigung verstanden.
2. TISAX oder ein ISO-27001-ISMS werden als Ersatz für den Produkt-Cybersecurity-Nachweis behandelt.
3. TARA-Ergebnisse bleiben Dokumente und treiben weder Anforderungen noch Restrisikoentscheidungen.
4. Nachweise werden vor dem Audit konstruiert statt im Engineering-Betrieb erzeugt.
5. Betrieb, Incident Response, Software-Update-Fähigkeit (R156, ISO 24089) und die Lieferkette werden vom Lebenszyklus abgekoppelt.

Risiken und Trade-offs

Ein zu prozesslastiger Ansatz erzeugt Arbeitsergebnisse, aber keine belastbare Steuerung; das Audit wird teuer und fragil. Ein zu schlanker Ansatz gefährdet die Genehmigungsfähigkeit ganzer Fahrzeugtypen. Standardisierte Prozesse erleichtern Nachweis und Re-Audit, passen aber nicht zu jeder Plattform- und Zulieferkonstellation.

Beim Geltungsbereich gilt: Typgenehmigte Fahrzeuge unter VO (EU) 2019/2144 sind vom Cyber Resilience Act ausgenommen; dieselben Komponenten können jedoch separat außerhalb des Typgenehmigungsregimes vertrieben wieder in den CRA-Anwendungsbereich fallen. Produkt-Cybersecurity und Organisations-Compliance (etwa NIS2-Pflichten des OEM als Einrichtung) sind zudem unterschiedliche Mechanismen mit unterschiedlichen Behörden und klar abzugrenzen.

Entscheidungspunkte

• Wie wird die durchgängige Nachweisspur vom Engineering bis zur Genehmigungsbehörde organisiert und wer verantwortet sie?
• Welche Cybersecurity-Verantwortung liegt beim OEM, welche bei Zulieferern, und wie wird das belegt?
• Wie werden Cybersecurity-Lebenszyklus (R155, ISO/SAE 21434) und Software-Update-Management (R156, ISO 24089) verzahnt?
• Wie werden ISMS- und TISAX-Nachweise klar von Produkt-Cybersecurity-Nachweisen getrennt?
• Wie werden der Geltungsbereich gegenüber dem CRA und die Erneuerung des CSMS-Zertifikats sichergestellt?

Praktische Empfehlungen

1. Verstehen Sie den Lebenszyklus als Nachweisbasis für R155, nicht als isoliertes Zertifizierungsziel.
2. Machen Sie TARA zum Treiber von Anforderungen und Restrisikoentscheidungen.
3. Erzeugen Sie Nachweise im Regelbetrieb, sodass das Audit Bestätigung statt Rekonstruktion ist.
4. Trennen Sie Produkt-Cybersecurity sauber von ISMS und TISAX und nutzen Sie diese komplementär.
5. Verzahnen Sie Cybersecurity- und Software-Update-Lebenszyklus und klären Sie den Geltungsbereich gegenüber CRA und NIS2.

Relevante Normreferenzen

• UN-Regelung Nr. 155 (Cyber Security und CSMS): verbindliche Anforderung im Typgenehmigungsrecht; frei zugänglich über UNECE.
• UN-Regelung Nr. 156 (Software Update und SUMS): ergänzende Anforderung an Software-Updates inklusive drahtloser Updates; frei zugänglich über UNECE.
• Verordnung (EU) 2019/2144 (General Safety Regulation): macht UN R155 und R156 im EU-Typgenehmigungsrecht verbindlich; frei zugänglich über EUR-Lex.
• ISO/SAE 21434: Referenz für den Cybersecurity-Engineering-Lebenszyklus; kostenpflichtig, hier nur Struktur und Konzept.
• ISO 24089: Referenz für Software-Update-Engineering; korrespondiert mit R156, kostenpflichtig.
• ISO/IEC 27001: Referenz für Organisations-Informationssicherheit (ISMS); ersetzt CSMS und Typgenehmigung nicht.