Warum sich das Cybersecurity-Konzept (ISO/SAE 21434) nicht nur auf das Fahrzeug beschränken darf: Impulse für Cybersecurity Manager

Praktisch bedeuten die Anforderungen aus der UN R155 und ISO/SAE 21434 nichts anderes, als ein regelrechtes „Betriebssystem” für Cybersicherheit in der gesamten Fahrzeug-Organisation aufzubauen – eines, das Projektmanagement, Werke und Produktionsstätten, Lieferanten, IT- und OT-Infrastrukturen, Qualitätssicherung sowie Personal- und Beschaffungswesen konsistent miteinander verbindet.

Damit stellt Cybersicherheit im Fahrzeugumfeld mehr dar, als eine isolierte Technikdisziplin, die irgendwo in der Entwicklungsabteilung zu verorten ist.

Die zentrale Rolle des Cybersecurity Managers: Verantwortung zwischen Organisation und Projekt

Im Zentrum dieser Gesamtarchitektur steht in der Regel die Rolle des Cybersecurity Managers. Entscheidend dabei ist: Diese Rolle ist nicht eindimensional zu verstehen. In der Praxis wird diese Funktion für zwei unterschiedliche Verantwortungsbereiche verwendet, die zwar eng miteinander verzahnt sind, aber unterschiedliche Wirkungsebenen adressieren. Zum einen das Projekt, zum anderen die Organisation.

Aus unserer Erfahrung sind rund vier von fünf Kolleginnen und Kollegen mit dem Titel Cybersecurity Manager letztendlich primär in projektbezogenen Rollen unterwegs.

Sie verantworten dabei die ordnungsgemäße Umsetzung von Cybersecurity-Aktivitäten innerhalb eines konkreten Entwicklungsprojekts: von der Schärfung der Item Definition über die Planung der TARA, Cybersecurity Concept und Verifikation bis zur Bereitstellung der erforderlichen Work Products für Reviews, Assessments und Typgenehmigung. Vereinfacht gesagt: Es soll mit dieser Rolle eine verantwortende Funktion geschaffen werden, die auf der operativen Ebene des Projekts „irgendwie alles mit Cybersicherheit“ realisieren soll.

Daneben existiert – teils explizit benannt, teilweise implizit gelebt – eine Rolle auf Organisations-Ebene, häufig als Global Security Manager, Head of Cybersecurity oder vergleichbar.

Diese Rolle verantwortet definitionsgemäß nicht einzelne Projekte, sondern übergreifende Cybersecurity-Governance in der Organisation: Policies, Rollenmodelle, Prozesse, Schnittstellen, Eskalationsmechanismen sowie die Integration von Cybersecurity in bestehende Managementsysteme.

Und hier entsteht das Kernproblem, das dieser Artikel adressieren soll: Häufig lassen sich cybersicherheitsrelevante Notwendigkeiten nicht auf Projektebene „lösen“. Vielmehr müssen auf Ebene der Organisation die Voraussetzungen geschaffen werden (Strukturen, Prozesse, Vorgehensweisen), damit Projekte Cybersicherheit überhaupt wirksam, effizient und auditsicher umsetzen können.

So ist diese entscheidet diese Schnittstelle zwischen Organisation und Projekt, ob Cybersecurity in der Praxis als formales Dokumentationsartefakt endet oder als wirksames System im Entwicklungs-, Produktions- und Betriebsalltag funktioniert.

Das Cybersecurity Concept ist damit nicht nur ein technisches Bindeglied, sondern auch ein Spiegel dafür, wie gut Organisation und Projekt in ihrer Verantwortung verzahnt sind.

Der Cybersecurity Manager als Governance-Owner der Security

Die Rolle des Cybersecurity Managers muss also fundamental anders verstanden werden als die klassische Vorstellung eines technischen Sicherheitsspezialisten.

Der Cybersecurity Manager fungiert vielmehr als Owner für die gesamte Cybersecurity-Governance: Er oder sie verantwortet die Etablierung und Durchsetzung(!) von Policies, die klare Definition von Zuständigkeiten über Organisationsgrenzen hinweg, die Ausgestaltung wirksamer Eskalationswege, die strategische Allokation von Ressourcen sowie die kontinuierliche Wirksamkeitskontrolle(!) durch KPIs und Audits.

Das ist für jede Organisation, die etwas am Markt verkaufen will, von fundamentaler Bedeutung.

Nicht zuletzt trägt die Rolle des Cybersecurity Manager die Verantwortung für die Beweisführung gegenüber externen Audits – ein Aspekt, der spätestens bei der Typgenehmigung nach UNR155, GB-44495 & Co geschäftskritisch wird.

Dies gilt genauso in der Welt der Zulieferer und Technologieanbieter: Die ISO/SAE 21434 unterstreicht die organisatorische Verankerung explizit, indem sie definierte Verantwortlichkeiten und die Verteilung von Cybersecurity-Aktivitäten über mehrere Organisationen hinweg fordert – etwa zwischen OEM, Tier-1-Lieferanten und nachgelagerten Zulieferern.

Wichtig: Das Mandat und die Handlungskompetenz für den Automotive Cybersecurity Manager

