Die unterschätzten Kosten der Cybersicherheit im Fahrzeug und die Frage der Verteilung

„Cybersicherheit kostet Geld.“ Immerhin dieser kleinste gemeinsame Nenner hat sich in der Fahrzeug- und Automobilindustrie zwar zähneknirschend, aber zügig durchgesetzt.

Manche sagen, er stimme und stimme gleichzeitig nicht.

Er stimmt, weil die Investitionen real sind. In Cybersecurity-Ingenieure, Kompetenz, Tooling, Audits, sichere Hardware, Monitoring-Infrastruktur.

Er stimmt nicht, weil er impliziert, der Preis sei bekannt und die security-relevanten Entscheidungen damit kalkulierbar. Beides trifft gegenwärtig noch nicht so zu, wie es im Sinne einer sauberen Planbarkeit wünschenswert wäre.

Erschwerend kommt hinzu, dass Cybersicherheitsausgaben in ihrer Grundlogik präventiv sind. Sie sollen abwenden, was im Ernstfall deutlich teurer würde: einen Sicherheitsvorfall, ein verlorenes Kundenprojekt, eine nicht erteilte Typgenehmigung. Was sie abwenden, lässt sich per Definition nicht messen.

Wer heute versucht, die Gesamtkosten für regulatorisch belastbare Fahrzeug-Cybersicherheit über den vollständigen Produktlebenszyklus zu beziffern, findet derzeit wenig Belastbares und stößt gleichzeitig weiterhin auf strukturelle Unklarheiten.

Genau dort liegt das eigentliche Problem. Nicht in der Technik, nicht einmal primär in der Regulierung, sondern in der Art, wie die Branche bislang mit dem noch recht neuen Kostenblock für Produkt-Cybersicherheit umgeht.

Akteure der Fahrzeugindustrie verstehen Cybersicherheit primär als Entwicklungsposition, als projektbezogenen Einmalaufwand.

Wer die UN R155 und den zugehörigen Branchenstandard ISO/SAE 21434 jedoch kennt, weiß: das ist nicht zulässig.

Was fordern UN R155 & ISO/SAE 21434 an Security-Kosten und was das ökonomisch bedeutet

Die UN R155 und die Schwester UN R156 (Software Update Management) bilden im Typgenehmigungsrecht ein regulatorisches Zwillingspaar. Beide Managementsysteme sind Voraussetzung für die Erlangung einer Typgenehmigung.

Was die Regulierungen heute für alle neu zugelassenen Fahrzeuge inhaltlich fordern, geht deutlich über eine einmalige Produktprüfung hinaus.

So muss das Cybersecurity Management System (CSMS) der UN R155 muss Entwicklung, Produktion und die sogenannte Post-Production-Phase abdecken.

Prozesse für Monitoring, Angriffserkennung und Vorfallreaktion müssen kontinuierlich vorgehalten werden und Fahrzeuge im Feld einschließen. Das CSMS-Zertifikat selbst ist nicht unbegrenzt gültig, da die R155 eine Erneuerung im Drei-Jahres-Rhythmus vorsieht.

Cybersicherheit ist damit regulatorisch kein einmaliger SOP-Check, sondern eine wiederkehrende Nachweis- und Auditarbeit.

End-of-Life Cybersecurity in der Automobilindustrie: Ein Interessenskonflikt?

Für die Kostenlogik ist die Definition der Post-Production-Phase entscheidend. Sie beginnt, wenn ein Fahrzeugtyp nicht mehr produziert wird — und endet erst mit dem End-of-Life aller Fahrzeuge dieses Typs. Dies ist eine erheblich längere Betrachtung als klassische Gewährleistungs- oder Garantiefristen, die in der Branche als Planungsgrundlage gelten.

Nicht das Garantieende definiert die Supportverpflichtung für Cybersicherheit, sondern das letzte Fahrzeug dieses Typs auf der Straße (so die aktuelle regulatorische Auslegung.)

Genau daraus entsteht der ökonomische Konflikt, der derzeit eine der zentralen Branchendiskussionen prägt.

Der deutsche Branchenverband VDA argumentiert, dass die lange Post-Production-Pflicht eine zeitlich praktisch unbestimmte aktive Supportverpflichtung erzeugt. Er schlägt dahe ein formales „End of Cybersecurity Support“ (EoCSS) vor: aktive Pflegephase bis EoCSS, danach passive Beobachtungspflicht bis zum Ende des Fahrzeuglebens.

