English Version:
Connected vehicles are a near-perfect illustration of how readily Europe can default to a familiar policy pattern: define technical minimum standards, mandate processes, audit artefacts, and assume that “cybersecurity” has thereby been dealt with. In the automotive context, this approach is well institutionalised in Europe, above all through UN Regulation No. 155, with its CSMS requirement and type-approval interface, which deliberately adopts a risk-based logic. It is precisely at this juncture that the DGAP memorandum “Connected Vehicle Cybersecurity: The EU Must Consider Non-technical Risk Factors” strikes a chord: the technical framework is necessary, but it is not sufficient where the decisive risk driver is not the next vulnerability in a software stack, but rather the question of who is structurally positioned—through supply and operational relationships—to compel influence.
DGAP frames the challenge explicitly in geopolitical terms. Connected vehicles collect data, communicate continuously with external systems, receive updates, integrate services and suppliers into operations and maintenance, and thus carry an attack surface that consists not only of exploits but also of power relationships. The memorandum illustrates this with an ostensibly tangible example: battery management systems are not merely “electronics”; they are digital control and regulation components capable of influencing physical parameters. In the same breath, it argues that EU rules do set technical guardrails, but do not embed “non-technical risk factors” as a first-order principle; specifically, it criticises the absence of supplier or manufacturer origin as a regulatory consideration.
That diagnosis is broadly correct, but it becomes risky if answered with a simplistic instrument. The temptation is obvious: if “origin” is interpreted as a risk, a ban appears to follow naturally. DGAP moves in that direction by drawing an analogy to US rulemaking. The United States, via the Department of Commerce and the Bureau of Industry and Security, has pursued an approach that restricts connected vehicles and certain hardware/software components with a China or Russia nexus, explicitly grounded in national security concerns, on the premise that firms under the relevant jurisdiction could be compelled to cooperate, thereby enabling access or data exfiltration.
However, once one takes OEM reality seriously, it becomes clear why such an approach is problematic as a European default. “Country of origin” is rarely a single, unambiguous truth in automotive bills of materials. A module may be manufactured in China, its firmware stack may originate in a third country, its update mechanism may run through an OEM pipeline, and its operational servicing may be conducted by a European entity. Conversely, a component may be labelled “European” while toolchains, build pipelines, remote-support pathways, or sub-tier components remain entirely opaque. Reducing the problem to a passport or an assumed country of origin creates incentives for obfuscation and produces an illusory compliance surface that, in a crisis, does not protect—only makes reporting look cleaner.
To DGAP’s credit, the memorandum does not simply follow the political reflex of “ban it”, but instead presses its readership for precision and scoping. It argues that an EU approach—if it is to draw on the US model—must not only arrive quickly, but must above all define with care what constitutes a critical, exposed connected-vehicle component. It cites, as illustrative categories, Wi-Fi, cellular, and satellite connectivity as well as Bluetooth; proximity to telematics and operating systems; advanced driver assistance and automated driving systems; and battery management systems. The list is not perfect, but it points in the right direction: not every part of the vehicle carries the same risk; the primary concern lies with external communication paths and the systems that exercise privileged control over safety- or function-critical domains.
From an OEM perspective, this enables a clear position that can be defended politically without resorting to reflexive resistance. First, Europe must acknowledge that geopolitical leverage is a cyber risk driver, irrespective of how well a manufacturer implements classical CSMS controls. Second, Europe must accept that the appropriate object of governance is not “origin” as a symbol, but “privileged access” as a capability: who can deploy software changes, who can use diagnostic interfaces, who can influence key material, who can manipulate build artefacts or compromise update chains, and who can politically instrumentalise supply relationships through jurisdiction. Third, Europe must formulate requirements such that they are auditable; otherwise, the entire construct degenerates into paper compliance.
At this point, the debate becomes interesting because it begins to move beyond the automotive silo. Even if NIS2 and the CRA are not the leading legal frameworks for the vehicle product, it is politically apparent that the EU is developing a horizontal logic to address “non-technical risks” in ICT supply chains. A Council document concerning the revision of the Cybersecurity Act environment explicitly describes a “trusted ICT supply chain framework” intended to address non-technical risks, identify critical ICT assets, and provide for proportionate countermeasures. The noteworthy element is not an immediate legal effect on the vehicle product, but the signal: conceptually, the EU is moving in the direction DGAP calls for in relation to connected vehicles.
If one brings these lines together, a position emerges for a European OEM that is simultaneously security-driven and industrially responsible. The OEM can and should acknowledge that UN R155, as a risk-based CSMS framework, can in principle incorporate “non-technical risk factors” within risk assessments, but that this does not scale politically without harmonised criteria. What is therefore required is an EU-wide, harmonised add-on that does not replace the CSMS, but overlays it with a trust layer. That trust layer must target critical, exposed subsystems; otherwise, cost and complexity will explode and the outcome will be a busy compliance function rather than increased security. DGAP itself points to cost effects and, through the Porsche example, illustrates that cybersecurity requirements can influence real product decisions; any additional regulation must therefore demonstrate actual risk reduction rather than geopolitical symbolism.
What does this mean in practical terms for the supply chain, particularly with regard to hardware sourcing from China? It does not mean proclaiming “China out”. It means defining which components constitute a strategic risk due to exposure and privilege, and which evidence the OEM must be able to demand and enforce from suppliers. A serious approach will therefore not stop at SBOM rhetoric; it will require build provenance and signature chains, clear rules for remote-support access, and a hard separation between supplier capability and supplier privilege. The distinction is fundamental: a supplier may deliver components, but must not automatically be in a position, post-SOP, to operate with privileged access on the vehicle or on safety-critical update pipelines. In practice, this is often precisely where “non-technical risk” becomes “technical compromise”.
An OEM can also be credible in an assertive, rather than defensive, posture. It can say to policymakers and authorities: we support EU harmonisation because fragmentation reduces real security and only increases cost. We accept the trust debate as an intrinsic part of cybersecurity because jurisdiction and ownership create leverage. We insist, however, that the EU formulate governance precisely, align it to critical functions, and permit a staged approach that prioritises containment and enhanced assurance, with substitution only as a measure of last resort. At the same time, the OEM can commit to making supplier-access models zero-trust capable, anchoring key sovereignty consistently with the OEM, and providing additional assurance artefacts for the externally exposed “crown jewels” of the architecture.
DGAP further calls for speed and argues that later “expunging” of high-risk components will be costly. This is understandable as a political logic, but insufficient as a governing principle. Speed without precision becomes an error multiplier, because supply chains then become not more resilient, but more erratic. What Europe needs is an approach that starts quickly yet takes effect in phases: clear definitions, clear evidence obligations, clear transition windows for new platforms, and realistic containment mechanisms for the installed base. Anything else will either not be implemented or will trigger substantial industry pushback without a corresponding security gain.
The conclusion is therefore straightforward. To the extent that DGAP argues for a rapid adoption of the US ITCS-style regulatory approach, it signals that it has incorporated the commercial and operational constraints of the OEM business only insufficiently into its conceptual model. The solution does not lie in excluding suppliers across the value chain on a country-of-origin principle modelled on the United States. Instead, any incorporation of non-technical risk factors—geopolitical considerations included—must itself remain grounded in risk-based assessment. The underlying problem is real; the trust dimension must be embedded in cybersecurity governance; but the instrument must be auditable, functionally scoped, and harmonised at EU level. If Europe achieves that, it secures two outcomes at once: greater real-world resilience against strategic interference, and avoidance of cybersecurity becoming a disguised industrial or trade-policy contest that ultimately sets the wrong incentives.
Deutsche Version:
Connected Vehicles sind das perfekte Beispiel dafür, wie schnell Europa in einem vertrauten Denkmuster hängen bleibt: Man definiert technische Mindeststandards, man fordert Prozesse, man auditieret Artefakte, und man hofft, dass damit das Problem „Cybersecurity“ erschlagen ist. Im Fahrzeugkontext ist das in Europa sauber institutionalisiert, vor allem über die UN R155 mit dem CSMS- und Typ Approval-Erforernis, welches das Thema bewusst risikobasiert angeht. Genau an dieser Stelle setzt das Memo der DGAP “Connected Vehicle Cybersecurity: The EU Must Consider Non-technical Risk Factors” an, und es trifft einen Nerv: Der technische Rahmen ist notwendig, aber er ist nicht hinreichend, wenn der relevante Risikotreiber nicht die nächste Schwachstelle in einem Stack ist, sondern die Frage, wer entlang der Liefer- und Betriebsbeziehungen strukturell in der Lage ist, Einfluss zu erzwingen.
Die DGAP formuliert das Problem bewusst geopolitisch. Connected Vehicles erfassen Daten, sie kommunizieren ständig nach außen, sie bekommen Updates, sie binden Services und Zulieferer in Betrieb und Wartung ein, und sie tragen damit eine Angriffsoberfläche, die nicht nur aus Exploits besteht, sondern aus Machtbeziehungen. Das Memo nutzt dafür ein vermeintlich sehr greifbares Beispiel: Batteriemanagementsysteme sind nicht nur „Elektronik“, sondern digitale Steuer- und Regelkomponenten, die physische Parameter beeinflussen können. Im selben Atemzug wird betont, dass EU-Regeln zwar technische Leitplanken setzen, aber „non-technical risk factors“ nicht als Kernprinzip verankern; konkret wird kritisiert, dass die Hersteller- oder Zulieferherkunft nicht berücksichtigt wird.
Diese Diagnose ist im Kern richtig, aber sie ist gefährlich, wenn man sie mit einem simplen Instrument beantwortet. Die Versuchung ist offensichtlich: Wenn man „Herkunft“ als Risiko versteht, dann liegt ein Verbot nahe. Genau diese Richtung argumentiert die DGAP, indem sie eine Analogie zur US-Regelsetzung zieht. Die Vereinigten Staaten haben über das Department of Commerce und die Bureau of Industry and Security einen Ansatz gewählt, der Connected Vehicles und bestimmte Hardware-/Software-Komponenten mit China- oder Russland-Nexus einschränkt und das explizit mit nationalen Sicherheitsrisiken begründet, weil Unternehmen unter der jeweiligen Jurisdiktion zur Kooperation gezwungen werden könnten und damit Zugriff oder Datenabfluss möglich wird.
Wenn man aber OEM-Realität ernst nimmt, wird klar, warum das als europäischer Standardansatz problematisch ist. „Country of origin“ ist in Automotive-BOMs selten eine eindeutige Wahrheit. Ein Modul kann in China gefertigt werden, sein Firmware-Stack kann aus einem Drittland stammen, sein Update-Mechanismus kann über eine OEM-Pipeline laufen, und seine operative Wartung kann über eine europäische Entität erfolgen. Umgekehrt kann ein Bauteil „europäisch“ gelabelt sein, während Toolchains, Build-Pipelines, Remote-Support-Zugänge oder Sub-Tier-Komponenten völlig undurchsichtig bleiben. Wer das Problem auf einen Pass oder ein vermeintliches Herkunftsland reduziert, schafft Anreize zur Verschleierung und produziert eine trügerische Compliance-Oberfläche, die im Ernstfall nicht schützt, sondern nur das Reporting hübscher macht.
Nun muss man dem DGAP-Memo zu Gute halten, dass es nicht dem politischen Reflex „ban it“ folgt, sondern vielmehr mit der Forderung nach Präzision und Scoping an seiner Leserschaft herantritt. Das Memo benennt, dass ein EU-Ansatz – wenn er sich am US-Vorbild orientiert – nicht nur schnell kommen müsse, sondern vor allem genau definieren sollte, was überhaupt als kritische, exponierte Connected-Vehicle-Komponente gilt. Es werden als beispielhafte Kategorien unter anderem Wi-Fi-, Mobilfunk- und Satellitenkonnektivität sowie Bluetooth genannt, ebenso Telematik/Operating-System-Nähe, fortgeschrittene Fahrerassistenz- und automatisierte Fahrsysteme sowie Batteriemanagementsysteme. Diese Liste ist nicht perfekt, aber sie zeigt die richtige Denkrichtung: Nicht das gesamte Fahrzeug ist gleich riskant, sondern die externen Kommunikationspfade und die Systeme, die privilegierte Kontrolle über sicherheits- oder funktionskritische Domänen haben.
Aus OEM-Sicht ist daraus eine klare Position ableitbar, die man politisch vertreten kann, ohne in Abwehrreflexe zu verfallen. Erstens muss Europa anerkennen, dass geopolitische Einflussnahme ein Cyber-Risikotreiber ist, und zwar unabhängig davon, wie gut ein Hersteller seine klassischen Controls im CSMS implementiert. Zweitens muss Europa akzeptieren, dass das richtige Steuerungsobjekt nicht „Herkunft“ als Symbol ist, sondern „privileged access“ als Fähigkeit: Wer kann softwareseitig Änderungen ausrollen, wer kann Diagnoseschnittstellen nutzen, wer kann Schlüsselmaterial beeinflussen, wer kann Build-Artefakte manipulieren oder Update-Ketten kompromittieren, und wer kann Lieferbeziehungen über Jurisdiktion politisch instrumentalisieren. Drittens muss Europa Anforderungen so formulieren, dass sie auditierbar sind, weil ansonsten das gesamte Konstrukt zu Papiercompliance degeneriert.
An diesem Punkt wird die Debatte interessant, weil sie an dieser Stelle die Automotive-Blase verlässt. Selbst wenn NIS2 und CRA nicht der führende Rechtsrahmen für das Fahrzeugprodukt sind, ist politisch erkennbar, dass die EU eine horizontale Logik entwickelt, um „non-technical risks“ in ICT-Lieferketten zu adressieren. In einem Ratsdokument zur Revision des Cybersecurity-Act-Umfelds wird explizit ein „trusted ICT supply chain framework“ beschrieben, das nicht-technische Risiken adressieren, kritische ICT-Assets identifizieren und proportionale Gegenmaßnahmen vorsehen soll. Bemerkenswert ist dabei nicht die unmittelbare Rechtswirkung für das Fahrzeugprodukt, sondern die Signalwirkung: Die EU bewegt sich somit konzeptionell genau in die Richtung, die die DGAP für Connected Vehicles fordert.
Wenn man diese Linien zusammenführt, entsteht für einen europäischen OEM eine Position, die gleichzeitig sicherheitsorientiert und industriell verantwortbar ist. Der OEM kann und sollte anerkennen, dass UN R155 als risk-based CSMS-System „non-technical risk factors“ zwar prinzipiell in Risikoanalysen aufnehmen kann, dass dies aber ohne harmonisierte Kriterien politisch nicht skaliert. Es braucht also eine EU-weit einheitliche Ergänzung, die nicht das CSMS ersetzt, sondern einen Trust-Layer darüberlegt. Dieser Trust-Layer muss auf kritische, exponierte Subsysteme zielen, weil sonst Kosten und Komplexität explodieren und am Ende nur die Compliance-Abteilung beschäftigt ist, nicht die Sicherheit. Das DGAP-Memo verweist selbst auf Kosteneffekte und illustriert über das Porsche-Beispiel, dass Cybersecurity-Vorgaben reale Produktentscheidungen beeinflussen können; jede zusätzliche Regulierung muss deshalb zeigen, dass sie Risiko reduziert, statt nur geopolitische Symbolik zu liefern.
Was bedeutet das konkret in der Lieferkette, insbesondere mit Blick auf Hardware-Sourcing aus China? Es bedeutet nicht, dass man „China raus“ ruft. Es bedeutet, dass man definieren muss, welche Komponenten aufgrund ihrer Exponiertheit und Privilegierung ein strategisches Risiko darstellen und welche Nachweise der OEM von Zulieferern erzwingt. Ein seriöser Ansatz wird daher nicht nur SBOM-Rhetorik liefern, sondern Build-Provenance und Signaturketten, klare Regeln für Remote-Support-Zugriffe und eine harte Trennung zwischen Zuliefererfähigkeit und Zuliefererprivileg. Der Unterschied ist fundamental: Ein Zulieferer darf Komponenten liefern, aber er darf nicht automatisch in der Lage sein, nach SOP mit privilegierten Zugängen am Fahrzeug oder an sicherheitskritischen Update-Pipelines zu „operieren“. Das ist in der Praxis häufig genau die Stelle, an der „non-technical risk“ zu „technical compromise“ wird.
Hier kann ein OEM auch offensiv glaubwürdig werden, statt defensiv zu wirken. Man kann gegenüber Politik und Behörden sagen: Wir unterstützen eine EU-Harmonisierung, weil Fragmentierung die reale Sicherheit senkt und nur Kosten erhöht. Wir akzeptieren die Trust-Debatte als Teil von Cybersecurity, weil Jurisdiktion und Ownership Einflussmöglichkeiten schaffen. Wir verlangen aber, dass die EU die Steuerung präzise formuliert, an kritischen Funktionen ausrichtet und einen Stufenansatz zulässt, der Containment, Enhanced Assurance und erst im Extremfall Substitution vorsieht. Gleichzeitig kann der OEM zusagen, dass er intern Supplier-Access-Modelle zero-trust-fähig macht, Schlüsselhoheit konsequent beim OEM verankert und für die „crown jewels“ der extern exponierten Domänen zusätzliche Assurance-Artefakte liefert.
Die DGAP fordert darüber hinaus Geschwindigkeit und verweist darauf, dass ein späteres „Expunging“ risikobehafteter Komponenten teuer wird. Das ist als politische Logik nachvollziehbar, aber als Steuerungsprinzip allein unzureichend. Geschwindigkeit ohne Präzision wird zum Fehler-Multiplikator, weil Lieferketten dann nicht resilienter, sondern hektischer werden. Was Europa braucht, ist ein Ansatz, der schnell startet, aber schrittweise greift: klare Definitionen, klare Evidence-Pflichten, klare Übergangsfenster für neue Plattformen, und für Bestandsplattformen realistische Containment-Mechanismen. Alles andere wird entweder nicht umgesetzt oder erzeugt massive Abwehrreaktionen der Industrie, ohne Sicherheitsgewinn.
Das Fazit: Soweit der Thinktank DGAP für eine schnelle Adaption der US ITCS-Regulierung votiert, macht er deutlich, das er die Rahmenbedingungen des OEM-Geschäfts nur unzureichend in sein Gedankenkonstrukt inkorporiert hat. Die Lösung besteht gerade nicht darin, Zulieferer in der Wertschöpfungskette aufgrund des Herkunftslandprinzip nach US-amerikanischem Vorbild auszuschließen. Vielmehr muss ein entsprechender Ansatz zur Adaption von nicht-technischen Risikofaktoren, wie bspw. geopolitische Aspekte, dennoch auf einer risikobasierten Abwägungen beruhen. Das Problem selbst ist real, der Trust-Aspekt gehört zwingend in die Cybersecurity-Governance, aber das Instrument muss auditierbar, funktional gescoped und europäisch harmonisiert sein. Wenn Europa das schafft, erreicht es zwei Dinge gleichzeitig: Es stärkt reale Resilienz gegen strategische Einflussnahme, und es vermeidet, dass Cybersecurity zum verkappten Industrie- oder Handelspolitik-Spiel wird, das am Ende die falschen Anreize setzt.