Die operative Umsetzung dieser Anforderungen verlangt vom Cybersecurity Manager ein klares Mandat (Stichwort: Management Commitment), ausreichendes Budget und ausgeprägte Schnittstellenkompetenz, um Core-Teams aufzubauen, spezialisierte Funktionen wie Testteams oder Incident-Response-Einheiten zu etablieren, Kompetenzen zielgerichtet zu entwickeln und verbindliche Eskalationspfade zu definieren.

Ein bewährter Ansatz besteht darin, die Cybersecurity-Governance eng an bereits etablierte Managementsysteme anzudocken – insbesondere an Quality-Management-Strukturen.

Definierte Prozesse, unabhängige Audits und Reviews, Management-Reviews sowie eine klare „Authority to act” sind dann keine neuen Erfindungen, sondern werden als bewährte Mechanismen adaptiert und auf den Cybersecurity-Kontext übertragen.

Erst dann sind für den oder die Verantwortliche für Cybersicherheit auf Projektebene überhaupt die Voraussetzungen auf Organisationsebene gegeben, um seinen/ihren Teil der Themen effektiv im Projekt angehen zu können.

Soweit zur etwas abstrakten Einführung. Was bedeutet das nun konkret?

Der Blick auf das Cybersecurity Concept (gemäß ISO/SAE 21434) als zentrales Work Product: Mehr als nur Fahrzeugtechnik

Ein besonders anschauliches Beispiel dafür, warum nachhaltiges Cybersicherheit zwingend über die reine Fahrzeugtechnik hinausgehen muss, ist das sogenannte Cybersecurity Concept, eines der zentralen Work Products, das die ISO/SAE 21434 in der Konzeptphase explizit fordert.

Der Zweck dieses Work Products ist dabei klar definiert: Das Cybersecurity Concept beschreibt die Strategie zur systematischen Reduzierung der identifizierten technischen Cybersecurity-Risiken im Fahrzeug. Es übersetzt die Ergebnisse der risikobasierten Analyse (insbesondere der TARA) in konkrete Cybersecurity-Anforderungen und legt fest, mit welchen technischen und nicht-technischen Maßnahmen Cybersicherheit effektiv erreicht werden soll.

Mit dieser „strategischen Übersetzungsfunktion“ wird deutlich, warum sich das Cybersecurity Concept nicht auf fahrzeuginterne Sicherheitsmechanismen beschränken darf.

Neben technischen Anforderungen an das Fahrzeug adressiert es explizit auch Anforderungen an die operative Umgebung – und erkennt damit an, dass die Wirksamkeit technischer Controls untrennbar von den sie umgebenden Prozessen, Strukturen und organisatorischen Rahmenbedingungen abhängt.

Genauer gesagt: Dieses Dokument ist weit mehr als eine technische Spezifikation von Sicherheitsmechanismen im Fahrzeug.

Und noch genauer gesagt: Es besteht aus Cybersecurity-Anforderungen an das Produkt und Anforderungen an die operative Umgebung, die beide aus den Cybersecurity Goals abgeleitet werden und auf einer umfassenden Betrachtung des betrachteten Items basieren.

Das Cybersecurity Concept ist das verbindende Element zwischen der risikobasierten Analyse- und Bewertungsarbeit und der technischen Implementierung – aber es beschränkt sich keineswegs auf letztere.

Entscheidend ist die Formulierung “Anforderungen an die operative Umgebung”: Hier wird explizit anerkannt, dass selbst die robusteste technische Sicherheitsarchitektur im Fahrzeug nur dann wirksam sein kann, wenn die umgebenden Prozesse, Systeme und organisatorischen Rahmenbedingungen dies unterstützen.

Ein Cybersecurity Concept, das ausschließlich definieren würde, welche kryptografischen Verfahren oder Netzwerkmechanismen im Fahrzeug zum Einsatz kommen, greift strukturell zu kurz.

Damit reden wir über die Notwendigkeit von Ergänzungen auf organisatorischer Ebene. Mit anderen Worten: Diese organisatorische Fundierung sollte im Cybersecurity Concept kein nachgelagertes Implementierungsdetail darstellen, sondern stellt viel mehr eine Voraussetzung dafür dar, dass das Cybersecurity Concept als Work Product überhaupt sinnvoll erstellt, verifiziert und in nachfolgende Phasen überführt werden kann.

Ein Cybersecurity Concept, das diese organisatorischen Dimensionen ausblendet, mag formal den Anforderungen entsprechen, wird in der Praxis jedoch scheitern, weil die notwendigen Fähigkeiten, Strukturen und Wirksamkeitsüberprüfungen fehlen, um es wirksam umzusetzen.

Was sind nun aber “Anforderungen an die operative Umgebung” die ein vollständiges Cybersecurity Concept zwingend adressieren muss? Und – dies erweitert – welche Grundvoraussetzungen müssen eigentlich erfüllt sein, damit ein Cybersecurity Concept effektiv wirksam sein kann?

Acht zentrale Handlungsfelder als Vorrausetzung für ein effektives Cybersecurity Concept

Vor diesem Hintergrund lassen sich zentrale Handlungsfelder ausmachen, die jeweils an kritischen Übergängen von immenser Bedeutung für die Gesamt-Fahrzeug Cybersicherheit sind – etwa zwischen Werk und Entwicklung, zwischen Testumgebungen und Produktion, an Supplier-Schnittstellen, an IT/OT-Grenzen, in Change-Prozessen.