Gegenwärtig geltend ist die lange Regelung; diskutiert wird daher gegenwärtig, ob ein formaler Übergang von aktiver Pflege zu passiver Beobachtung eingeführt werden sollte.

Faktisch entscheidet genau dieser Übergang über Milliardenbeträge an Lebenszykluskosten — auch wenn er in der öffentlichen Berichterstattung selten so explizit benannt wird.

Wichtig zu wissen: Diese Kostenrealität betrifft auch nicht allein den OEM. Sie zieht sich durch die gesamte Lieferkette: Auch Tier-1- und Tier-2-Zulieferer müssen die Kosten langfristiger Cybersicherheitspflichten intern tragen und irgendwo umlegen. Wie und an wen, ist in vielen Lieferbeziehungen noch ungeklärt.

Ein Vergleich mit anderen Branchen, in denen Support-Lebenszyklen schon länger etabliert sind, lohnt sich: Im Enterprise-Betriebssystem-Segment werden beispielsweise Extended-Support-Fenster von zehn Jahren und mehr definiert und End-of-Support-Daten Jahre im Voraus kommuniziert, da Unternehmen Planungssicherheit für ihre Infrastruktur, Compliance und IT-Budgets benötigen. Smartphone-Hersteller konkurrieren inzwischen aktiv mit Update-Garantien, da Konsumenten gelernt haben, dass fehlende Sicherheitsupdates ein reales Risiko darstellen.

In beiden Fällen gilt: Der Hersteller muss nicht nur das Produkt bereitstellen, sondern auch die Infrastruktur vorhalten, die Updates möglich macht. Entwicklungsumgebungen, Security-Infrastruktur, Testprozesse, Support-Kanäle.

Genau diese Strukturen für Cybersicherheit fehlten im Automotive- und Fahrzeug-Kontext bislang als definierte Planungsgröße.

Die Herausforderung: Während ein Smartphone nach wenigen Jahren schlicht ausgetauscht wird und ein Enterprise-Serversystem nach einem definierten Lifecycle-Datum abgelöst werden kann, bleibt ein Fahrzeug im Schnitt deutlich länger im Betrieb.

Dabei ist es physisch, rechtlich und sicherheitsrelevant in einer Weise vernetzt, die keinen ungestützten Weiterbetrieb ohne Konsequenzen erlaubt.

Genau das macht die EoCSS-Debatte (in der vielschichtig verzweigten Fahrzeugzuliefererstruktur) so wichtig: Es geht nicht darum, Verantwortung zu vermeiden. Es geht darum, Cybersicherheitsnotwendigkeiten so zu strukturieren, dass sie langfristig tatsächlich umsetzbar sind.

Security-Kosten, die nicht in der Stückliste stehen

Eine weitere Challenge: Die Kostenstruktur von Automotive-Cybersecurity ist entlang des Fahrzeuglebenszyklus stark unterschiedlich verteilt.

In der Entwicklungsphase dominieren einmalige, aber volumenwirksame Aufwendungen.

Konkret bezogen darauf, was die gesamtheitliche Cyberrisikobewertung entlang der etablierten Threat Analysis and Risk Assessment-Methodik zu Tage fördert.

Die Security-Anforderungen an das Produkt, das Cybersecurity-Konzept, Verifikation und Validation. Die gesamte Lieferantensteuerung in Bezug auf Cybersecurity. Alle Work Products und Dokumentationen.

In der Produktion kommen drei Kostenbereiche hinzu, die sich sauber unterscheiden lassen:

• Erstens Entwicklungskosten in Form von Ingenieursstunden: für die Spezifikation sicherer Fertigungsprozesse, die Auditfähigkeit der Produktion und das Schlüsselmanagement-Konzept.
• Zweitens Hardwarekosten, die sich direkt in der Bill of Material niederschlagen: sichere Hardware, Hardware Security Modules, Secure Elements. Die UN R155 nennt den Einsatz von Hardware Security Modules ausdrücklich als Beispiel einer zulassungsrelevanten Mitigation.
• Drittens entstehen operative Produktionskosten: Key-Injection-Infrastruktur, gesicherte Flash-Stationen, Prozesskontrollen.

