Regulatorische Anforderungen im Automotive-Umfeld
Anforderungen wie UNECE R155, ISO/SAE 21434 oder OEM-Vorgaben sind vielfältig, oft widersprüchlich und ohne klare Priorisierung. In vielen Projekten fehlen die Strukturen, um Security skalierbar und auditierbar umzusetzen.
Wir zeigen, wie wir Konzepte entwickeln, die Normen, Gesetze und Kundenziele vereinen – klar, skalierbar und praxisnah.
Mit der zunehmenden Digitalisierung in der Fahrzeugentwicklung wird Cybersecurity zum zentralen Bestandteil technischer Verantwortung. Moderne Fahrzeuge sind längst keine isolierten Maschinen mehr, sondern eingebettet in hochvernetzte Systeme. Die Entwicklung hin zu Software Defined Vehicles führt dazu, dass klassische Mechanik zunehmend durch Software und elektronische Steuerung ersetzt wird. Das macht Fahrzeuge zwar anpassungs- und servicefähiger – jedoch auch deutlich verwundbarer.
Neben der Fahrzeugarchitektur rückt auch die angebundene IT-Infrastruktur in den Fokus – insbesondere cloudbasierte Backendsysteme, die essenzielle Funktionen ermöglichen und absichern müssen. Damit Daten geschützt bleiben, Geschäftsgeheimnisse gewahrt werden und keine Schwachstellen für die gesamte Fahrzeugflotte entstehen, ist es unerlässlich, Backend‑Architekturen systematisch mit klar definierten Prozessen und Methoden zu analysieren.
Die Bedrohungslage ist real
Angriffe auf Fahrzeuge und ihre digitale Infrastruktur – insbesondere Backend-Systeme, Kommunikationsschnittstellen und Update-Mechanismen – sind längst keine theoretischen Szenarien mehr. Phishing, Ransomware oder manipulierte Over-the-Air-Updates betreffen heute nicht nur zentrale IT-Systeme, sondern zunehmend auch Fahrzeuge selbst. Wer etwa die Kommunikation zwischen Steuergeräten manipuliert oder die Sensorik für Fahrassistenzsysteme täuscht, greift nicht nur auf Daten zu, sondern gefährdet Funktion, Sicherheit und letztlich auch Menschenleben.
Zu den typischen Angriffspunkten moderner Fahrzeugarchitekturen gehören neben den internen Kommunikationsnetzwerken vor allem cloudbasierte Dienste, Benutzer- und Zugriffsschnittstellen sowie datengetriebene Steuerungssysteme.
Der Paradigmenwechsel in der Automotive-Industrie ist in vollem Gange: Cybersecurity ist spätestens seit der UN-Regelung „UNECE R155“ nicht mehr Kür, sondern verbindliche Voraussetzung für den Marktzugang.
Doch viele Unternehmen stehen noch immer am Anfang der praktischen Umsetzung – oder kämpfen mit unzureichend verankerten Prozessen.
Einheitlicher Rahmen – unterschiedliche Erwartungen
Die UNECE R155 macht seit 2022 deutlich: Hersteller, die keine klare Cybersecurity-Strategie nachweisen können, bekommen keine Typzulassung mehr. ISO/SAE 21434 liefert hierfür das normative Gerüst. Aber: In der Praxis stoßen wir auf ein vielschichtiges Spannungsfeld. Denn neben den internationalen Vorgaben haben viele OEMs eigene Security-Prozesse, Checklisten und Gate-Kriterien, die erfüllt werden müssen.
Das betrifft nicht nur klassische Pkw-Hersteller, sondern auch unsere Kunden aus dem Nutzfahrzeug- und Trailerbereich, wie Meiler oder Goldhofer. Für beide haben wir bereits Erstzertifizierungen gemäß CSMS und SUMS als Cybersecurity-Berater und Pre-Assessor begleitet.
In unseren Projekten sehen wir häufig, dass verschiedene Vorgaben miteinander kollidieren. Erst durch ein strukturiertes und transparentes Sicherheitskonzept lassen sie sich auf einen gemeinsamen Nenner bringen. Denn die Kombination aus internationaler Norm, OEM‑spezifischen Richtlinien und projektspezifischer Architektur erfordert eine gute Moderation aller Beteiligten und eine sorgfältige, nachvollziehbare Dokumentation.
Aktuell bereiten wir zudem eine gezielte Cybersecurity‑Sales‑Kampagne vor, mit der wir über 80 weitere potenzielle Kunden im Nutzfahrzeug‑ und Trailersegment adressieren werden.
Security beginnt mit Systemverständnis
Am Anfang steht bei uns immer die Frage: Welche Funktionen sollen geschützt werden – und warum?
Wir starten mit Threat Analysis and Risk Assessment (TARA) – ganz im Sinne der ISO/SAE 21434 – und analysieren systematisch Bedrohungen, Schwachstellen und potenzielle Auswirkungen. Besonders wichtig: Wir denken nicht nur technisch, sondern beziehen auch relevante Stakeholder, Betriebsszenarien und Systemabhängigkeiten mit ein.
Der Anspruch: Security-Ziele, die wirklich zum System passen – statt generischer Schutzmaßnahmen nach Checkliste.
Die Ergebnisse fließen in ein modulares Security‑Konzept, das mit dem System mitwachsen kann – also flexibel auf neue Funktionen, Schnittstellen und Architekturänderungen reagiert.
Denn: Was heute sicher scheint, kann morgen schon Lücken haben – sei es durch neue Schnittstellen, Feature-Updates oder Änderungen im Backend.
Dabei analysieren wir systematisch Angriffsvektoren auf Kommunikationsflüsse, Verwaltungskanäle und Monitoring-Schnittstellen in der Cloud – ebenso wie klassische Steuergeräte im Fahrzeug.
Von der Analyse zur konkreten Maßnahme
Sicherheitskonzepte müssen mehr sein als wohlklingende Absichtserklärungen. Deshalb erfassen wir nicht nur die Risiken, sondern benennen auch deren konkrete Schutzziele, zugehörige Funktionen und die passenden Maßnahmen zu ihrer Behandlung:
- Welche Datenflüsse müssen geschützt werden?
- Welche Komponenten brauchen Authentifizierung, welche Verschlüsselung?
- Wo sind Updates notwendig – und wie werden diese gegen Manipulation geschützt?
In der Praxis setzen wir unter anderem auf:
- Secure Boot und Code Signing
- ECU-Hardening
- Segmentierte Fahrzeugnetzwerke
- Rollenbasierte Zugriffskontrollen
- Intrusion Detection Systeme (onboard & im Backend)
Ergänzt wird dies durch übergeordnete Mechanismen wie verschlüsselte Schnittstellenkommunikation, Least-Privilege-Zugriffskonzepte und transparente Monitoring- und Logging-Strukturen für alle digitalen Dienste.
All das dokumentieren wir entlang definierter Auditpfade, sodass im Typ-Genehmigungsverfahren nachvollziehbar bleibt, wo, wie und warum Schutzmaßnahmen greifen.
Sicherheit endet nicht bei der Übergabe
Ein oft unterschätzter Aspekt: Auch nach SOP (Start of Production) muss die Cybersecurity dauerhaft sichergestellt sein. Dazu gehören sichere Software-Updates, ein funktionierendes Incident-Handling und klare Verantwortlichkeiten – gerade in SDV-Projekten, bei denen Zulieferer sicherheitsrelevante Funktionen beisteuern.
Dabei gewinnen Over-the-Air-Updates immer stärker an Bedeutung. Damit kein Softwarefehler in der Cloud landet oder auf unzählige Fahrzeuge verteilt wird, muss sichergestellt sein, dass nur autorisierte, geprüfte Updates eingespielt werden – möglichst ohne Kundeneingriff.
Das erfordert robuste Update-, Freigabe- und Recovery-Konzepte – in Fahrzeugfunktionen und Cloudsystemen.
Auch in der Lieferkette: Vertrauen ist gut, Audit ist besser
Kein Fahrzeug entsteht im luftleeren Raum – Security ist immer auch eine Frage der Kooperation. Deshalb legen wir in Projekten großen Wert auf klare Vereinbarungen mit Zulieferern:
- Welche Security-Vorgaben gelten verbindlich?
- Wer testet was – und wann?
- Wie sieht die Nachweiskette aus?
Wir etablieren durchgängige Prozesse – etwa über abgestimmte Security Requirement Specifications, gemeinsame FMEA-Workshops oder Security-Assessments im Rahmen von Lieferantenfreigaben.
Zunehmend wichtig sind auch:
- Vertraglich definierte Logging-Pfade
- Technische Mindestanforderungen an Cloud-Dienste
- Verpflichtende Teilnahme an plattformübergreifenden Reviews
Mittels Interface Agreements definieren wir im Auftrag unserer Kunden – meist OEMs – klare Verantwortlichkeiten. Auf technischer Ebene analysieren wir Produkte zum Beispiel mithilfe von SBOMs (Software Bill of Materials).
Fazit: Struktur schlägt Unsicherheit
Wer Cybersecurity früh, strukturiert und partnerschaftlich denkt, schafft nicht nur Vertrauen, sondern auch Stabilität in der Entwicklung. Regulatorische Anforderungen wie UNECE R155 oder ISO/SAE 21434 sind keine lästige Hürde – sie sind ein Katalysator für saubere Prozesse, langfristige Absicherung und bessere Produkte.
Unser Ansatz: Nicht mehr Aufwand als nötig, aber mit ausreichend Substanz, um Systeme sicher zu machen – und sicher zu halten.
Dazu gehört, Cybersecurity nicht als nachgelagerten Prüfschritt zu behandeln, sondern von Beginn an in den Produktentstehungsprozess zu integrieren. Konkret bedeutet das: Sicherheitsanforderungen, Analysen und Maßnahmen werden bereits in den frühen PEP‑Phasen definiert und als verbindliche Work Products festgehalten – statt erst beim Testing sichtbar zu werden.
Dieser frühzeitige Einstieg schafft mehrere Vorteile: Risiken werden früher erkannt, Architekturentscheidungen können sicherheitsorientiert getroffen werden, und kostspielige Änderungen am Ende des Projekts werden vermieden. Genau das beschreibt der Shift‑Left‑Gedanke: sicherheitsrelevante Aufgaben wandern zeitlich nach vorne. Ergänzt wird dies durch Security‑by‑Design, also die Grundidee, Sicherheit als festen Bestandteil der System- und Softwarearchitektur mitzudenken, statt sie später auf bestehende Strukturen „aufzusetzen“.
Am Ende entscheidet nicht das ausgeklügelte Dokument, sondern der Prozess in der Praxis.
Eine gute Dokumentation schafft die Basis – Sicherheit entsteht durch konsequente Umsetzung.
Inspiriert von: Wie Hacker die Zukunft der Software Defined Vehicles bedrohen