Mit der nachfolgenden Aufstellung, die keineswegs einen Anspruch auf Vollständigkeit erhebt, soll in erster Linie aufgezeigt werden, wie weitreichend diese Handlungsfelder in die gesamte Organisation, Strukturen und Prozesse einwirken.

Sie soll vor allem verdeutlichen, dass nicht die bloße Existenz technischer Mechanismen letztendlich die beabsichtigte Wirkung erzielt, sondern dass effektive Sicherheit erst durch die Organisation drumherum garantiert wird. Dazu gehören die Einhaltung, Autorisierung, Nachvollziehbarkeit und gegebenenfalls Wiederherstellung der Mechanismen im täglichen Betrieb.

Fangen wir an:

1. Netzwerksegmentierung: Mehr als Architekturdiagramme

Netzwerksegmentierung im Automotive-Kontext erschöpft sich nicht im Zeichnen sauberer Architekturdiagramme. Sie ist vielmehr eine Governance-Frage über Verantwortungsgrenzen und die tatsächliche Betriebsrealität.

Segmentierung trennt Zonen mit unterschiedlichen Schutzbedarfen – etwa Engineering-Netze, Testumgebungen, Produktions-OT-Systeme oder Supplier-Remote-Access-Zonen – und reduziert das Risiko lateraler Bewegungen nach einem initialen Einbruch (der häufig ja eine Insider-Attacke ist).

Denken wir dies in der Methodik der TARA: So verkleinert eine wirksame Netzwerksegmentierung gezielt das Window of Opportunity entlang potenzieller Attack Paths. Ein Entwickler erhält beispielsweise keinen Zugriff auf die final freigegebenen Software-Artefakte, die in der Produktion ins Fahrzeug geflasht werden, während umgekehrt Mitarbeitende in der Produktion – häufig temporär beschäftigt und mit begrenzter Vorabprüfung – keinen Zugriff auf sensible Entwicklungsdaten, Architekturen oder sicherheitskritische Dokumentationen haben.

Organisatorisch erfordert dies klare Network-Ownerships, die eindeutig regeln, wer für welche Netzwerkzone zuständig ist (IT-Abteilung versus OT-Betrieb versus Engineering), definierte Schnittstellen und Übergabepunkte zwischen diesen Zonen, Freigabeprozesse für begründete Ausnahmen, verbindliche Logging- und Monitoring-Pflichten sowie regelmäßige Reviews der Segmentierungsarchitektur.

Denn in der Praxis erodiert selbst die durchdachteste Segmentierung schnell durch „temporäre” Brücken – Debug-Interfaces für Entwickler, spezielle Test-Setups oder kurzfristig eingerichtete Supplier-VPNs.

Die R155-Denke verstärkt diese Anforderung, da die Fähigkeit zur Überwachung und Detektion über die gesamte relevante Infrastruktur hinweg nicht als optionales Add-on, sondern als verpflichtende Fähigkeit verstanden wird.

Welche verehrenden Konsequenzen die Vernachlässigung haben kann, ist durch folgenreiche Cybersicherheitsvorfälle in der Automobilpraxis bereits deutlich veranschaulicht worden.

So zeigte ein weltweit für Schlagzeilen sorgender Fall eines großen OEMs aus Großbritannien im Jahr 2025 exemplarisch, wie fehlende Netzwerksegmentierung einen gleichzeitigen Ausfall von Produktion und Geschäfts- und besonders Zahlungssystemen über alle globalen Standorte hinweg ermöglichte.

2. Passwortmanagement: Von der Richtlinie zur gelebten Praxis

Passwortmanagement wird im Fahrzeugumfeld insbesondere dort kritisch, wo Menschen und Werkzeuge mit Produktions- und Testsystemen interagieren: Diagnosezugänge, Software-Build- und Flash-Pipelines, Test-Rigs oder Supplier-Portale.

In vielen kleineren OEM- und Zulieferorganisationen ist beispielsweise eine durchgängige Absicherung des Flash-Prozesses über digitale Signaturen noch nicht vollständig etabliert. In diesen Fällen wird beim Flashen der Zugriff auf Steuergeräte häufig über eine Passwort-Abfrage geregelt, die prüft, ob das System berechtigt ist, neue Software zu installieren.

Dieser Mechanismus ist jedoch nur dann wirksam, wenn das betreffende Passwort tatsächlich exklusiv bei den wenigen autorisierten Personen verbleibt. Sobald Zugangsdaten breit geteilt, mehrfach verwendet oder informell weitergegeben werden, verliert dieser Schutzmechanismus seine sicherheitsrelevante Wirkung – mit folgenschweren Konsequenzen für die Integrität der in der Produktion eingebrachten Software.

Die ISO/SAE 21434 zielt explizit auf nachweisbare Prozesse und wiederholbare Evidenzen ab.

Passwortregeln dürfen nicht als abstrakte Policy existieren, sondern müssen als durchgesetzte Praxis mit technischen Kontrollen verankert sein: Password-Vaulting, Rotationsintervalle, Multi-Faktor-Authentisierung dort, wo möglich, sowie stets deine konsequente Anwendung des Least-Privilege-Prinzips.