Alle drei Bereiche sind real, aber in der betrieblichen Praxis oft unterschiedlichen Budgettöpfen zugeordnet, was eine saubere Gesamtkostenbetrachtung erschwert.

Im Feld verschiebt sich die Logik dann in Richtung operativer Daueraufwendungen: Monitoring, PSIRT-Arbeit, Vulnerability Management, OTA-Kampagnen samt der dafür notwendigen Server- und Backend-Infrastruktur, Cloud- und Konnektivitätsbetrieb, Tooling für Update-Verteilung und Regressionstests.

Große Zulieferer beschreiben diese Langfristigkeit zunehmend zwiegespalten: Software könne über Updates over-the-air (kurz OTA) über den gesamten Lebenszyklus optimiert werden; zugleich sei es eine Herausforderung, Software viele Jahre nach der ursprünglichen Entwicklung noch aktualisieren zu können.

Software-Updates sparen zwar teure Rückrufkosten, erzeugen aber zugleich neue Daueraufwendungen in Cloud, Konnektivität, Test und regulatorischer Nachweisführung.

Zusammengefasst gilt: Langfristige Cybersicherheit ist kein beiläufiger Service, sondern ein eigener Leistungs- und Kostenblock mit eigenen Erforderlichkeiten.

Die asymmetrische Last der Cybersicherheit in der Fahrzeug-Lieferkette

Für Zulieferer ist die derzeitige Lage im Umgang mit Kosten für Fahrzeug-Cybersicherheit besonders widersprüchlich.

Typgenehmigungsbehörden vergeben CSMS- und SUMS-Zertifikate grundsätzlich an Gesamtfahrzeughersteller, nicht an Komponentenlieferanten. (Wenngleich letztere sich vor allem medienwirksam gerne mit Security-Zertifizierungen ins rechte Licht rücken.)

Gleichzeitig müssen OEMs im Typgenehmigungsprozess aber nachweisen können, wie sie ihre Lieferkette gesteuert haben und wie die Zulieferkomponenten in die Cybersecurity-Architektur eingebunden sind.

Der OEM muss also nicht nur (mit dafür einhergehenden Aufwendungen) das eigene CSMS aufbauen und auditierbar halten, sondern auch konsequent sicherstellen, dass seine gesamte Lieferkette den geforderten Sicherheitsstandard erreicht und nachweisbar hält.

Der zugehörige Steuerungsaufwand, der hier „nur“ durch Cybersicherheit geschaffen wird, ist nicht zu unterschätzen.

Das Ergebnis ist eine indirekte, aber harte Regulierung der Zulieferer, die sich in umfangreichen Lastenheften, dedizierten Cybersecurity Interface Agreements, Freigabenachweisen und allerlei (idealerweise kollaborativen) Cybersecurity-Zusammenarbeiten widerspiegelt.

Die Kosten der Automotive Cybersecurity für Supplier konkretisieren

Das vom VDA entwickelte Cybersecurity-Interface-Agreement-Rahmenwerk (kurz VDA CSIA) bemüht sich, diese Rollenverteilung zu konkretisieren:

• Auf OEM-Seite liegen Gesamt-TARA, Security Goals und Fahrzeugtypvalidierung.
• Auf der Seite der Zulieferer liegen Komponentenspezifikation, Verifikations- und Integrationsberichte, Schwachstellen aus der Entwicklung, Produktionskontrollpläne, ein etablierter und aktivierbarer Incident-Response-Prozess, kontinuierliche Cybersecurity-Aktivitäten und Prozesse zur Kommunikation des End of Cybersecurity Support.

Auch dieser Rahmen zeigt vor allem: Supplier-Cybersecurity ist kein punktuelles Projekt, sondern ein Prozessapparat, der sich über Entwicklung, Produktion, Betrieb und Supportende hinweg erstreckt.

Die unterschätzten Kosten der Automotive-Cybersecurity entlang der Lieferkette

Erfahrungen aus der Praxis und erste Branchenanalysen zeigen, dass insbesondere Tier-Unternehmen die Business- und Kosteneffekte von Automotive-Cybersecurity häufig unterschätzen.

Insbesondere die Phase nach den Fahrzeugverkauf wird organisatorisch häufig vernachlässigt, da Updates und Tests insbesondere nach Ablauf der Garantie als kostspielig wahrgenommen werden.