Gleichzeitig zeigt die Praxis, dass hier effektiv ein sinnvolles Maß gefunden werden muss. Übermäßig restriktive Regeln – etwa sehr kurze Passwortwechselzyklen – führen häufig dazu, dass Mitarbeitende mit ihren Passwörtern nicht mehr sinnvoll arbeiten können oder wollen. Die Folge sind informelle Umgehungen wie Notizzettel unter der Tastatur, Einträge in Schränken oder Ablagen in ungesicherten Dateien.

Insbesondere bei einer Vielzahl unterschiedlicher Zugänge ist der Einsatz eines professionellen Passwort-Managers daher nicht nur empfehlenswert, sondern faktisch Voraussetzung für eine sichere und zugleich praxistaugliche Umsetzung.

Zielgerichtete Schulungs- und Awareness-Programme, die sicherstellen, dass eben solche Regeln verstanden und im Alltag gelebt werden, sind unverzichtbar. (Gerade in der altehrwürdigen Automobilbranche lassen sich nämlich weitläufig die größten Diskrepanzen zwischen „auf dem Papier“ und der tatsächlich Handhabe beobachten.)

Best Practice ist es darüber hinaus, Credentials als integralen Bestandteil von Konfigurations- und Asset-Management zu behandeln: Wer besitzt welche Secrets, wo werden sie gespeichert, wie oft werden sie rotiert, und wie wird technisch verhindert, dass Zugangsdaten in Ticketsystemen, E-Mails oder gar Fertigungsanweisungen auftauchen? Erst diese Kombination aus technischer Kontrolle, organisatorischer Einbettung und realistischer Umsetzbarkeit macht Passwortmanagement im Sinne der ISO/SAE 21434 tatsächlich wirksam.

3. Software-Flashing in der Produktion: Der kritische Kontrollpunkt

Software-Flashing in der Produktion stellt einen klassischen „High-Impact Control Point” dar. Hier entscheidet sich, ob ausschließlich autorisierte, integritätsgesicherte Softwarestände ins Fahrzeug gelangen und ob die notwendigen Zugänge zu diesen Systemen wirksam kontrolliert sind.

Idealtypisch gedacht basiert der Flash-Prozess auf kryptografisch signierten und eindeutig gebundenen Software-Artefakten. Jeder einzelne Flash-Vorgang ist dabei nachvollziehbar dokumentiert (wer hat wann welches Image an welcher Station geflasht), und Ausnahmefälle wie Rework oder Reparaturen sind über klar definierte und freigegebene Prozesse geregelt.

Die Praxis sieht anders aus. Insbesondere bei Steuergeräten älterer Generationen fehlen häufig die technischen Voraussetzungen für eine vollständige Signaturprüfung oder sichere Schlüsselablage auf dem Steuergerät. In solchen Fällen kommen alternative Mechanismen zum Einsatz, etwa eine verpflichtende Passwort- oder Authentisierungsabfrage des Steuergeräts vor dem Start des Flash-Vorgangs (vgl. Passwortmanagement weiter oben). Entscheidend ist dabei weniger der konkrete Mechanismus als dessen Wirksamkeit, Zugriffsbeschränkung und nachvollziehbare Einbettung in definierte Prozesse.

Unabhängig von der konkreten technischen Ausprägung ergeben sich zwei zentrale Herausforderungen, die zwingend auf Organisationsebene adressiert werden müssen und nicht im Projekt gelöst werden können.

• Ein signaturbasierter Flash-Prozess erfordert eine klar definierte Schlüsselstrategie: Es muss festgelegt sein, wo kryptografische Schlüssel innerhalb der Infrastruktur gespeichert werden, wie sie geschützt sind und wie sichergestellt wird, dass sie nicht unbemerkt ersetzt oder missbräuchlich verwendet werden können.
• Im Supplier–Customer-Verhältnis ist eine verbindliche Strategie für den Austausch und die Nutzung von Schlüsseln erforderlich. Insbesondere dann, wenn ein Lieferant die Software initial installiert, der OEM jedoch später in der Lage sein muss, Updates oder Re-Flashes durchzuführen, muss eindeutig geregelt sein, welche Partei welche Schlüssel besitzt, wie Übergaben erfolgen und wie langfristige Update-Fähigkeit sichergestellt wird.

Organisatorisch ist dieser Kontrollpunkt rund um Software-Flashing besonders sensibel, da Produktionsumgebungen typischerweise auf maximalen Durchsatz optimiert sind. Ohne klare Governance und konsequente Wirksamkeitskontrolle besteht die Gefahr, dass Sicherheitskontrollen „nur für den Test” oder „nur kurz wegen Zeitdruck” deaktiviert und anschließend nicht wieder aktiviert werden.

Ein belastbarer Flash-Prozess erfordert daher ein sauberes Zusammenspiel aus Berechtigungsmanagement, Rollentrennung (z. B. Freigabe vs. Ausführung), lückenlosem Logging sowie klaren Schnittstellen zwischen Engineering-Release-Prozessen, Produktions-OT und Qualitätssicherung. Nur so lässt sich sicherstellen, dass Sicherheit nicht nur definiert, sondern im realen Produktionsalltag dauerhaft wirksam bleibt.

4. Speicherung und Handhabung von Keys: Organisationale Kontrolle über den Flash-Prozess hinaus

Die Speicherung und Handhabung von kryptografischem Schlüsselmaterial – private und öffentliche Schlüssel, Zertifikate, Seed- und Key-Material – ist weniger eine isolierte Kryptografie-Frage als vielmehr ein zentrales Betriebs- und Missbrauchsrisiko auf Organisationsebene.

Während im Vorangegangenen der konkrete Einsatz von Schlüsseln im Produktions-Flash-Prozess betrachtet wurde, adressieren wir nun die übergeordnete Frage, wie Schlüssel über Projekte, Produkte, Lieferanten und Lebenszyklusphasen hinweg kontrolliert werden.

Ein Verlust dieser Kontrolle hat unmittelbare systemische Folgen: Sobald private Schlüssel auslesbar sind oder Schlüsselmaterial unkontrolliert in Engineering-Tools, Test-Images oder Werkssysteme diffundiert, ist der gesamte Root of Trust faktisch kompromittiert – unabhängig davon, wie gut einzelne technische Controls im Fahrzeug umgesetzt sind. (Dies ist in der Praxis bereits zu häufig in anschaulichen Vorfällen demonstriert worden.)

Organisatorisch wird also ein eigenständiges Key-Management-System mit klar zugeordnetem Ownership und definiertem Lebenszyklus erforderlich: Erzeugung, Verteilung, Nutzung, Rotation, Sperrung und Außerbetriebnahme. Dazu gehören eindeutige Regeln zur Trennung von Test- und produktiven Schlüsseln, saubere Abgrenzung der zugehörigen Umgebungen sowie technische und prozessuale Maßnahmen, um unautorisierte Kopien oder Substitution von Schlüsseln zu verhindern.

Ergänzend dazu muss zwischen infrastrukturellem Key-Management und produktseitiger Schlüsselverwendung klar unterschieden werden. Mechanismen wie Hardware Security Module (HSM), Secure Elements oder Secure Storage im Steuergerät adressieren die sichere Nutzung von Schlüsseln im Produkt. Die Verantwortung für deren Generierung, Verteilung, Aktivierung und Rücknahme liegt jedoch in der Organisation – typischerweise gestützt durch eine Public Key Infrastructure (PKI), also ein zentrales System zur Verwaltung von Zertifikaten, Schlüsseln und Vertrauensketten.

Eine zusätzliche, oft unterschätzte Herausforderung ergibt sich aus der Lieferkette.

Hersteller müssen jederzeit nachvollziehen können, welcher Supplier welche Schlüssel oder Zertifikate besitzt, wofür diese genutzt werden dürfen und in welchem Status sie sich befinden. Bei modernen Fahrzeugarchitekturen mit mehreren Dutzend bis weit über hundert Steuergeräten ist dies ohne tool-gestützte Transparenz faktisch nicht mehr beherrschbar. Fehlende Übersicht führt hier nicht nur zu Sicherheitsrisiken, sondern auch zu operativen Problemen bei Updates, Re-Flashes oder der kontrollierten Stilllegung von Lieferantenbeziehungen.

Die ISO/SAE 21434 adressiert diese Thematik explizit über alle Lebenszyklusphasen hinweg – einschließlich Produktion und Betrieb.

Kryptografische Schlüssel sind dabei kein lokales Projektartefakt, sondern ein organisationsweites Asset, dessen Kontrolle Voraussetzung für Auditierbarkeit, Update-Fähigkeit und regulatorische Konformität ist. Erst die Kombination aus klarer Governance, tool-gestützter Transparenz und sauberer Trennung zwischen Produkt- und Organisationsverantwortung macht Key-Management in der Praxis beherrschbar.

5. Governance, Knowledge und Awareness: Die unterschätzten Voraussetzungen für wirksame Security Controls

Governance und Management – einschließlich klarer Verantwortlichkeiten, definierter Entscheidungsbefugnisse und geeigneter personeller Maßnahmen – sind in der Fahrzeug-Cybersicherheit weiterhin das am meisten unterschätzte Handlungsfeld, obwohl sie eine unmittelbare Wirkung auf die Wirksamkeit technischer und prozessualer Controls in Projekten haben.

Projektseitige Sicherheitsmaßnahmen entfalten nur dann ihre Schutzwirkung, wenn die organisatorischen Rahmenbedingungen Angriffsflächen nicht bereits vorgelagert öffnen.

Ein erheblicher Teil realer Angriffspfade beginnt nicht etwa mit technischer Exploitation, sondern mit Social Engineering. Typische Einstiegsszenarien sind etwa der Zugriff auf sensible Informationen durch das Vortäuschen einer vertrauenswürdigen Identität (digital über E-Mail oder Messenger, aber auch physisch vor Ort), das Eindringen in interne Netzwerke über Phishing-Angriffe oder sogar auch das gezielte Einschleusen von Personen mit Zugriff auf Entwicklungs-, Test- oder Produktionsumgebungen.

Solche Einstiege wirken direkt auf die Machbarkeit von Angriffspfaden, die später in der TARA bewertet werden.

Um auch solchen Angriffsvektoren wirksam zu begegnen und die Eintrittswahrscheinlichkeit belastbar zu reduzieren, sind organisationsweite Maßnahmen erforderlich:

• regelmäßige und verpflichtende IT-Security-Awareness-Trainings für alle Mitarbeitenden,
• zielgruppenspezifische Schulungen für privilegierte Rollen
• sowie – abhängig vom Bedrohungsprofil – auch Hintergrundprüfungen für sicherheitskritische Positionen, wie sie in einigen Märkten bereits gängige Praxis sind.

Anderenfalls: Ohne diese Maßnahmen ist es faktisch nicht zulässig, diese Angriffsschritte in der TARA als „schwierig“ zu bewerten. (Einfach, weil sie nicht schwierig, sondern einfach umzusetzen sind.)

Wichtig ist dabei auch stets die klare Abgrenzung der Verantwortlichkeiten: Die Etablierung solcher Awareness-, Schulungs- und Personalmaßnahmen liegt in der Regel wieder nicht in der direkten Verantwortung oder operativen Machbarkeit des Cybersecurity Managers – hier sogar weder auf Projekt- noch auf Organisationsebene.

Dennoch wirken diese Maßnahmen unmittelbar auf die Qualität der projektseitigen Risikoargumentation. Fehlen sie, bleiben technische Controls im Projekt isoliert und verlieren ihre Schutzwirkung im Gesamtsystem.

Für die regulatorische Perspektive – insbesondere im Kontext der UNR155 – kommt ein weiterer Aspekt hinzu: Nachweisbarkeit.

Es genügt nicht, Awareness-Programme, Zugriffsbeschränkungen oder Governance-Regeln konzeptionell zu definieren. Es müssen zugehörige belastbare Evidenzen existieren, etwa Schulungsnachweise, Teilnahmequoten, Rezertifizierungen privilegierter Rollen oder dokumentierte Reviews kritischer Berechtigungen. Erst diese Evidenzen ermöglichen es, in Assessments nachvollziehbar darzulegen, dass Angriffsvektoren nicht nur theoretisch, sondern organisatorisch wirksam abgesichert sind.

Dieses Zusammenspiel aus Governance, Knowledge und Awareness bildet damit die unsichtbare, aber entscheidende Grundlage dafür, dass projektseitige Cybersecurity-Controls plausibel, argumentierbar und regulatorisch belastbar sind.

6. Supplier-Evaluierung: Regulatorische Verantwortung trifft auf verteilte Implementierung

Die Evaluierung und das Management von Lieferanten ist unter UN R155 keineswegs ein „Nice to have”, denn die regulatorische Verantwortung liegt letztlich beim Fahrzeughersteller – selbst wenn die tatsächliche Implementierung sicherheitsrelevanter Funktionen über eine Vielzahl von Parteien verteilt ist.

Organisatorisch erfordert dies ein durchgängiges Supplier-Cybersecurity-Operating-Model, das mindestens vier zentrale Aspekte sicherstellt:

1. Es müssen definierte Anforderungen an Lieferanten formuliert werden, einschließlich erwarteter Work Products und Evidenzen.
2. Es bedarf einer systematischen Capability-Bewertung durch Assessments oder Audits, um die tatsächliche CSMS-Reife des Lieferanten zu verifizieren.
3. Eine stets bidirektionale Traceability der Anforderungen muss gewährleistet sein – vom übergeordneten Item oder Projekt bis hinunter zum konkreten Supplier-Work-Product und wieder zurück.
4. Ein laufendes Monitoring und Issue-Management über die gesamte Lieferkette hinweg ist erforderlich, um Risiken frühzeitig zu erkennen und zu steuern.

Die ISO/SAE 21434 adressiert die Verteilung von Cybersecurity-Aktivitäten zwischen Customer und Supplier explizit und zielt darauf ab, diese „Interface-Governance” zu operationalisieren.

In der Praxis bedeutet dies, dass Lieferantenverträge nicht nur bei verteilter Entwicklung klare technische Spezifikationen enthalten dürfen, sondern auch verbindliche Anforderungen an Prozesse, Evidenzen und die nachweisbare Einbindung des Lieferanten in das übergeordnete CSMS definieren müssen.

Dies gilt ebenso für den Einsatz von Components-off-the-shelf (COTS)-Produkten, die häufig ohne direkte Einbindung des Cybersecurity Managers beschafft werden, jedoch zentrale technische Voraussetzungen für definierte Cybersecurity-Controls möglicherweise nicht erfüllen – etwa fehlende Hardware-Security-Module zur sicheren Schlüsselablage oder eingeschränkte Update-Fähigkeiten.

Hinzu kommt, dass insbesondere bei Lieferanten, die Cybersecurity erst schrittweise etablieren, belastbare Nachweise und Work Products zu Beginn einer Zusammenarbeit oft noch nicht vorliegen.

Um spätere Risiken zu vermeiden – sei es durch strukturelle Schwachstellen auf Lieferantenseite oder durch fehlende technologische Grundlagen im Produkt – ist es daher entscheidend, bereits frühzeitig eine fundierte Einschätzung der Cybersecurity-Capability des jeweiligen Lieferanten vornehmen zu können. Diese Bewertung bildet die Grundlage dafür, ob ein Produkt oder eine Entwicklungsleistung überhaupt geeignet ist, definierte Cybersecurity-Controls wirksam zu unterstützen, oder ob zusätzliche Maßnahmen, Einschränkungen oder Kompensationen erforderlich werden.