Genau dort liegt die eigentliche Kostenherausforderung: weniger in der erstmaligen Implementierung als in der langen Pflege.

Supplier tragen nicht nur Compliance-Kosten, sondern auch Vorhaltekosten: alte Build-Umgebungen, kryptografische Materialien, Teilstände, qualifiziertes Personal — oft noch Jahre nach dem Auslaufen des eigentlichen Seriengeschäfts. (Man kann sich vor Augen führen: Selbst die NASA musste auf ihre zwischenzeitlich pensionierten Spezialisten wieder zurückholen, um historisches Wissen und sicherheitsrelevante Details wieder verfügbar zu machen.)

Effizienz unter Effizienzdruck

Die Automobilindustrie befindet sich in einer widersprüchlichen Lage: Einerseits kommen alternative Antriebe und technologische Fortschritte der Digitalisierung voran, wodurch der Cybersecurity-Footprint wächst, andererseits ist das Geschäftsklima tief im negativen Bereich, Margen sinken, Finanzierungskosten steigen.

In dieser Gemengelage laufen bei mehreren großen Tier-Zulieferern gleichzeitig Restrukturierungsprogramme. Beschäftigungsabbau im dreistelligen bis vierstelligen Bereich, Abspaltungen von Automotive-Geschäften, Kostensenkungsziele im dreistelligen Millionenbereich sind keine Randereignisse, sondern die gegenwärtige Normalität.

Vor dieser Ausgangslage müssen Cybersecurity-Budgets und -Ressourcen (und nicht zuletzt wertvoll aufgebaute Expertise) heute verteidigt werden.

Aktuell sieht es also so aus: Geld für Cybersicherheit konkurriert direkt mit Geld für Elektrifizierung, Softwareplattformen und Restrukturierung.

Das ist kein theoretisches Problem, sondern ein realer Allokationskonflikt, der aktuell in den meisten Organisationen derzeit nahezu täglich ausgetragen wird.

Hinzu kommt der aktuelle „Regulierungs-Wildwuchs“. Die UN R155 (bzw. die GB-44495, AIS 189, Korea Security Regulierung u.a.), der Cyber Resilience Act und NIS-2 treffen die Branche nicht isoliert, sondern gleichzeitig – und das mit teils überlappenden, teils widersprüchlichen Anforderungen.

Verbände auf nationaler und europäischer Ebene fordern deshalb zu Recht klarere Mappings zwischen den Regelwerken, weniger Doppelberichtspflichten und eine Regulierungsarchitektur, die den Compliance-Aufwand und den tatsächlichen Sicherheitsgewinn in ein vernünftiges Verhältnis setzt. Denn nicht nur Unsicherheit kostet Geld. Auch eine schlechte Regulierungsarchitektur kostet Geld.

Wo Effizienzpotenziale liegen und warum sie nicht kostenlos zu heben sind

Eine weitere ökonomische Challenge lautet: Teuer steht nicht für mehr Security. Teuer steht in der Regel vor allem für schlecht organisierte Security.

Das klingt trivial, ist aber gegenwärtig eine der umfassendsten Handlungsfelder beim Auf- und Aus- und Umbau von Automotive-Cybersecurity-Strukturen.

Die historische Logik der Automobilindustrie (projektbezogene Budgets, proprietäre Plattformlandschaften) erschwert eine echte Planbarkeit der Cybersecurity-Kosten über einen längeren Zeitraum hinweg.

Es gibt keine historischen Durchschnittswerte, die Zielgrößen sind unklar, etliche Varianten, fehlende Standardisierung, unklare Supportverpflichtungen – die Rahmenbedingungen werden zum Hindernislauf.

Gleichzeitig setzt sich mühsam die Erkenntnis durch: Der echte Preis einer vermeintlich günstigen Lösung zeigt sich erst später — und fällt dann deutlich höher aus.

Was sich ändern muss und was das für das Cybersecurity Management in Automotive schon heute bedeutet

Was sich aus dem Beschriebenen ableiten lässt, sind keine technischen Maßnahmen. Es sind Entscheidungen über Governance, Vertragsarchitektur und strategische Prioritätensetzung, die für effektive Fahrzeug-Cybersicherheit einfach getroffen werden müssen.