Die Einhaltung der vereinbarten Anforderungen ist anschließend nicht nur punktuell, sondern gesamtheitlich und kontinuierlich im Rahmen von CSMS-Einbindungen, Lieferantenaudits, Capability-Assessments und Review-Zyklen zu überprüfen und nachvollziehbar zu dokumentieren. (Hier sind nicht außer Acht zu lassen, tiefergehende Audits, wie die Korea Vehicle Security Regulierung, bei der beispielsweise auch erfragt wird, wie die von Lieferanten erhaltenen Cybersecurity-Zusagen auf der eigenen Seite effektiv überprüft wurden.)

Wir halten fest: Was hier etwas allgemein nach Qualität, Organisation und Prozess klingt, hat stets handfeste Auswirkungen auf die Effektivität der Cybersicherheit im Cybersecurity Concept, bzw. im finalen Fahrzeugprodukt.

7. Kommunikations- und Informationsausaustausch: Der banale, aber kritische Risikofaktor

Die Art und Weise, wie intern und extern kommuniziert wird, wirkt auf den ersten Blick banal, ist jedoch ein häufiger Root Cause für Credential-Leaks und die Umgehung etablierter Controls.

In Automotive-Entwicklungsorganisationen sind E-Mail, Ticketsysteme, Chat-Tools und Supplier-Portale alltägliche Arbeitsmittel.

Ohne klare und durchgesetzte Regeln werden Passwörter, Benutzernamen, Diagnosezugänge oder Test-Accounts über unsichere Kanäle geteilt, weitergeleitet und archiviert – oft mit besten Absichten, aber katastrophalen Sicherheitsfolgen.

Organisatorisch sind daher verbindliche Kommunikationsrichtlinien erforderlich, die durch technische Enforcer unterstützt werden: Multi-Faktor-Authentisierung, Conditional Access, automatische Erkennung und Blockierung von Secret-Patterns in Tickets sowie sichere Secret-Sharing-Mechanismen.

Darüber hinaus sollte eine „Default secure”-Toolchain etabliert werden, die beispielsweise Single Sign-On und Multi-Faktor-Authentisierung überall dort vorsieht, wo privilegierte Funktionen genutzt werden.

Dies passt unmittelbar zur Logik der ISO/SAE 21434, die darauf abzielt, eine Cybersecurity-Kultur und nachvollziehbare Prozesse aufzubauen – nicht nur technische Engineering-Controls.

Ganz konkrete Schulungen und Awareness-Programme müssen die Mitarbeitenden dabei unterstützen, die Risiken unsicherer Kommunikation zu verstehen und sichere Alternativen selbstverständlich zu nutzen – etwa indem Software und zugehörige Passwörter konsequent über getrennte Kanäle ausgetauscht werden oder große Entwicklungs- und Servicedokumente ausschließlich über kontrollierte Austauschplattformen statt über E-Mail oder offene externe Zugriffe bereitgestellt werden.

8. Change- und Konfigurationsmanagement: Wo Nachhaltigkeit entschieden wird

Change- und Konfigurationsmanagement ist das Handlungsfeld, in dem über die langfristige Nachhaltigkeit des gesamten Cybersecurity-Konzepts entschieden wird.

Man kann die besten Controls definieren und technisch perfekt implementieren – wenn nach Testläufen in der Produktion oder nach Debug-Sessions sicherheitsrelevante Funktionen deaktiviert bleiben, oder wenn niemand mehr mit Sicherheit sagen kann, welche Softwarestände tatsächlich wo verbaut sind, verliert man sowohl die Kontrolle als auch die Bewertbarkeit.

Die ISO/SAE 21434 ist explizit lifecycle-orientiert; UN R155 fordert eine fortlaufende Fähigkeit zur Überwachung und Reaktion. Daraus folgt organisatorisch die Notwendigkeit eines zentralen, über alle Domänen hinweg tragfähigen Configuration-Management- und Release-Systems, das Engineering, Werk und Aftermarket konsistent verbindet.

Ein zentraler Bestandteil dieses Konfigurationsmanagements ist auch das Access Management auf Software-Artefakte selbst, insbesondere auf den Quellcode. Geschützte Code-Repositories mit klar geregelten Zugriffsrechten, Review-Pflichten und nachvollziehbarer Änderungsverfolgung schaffen die grundlegende Voraussetzung, um unautorisierte oder manipulative Softwareänderungen strukturell zu verhindern. Der Bedrohungspfad „malicious software modification“ taucht in nahezu jeder TARA auf – und wird bereits durch diese organisatorische Maßnahme signifikant in seiner Machbarkeit reduziert, noch bevor technische Laufzeit-Controls greifen.

Konkret bedeutet dies: klare Baselines für jede Produktvariante, eindeutige Identitäten von Software-Artefakten (beispielsweise durch kryptografische Hashes oder Versionsnummern), verbindliche Change-Gates, bei denen sicherheitsrelevante Änderungen ein formales Security-Sign-off durchlaufen müssen, sowie etablierte Mechanismen zur „Control Re-Enablement” nach Ausnahmezuständen.

Das Prinzip „no control left behind” muss technisch und prozessual verankert sein: Nach jedem Test, jedem Rework, jeder Debug-Session muss sichergestellt sein, dass alle deaktivierten Sicherheitsfunktionen systematisch reaktiviert werden.

Dies ist zugleich die Brücke zur Beweisführung, die in cybersicherheitsspezifischen Product-Assessments zentral ist: Man benötigt nicht nur die dokumentierte Entscheidung, dass ein bestimmter Control existiert, sondern den lückenlosen Nachweis, wann dieser Control aktiv war, wann er aus welchem Grund deaktiviert wurde, wer diese Deaktivierung freigegeben hat und wann die Reaktivierung erfolgte.

Nur so lässt sich im Audit belastbar demonstrieren, dass das CSMS nicht nur auf dem Papier, sondern auch in der operativen Realität funktioniert.

Die Management-Klammer: Drei zentrale Fähigkeiten des Cybersecurity Managers

Zieht man diese ersten Handlungsfelder zusammen, ergibt sich eine klare Management-Klammer: Das nachhaltige Cybersecurity-Konzept ist im Kern ein Satz organisatorischer Fähigkeiten, die technische Mechanismen im Fahrzeug über den realen Entwicklungs- und Produktionsalltag überhaupt erst ermöglichen und über den gesamten Lebenszyklus hinweg effektiv wirksam halten.

Der Cybersecurity Manager muss dafür drei zentrale Fähigkeiten beherrschen.

• Governance: Die Etablierung und Durchsetzung klarer Rollen, verbindlicher Policies und belastbarer Entscheidungsmacht. Ohne diese Grundlage bleibt selbst die beste technische Lösung ein zahnloser Tiger, weil sie im Konfliktfall mit anderen Prioritäten (Zeit, Kosten, Durchsatz) nicht durchgesetzt werden kann.
• Integration: Die konsistente Verbindung zwischen IT-/IT-Security, Quality-Management, Engineering, Produktion und dem Supplier-Interface. Cybersecurity darf nicht als isolierter Silo operieren, sondern muss als Querschnittsfunktion in bestehende Prozesse und Entscheidungsstrukturen eingebettet sein. Dies erfordert ausgeprägte Schnittstellenkompetenz und die Fähigkeit, in verschiedenen „Sprachen” mit verschiedenen Stakeholdern zu kommunizieren – von der Entwicklungsabteilung über das Werk bis zur Beschaffung.
• Evidence: Die Sicherstellung von Auditierbarkeit durch belastbare Evidenzen, aussagekräftige Metriken und durchgängige Traceability. In einer regulierten Industrie genügt es nicht, Sicherheit zu „machen” – man muss auch nachweisen können, dass man sie macht, wie man sie macht und dass die getroffenen Maßnahmen tatsächlich wirken. Dies erfordert ein durchdachtes System zur Dokumentation, regelmäßige interne Gap-Analysen und Audits sowie die Fähigkeit, auf Basis dieser Evidenzen Management-Reviews und externe Assessments erfolgreich zu bestehen. Unabhängig davon, was beispielsweise in der Produktion oder IT „so üblich“ ist, muss dieses System über die oben genannten Funktionen und Verantwortungsbereiche dann auch konsequent angewandt werden.

Zusammengefasst: Technik schützt Fahrzeuge – Organisationen wahren die Fähigkeit, Cybersicherheit dauerhaft zu ermöglichen

Die zentrale Botschaft dieses Artikels lässt sich in einem einzigen Satz zusammenfassen: Technische Maßnahmen schützen Fahrzeuge, aber Organisationen wahren die Fähigkeit, Cybersicherheit dauerhaft zu liefern.

Wer als Cybersecurity Manager die organisatorischen Fähigkeiten robust aufsetzt, Rollen klar definiert, Prozesse belastbar gestaltet und die Lieferkette systematisch einbindet, schafft die unverzichtbare Grundlage dafür, dass die technischen Controls im Fahrzeug verlässlich wirken – nicht nur im Moment der Auslieferung, sondern über den gesamten Lebenszyklus hinweg.

Dem folgend muss Cybersecurity eben mit allen zugehörigen Handlungsfeldern als strategische Managementaufgabe verstanden und mit entsprechender Priorität, Ressourcenausstattung und Durchsetzungsmacht ausgestattet werden.

Wer diese Perspektive konsequent einnimmt und die beschriebenen Domänen und Aufgabenstellungen nicht als technische Checkboxen, sondern als organisatorische Befähigungsfragen versteht, wird in der Lage sein, ein nachhaltiges Cybersecurity Concept zu etablieren, das sowohl den regulatorischen Anforderungen standhält als auch im rauen Alltag von Entwicklung, Produktion und Betrieb tatsächlich funktioniert.

Genau diese Logik – Prozesse und Maßnahmen, Transparenz und Evidenzen, Integration und Governance – wird in praxiserprobten Interpretationen von ISO/SAE 21434 und in UNR155-CSMS-Kontexten immer wieder als entscheidender Erfolgsfaktor hervorgehoben.

Die Herausforderung für Cybersecurity Manager besteht darin, diese Logik in die eigene Organisation zu übersetzen und dort lebendig werden zu lassen.

Hinweis: Der vorliegende Beitrag bildet eine konzeptionelle Fortführung der theoretischen Grundlagen aus Kapitel C07 Cybersecurity Implementation der branchenweit etablierten Fachpublikation 1000 Things Worth Knowing in Automotive Cybersecurity (2025)