Da wären beispielsweise zu nennen:

• Security-Supportverpflichtungen müssen in Produkt- und Lieferantenverträge aufgenommen werden, bevor das erste Fahrzeug vom Band läuft. Nicht erst, wenn eine Schwachstelle Nachverhandlungsdruck erzeugt. Die Rollenverteilung zwischen OEM und Supplier lässt sich über den gesamten Lebenszyklus (Konzept, Entwicklung, Produktion, Betrieb, Supportende) strukturieren und vertraglich verankern. Wo das versäumt wird, entstehen keine technischen Probleme. Es entstehen kommerzielle.
• Monitoring- und OTA-Kosten sind kein After-Sales-Residual. Sie sind planbare Betriebskosten. Als solche müssen sie im Budget ausgewiesen werden und dürfen nicht als diffuse Restgröße in den Bereichen „Garantie” und „Service” verschwinden. Wer diese Kosten nicht explizit plant, plant implizit entweder Kostenspitzen oder unterlassene Updates ein. Beides ist teurer als die Alternative.
• Die Unterscheidung zwischen kritischen und nicht-kritischen Funktionen ist dabei kein technisches Detail, sondern eine strategische Weichenstellung. Die UN R155 lässt explizit Raum dafür, dass das CSMS spezifische Prozesse für das Supportende definiert, einschließlich der Frage, welche Funktionen unter welchen Bedingungen abgeschaltet werden können. Wer diese Weichenstellung früh trifft, behält Handlungsspielraum. Wer sie vermeidet, übergibt ihn später an den Regulierer oder den Markt.
• Und schließlich die grundlegendste Verschiebung: Cybersicherheit ist keine Compliance-Kostenstelle. Sie ist Bestandteil der Produktstrategie, der Plattformstrategie und der After-Sales-Ökonomie, mit realen Trade-offs, die sich rechnen lassen. OTA spart Rückrufkosten, erzeugt aber Dauerbetriebskosten. Secure Hardware erhöht die Stückpreise, senkt aber das Risiko teurer Feldereignisse. Längerer Support stärkt Vertrauen und Restwerte, verlängert aber den Schweif alter Architekturen.

Diese Ambivalenzen sind kein Argument für Unentschlossenheit. Sie sind der Grund, warum Cybersecurity-Kosten strategisch modelliert werden müssen. Mit denselben Werkzeugen und derselben Ernsthaftigkeit wie jede andere langfristige Investitionsentscheidung im Fahrzeugprogramm.

Fazit: Kritische Fragen zu Cybersecurity-Kosten in Automotive

Der eigentliche Preis der Automotive Cybersecurity ist der Preis der Dauerhaftigkeit in einer Industrie, die historisch auf einmalige Stückkostenlogik optimiert war. Die UN R155 zwingt die Branche zum Paradigmenwechsel in einer Zeit, in der jeder Euro bereits zweimal gezählt wird.

Genau deswegen sind Fragen, wie Cybersecurity-Kosten organisiert und verteilt werden, keine technischen Fragen mehr. Sie sind strategische.

Zur Inspiration:

• Wie weit reicht die Supportverpflichtung des eigenen Unternehmens nach aktuellem Vertragsstand tatsächlich? Deckt sie sich mit dem, was die UN R155 regulatorisch fordert?
• Sind Cybersecurity-Kosten der Post-Production-Phase als eigene Budgetposition geplant? Oder verschwinden sie in Warranty, After-Sales oder unbeplanten Restposten?
• Wie ist die OEM-Supplier-RACI für Vulnerability Handling, Re-Testing und EoCSS-Kommunikation vertraglich geregelt? Wurde diese Regelung (jeweils) mit dem tatsächlichen technischen Scope abgeglichen?
• Welche Fahrzeugfunktionen wären nach einem hypothetischen EoCSS noch pflegepflichtig? Welche könnten unter definierten Bedingungen abgeschaltet werden?
• Ist die eigene Cybersecurity-Architektur so gestaltet, dass Software-Updates und Sicherheitspatches in zehn Jahren noch sicher gebaut, getestet und ausgerollt werden können?
• … hier lassen sich noch einige Fragen stellen und beantworten, für die es sich lohnen kann mit Expertinnen und Experten zu sprechen.