# smartnuts

... the world on the cabaret-style dissecting table

- Website: https://smartnuts.com/

## When phishing meets executive search, the only qualification required is a sufficiently low IQ — on either side.

- Link: https://smartnuts.com/2026/10/08/when-phishing-meets-executive-search-the-only-qualification-required-is-a-sufficiently-low-iq-on-either-side/
- Veröffentlicht: 2026-10-08T21:09:17+02:00
- Autor: Michael Bunzel

Apparently, word of the industry’s predicament is spreading quickly, and so small-
time, pimply-faced scammers, who go by names like Courtney Nierengarten, Victor 
Johnson, or Jennifer Hang and adorn themselves with titles such as “Board Executive
Search Partner” or “Executive Recruiter”, get the idea to go fishing for a bit. 
In an email that appears to have been tweaked with AI to produce reasonably conversational
business English, they offer their assistance with the next step up into the world
of executive-level positions.

With a personalized email, the content of which was scraped from websites and a 
LinkedIn profile, they’re clearly trying to give the impression that they’ve conducted
extensive background research on the potential candidate. Then they top off all 
this drivel with a few ego-boosting compliments … and the phishing email is ready
to go. To be honest … I can’t decide what’s more disturbing: the breathtaking incompetence
of these scammers, or their apparent confidence that the average security professional
is even more incompetent..

Two fundamental principles are now facing off and battling each other in my mind:
On the one hand, the principle of mental plausibility (people tend to attribute 
significance or feasibility to an idea simply because it exists in their minds or
because someone has already invested energy in it), and on the other hand, the circular
reasoning principle (in the sense that there must be “something to it,” _because_
it was tried).

But ultimately, we don’t need to delve that deeply into cognitive science. In the
end, the explanation is probably much more trivial: The scammers’ effort is calibrated
to the anticipated perception threshold of their potential victims. This makes one
thing abundantly clear: We’re getting dumber and dumber and have evidently lost 
all capacity for critical thinking.

## Der Agent hat einen Plan. Hat er auch die Erlaubnis?

- Link: https://smartnuts.com/2026/10/04/der-agent-hat-einen-plan-hat-er-auch-die-erlaubnis/
- Veröffentlicht: 2026-10-04T18:50:26+02:00
- Autor: Michael Bunzel

_Wie normative Anforderungen zu technischen Grenzen für KI-gestützte Security-Tests
werden_

Vor ein paar Jahren war der Begriff “Tech Law” in der Szene wie eine Seuche: Zum
einen waren da die Old School-Juristen, die endlich einen Chance witterten, mit 
ihren Themenfeldern wieder in alle Munde zu kommen: angefangen vom angestaubten 
Gewerblichen Rechtsschutz über das Urheber- und das Datenschutzrecht bis hin zum
IT-Recht (Softwareverträge, E-Commerce-Recht, Cloud Computing, IT-Sicherheitsrecht)–
man gab sich jung, frisch und am Puls der Zeit. Und dann bogen die Hipster unter
den Tech Lawyers um die Ecke, die ihre Blogs mit Begriffen wir Block Chain, Code
ist Law, Smart Contracts, Tokenisierung und NFTs, DAOs, Oracles fluteten – einmal
mehr beseelt vom Wunsch, die Aufmerksamkeitswelle auch mal mit ein paar juristischen
Themen reiten zu können.

Wenn man heute die juristischen Frontier- oder Edge-Themen auf einer Perlenkette
aufreihen wollte, finden sich dann solche Schlagworte wie KI-Agenten als Vertragspartner,
Rules-as-Code, Agent-Kartelle (bspw. im Kontext von Preisabsprachen), Digital Twins,
Quantencomputing und digitale Signatur und Neurorights. All diesen Themen ist gemein,
dass man auf diese im Rahmen des hergebrachten Rechtsrahmens keine verlässlichen
Antworten geben kann. Verengt man den Blick auf potentielle Fallgestaltungen im 
Kontext eines OEMs, sind wir diesbezüglich auch mit hinreichend Potential für juristische
Aufarbeitung gesegnet. Beispielhaft seien an dieser Stelle folgende Themen genannt:

 * LLM-gestütztes Pentesting**:** Was gilt, wenn der Agent den vereinbarten Scope
   verlässt? Offen sind Autorisierung, Hackerparagraf und Haftung zwischen Auftraggeber,
   Supplier und Tool-Anbieter.
 * KI-generierter Code im CRA**:** Wer ist Hersteller, wer schuldet die Sorgfalt,
   und gehört das Modell in die SBOM?
 * Scope-Kollision CRA und R155**:** Das Fahrzeug ist ausgenommen, aber was ist 
   mit Aftermarket, Ladeinfrastruktur und Backend?
 * Data Act gegen Cybersecurity**:** Die Pflicht zum Datenzugang trifft auf die 
   Pflicht zur Abschottung.
 * Kollidierende Meldepflichten für Schwachstellen: EU und China verlangen jeweils
   zuerst die Meldung an die eigene Behörde.
 * OTA-Updates und Typgenehmigung: Ab wann ist ein Update ein neues Fahrzeug?
 * Herkunft als Rechtskriterium: Bei ICTS-Regeln und Connected-Vehicle-Verboten 
   wird Geopolitik zur Compliance-Frage.
 * “Stand der Technik” und Post-Quantum: Ab wann ist fehlende Krypto-Agilität ein
   Rechtsverstoß?

Der vorliegende Blogbeitrag beschäftigt sich in der Frage, wie man als Produktverantwortlicher
die normative Verpflichtung zur Validierung (nachfolgend i.S.d. Pentestings) des
eigenen Produkts bzgl. Schwachstellen unter Nutzung von LLM-Modellen so designed,
orchestriert und dokumentiert, dass man weder zu kurz (“Nein! Sie haben nicht alles
getan, um Schwachstellen in ihrem Fahrzeug zu finden.”) noch zu weit (Schade, dass
ihre Pentester diese unscheinbare Drittbibliothek im Code des Suppliers auch noch
getestet haben und dabei auch noch Lastenhefte, Specs usw. in die Cloud des LLM-
Abieters hochgeladen haben) springt. Dies ist mithin ein Tanz auf der Rasierklinge,
der natürlich in einem Umfeld, welches durch die Neugier von Ingenieuren vorangetrieben
wird, häufig immer erst zu einer technischen Lösungen/Implementierung führt und 
dann erst im zweiten Schritt die normativen Regeln nachzieht.

Doch nun genug des Vorspiels. Starten wir zunächst mit einem kleinen Beispiel, um
das Problem zur verdeutlichen:

Stellen wir uns vor, ein KI-Agent untersucht die Software eines Steuergeräts im 
Testlabor. Er entdeckt Zugangsdaten und schlägt vor, sie gleich am Backend eines
Suppliers auszuprobieren. Technisch ist das eine naheliegende Anschlussfrage. Für
den Testauftrag kann es ein Sprung über die Grenze sein: War das Backend freigegeben?
Wer dürfte einen solchen Zugriff erlauben? Und welche Informationen hat der Agent
bis dahin bereits verarbeitet?

Diese Fragen lassen sich nicht erst im Abschlussbericht beantworten. Eine Plattform
für agentische Security-Tests muss den zulässigen Handlungsrahmen kennen, bevor 
der erste Toolaufruf erfolgt.

## Die Übersetzungslücke zwischen Anforderung und Test

In der Automotive Cybersecurity (ACS) sind wir gewohnt, Risiken, Maßnahmen und Nachweise
über den Lebenszyklus eines Fahrzeugs zu betrachten. Die [UN-R155](https://eur-lex.europa.eu/eli/reg/2025/5/oj/deu/pdf)
verlangt unter anderem Prozesse für Cybersecurity-Tests und den Umgang mit Risiken
und Abhängigkeiten in der Lieferkette. Sie schreibt keine KI-Agenten vor. Sie stellt
aber eine Frage, die mit wachsender Testautomatisierung konkreter wird: Wie lässt
sich nachweisen, dass Prüfungen wirksam, nachvollziehbar und innerhalb ihres zulässigen
Rahmens durchgeführt wurden? Der hierfür einschlägige Rahmen wird dabei nicht (nur)
durch die ACS-Hom-Anforderungen determiniert. Vielmehr treffen diese dann auf Normen
des Strafsanktionsrechts, der Urheber-, Datenschschutz und Geschäftsgeheimnisschutzes.
Erst im ausbalancierten Verhältnis der vorgenannten Normen mit den homologationsrechtlichen
Anforderungen kann eine Antwort auf die Frage gefunden werden, wie man die Idee 
des LLM-basierten Pentestings praktisch umzusetzen vermag.

Was den hierfür erforderlichen Rahmen angeht: Für die Homologation über verschiedene
Märkte hinweg gibt es darauf keine weltweit einheitliche Checkliste. Schon innerhalb
des UNECE-Systems wenden Vertragsparteien [nicht automatisch jede UN-Regelung an](https://unece.org/transport/vehicle-regulations/faq).
Eine gemeinsame Testplattform kann dennoch einen stabilen Kern schaffen und die 
jeweils geltenden Anforderungen als überprüfbare Regeln und Nachweise abbilden.

Dazwischen liegt die eigentliche Arbeit. Eine normative Vorgabe oder ein Supplier-
Vertrag sagt noch nicht, ob ein Agent _jetzt_, gegen _dieses_ Steuergerät und mit
_diesen_ Parametern einen bestimmten Test ausführen darf.

## Das Engagement schreibt den Handlungsrahmen fest

Ausgangspunkt jedes Testlaufs sollte deshalb ein freigegebenes Testing Engagement
sein. Es beschreibt das Testobjekt einschließlich Softwareversion und Umgebung, 
die zulässigen Targets und Methoden, die Eingriffstiefe, zeitliche und technische
Grenzen sowie den Umgang mit Daten. Ebenso hält es fest, auf welcher Befugnis der
Test beruht und wer eine Erweiterung freigeben kann.

Diese Festschreibung ist mehr als ein Ticket mit dem Vermerk „Pentesting erlaubt“.
Gerade bei Supplier-Software können Beobachtung und Test, Programmkopien, Bearbeitung
oder Dekompilierung unterschiedlich zu beurteilen sein; das zeigen bereits die [§§ 69c bis 69e UrhG](https://www.gesetze-im-internet.de/urhg/BJNR012730965.html).
Auch eine Freigabe für ein Steuergerät umfasst nicht automatisch ein Supplier-Backend,
Systeme von Unterlieferanten oder die Übermittlung vertraulicher Artefakte an einen
externen KI-Dienst.

Hier liegt zugleich die mögliche Erlaubniswirkung gegenüber Suppliern: Soweit die
zuständigen Parteien einen konkreten Testumfang wirksam vereinbart oder freigegeben
haben, kann das Engagement diese Befugnis eindeutig dokumentieren. Der Plattformdatensatz
erteilt selbst keine Rechte. Er sorgt allerdings dafür, dass sich die tatsächlich
erteilte Erlaubnis in den ausführbaren Aktionen wiederfindet. Wird der Scope erweitert,
braucht auch die Freigabe eine erneute Prüfung.

## Aus der Freigabe wird eine Laufzeitentscheidung

Ein Agent auf Basis eines großen Sprachmodells kann Hypothesen entwickeln, Tests
planen und den nächsten sinnvollen Schritt vorschlagen. Ob er ihn ausführen darf,
entscheidet eine Kontrollschicht außerhalb des Modells.

Dafür werden Testhandlungen typischer Weise in einer gemeinsamen Capability Matrix
beschrieben. Diese Capability_matrix definiert dann, was bei welchem Target, in 
welcher Umgebung und mit welcher Wirkung zulässig ist. Die daraus abgeleiteten Plattformregeln
beantworten einen konkreten Toolaufruf sodann mit ALLOW, DENY oder STEP-UP – also
Ausführen, Sperren oder zusätzliche Freigabe einholen.

Nun aber zurück zu unserem ursprünglichen Beispiel: Begrenzte Diagnoseaufrufe am
freigegebenen Steuergerät können erlaubt sein. Das Schreiben in den Speicher kann
gesperrt sein. Der Wechsel zu einem Backend auf der anderen Seite löst aber mindestens
eine neue Scope- und Berechtigungsprüfung aus. Der Agent kann diesen Wechsel zwar
vorschlagen; seine eigene Einschätzung erweitert den Auftrag aber eben nicht automatisch.

Dies ist letztlich die technisierte Implementierung von Governance: Fachliche und
rechtliche Entscheidungen werden zunächst von Menschen getroffen und anschließend
als Regeln im Ausführungspfad wirksam. Die KI dageben bleibt für Analyse und Anpassung
flexibel einsetzbar. Ihre Werkzeuge allerdings bleiben an den freigegebenen Rahmen
gebunden.

## Der Scope umfasst auch Informationen

Ein weiterer interessanter Punkt: Bei KI-gestützten Tests endet die Governance nicht
an der Netzwerkschnittstelle. Supplier-Dokumentation, Quellcode, Tickets, Logs und
frühere Findings können für einen Test wertvoll sein. Sie können aber zugleich auch
vertrauliche oder personenbezogene Informationen enthalten. Das Engagement muss 
also festlegen, welche Daten ein Agent sehen darf, welches Modell sie verarbeiten
darf und ob eine externe Verarbeitung überhaupt freigegeben ist. Bei personenbezogenen
Daten kommen noch die Anforderungen der [DSGVO](https://eur-lex.europa.eu/eli/reg/2016/679/oj/deu)
hinzu.

Hinzu kommt ein technisches Problem: Ein Dokument kann Anweisungen enthalten, die
ein Sprachmodell fehlleiten sollen (sog. AI-Prompt Injection). Solche Inhalte sind
mithin Testdaten und keine Befehle an den Agenten. [OWASP beschreibt Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
und zu weitreichende Agentenrechte als eigenständige Risiken. Datenklassifizierung,
begrenzte Toolrechte und eine vom Modell unabhängige Freigabeentscheidung gehören
deshalb zusammen.

Schließlich muss die Plattform den Ablauf rekonstruierbar halten: Welches Engagement
galt? Welche Information führte zu welcher Testhypothese? Welche Aktion wurde beantragt,
erlaubt und tatsächlich ausgeführt? So entsteht neben dem Finding auch ein belastbarer
Nachweis über seinen Entstehungsweg.

## Auf dem Weg zu einer gemeinsamen Sprache

Eine KI-Validierungs- oder Pentesting-Plattform beginnt nicht mit einem allmächtigen
Pentesting-Agenten. Sie beginnt mit einer Capability Matrix, an der Cybersecurity,
Engineering, Supplier Management, Datenschutz und Legal beziehungsweise Homologation
gemeinsam arbeiten. Für Analyse, Fuzzing, Exploit-Verifikation, Zugriff auf weitere
Systeme und Nutzung externer Modelle muss jeweils klar sein, welche Befugnis, Grenze
und Freigabe gilt.

Nicht jede normative Frage lässt sich mit technischen Mittel abbilden oder automatisieren.
Eine geklärte Entscheidung in normativen Sinne lässt sich aber technisch durchsetzen
und später belegen. Genau darin liegt der Gewinn einer Plattform, auf der entsprechende
Engagements nach festehenden Rahmenbedingungen definiert werden: Mehr adaptive Testintelligenz
wird möglich, weil der erlaubte Handlungsrahmen vor dem Test feststeht, während 
des Tests gilt und danach nachvollziehbar bleibt.

## Diese undankbaren Chinesen

- Link: https://smartnuts.com/2026/06/25/diese-undankbaren-chinesen/
- Veröffentlicht: 2026-06-25T23:27:18+02:00
- Autor: Michael Bunzel

_… über die Empörung, dass die chinesische Executive Order No. 834 ausgerechnet 
das US-ICTS-Mapping in der Automotive Supply Chain erschwert._

Wie kann man nur so undankbar sein. Da gibt sich die freie Welt redliche Mühe, die
globale Lieferkette endlich sauber nach Herkunftsländern zu sortieren, und was macht
Peking? Es macht es schwer. Einfach so. General Motors hatte seinen Zulieferern 
aufgetragen, bis 2027 chinesische Teile und Materialien aus den nordamerikanischen
Lieferketten zu entfernen. Ein durchschnittliches Auto besteht aus rund 30.000 Teilen,
vom Halbleiter bis zur Schraube. Und für jedes davon heißt es jetzt natürlich erst
einmal: lückenlos kartieren, wo dieses China überall drinsteckt. Eine ehrliche Fleißarbeit.
Und mitten hinein platzt die chinesische Regierung mit einer Verordnung, die genau
dieses Kartieren zum rechtlichen Risiko macht. Wie kann man nur.

Man fragt sich wirklich, wie diese Leute auf so etwas kommen. Anstatt dankbar zuzusehen,
wie ausländische Konzerne ihre Lieferanten, ihre Werke und ihre Prozesse im Detail
vermessen, um einer US-Behörde zuzuarbeiten, stellen sie sich quer. Undankbar. Beinahe
so, als hätten sie ein Interesse daran, dass niemand Fremdes ihre Lieferketten ausleuchtet.

Und dann, irgendwo zwischen der dritten Beschwerde-E-Mail und dem vierten Compliance-
Webinar, kommt der unangenehme Gedanke: Moment. Wer hat damit angefangen, die Lieferkette
zur Waffe zu erklären?

## Wer hatS Erfunden?

Das Instrument heißt ICTS. Hinter dem Kürzel steckt die [Executive ](https://www.federalregister.gov/documents/2019/05/17/2019-10538/securing-the-information-and-communications-technology-and-services-supply-chain)
[Order](https://www.federalregister.gov/documents/2019/05/17/2019-10538/securing-the-information-and-communications-technology-and-services-supply-chain)
[ 13873](https://www.federalregister.gov/documents/2019/05/17/2019-10538/securing-the-information-and-communications-technology-and-services-supply-chain)
von 2019, „Securing the Information and Communications Technology and Services Supply
Chain”, ausbuchstabiert im US-Handelsministerium durch das Bureau of Industry and
Security und kodifiziert in 15 C.F.R. Part 791. Die für Autos einschlägige Ausprägung
ist die [Connected-Vehicles-Regel von Anfang 2025 (90 FR 5360, in Kraft seit dem 17. ](https://www.federalregister.gov/documents/2025/01/16/2025-00592/securing-the-information-and-communications-technology-and-services-supply-chain-connected-vehicles)
[März](https://www.federalregister.gov/documents/2025/01/16/2025-00592/securing-the-information-and-communications-technology-and-services-supply-chain-connected-vehicles)
[ 2025)](https://www.federalregister.gov/documents/2025/01/16/2025-00592/securing-the-information-and-communications-technology-and-services-supply-chain-connected-vehicles).
Sie verbietet, gestaffelt nach Modelljahr, vernetzte Fahrzeuge mit Software aus 
China oder Russland ab Modelljahr 2027 und mit entsprechender VCS-Hardware ab Modelljahr
2030. „Foreign adversary” ist hier ein Rechtsbegriff, kein Stilmittel.

Das ist der Startschuss. Nicht Peking hat die Lieferkette zum Schlachtfeld erklärt,
sondern Washington hat sie zuerst als Hebel entdeckt: Wer hier verkaufen will, muss
nachweisen, woher jede relevante Zeile Code und jedes relevante Funkmodul stammt.
Die Kartierung, über deren Erschwerung sich nun alle empören, ist nicht Selbstzweck.
Sie ist Erfüllungsgehilfin einer amerikanischen Regel.

Wie ernst es gemeint ist, zeigt der erste US-amerikanische OEM, der um eine Ausnahme
bittet. Ford hat beim US-Handelsministerium beantragt, den in China gebauten Lincoln
Nautilus trotz der Regel weiter importieren zu dürfen. Pikant daran: Die Software
des Fahrzeugs wird in den USA entwickelt, in China wird sie dann in dasselbige geflasht.
Und allein das genügt, um eben jenen Lincoln Nautilus unter die Regel fallen zu 
lassen. Der Erfinder des Spiels bittet als Erster darum, von den eigenen Regeln 
verschont zu bleiben. Man muss das nicht kommentieren. HIer schriebt schreibt sich
Ironie (und ein bisserl Häme) ganz von selbst.

## Geliefert wie Bestellt …

Auf eine Lieferketten-Waffe folgt eine Lieferketten-Waffe. Am 31. März 2026 trat
in China die Verordnung in Kraft, die der ganzen Debatte ihren Namen gab: [State Council Decree No. 834](https://www.chinalawtranslate.com/en/-State-Council-Provisions-on-Industrial-and-Supply-Chain-Security/),
die „Provisions of the State Council on the Security of Industrial and Supply Chains”.
Ihr Artikel 13 stellt Untersuchungen und Datenerhebungen zur Lieferkette durch ausländische
Akteure unter Genehmigungsvorbehalt: Lieferanten-Audits, Fragebögen, Vor-Ort-Prüfungen.
Wer ohne Freigabe kartiert, um fremden Compliance-Regimes zuzuarbeiten, handelt 
rechtswidrig.

Übersetzt: Genau das Mapping, das die ICTS-Regel verlangt, wird auf chinesischem
Boden zum regulatorischen Risiko. Der Tier 1, der seinem amerikanischen Kunden zuliefern
und gleichzeitig seinen chinesischen Sub-Lieferanten ausleuchten will, sitzt in 
der Zange. Beide Seiten verlangen das Gegenteil voneinander, und er steht in der
Mitte. Das ist der Catch-22, über den sich die Branche zu Recht beklagt, nur eben
bei der falschen Adresse.

## 835 – The HIDden Gem …

Hier wird es für die Empörten richtig unangenehm. Denn 834 ist die defensive Hälfte
der Regulierung. Die offensive steht eine Erlassnummer weiter – und die hat es dann
wirklich in sich.

Eine Woche später, am 7. April 2026, trat [Decree No. 835](https://www.chinalawtranslate.com/en/counter-long-arm/)
in Kraft, die „Regulations of the PRC on Countering Unjustifiable Extraterritorial
Jurisdiction Measures Imposed by Foreign States”. Sie schafft ein Verfahren, ausländische
Maßnahmen als „ungerechtfertigt” einzustufen, sie per Anordnung zu untersagen und
die Akteure, die sie umsetzen, auf eine „Malicious Entities List” zu setzen. Das
ist keine Supply-Chain-Hygiene mehr. Das ist die maßstabsgetreue Spiegelung der 
ICTS-Logik: Wenn ihr unsere Komponenten nach Herkunft aussperrt, sperren wir die
Umsetzung eurer Aussperrung aus.

Die Pointe ist fast zu schön. In der ursprünglichen Empörung schwang ja der Vorwurf
mit, China hätte es doch auch eleganter haben können, etwa mit einer zu ICTS reziproken
Regelung gegen Hard- und Software aus unsicheren Herkunftsländern. Die Antwort steht
längst im Gesetzblatt. Sie haben eine solche Regelung gemacht. Sie heißt 835. Während
der Westen über die defensive 834 jammert, hat er die wahre Antwort auf die eigene
Politik schlicht übersehen.

## Reziprozität UND Kausalität

Wer das für chinesische Bockigkeit hält, hat das Spiel nicht verstanden. Reziprozität
ist das vorhersehbarste Muster der Handelspolitik und kein reflexhafter Gefühlsausbruch.
Ein Instrument, das den Marktzugang an die Herkunft jeder Komponente knüpft, exportiert
die Bauanleitung für sein Spiegelbild gleich mit. Man bekommt nicht die Vorteile
der Lieferketten-Waffe ohne das Risiko, dass die Gegenseite dieselbe Waffe baut.
Sie liegt offen herum, fertig konstruiert.

Und an dieser Stelle lohnt der ehrliche Blick auf den vermeintlich naiven Gegenspieler.
China behandelt Lieferketten-Resilienz nicht als moralisches Projekt, sondern als
Hebel: integriert, staatlich orchestriert über ein Dutzend Behörden, in einem Aufwasch
defensiv (834) und offensiv (835). Der Westen verteilt dieselbe Aufgabe auf konkurrierende
Programme, garniert sie mit Werten und wundert sich, dass die Gegenseite schneller
und geschlossener zieht. Man muss Pekings Methoden nicht mögen, um zu erkennen, 
wer hier das Spiel um globale Marktmacht besser begriffen hat.

## … UND wie es die Supplier betrifft

Für OEMs und ihre Tier-Xe ist die Lehre unbequem, aber schlicht. Regulatorisches
Decoupling schneidet in beide Richtungen: Jede Anforderung, die Herkunft zur Bedingung
macht, erzeugt mit einiger Wahrscheinlichkeit eine symmetrische Gegenanforderung
auf der anderen Seite. Wer nur die eigene Seite plant, plant das halbe Problem. 
Das Fenster für lückenloses Mapping schließt sich deshalb von beiden Seiten zugleich:
ICTS zieht von außen, 834 von innen. Wer auf die OEM-Direktive wartet, kommt zu 
spät zu einem Mapping, das dann längst zum Risiko geworden ist. Und darunter sitzt
die strategisch wichtigste Einsicht: Resilienz ist nicht dasselbe wie einseitiges
De-Risking. Eine Lieferkette, die nur gegen eine Himmelsrichtung gehärtet ist, ist
nicht resilient, sondern bloß anders abhängig.

Die ehrliche Planungsannahme lautet deshalb nicht, wie man sich von China befreit,
sondern wie man operiert, während zwei Großmächte denselben Hebel gegeneinander 
ansetzen und der eigene Lieferant dazwischensteht. Das ist unbequemer als ein Mapping-
Projekt mit Stichtag 2027. Es ist aber die Lage.

Insofern: Schluss mit der Empörung über die undankbaren Chinesen. Sie haben nur 
zugehört, als der Westen ihnen vorgemacht hat, wie man die Lieferkette zur Waffe
macht, und es dann ordentlicher umgesetzt. Wie man in den Wald hineinruft, so schallt
es heraus. Niemand sollte sich wundern, wenn das Echo lauter zurückkommt, als der
Ruf hineingegangen ist.

---

_Dieser Beitrag gibt eine persönliche fachliche Einschätzung des Autors wieder und
keine Position seines Arbeitgebers. Mit diesem Beitrag ist keine Rechtsberatung 
intendiert. Maßgeblich für die im Beitrag genannten regulatorischen Vorgaben ist
der jeweils geltende Rechtstext._

## Der überlesene Absatz – ODER: Wann der AI Act das Fahrzeug erreicht

- Link: https://smartnuts.com/2026/06/21/der-ueberlesene-absatz-oder-wann-der-ai-act-das-fahrzeug-erreicht/
- Veröffentlicht: 2026-06-21T00:17:13+02:00
- Autor: Michael Bunzel

… _und warum das bestehende Cybersecurity-Management-System die geforderte AI-Security(
noch) nicht trägt._

## Eine Deadline, die in einigen Roadmaps falsch Verortet wurde

In zahlreichen Compliance-Roadmaps der Automobilindustrie ist der 2. August 2026
als harte Frist vermerkt: ab diesem Tag, so die verbreitete Lesart, greife der EU
AI Act mit vollem Pflichtenkatalog auf Fahrzeuge mit KI-gestützten Fahrfunktionen.
Diese zeitliche Verortung ist im Kern falsch. Und sie ist zudem teuer, weil sie 
Ressourcen auf eine Frist lenkt, die für das Fahrzeug so nicht existiert, während
die regulatorische Entwicklung an einer ganz anderen Stelle stattfindet.

Der Grund liegt in einem Absatz, der in der Diskussion regelmäßig übergangen wird:
[Artikel 2 Absatz 2](https://artificialintelligenceact.eu/de/article/2/) in Verbindung
mit der Zweiteilung von [Anhang I des AI Act](https://artificialintelligenceact.eu/de/annex/1/).
In der Homologations-Planung ist der AI Act danach keine Direktnorm mit Stichtag
2026. Er ist für das Fahrzeug ein Rahmen, dessen materielle Anforderungen erst über
das sektorale Typgenehmigungsrecht greifen, zeitversetzt und in dessen Logik.

Aus diesem ersten Befund folgt ein zweiter, der in den Roadmaps noch seltener auftaucht:
Selbst wenn die Anforderungen des AI Act über das Typgenehmigungsrecht ankommen,
ist damit nicht gesagt, dass der vorhandene Cybersecurity-Nachweisapparat des Fahrzeugs
sie inhaltlich trägt. Die erste Frage ist eine des _Wann und über welches Regime_;
die zweite eine des _Womit_. Beide werden hier getrennt beantwortet; denn gerade
ihre Vermengung erzeugt eben jene teuren Planungsfehler, auf die die OEMs gerade
in den jetzigen Zeiten gern verzichten würden.

## Der Mythos und seine Quelle

Die Argumentationskette des Missverständnisses ist auf den ersten Blick schlüssig:
KI-Systeme für das automatisierte und autonome Fahren sind Hochrisiko-Systeme; Hochrisiko-
Systeme unterliegen dem vollen Anforderungskatalog des AI Act (Art. 8 bis 15); also
gilt dieser Katalog ab Anwendbarkeit des AI Act für das Fahrzeug.

Der Fehler steckt im mittleren Glied: Der AI Act kennt zwei Wege in die Hochrisiko-
Klassifizierung, und sie führen zu unterschiedlichen Rechtsfolgen:

 * **[Anhang III](https://artificialintelligenceact.eu/de/annex/3/)** erfasst eigenständige
   Hochrisiko-Anwendungen (etwa biometrische Identifizierung oder KI im Beschäftigungskontext).
   Für diese gilt der materielle Pflichtenkatalog unmittelbar.
 * **[Anhang I](https://artificialintelligenceact.eu/de/annex/1/)** erfasst KI als
   Sicherheitskomponente oder Produkt innerhalb bestehender Produktsicherheits- 
   und Typgenehmigungsregime. Hier ist die Rechtsfolge differenzierter, und in diese
   Kategorie fällt das Fahrzeug.

Die Vermengung beider Anhänge unter dem pauschalen Etikett „Hochrisiko” erzeugt 
den Mythos der harten 2026-Fahrzeug-Deadline.

## Die Korrektur: der Abschnitt-B-Mechanismus

Die Hochrisiko-Einordnung von KI-Fahrfunktionen ergibt sich aus [Art. 6 Abs. 1 AI Act](https://artificialintelligenceact.eu/de/article/6/)
in Verbindung mit Anhang I. Art. 6 Abs. 1 verlangt zwei kumulative Bedingungen: 
Das KI-System ist Sicherheitskomponente eines Produkts (oder selbst ein Produkt),
das unter eine in Anhang I gelistete Harmonisierungsvorschrift fällt (lit. a), und
dieses Produkt unterliegt vor dem Inverkehrbringen einer Drittkonformitätsbewertung
nach jener Vorschrift (lit. b). Für ein typgenehmigungspflichtiges Fahrzeug ist 
beides erfüllt.

Die innere Struktur von Anhang I ist zweigeteilt:

 * **Abschnitt A** listet die Rechtsakte des „New Legislative Framework” (Maschinen,
   Spielzeug, Medizinprodukte und weitere).
 * **Abschnitt B** listet acht sektorale Sonderregime mit eigenem, etabliertem Typgenehmigungs-
   bzw. Zertifizierungssystem, darunter die Luftfahrt, die Bahn, die Schifffahrt
   und das Kraftfahrzeugrecht.

Die für das Fahrzeug maßgeblichen Rechtsakte stehen in Abschnitt B: die Typgenehmigungs-
Rahmenverordnung [VO (EU) 2018/858](https://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX:32018R0858)(
Anhang I, Eintrag 18) und die „General Safety Regulation” [VO (EU) 2019/2144](https://eur-lex.europa.eu/eli/reg/2019/2144/oj?locale=de)(
Anhang I, Eintrag 19).

Diese Verortung in Abschnitt B bestimmt die Rechtsfolge. Art. 2 Abs. 2 AI Act ordnet
für Hochrisiko-KI, die zu Produkten unter den Abschnitt-B-Rechtsakten gehört, ausdrücklich
an:

„… only Article 6(1), Articles 102 to 109 and Article 112 apply.”

Für das Fahrzeug gilt damit nicht der materielle Hochrisiko-Katalog aus Kapitel 
III Abschnitt 2 (Art. 8 bis 15) unmittelbar. Es gibt keinen direkten Durchgriff 
einer „AI-Act-Konformitätsbewertung” über eine notifizierte Stelle auf das typgenehmigte
Fahrzeug, und die Anforderungen an Risikomanagement, Daten-Governance, Transparenz,
menschliche Aufsicht oder Robustheit greifen nicht als unmittelbar anwendbares Recht.
Anwendbar sind allein die Klassifizierungsregel (Art. 6 Abs. 1), die Änderungsbefehle
an das Sektorrecht (Art. 102 bis 109) und eine Schlussbestimmung (Art. 112). Alle
übrigen Regelungen des AI Act, einschließlich des materiellen Pflichtenkatalogs 
und der horizontalen Verfahrensregeln, sind durch die abschließende Aufzählung des
Art. 2 Abs. 2 für das Fahrzeug ausgenommen.

## „Aber nicht nichts”: Integration über das Typgenehmigungsrecht

Daraus zu schließen, der AI Act sei für das Fahrzeug irrelevant, ginge allerdings
ebenso fehl. Der Verweis auf die Art. 102 bis 109 ist nicht nur deklaratorisch, 
sondern der Wirkmechanismus selbst: Diese Artikel ändern die Abschnitt-B-Rechtsakte
und verankern die AI-Act-Anforderungen dort, wo sie das Fahrzeug erreichen, im Typgenehmigungsrecht.

Konkret:

 * [**Art. 107 AI Act** ](https://artificialintelligenceact.eu/de/article/107/)fügt
   dem Art. 5 der VO (EU) 2018/858 einen Absatz hinzu, wonach bei künftigen delegierten
   Rechtsakten zu KI-Sicherheitskomponenten die Anforderungen des Kapitels III Abschnitt
   2 des AI Act zu berücksichtigen sind.
 * **[Art. 109 AI Act](https://artificialintelligenceact.eu/de/article/109/)** fügt
   dem Art. 11 der VO (EU) 2019/2144 eine parallele Bestimmung für Durchführungsrechtsakte
   hinzu.

Die materiellen Hochrisiko-Anforderungen gelangen also nicht per Stichtag in das
Fahrzeug, sondern dann und in dem Maße, wie die Kommission sie über delegierte bzw.
Durchführungsrechtsakte in die typgenehmigungsrechtliche Systematik überführt. Selbst
dort gelten sie zunächst als „zu berücksichtigender” Maßstab, nicht als unverändert
durchgereichter Katalog. Diese Lesart deckt sich mit der Anwendungsregel des Art.
113: Während der AI Act allgemein ab dem 2. August 2026 anwendbar ist, gelten Art.
6 Abs. 1 und die zugehörigen Pflichten erst ab dem 2. August 2027.

Der für die Homologation relevante Stichtag ist damit nicht 2026 und genaugenommen
auch nicht 2027, sondern der jeweils noch offene Zeitpunkt der sektoralen Rechtsetzung.

## Vorausschau I: die offene Novellierung

Damit verschiebt sich die regulatorische Beobachtungsaufgabe: Die Variable ist nicht
länger der AI Act-Text; es ist die Frage, wann und wie die Kommission die delegierten
und Durchführungsrechtsakte unter VO 2018/858 und VO 2019/2144 ausgestaltet, die
die Kapitel-III-Anforderungen in das Fahrzeugrecht tragen.

Belastbare Termine hierfür liegen derzeit nicht vor; jede Datierung wäre Spekulation.
Festhalten lässt sich jedoch die Mechanik: Die Integration erfolgt im etablierten
Verfahren der Fahrzeug-Rechtsetzung, mit dessen Konsultations-, Beteiligungs- und
Übergangslogik, nicht im Tempo des horizontalen AI-Act-Zeitplans. Für die Planung
folgt daraus, die Anforderungen aus Art. 8 bis 15 (Risikomanagement, Daten und Daten-
Governance, technische Dokumentation, Protokollierung, Transparenz, menschliche 
Aufsicht, Genauigkeit/Robustheit/Cybersecurity) bereits jetzt als kommende Typgenehmigungsmaßstäbe
zu behandeln, ohne sich an eine vermeintliche 2026-Frist zu binden.

## Zwei Fragen, nicht eine

Die bisherige Korrektur betrifft die institutionelle Ebene: über _welches_ Regime
und ab _wann_ die Anforderungen des AI Act das Fahrzeug erreichen. Mit ihr ist die
zweite, schwierigere Frage erst gestellt, jedoch noch nicht beantwortet: Trägt der
_Inhalt_ des heutigen Cybersecurity-Nachweisapparats die Schutzziele, die der AI
Act für die KI-Sicherheitskomponente verlangt, sobald sie über die Novellierung 
ankommen?

Diese Trennung ist mehr als akademisch. Die in der Praxis gängige Leitfrage, ob 
sich die AI-Security über die Automotive Cybersecurity (UN R155 und die VO 2018/
858) abdecken lässt oder ob es eine stärker IT-bezogene Betrachtung braucht, suggeriert
eine Wahl zwischen zwei Polen. Tatsächlich laufen hier zwei Ebenen auseinander, 
die getrennt zu beantworten sind:

 1. **Institutionell:** durch welches Regime wird die AI-Security des Fahrzeugs verwaltet?
    Die Antwort ist sektoral, nicht horizontal.
 2. **Substanziell:** trägt der heutige Inhalt dieses Regimes die KI-spezifischen Schutzziele?
    Die Antwort ist nein … zumindest nicht ohne Ergänzung.

Die Vermengung beider Ebenen führt zu zwei Fehlern: zur falschen Beruhigung („es
gibt ja die UN R155”) oder zum falschen Reflex („dann braucht es einen zweiten, 
IT-getriebenen Nachweisstrang”). Beides verfehlt den Kernpunkt der Diskussion. Die
folgenden Abschnitte beantworten die institutionelle Ebene knapp, da sie bereits
entschieden ist, und widmen sich dann der substanziellen, die die eigentliche Vorbereitungsaufgabe
enthält.

## Die institutionelle Antwort: der Gesetzgeber normiert sektoral

Dass die AI-Security des Fahrzeugs im Typgenehmigungsregime und nicht in einem parallelen
horizontalen IT-Regime verwaltet wird, ist eine gesetzgeberische Entscheidung und
keine offene Auslegungsfrage mehr; sie wird an zwei Stellen deutlich sichtbar:

Erstens der **Cyber Resilience Act** ([VO (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj?locale=de)):
Er nimmt in Art. 2 Abs. 2 Produkte, für die die VO (EU) 2019/2144 gilt, ausdrücklich
aus seinem Anwendungsbereich aus. Die Begründung (EG 27/28) ist die eines _lex specialis_:
Das Kfz-Typgenehmigungsrecht leistet über R155 bereits eine lebenszyklusweite, zertifizierte
CSMS-Cybersecurity; das horizontale IT-Produkt-Regime tritt dort zurück, wo das 
Sektorrecht mindestens dasselbe Schutzniveau erreicht. Ein paralleler, horizontaler
IT-Sicherheitsnachweis neben der Typgenehmigung ist damit gerade nicht der vorgesehene
Weg.

Zweitens der **AI Act selbst**: Er greift, wie gezeigt, nicht horizontal auf das
Fahrzeug durch, sondern ändert über Art. 102 bis 109 die sektoralen Rechtsakte. 
Die begleitenden Erwägungsgründe bestätigen die Stoßrichtung: Die technischen und
regulatorischen Sektor-Spezifika und die bestehende Konformitätsbewertung sind zu
respektieren (EG 49), eine Doppelbewertung ist zu vermeiden (EG 124), und KI-Tests
sollen in die bestehenden Verfahren integriert werden (EG 64).

Die regulatorische Philosophie ist damit eindeutig: Das Fahrzeug ist kein generisches
IT-Produkt, sondern ein sicherheitskritisches System; seine AI-Security wird _innerhalb_
der Typgenehmigung verwaltet, nicht daneben. Ein eigenständiger „IT-Zulassungsstrang”
neben der Homologation ist nicht bloß unpraktisch; er ist rechtlich versperrt. So
weit die beruhigende Hälfte des Befunds. Die andere Hälfte betrifft den Inhalt.

## Die Lücke: was UN R155 und ISO/SAE 21434 nicht erfassen

KI-Systeme werden über eine eigene Klasse von Angriffen verwundbar, die nicht an
Code-Fehlern oder Netzwerk-Fehlkonfigurationen hängen, sondern an der statistischen,
datengetriebenen Natur des Modells. Die einschlägige Taxonomie (NIST AI 100-2; ENISA„
Securing Machine Learning Algorithms”) benennt im Kern drei Familien:

 * **Täuschende Eingaben (adversarial examples / model evasion):** minimal, oft 
   unmerklich gestörte Eingaben, etwa ein präparierter Aufkleber auf einem Stoppschild,
   die die Entscheidungsgrenze des Modells verschieben. Netz und Code bleiben dabei
   unversehrt.
 * **Verfälschung (data poisoning / model poisoning, Backdoors):** Manipulation 
   der Trainingsdaten oder vortrainierter Komponenten, lange vor Kompilierung oder
   OTA-Update.
 * **Vertraulichkeitsangriffe (model extraction, membership inference):** das statistische„
   Stehlen” eines trainierten Modells oder das Rückschließen auf Trainingsdaten 
   über bloßen Abfragezugriff.

Das Bedrohungsmodell der UN R155 adressiert davon nichts explizit. R155 definiert
Cybersecurity als Schutz der „elektrischen oder elektronischen Komponenten”; seine
Bedrohungsliste (Anhang 5) ist auf E/E-Architektur, Kommunikationswege und Software
ausgerichtet. Wo R155 verwandte Begriffe führt, meint es Klassisches:

| R155-Konzept (Anhang 5) | Was R155 darunter versteht | KI-Bedrohung, die _nicht_ erfasst ist | 
| „Manipulation von Sensorinformation” | Magnet am Hall-Sensor (physische E/E-Manipulation) | adversariale Störung des optischen Sensorbilds | 
| „Extraktion von Fahrzeugdaten/-code” | Softwarepiraterie, Auslesen kryptografischer Schlüssel | Modell-Extraktion, Membership Inference | 
| „Kompromittierter Update-Prozess / Malware” | manipuliertes Software-Update, eingeschleuste Malware | Vergiftung der Trainingsdaten (Datenkette, nicht Codekette) |

Auch die Engineering-Systematik der ISO/SAE 21434 (samt der ihr eigenen TARA) setzt
methodisch an der E/E-Architektur über den Lebenszyklus an, nicht am trainierten
Modell, seiner Datenversorgung oder seiner statistischen Robustheit. Die Trennlinie
verläuft damit präzise zwischen der Infrastruktur um das Modell und der statistischen
Integrität des Modells selbst. Das Cybersecurity-Management-System sichert die erste;
die zweite adressiert es nicht.

Ein naheliegender Einwand lautet, die Kombination aus ISO 26262 (funktionale Sicherheit)
und ISO 21448 (SOTIF) decke das KI-Verhalten doch bereits ab. Er trägt nicht, und
die Stelle, an der er bricht, ist aufschlussreich. SOTIF adressiert primär _nicht-
böswillige_ Funktions- und Leistungsgrenzen: das verblasste Schild, die Blendung,
den Regen, also die Umwelt-Verwundbarkeit des Sensors. Den _adversarialen_ Aufkleber,
die mathematisch konstruierte Täuschung, deckt es nicht ab; sie fällt in die Security-
Domäne. Die Lücke sitzt damit exakt zwischen der „natürlichen Grenze” einer Funktion(
SOTIF) und der „böswilligen Ausnutzung genau dieser Grenze” (bislang ungedeckt).

## Was Art. 15 verlangt: die Lücke ist die Anforderung

Diese Lücke ist nicht hypothetisch, sie ist bereits kodifiziert. [Art. 15 AI Act](https://artificialintelligenceact.eu/de/article/15/)
verlangt für Hochrisiko-Systeme ein angemessenes Maß an Genauigkeit, Robustheit 
und Cybersicherheit. Art. 15 Abs. 5 wird konkret und übernimmt die Adversarial-ML-
Taxonomie nahezu wörtlich ins Recht: Die technischen Lösungen müssen, „where appropriate”,
gegen die Manipulation der Trainingsdaten (data poisoning), die Manipulation vortrainierter
Komponenten (model poisoning), täuschende Eingaben (adversarial examples / model
evasion), Vertraulichkeitsangriffe und Modellfehler wirken.

Damit schließt sich der Kreis: Was Art. 15 Abs. 5 verlangt, ist genau das, was der
heutige ACS-Bestand nicht abdeckt. Sobald die Cybersecurity-Dimension des Art. 15
über die sektorale Novellierung in das Typgenehmigungsrecht einfließt (über den 
eingangs beschriebenen Mechanismus: Art. 107 → Art. 5 VO 2018/858; Art. 109 → Art.
11 VO 2019/2144), entsteht ein inhaltlicher Anforderungsüberhang, den R155-CSMS 
und ISO/SAE 21434 in ihrer heutigen Form nicht bedienen. Der naheliegende Schluss,
der vorhandene Nachweisapparat trage die Art.-15-Anforderungen „in weiten Teilen”
bereits mit, ist deshalb zu optimistisch. Der Evidenz-Crosswalk zwischen CSMS-/21434-
Artefakten und den Art.-15-Dimensionen ist kein Umetikettieren vorhandener Nachweise,
sondern eine Gap-Analyse, die diese Deckungslücke offenlegt.

## Zwei Denkmodelle, beide allein untauglich

Aus der Spannung zwischen institutioneller Zuständigkeit und substanzieller Lücke
ergeben sich zwei naheliegende, aber je für sich unzureichende Denkmodelle.

**Modell A: das ACS-Regime erweitern**, also die AI-Security in CSMS und TARA integrieren.
Dafür spricht der Gesetzgeberwille: sektorales Routing, CRA-Ausschluss, eine Governance-
Klammer, eine Konformitätsbewertung, die etablierte Lebenszyklus-, Audit- und Feld-
Monitoring-Mechanik, keine Doppeldokumentation. Dagegen spricht, dass die TARA-Methodik(
ausgelegt auf logische Fehler, offene Ports, Netzangriffe) die KI-Schutzziele technisch
nicht von selbst trägt: Klassische E/E-Cybersecurity-Kompetenz reicht für adversariales
Training, Privacy-Auditing oder die Attestierung der Daten-Lieferkette nicht aus.
Die Gefahr besteht darin, die Lücke unter dem vertrauten Label „CSMS” zu _übersehen_.

**Modell B: eine separate IT-/AI-Security-Betrachtung** als eigenständiger Strang.
Dafür spricht, dass es die fehlende fachliche Tiefe (Adversarial Robustness, Dataset-
Integrität, MLSecOps) sauber einbringt und die KI-Spezifika sichtbar macht. Dagegen
spricht alles, was die institutionelle Ebene bereits geklärt hat: Als _paralleler
Nachweisstrang_ ist es rechtlich versperrt (CRA-Ausschluss, EG 124) und zerreißt
die einheitliche sicherheitskritische Betrachtung des Fahrzeugs.

Die tragfähige Antwort liegt nicht zwischen den Modellen, sondern setzt sie übereinander:
das sektorale Regime als Container, eine eigenständige AI-Security-Disziplin als
Inhalt. Die Governance-Klammer bleibt sektoral: CSMS, TARA und ISO 21434 als integrierende
Prozess- und Nachweisstruktur, der vom Gesetzgeber gewollte und einzig zulässige
Weg in die Typgenehmigung. In diese Klammer wird die AI-Security-Substanz _hineingezogen_,
nicht danebengestellt: Der TARA-Scope wird um KI-Assets und einen KI-Bedrohungskatalog
erweitert, und die fehlenden Arbeitsstränge kommen hinzu: Daten-Governance und Dataset-
Integrität, Robustheits- und Adversarial-Testing, das Prüfen der KI-Lieferkette 
einschließlich vortrainierter Komponenten, modellbezogenes Red-Teaming sowie ein
Feld-Monitoring, das auch das Verhalten des Modells und Out-of-Distribution-Fälle
erfasst.

Entscheidend ist dabei, dass die Lücke nicht primär eine Dokumentations-, sondern
eine Fähigkeitslücke ist. Ein klassischer E/E-Penetrationstester deckt adversariale
und Vertraulichkeitsangriffe nicht ab. Ohne spezialisierte AI-Security-Kompetenz(
aufgebaut oder eingekauft) bleibt die KI-Komponente trotz formal grünem CSMS exponiert.

## Das fehlende PuzzleStück wird bereits normiert

Diese Disziplin muss nicht erst erfunden werden; sie entsteht bereits _innerhalb_
des Automotive-Ökosystems, wie sich an der Normung ablesen lässt. Deren Richtung
bestätigt den Befund: keine Ablösung der etablierten Systematik, sondern ihre Erweiterung.

Tragend ist hier zweierlei. ISO/PAS 8800 (2024) zur Sicherheit künstlicher Intelligenz
in Straßenfahrzeugen adressiert KI-basierte Fahrfunktionen als dedizierter Automotive-
Standard und erweitert die etablierten ISO 26262 und ISO 21448 (SOTIF); ihre Kerninnovation
ist, die Trainingsdaten als primäres, eigenständig zu verifizierendes Engineering-
Artefakt zu behandeln (ein „Dataset V-Model”). Die KI-spezifische Bedrohungsseite(
Datenvergiftung, adversariale Eingaben, Modell-Extraktion) adressiert der in Entstehung
befindliche ISO/IEC 27090. Beide docken an die vorhandene Systematik an, statt sie
zu ersetzen.

Über diese beiden hinaus zeichnet sich ein breiterer Andockrahmen ab, der hier als
Beobachtungslinie und nicht als gesicherter Befund genannt sei: horizontale ISO/
IEC-AI-Normen, die über den Automotive-Stack gelegt werden (ISO/IEC 42001 für KI-
Management und ISO/IEC 23894 für KI-Risiko), sowie für autonome Produkte der strukturierte
Sicherheitsnachweis nach UL 4600. Ob und wie genau diese Normen im Typgenehmigungskontext
verbindlich werden, ist offen und am jeweiligen Originaltext zu prüfen; festhalten
lässt sich nur die Stoßrichtung.

Diese Entwicklung verschiebt den Vorbereitungshebel von einem Sollen zu einem Ist:
Die AI-Security-Disziplin _entsteht bereits_ sektorintern. Der falsche Weg wäre 
die Doppeldokumentation in einem zweiten, getrennten Nachweisstrang; der ebenso 
falsche die Annahme, das bestehende CSMS leiste das Geforderte schon. Tragfähig 
ist allein die frühe Adoption dieser entstehenden Systematik samt des dafür nötigen
Kompetenzaufbaus, statt auf die delegierten Rechtsakte zu warten.

## Fazit

Der AI Act trifft das Fahrzeug nicht mit dem horizontalen Stichtag, der vielerorts
in regulatorischen Umsetzungs-Roadmaps steht. Seine materiellen Hochrisiko-Anforderungen
erreichen die Typgenehmigung über einen Umweg, den Art. 2 Abs. 2 und die Anhang 
I, Abschnitt B-Verortung skizzieren und den die Art. 107 und 109 in das Sektorrecht
einbringen. Das beantwortet das _Wann und Wie_.

Offen bleibt das _Womit_. Die institutionelle Zuständigkeit liegt zweifelsfrei beim
Typgenehmigungsregime, doch dessen Inhalt deckt die KI-spezifischen Schutzziele 
des Art. 15 heute noch nicht ab: Das CSMS sichert die Infrastruktur um das KI-Modell,
nicht dessen statistische Integrität. Wer beide Hälften in der Planung abbildet,
vermeidet drei Fehler zugleich: die Fehlinvestition gegen eine Phantom-Deadline,
das Versäumnis, die kommende Novellierung des Typgenehmigungsrechts rechtzeitig 
zu verfolgen, und die trügerische Beruhigung, ein grünes CSMS belege bereits die
AI-Security. Das richtige Modell ist der sektorale Container mit einer eigenständigen
AI-Security-Disziplin als Inhalt; sie beginnt, sich in ISO/PAS 8800 und ISO/IEC 
27090 zu materialisieren. Damit verbindet sich eine letzte Beobachtung, die über
den AI Act hinausweist: Dieselbe Hochrisiko-KI im selben Fahrzeug wird je nach Rechtsraum
unterschiedlich erfasst. Die globale Fragmentierung der Fahrzeug-Cybersecurity-Regulierung
soll jedoch nicht Gegenstand dieses Beitrags werden.

## Das Cybersecurity-Ablaufdatum

- Link: https://smartnuts.com/2026/04/27/das-cybersecurity-ablaufdatum/
- Veröffentlicht: 2026-04-27T22:12:58+02:00
- Autor: Michael Bunzel

… oder wie der ZDK aus einem VDA-Positionspapier einen digitalen Aftermarket-Horrorfilm
macht.

Der Zentralverband Deutsches Kraftfahrzeuggewerbe hat eine [Pressemitteilung](https://www.kfzgewerbe.de/branchenbuendnis-warnt-vor-ende-des-cyberschutzes-bei-kraftfahrzeugen-nach-zehn-jahren)
[ veröffentlicht](https://www.kfzgewerbe.de/branchenbuendnis-warnt-vor-ende-des-cyberschutzes-bei-kraftfahrzeugen-nach-zehn-jahren),
die ungefähr so klingt, als würden deutsche Hersteller planen, nach zehn Jahren 
kollektiv den Stecker aus Millionen Fahrzeugen zu ziehen, während freie Werkstätten
machtlos danebenstehen und der Gebrauchtwagenmarkt in Flammen aufgeht. Der Titel:
Ein Branchenbündnis warnt vor dem „Ende des Cyberschutzes bei Kraftfahrzeugen nach
zehn Jahren“. Der Anlass: die [VDA-Position zum „End of ](https://www.vda.de/de/aktuelles/publikationen/publication/ein-smarter-weg-zur-cybersecurity-im-fahrzeug)
[Cybersecurity](https://www.vda.de/de/aktuelles/publikationen/publication/ein-smarter-weg-zur-cybersecurity-im-fahrzeug)
[-Support“](https://www.vda.de/de/aktuelles/publikationen/publication/ein-smarter-weg-zur-cybersecurity-im-fahrzeug),
kurz EoCSS. Der Effekt: maximale Alarmwirkung bei sehr begrenzter begrifflicher 
Präzision.

Das zentrale Problem beginnt schon bei der Zuspitzung. Die ZDK-Mitteilung behauptet,
deutsche Hersteller planten, „nach zehn Jahren keine Updates mehr bereitzustellen“.
Das klingt knackig, ist aber im beigefügten VDA-Papier so nicht sauber herzuleiten.
Der VDA fordert gerade keinen pauschalen Zehn-Jahres-Schalter, sondern eine regulatorische
Anerkennung eines EoCSS, der für Fahrzeugtypen und sogar für einzelne Elemente der
E/E-Architektur differenziert festgelegt werden können soll. Das Papier spricht 
ausdrücklich von Kategorien, risikobasierter Behandlung und unterschiedlichen Zeiträumen
für aktive und reaktive Maßnahmen. Die berühmte eine Zahl, aus der die Pressemitteilung
ihren kleinen Weltuntergang baut, ist im VDA-Dokument jedenfalls nicht der tragende
normative Mechanismus.

Noch kurioser wird es beim Begriff „Cyberschutz“. Der ZDK behandelt ihn rhetorisch
wie eine Art digitale Airbag-Funktion: entweder vorhanden oder weg. Aber das ist
technisch Unsinn. Cybersecurity-Support ist kein einzelner Knopf mit der Beschriftung„
sicher“. Der VDA unterscheidet zwischen aktivem Support, reaktivem Support und passiver
Produktbeobachtung. Aktiver Support kann Threat Intelligence, Vulnerability Monitoring,
Analyse und Risikobewertung umfassen; reaktiver Support kann Einzelfallmeldungen,
Händler- und Importeurmeldungen, Kundenbeanstandungen und Behördenbeanstandungen
umfassen. Nach EoCSS soll nicht „gar nichts“ passieren, sondern eine passive Produktbeobachtung
im Rahmen der allgemeinen Produktbeobachtungspflicht verbleiben. Das kann man kritisieren.
Man sollte es aber nicht so darstellen, als würde der Hersteller am elften Geburtstag
des Fahrzeugs die Cybersecurity beerdigen und dem Halter eine Kondolenzkarte schicken.

Der eigentliche Konflikt ist real, aber deutlich komplizierter. UN R155 verlangt,
dass das CSMS auch die Post-Production-Phase abdeckt. Diese Phase endet nach der
Definition erst, wenn keine Fahrzeuge des betreffenden Fahrzeugtyps mehr betrieben
werden. Der VDA leitet daraus zu Recht ein Problem ab: Wenn man das streng liest,
entsteht eine faktisch unbestimmte Supportpflicht bis zum letzten operierenden Fahrzeug.
Das kann Jahrzehnte dauern. Die technische Lieferkette, Standardsoftware, Open Source,
Toolchains, Kryptographie, Backend-Infrastrukturen und Fachkräfteverfügbarkeit interessieren
sich aber nicht dafür, dass irgendwo in 27 Jahren noch ein einzelnes Fahrzeug im
Alltagsbetrieb läuft. Der VDA sagt im Kern: Eine unbegrenzte aktive Cybersecurity-
Pflicht ist industriell, technisch und organisatorisch nicht realistisch. Diese 
These ist nicht absurd. Sie ist sogar der Teil der Debatte, den man ernst nehmen
sollte.

Der ZDK macht daraus allerdings einen Verbraucherschutzkrimi: Fahrzeuge könnten 
trotz technischer Fahrtauglichkeit ihre Betriebserlaubnis verlieren oder nur noch
eingeschränkt nutzbar sein. Das ist eine starke Behauptung. In der Pressemitteilung
wird sie aber nicht sauber hergeleitet. Weder folgt aus einem definierten EoCSS 
automatisch der Verlust der Betriebserlaubnis, noch verlangt das VDA-Papier eine
pauschale Außerbetriebsetzung alter Fahrzeuge. Der VDA spricht vielmehr davon, nach
EoCSS noch passive Produktbeobachtung vorzusehen und aktive beziehungsweise reaktive
Maßnahmen vor EoCSS nach Risiko und Architekturkategorie zu differenzieren. Der 
ZDK argumentiert also mit einer möglichen regulatorischen Folge, als sei sie bereits
das erklärte Ziel der Hersteller. Das ist politisch wirkungsvoll, aber analytisch
dünn.

Auch die Formulierung, ein Ende der Updates würde „Millionen Fahrzeuge über Nacht
entwerten“, ist eine schöne kleine Feuerwerksrakete aus der Lobbykommunikation. 
Sie leuchtet hell, macht Lärm und verschwindet bei näherem Hinsehen schnell im Rauch.
Ein EoCSS wäre gerade kein überraschender nächtlicher Zauberakt, sondern ein definierter
Support-Zeitraum. Man kann darüber streiten, wie lang dieser Zeitraum sein muss,
wie transparent er kommuniziert wird, welche Mindestpflichten bleiben und ob sicherheitsrelevante
Funktionen anders behandelt werden müssen als Komfortdienste. Aber „über Nacht entwertet“
ist eine Überzeichnung. Besonders ironisch: Gerade die Forderung nach unbegrenztem
Support kann Fahrzeuge verteuern, weil Hersteller mehr Hardware-Reserve, längere
Lieferkettenverpflichtungen, langfristige Toolchain-Konservierung und Supportkapazitäten
einpreisen müssten. Der ZDK warnt also vor Kosten für Verbraucher, ohne sauber zu
adressieren, dass seine eigene Maximalforderung ebenfalls Kosten produziert.

Der interessanteste Punkt ist aber die eigene Interessenlage des ZDK. Der Verband
vertritt das Kraftfahrzeuggewerbe, also unter anderem Werkstätten und Betriebe, 
die im Aftermarket Leistungen erbringen. Die Pressemitteilung selbst beschreibt 
das Bündnis als Allianz entlang des Aftermarkets: ZDK, ADAC, Reifenhandel, Kautschukindustrie,
Autoglaser und Teilehandel. Außerdem verknüpft sie Cybersecurity ausdrücklich mit
diskriminierungsfreiem Zugang zu Fahrzeugdaten, Reparierbarkeit, Teileversorgung,
Werkstattpraxis und bezahlbarer Mobilität. Das ist legitim. Aber es ist nicht nur
altruistischer Verbraucherschutz in weißem Kittel. Es ist auch knallharte Marktpositionierung.
Wer im Aftermarket Geld verdient, hat ein offensichtliches Interesse daran, dass
Fahrzeuge möglichst lange reparierbar, nutzbar und wirtschaftlich betreibbar bleiben—
und dass Hersteller nicht über Cybersecurity-Architekturen, Softwarezugänge und 
Supportmodelle die Kontrolle über den Servicekanal verdichten.

Genau deshalb wirkt die Pressemitteilung an einigen Stellen wie ein rhetorischer
Doppeldecker. Oben sitzt der Verbraucherschutz: Sicherheit, bezahlbare Mobilität,
Gebrauchtwagenmarkt, soziale Teilhabe. Unten läuft der eigentliche Antrieb: Zugang
zu Fahrzeugdaten, freie Werkstätten, Teilehandel, Reparaturgeschäft, Wettbewerbsposition
im Aftermarket. Das ist nicht verwerflich. Verbände vertreten Interessen. Überraschung:
Wasser ist nass, Lobbyisten lobbyieren. Problematisch wird es erst, wenn die eigene
ökonomische Interessenlage als reine Sorge um die Verkehrssicherheit verkleidet 
wird.

Der VDA ist natürlich ebenfalls kein neutraler philosophischer Zirkel. Auch dort
geht es um Herstellerinteressen: Begrenzung unbegrenzter Pflichten, planbare Supportkosten,
Haftungsbegrenzung, Lieferkettenrealismus, Innovationsfähigkeit. Aber das VDA-Papier
ist zumindest in der Struktur näher an der eigentlichen technischen und regulatorischen
Frage: Wie lässt sich Cybersecurity über lange Lebenszyklen risikobasiert organisieren,
wenn Hardware, Software, Kryptographie, Lieferanten und Angriffslage sich schneller
verändern als ein Fahrzeugbestand altert? Die ZDK-Mitteilung hingegen übersetzt 
diese Frage in: „Die Hersteller wollen nach zehn Jahren keine Sicherheit mehr.“ 
Das ist kommunikativ effizient, aber fachlich grob.

Die bessere Position wäre: Ja, unbegrenzter aktiver Cybersecurity-Support bis zum
letzten Fahrzeug ist technisch und wirtschaftlich kaum haltbar. Nein, daraus darf
kein Freibrief entstehen, sicherheitsrelevante Fahrzeugfunktionen nach beliebiger
Herstellerlogik aus dem aktiven Support zu entlassen. Ein vernünftiges Modell müsste
Mindestlaufzeiten, risikobasierte Verlängerungspflichten, transparente EoCSS-Angaben
beim Kauf, Pflichten für kritische Schwachstellen, Datenzugang für unabhängige Reparaturakteure
und klare Regeln für das Abschalten nicht notwendiger Onlinefunktionen kombinieren.
Das wäre weniger dramatisch als „Sicherheit darf kein Verfallsdatum haben“, aber
deutlich brauchbarer.

Am Ende ist die ZDK-Pressemitteilung ein gutes Beispiel für politisches Framing:
Man nehme ein echtes regulatorisches Problem, reduziere es auf einen Empörungssatz,
stelle den Verbraucher nach vorn, den Aftermarket knapp dahinter und den Hersteller
als kalten Support-Abschalter auf die Bühne. Das funktioniert. Es ist nur nicht 
besonders sauber. Der VDA will nicht den Cyberschutz abschaffen. Er will eine Grenze
für aktive Cybersecurity-Pflichten definieren. Der ZDK will nicht nur Verbraucher
schützen. Er will auch sicherstellen, dass seine Mitglieder im digitalisierten Fahrzeugmarkt
nicht aus der Wertschöpfung gedrängt werden. Beides ist legitim. Aber wer über Cybersecurity
im Fahrzeuglebenszyklus spricht, sollte weniger Theaternebel einsetzen und mehr 
Architektur, Risiko und Rechtsfolgen sauber auseinanderhalten.

## The Commission’s Latest Regulatory Land Grab: Why CSA 2 Should Stay Out of Automotive

- Link: https://smartnuts.com/2026/03/20/the-commissions-latest-regulatory-land-grab-why-csa-2-should-stay-out-of-automotive/
- Veröffentlicht: 2026-03-20T22:25:56+01:00
- Autor: Michael Bunzel

In its regulatory frenzy, the European Commission has once again found itself a 
new patch of turf to conquer: connected and automated vehicles. Because apparently
a sector already covered by type-approval law, dedicated cyber rules, software update
rules, data protection law, artificial intelligence law and assorted compliance 
machinery was still looking a bit too relaxed. So now the idea is to pull automotive
into the orbit of a [future Cybersecurity](https://digital-strategy.ec.europa.eu/en/library/proposal-regulation-eu-cybersecurity-act)
[ ](https://digital-strategy.ec.europa.eu/en/library/proposal-regulation-eu-cybersecurity-act)
[Act 2](https://digital-strategy.ec.europa.eu/en/library/proposal-regulation-eu-cybersecurity-act)
and its supply-chain toolbox, allegedly to deal with “non-technical” risks that 
existing vehicle regulation supposedly does not capture well enough. That is the
theory, anyway. In practice, the argument is a lot less clean than Brussels would
like it to sound.

Let us start with the part that is actually true. The EU’s coordinated [risk ](https://www.ccam.eu/t/?e=bianca@eucoms.eu&m=17185&tr=trackMail&r=https%3A%2F%2Fwww.ccam.eu%2Ft/?e=bianca@eucoms.eu&m=17185&tr=trackMail&r=https%3A%2F%2Fwww.ccam.eu%2Fwp-content%2Fuploads%2F2026%2F03%2FNIS-Cooperation-Group-Risk-assessment-on-Connected-and-Automated-Vehicles.pdf)
[assessment](https://www.ccam.eu/t/?e=bianca@eucoms.eu&m=17185&tr=trackMail&r=https%3A%2F%2Fwww.ccam.eu%2Ft/?e=bianca@eucoms.eu&m=17185&tr=trackMail&r=https%3A%2F%2Fwww.ccam.eu%2Fwp-content%2Fuploads%2F2026%2F03%2FNIS-Cooperation-Group-Risk-assessment-on-Connected-and-Automated-Vehicles.pdf)
[ on connected and automated vehicles ](https://www.ccam.eu/t/?e=bianca@eucoms.eu&m=17185&tr=trackMail&r=https%3A%2F%2Fwww.ccam.eu%2Ft/?e=bianca@eucoms.eu&m=17185&tr=trackMail&r=https%3A%2F%2Fwww.ccam.eu%2Fwp-content%2Fuploads%2F2026%2F03%2FNIS-Cooperation-Group-Risk-assessment-on-Connected-and-Automated-Vehicles.pdf)
does not pretend the risk landscape is fictional. It identifies 107 risks, with 
14 top risks, and it says plainly that connected vehicles can be hacked through 
multiple pathways, with consequences ranging from data leakage to full remote takeover.
It also flags two issues that the Commission is especially keen on: weak charging
infrastructure and “high-risk suppliers” that could, in theory, be pressured by 
governments or military actors to introduce malicious hardware, software, updates
or configurations. The report also singles out vehicle control systems, processing
and decision-making systems, communication and connectivity systems, and cloud or
backend systems as especially critical assets. None of that is trivial, and pretending
otherwise would be intellectually lazy.

But here is where the Commission’s logic starts wobbling. The same risk assessment
also says, quite explicitly, that many of the top risks are already addressed by
the EU’s current type-approval rules, provided those rules are implemented properly.
That includes attacks on in-vehicle AI, vehicle control systems, connectivity pathways,
sensing systems, backdoors in open-source libraries and even manipulated over-the-
air updates. In other words, the report itself admits that a large part of the actual
technical attack surface is already inside the perimeter of the existing automotive
regime. That matters, because once you say that out loud, you are no longer arguing
about a sector with a missing framework. You are arguing about a sector that already
has one and that the Commission now wants to revisit through a second regulatory
door.

That second door is where the real problem starts. The Commission’s political line
is that CSA 2 would focus on non-technical risks in supply chains. Fine. But when
the risk assessment explains where action is supposedly needed, it does not stay
at the level of geopolitics, coercion or strategic dependency. It immediately goes
back to vehicle-related critical assets: processing and decision-making systems,
communication and connectivity systems, vehicle control systems capable of receiving
remote updates. That is not some abstract supply-chain governance exercise floating
above the product. That is product-adjacent regulation in everything but name. Call
it “non-technical” if that helps with the press line, but once your intervention
logic is anchored in the hardware and software architecture of the vehicle, you 
are regulating the vehicle ecosystem again.

That is exactly why the automotive industry should attack this proposal on grounds
of regulatory coherence rather than on the weaker claim that UN R155 magically covers
the entire universe. Because it does not. UN R155 is strong, but it is not a metaphysical
shield against all possible geopolitical scenarios. What it does do is require a
Cybersecurity Management System across the vehicle lifecycle, continuous risk assessment,
vulnerability monitoring, incident response and supply-chain cybersecurity management.
UN R156 adds a dedicated Software Update Management System, including disciplined
governance of update processes. That is not nothing. It is already a serious, lifecycle-
based regime aimed squarely at the real-world cyber risks of modern vehicles. So
the right industry argument is not “there is no residual issue anywhere.” The right
argument is that the Commission has not shown a credible residual gap that justifies
another horizontal layer landing on top of systems that are already regulated.

The Commission will respond, of course, that this is not about ordinary vulnerabilities.
It will say this is about high-risk suppliers under state pressure, hidden access
pathways, malicious updates and strategic dependencies. Fair enough. But that only
helps the Commission up to a point. If the concern is that a supplier may be coerced
by a third country, then the problem is not simply that a component is insecure.
The problem is economic security, foreign influence and dependency risk. That is
a different category of problem, and it should be treated honestly as such. Once
you admit that, the obvious follow-up question is this: why exactly is the answer
a second product-proximate cyber regime for vehicles rather than an economic security
instrument, investment screening, trade controls, procurement restrictions or targeted
foreign policy tools? There is no convincing answer to that, except perhaps the 
old Brussels classic: if in doubt, add another layer.

Charging infrastructure is another good example of the Commission’s overreach problem.
The risk assessment points to weak cybersecurity in charging infrastructure and 
treats that as part of the broader concern. But it also states that charging infrastructure
in the EU falls under NIS 2, with charging point operators treated as critical entities
in the energy sector. So even the report itself shows that this is already an infrastructure
governance issue with its own regulatory home. It is therefore a very odd basis 
for arguing that OEM supply chains now need to be swept into CSA 2 as well. If the
charger is the problem, regulate the charger properly. Dragging vehicle manufacturers
into another horizontal framework because somebody found a soft spot outside the
vehicle is not smart regulation. It is just scope expansion with better stationery.

There is also a more awkward institutional point the Commission would rather not
dwell on too much. The same risk assessment notes that connected and automated vehicles
that fall under Regulation (EU) 2019/2144 are excluded from the scope of the Cyber
Resilience Act because they are already covered by UN R155. That was the Union’s
own legislative logic: automotive is already sectorally regulated, so the horizontal
product regime steps back. Sensible enough. But if CSA 2 now comes in through the
side entrance and starts imposing supply-chain measures tied to the same vehicle-
related systems and assets, then the neat boundary the EU itself drew begins to 
look rather decorative. It is difficult to argue with a straight face that vehicles
should stay out of one horizontal cyber regime because sector-specific regulation
exists, while also trying to pull them into another horizontal regime built around
the same technical reality.

And then there is the certification angle, which deserves more attention than it
usually gets. Once the EU starts talking about trusted ICT supply chains, critical
assets and toolbox-style mitigation, industry is right to worry that certification
expectations will not be far behind. Maybe not immediately, maybe not in black and
white on day one, but the pathway is obvious enough. For automotive, that matters
because anything drifting toward Common-Criteria-style assurance logic can become
deeply awkward once it hits modern vehicle development: software-heavy architectures,
frequent updates, reuse across platforms, tight SOP timing, variant complexity and
the constant need to balance cybersecurity, safety and time-to-market. For a sector
built around iterative engineering and controlled updates, dragging slow, heavy 
certification culture into component sourcing is a good way to reduce agility while
claiming to improve resilience. A very Brussels outcome, in other words. The paperwork
would be magnificent.

The strongest case against applying CSA 2 to automotive is therefore not ideological
and not anti-security. It is structural. Automotive is already a regulated cyber
sector. The existing framework may need better enforcement, clearer guidance and
more consistent interpretation across approval authorities, but that is not the 
same as saying a new horizontal layer is needed. Where the remaining concern is 
genuinely technical or organisational, UN R155 and UN R156 already provide the right
regulatory home. Where the concern is genuinely geopolitical, then the right tools
are economic security tools, not disguised product regulation. What makes the Commission’s
current approach weak is that it tries to have both arguments at once. It says the
issue is non-technical, then defines the solution through critical vehicle assets.
It says the problem lies beyond the existing framework, then relies on scenarios
that already sit very close to what the existing framework regulates. That is not
precision. That is policy sprawl.

So the industry should not waste time claiming that nothing is left to discuss. 
That would be sloppy, and the Commission would rightly attack it. The smarter line
is sharper and more credible: yes, there are risks; yes, some of them involve awkward
geopolitical dependency questions; no, that does not justify re-regulating vehicle
systems through CSA 2. The EU should either strengthen the implementation of the
existing automotive cyber regime or use economic security instruments for genuinely
geopolitical problems. What it should not do is pretend that a new horizontal toolbox
somehow remains “non-technical” while quietly taking aim at the same software, connectivity
and control systems already sitting inside the type-approval framework.

Because once that game starts, this is no longer about closing a gap. It is just
Brussels doing what Brussels does best: finding a sector that is already regulated,
declaring it newly strategic, and then regulating it again from a slightly different
angle.

## TPMS Security – again

- Link: https://smartnuts.com/2026/02/27/tpms-security-again/
- Veröffentlicht: 2026-02-27T15:07:17+01:00
- Autor: Michael Bunzel

The [IMDEA Networks](https://networks.imdea.org/) research group, together with 
academic and government partners, has [published a new paper](https://dspace.networks.imdea.org/handle/20.500.12761/2011)
on a long-standing problem (e.g. [1](https://dl.acm.org/doi/pdf/10.1145/2517968.2517973),
[2](https://ieeexplore.ieee.org/document/7795497), [3](https://cwssp.uccs.edu/sites/g/files/kjihxj2466/files/2021-09/4_Securing%20Tire%20Pressure%20Monitoring%20System%20for%20Vehicular%20Privacy.pdf),
and [4](https://www.scitepress.org/Papers/2019/81654/81654.pdf)) in vehicle security
and privacy: TPMS wheel sensors still tend to broadcast tyre telemetry over the 
air in clear text and include identifiers that remain stable for long periods. The
paper’s central claim is not that this is a new weakness, but that it is operationally
exploitable at scale: with low-cost receivers deployed roadside over weeks, an attacker
can collect enough RF traffic to associate sensors to vehicles and infer movement
patterns and routines.

On the mitigation question, the uncomfortable but straightforward conclusion is 
that “securing TPMS communication at the ECU” is only meaningful for the wired hop
inside the vehicle, not for the over-the-air link that causes the privacy and spoofing
exposure in the first place. If the RF messages remain plaintext broadcasts, no 
amount of downstream ECU-side hardening will stop passive eavesdropping. A practical
security approach, therefore, has to treat the wheel sensor-to-receiver RF link 
as the primary object to protect. That is exactly where the industry pain starts:
securing TPMS is not “just add crypto”. Wheel sensors are among the most constrained
devices in the car. They are built to be cheap, sealed, and ultra-low power, expected
to survive years on a small battery with a tiny microcontroller and a strict transmit
duty cycle. Every additional byte over the air costs energy; every extra millisecond
of CPU time costs energy; every increase in code size, memory, or silicon capability
increases BOM cost across millions of units. Add to that the operational constraint
that tyres and sensors get replaced in the field. Any cryptographic scheme that 
is strong on paper but fragile in service workflows will either get bypassed by 
garages or produce customer-facing failures. The hard part is not the AES primitive;
it is key provisioning, pairing, re-pairing after service, and doing all of that
without turning TPMS into a support nightmare or burning down sensor battery life.

Now to the question the paper implicitly dares the reader to ask: how exploitable
is this data in a way that causes real damage to a customer? The answer is “it depends”,
and the dependency is not a footnote; it is the whole story. Raw TPMS captures are
not automatically “person tracking”. They become dangerous when an attacker can 
bind a TPMS identifier set to a specific human, and when the attacker has enough
RF coverage to observe that vehicle repeatedly across meaningful locations. The 
most plausible harms are classic privacy harms with a physical-world tail: routine
inference enabling stalking, identifying when a vehicle leaves or returns, or correlating
visits to sensitive locations. A more opportunistic crime angle is also possible:
if a criminal can observe that a specific vehicle is away from a home area, that
information can support targeted burglary or theft. But those scenarios require 
intent, persistence, and a capability to position receivers at the right places.
For random criminals, there are often cheaper and simpler signals than TPMS, such
as social media oversharing, visible number plates combined with camera infrastructure,
or direct observation.

This is where a critical reading of the “mass-scale tracking” headline is warranted.
Yes, the paper shows that building a passive collection pipeline is technically 
feasible and relatively inexpensive per receiver. That does not automatically mean
it will become a widespread real-world threat actor technique. Large-scale tracking
already exists through channels that are more reliable, more geographically complete,
and easier to operationalise than opportunistic RF collection. For many adversaries,
TPMS is an awkward telemetry source: range-limited, dependent on vehicle proximity,
and non-trivial to turn into identity-linked intelligence without additional collection
steps. The uncomfortable conclusion is therefore double-edged. On the one hand, 
TPMS remains a needless privacy beacon and there is no good engineering justification
for continuing to broadcast stable identifiers in plaintext. On the other hand, 
the incremental real-life impact of “mass-scale TPMS tracking” may be narrower than
the paper’s framing suggests, because the attackers who can truly do mass-scale 
surveillance already have better tools, and the attackers who want quick wins often
have easier targets. The result is still valuable, but mainly as a warning sign 
about avoidable leakage and poor protocol hygiene—not necessarily as proof of an
imminent new epidemic of TPMS-based tracking.

## Global CSMS Certifications — The After-Effects of Korea

- Link: https://smartnuts.com/2026/02/01/global-csms-certifications-the-after-effects-of-korea/
- Veröffentlicht: 2026-02-01T14:32:52+01:00
- Autor: Michael Bunzel

**English version:**

The after-effects of the CSMS certification required for market access in Korea,
based on UN R155, are multifaceted. They do not play out in isolation within individual
OEMs; they have also become a topic in the discussions around amending a free trade
agreement (FTA) between the European Union and Korea.

How are the two connected?

From the perspective of the OEMs that, over recent months, have had to address KATRI’s
questions on how [UN R155 requirements](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)
are implemented in Korea – questions that had to be answered in order to obtain 
the CSMS certification required as the basis for continued market access – this 
was anything but a “compliance exercise”, or, as others might put it, “a walk in
the park”.

Starting with the specific CSMS requirements, which – as tertiary law – had not 
yet completed the formal legislative process and therefore remained a moving target,
to the rather peculiar incorporation of a technical standard as the backbone of 
a binding governmental audit catalogue-compliance with which the authority treated
as a prerequisite for passing the audit- through to an assessment approach that 
often appeared detached from practical realities: in places, it gave the impression
that the broader end-to-end vehicle development context was being lost, and that
theoretical siloed knowledge was instead shaping the agenda of audit questions. 
Taken together, these aspects made audit experiences with other regulators and authorities–
such as Germany’s KBA or China’s CATARC – look like comparatively predictable and
professional exchanges between actors operating on equal footing. (For a [detailed account of a CSMS audit in Korea](https://www.cyeqt.com/en/korea-vehicle-cyber-security-audit-2026-practical-guide-oems-suppliers/),
see my esteemed [colleague ](https://www.linkedin.com/in/roth-felix/?originalSubdomain=de)
[Felix](https://www.linkedin.com/in/roth-felix/?originalSubdomain=de)[Roth](https://www.linkedin.com/in/roth-felix/?originalSubdomain=de).)

KATRI has now, at MOLIT’s request, consolidated its learnings from the initial audits
of predominantly European OEMs in the Korean market and categorised its observations
by focus areas – an exercise that, when read carefully, will in places elicit an
astonished “WTF!” from the attentive reader. This is not meant as a slight against
KATRI. Of course, there are findings that stem from a (misguided) interpretation
of mandatory implementation of an automotive cybersecurity standard and the CSMS
as a process framework by the OEM, or from a normatively questionable narrowing 
of terms that inherently require interpretation and discretionary leeway. But there
are also many observations whose root causes lie in processes that some OEMs would
describe as “compliance underwear”: practices whose proper implementation should
already follow from an OEM’s own understanding of what it means to ensure the cyber-
secure operation of a vehicle, and whose evidence in prior CSMS certifications in
other markets – such as Germany or China – should be day-to-day business for automotive
cybersecurity governance. Reviewing that latter set of findings more or less validates
one’s own emphasis and prioritisation when building and operating one’s management
system.

If one places KATRI’s results list from these initial audit activities into the 
broader context of aligning regulatory market requirements for automotive cybersecurity,
the link to the FTA discussions between Korea and the European Union becomes clear–
specifically, the question of recognising CSMS certifications issued in EU Member
States on the basis of UN R155. The attentive reader will know that Korea is also
a 1958 Agreement Contracting Party, i.e., it recognises UN R155, but has reserved
the right to regulate the operational implementation of UN R155 in a country-specific
manner. This includes the specifc form of the CSMS as the management framework for
automotive cybersecurity. In that light, KATRI’s consolidated “deficiency list” 
can be seen as an illustrative expression of the market-specific character that 
Korea intends for its automotive cybersecurity regulation. If one follows this line
of reasoning, it is internally consistent for the Korean regulator to consider any
UN R155 CSMS certification conducted outside Korea as insufficient, and to insist
instead on a local CSMS certification.

For a globally operating OEM, this is, of course, an unfortunate situation. There
is a global trade arrangement that aims to establish a homogeneous, reliable, and
binding basis for cross-market recognition of vehicle-related cybersecurity activities
and certifications – yet the operationalisation of that arrangement results in regulatory
fragmentation that can ultimately only be contained through market-specific activities.
The consequence is compliance cost that does not necessarily increase the product’s
cybersecurity. Rather, it primarily serves to nourish the supervisory authority’s
comfort in the respective market: if a cybersecurity-relevant incident occurs, it
can “wash its hands clean” when asked what it did to fulfil its oversight duty –
i.e., compliance for the filing cabinet, or, put bluntly, “cover my ass”.

However, it would be too simplistic to point a finger at Korea and solemnly invoke
the spirit of the WP.29 framework behind UN R155. The problem runs much deeper. 
The highly divergent outcomes of CSMS audits of European OEMs in Korea – particularly
with regard to those “underwear topics” such as methodology and practice of mandatory
risk analysis, or field and fleet monitoring including in-vehicle intrusion detection–
make it clear that auditing practice varies significantly even within Europe. It
is an open secret that in some EU Member States a CSMS certification is relatively
easy to obtain, whereas in others one faces a large number of critical questions
which, in the context of the enterprise as a whole, can push the budget required
to reach the demanded vehicle security level in a compliance-satisfactory way to
quite considerable heights. Against that backdrop, it is also understandable when,
for example, Germany’s KBA insists – when granting a type approval in Germany – 
that the CSMS required for that approval, as a normatively mandated management system,
must likewise have a local certificate.

This brings us to the bottom line of the debate: if we cannot even establish a consistent,
trust-based auditing practice for automotive cybersecurity within the European Union
on the basis of UN R155, how do we expect to speak with one voice towards trading
partners and insist on compliance with an agreement that evidently leaves so much
discretion to supervisory authorities? Perhaps the European Commission should first
take the time to resolve these operational questions in the context of the EU-wide
implementation of Regulation (EU) 2019/2144, instead of continuously opening new
regulatory construction sites that then have to be incorporated into the existing
body of EU law through ever-new harmonisation efforts – the [Cybersecurity Act](https://digital-strategy.ec.europa.eu/en/library/proposal-regulation-eu-cybersecurity-act),
[EU ](https://cadeproject.org/updates/eu-prepares-ict-supply-chain-toolbox-amid-tensions-over-chinese-vendors/)
[ICTS](https://cadeproject.org/updates/eu-prepares-ict-supply-chain-toolbox-amid-tensions-over-chinese-vendors/),
[ECCF](https://digital-strategy.ec.europa.eu/en/policies/cybersecurity-certification-framework)
and the [Digital ](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-regulation-proposal)
[Omnibus](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-regulation-proposal)
send their regards.

---

**Deutsche Version:**

Die Nachwirkungen der für den Markt Korea notwendigen CSMS-Zertifizierung auf der
Grundlage der UN R155 sind vielfältig und wirken nicht nur singulär bei den einzelnen
OEMs, sondern sind auch Gegenstand von Diskussion im Rahmen der Vereinbarung eines
Handelsabkommens zwischen der Europäischen Union und Korea.

Wie hängt beides zusammen?

Aus Sicht der OEM, die sich in den letzten Monaten den Fragen der KATRI bzgl. der
Umsetzung der [UN R155-Anforderungen](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)
im Markt in Korea stellen mussten, um die erforderliche CSMS-Zertifizierung als 
Grundlage zur den weiteren Marktzugang zu erhalten, war dies wahrlich keine “Compliance-
Übung” – oder wie man anderenorts zu sagen pflegt: „a walk in the park“.

Angefangen von den spezifischen CSMS-Anforderungen, die als Teritiärrecht noch nicht
den normativen Gesetzgebungsprozess bis zum Ende durchlaufen hatten und insoweit
ein “moving target” bildeten, über die befremdlich anmutende Inkorporierung eines
technischen Standards als Gerüst eines bindenden behördlichen Prüfkatalogs, dessen
Erfüllung als Voraussetzung für das Bestehen des Audits von der Behörde angesehen
wurde bis hin zur wenig praxisbezogenen Prüfweise, die beim geneigten Betrachter
den Eindruck aufkommen ließ, dass hier und dort der generelle Blick auf das Große
und Ganze in Bezug auf den Fahrzeugentwicklungsprozess verloren ging und stattdessen
theoretisches Inselwissen die Agenda von Prüfungsfragen determinierte – all diese
Aspekte ließen Prüfungserfahrungen mit anderen Regulatoren und deren Behörden, wie
dem deutschen KBA oder der chinesischen CATARC, wie einen wohlplanbaren und professionellen
Austausch zwischen auf Augenhöhe agierenden Akteuren erscheinen. Einen [detaillierten Erfahrungsbericht zu einem CSMS-Audit in Korea](https://www.cyeqt.com/en/korea-vehicle-cyber-security-audit-2026-practical-guide-oems-suppliers/)
findet sich im Übrigen bei [meinem geschätzten Kollegen FelixRoth](https://www.linkedin.com/in/roth-felix/?originalSubdomain=de).

Nun hat die KATRI auf Veranlassung der MOLIT ihre Erfahrungen aus der initialen 
Auditierung von vorwiegend europäischen OEM im koreanischen Markt zusammengefasst
und ihre Beobachtungen nach Schwerpunkten kategorisiert, die dem geneigten Leser
beim genaueren Durchlesen an mancher Stelle ein erstauntes “WTF!” entlocken. Und
dies ist dabei nicht einmal despektierlich gegenüber der KATRI gemeint: Klar – es
gibt Punkte, die aus dem (fehlgeleiteten) Verständnis der verpflichtenden Implementierung
eines Standards zur Automotive Cybersecurity und dem CSMS als Prozess-Framework 
durch den OEM oder aber der normativ nicht nachvollziehbaren Einengung von auslegungsbedürftigen
Begrifflichkeiten oder Ermessenspielräume herrühren. Aber häufig finden sich auch
Feststellungen, deren Ursachen in Prozessen liegen, die manche OEM als “Compliance-
Unterwäsche” bezeichnen würden – d.h. deren sachgerechte Umsetzung allein schon 
aus dem Selbstverständnis des OEMs in Bezug auf die Gewährleistung eines cybersicheren
Betriebs eines Fahrzeugs folgt und deren Nachweis im Rahmen von bisherigen CSMS-
Zertifizierungen in anderen Märkte wie Deutschland oder China zum Brot-und-Butter-
Geschäft einer Automotive Cybersecurity-Governance zählen sollte. Geht man gerade
die Liste der letztgenannten Feststellungen durch, bestätigt dies mehr oder minder
die eigene Akzentuierung und Prioritätensetzung beim Aufbau und Betrieb des eigenen
Managementsystems.

Rückt man diese Ergebnisliste der KATRI aus den initial durchgeführten Prüfungshandlungen
nunmehr in den größeren Kontext der Angleichung von regulatorischen Marktanforderungen
zur Automotive Cybersecurity, so schließt sich der Kreis zu den Diskussionen im 
Rahmen der Anpassung des Handelsabkommens (FAT) zwischen Korea und der Europäischen
Union, in der es auch im die Anerkennung von CSMS-Zertifizierung aus Mitgliedsländern
der europäischen Union geht, die auf der Grundlage der UN R155 erteilt wurden. Der
geneigte Leser wird wissen, dass auch Korea ein 1958er Vertragsstaat ist, d.h. die
UN R155 anerkennt, sich jedoch vorbehalten hat, die operative Umsetzung der UN R155
landesspezifisch zu regeln, was auch die Ausprägung des CSMS als dem Management-
Framework für die Automotive Cybersecurity betrifft. Insoweit könnte man die Zusammenführung
der “Mängelliste” durch die KATRI als exemplifizierten Ausdruck der gewünschten 
Marktspezifik der Automotive Cybersecurity-Regulierung in Korea ansehen. Folgt man
dieser Argumentation, ist es aus Sicht des koreanischen Regulators auch nur konsequent,
jedwede CSMS-Zertifizierung gem. UN R1^55, die außerhalb Koreas durchgeführt wurde,
als nicht hinreichend anzuerkennen, sondern auf einer lokalen CSMS-Zertifizierung
zu bestehen.

Aus Sicht eines global agierender OEM ist dies freilich ein misslicher Zustand: 
Da existiert eine globale Handelsvereinbarung, die sich zum Ziel gesetzt hat, eine
homogene, verlässliche und bindende Grundlage für die marktübergreifende Anerkennung
von fahrzeugbezogenen Cybersecurity-Aktivitäten und Zertifizierungen zu etablieren–
und dennoch führt dann die Operationalisierung dieser Handelsvereinbarung zu einem
regulatorischen Wildwuchs, den man letztendlich nur durch marktspezifische Aktivitäten
wieder einfangen kann. In der Konsequenz werden hierdurch Compliance-Kosten generiert,
die nicht zwingend zur Erhöhung der Cybersicherheit des Produkts beitragen. Vielmehr
wird nur das wohlige Gefühl der Aufsichtsbehörde im jeweiligen Markt genährt, dass
wenn ein Cybersecurity-relevantes Ereignis eintritt, man die eigenen Hände in Unschuld
waschen kann, wenn man selbst von einer Aufsichtsbehörde gefragt wird, was man getan
hat, um seiner Aufsichtspflicht nachzukommen -mithin also Compliance für die Schublade
oder wenn man es böse ausdrücken will für “cover my ass”.

Nun wäre es allerdings zu kurz gesprungen, mit dem erhobenen Finger auf Korea zu
zeigen und mahnend den Geiste des WP.29 Abkommens zur UN R155 zu beschwören. Vielmehr
liegt das Problem viel tiefer: Die sehr unterschiedlichen Ergebnisse der CSMS-Auditierung
von europäischen OEMs in Korea gerade bezüglich der “Unterwäsche-Themen” wie Methodik
und Praxis der verpflichtenden Risikoanalyse oder Feld- und Flottenmonitoring einschließlich
Intrusion Detection im Fahrzeug etc. machen deutlich, dass die Prüfungspraxis schon
innerhalb von Europa ein sehr unterschiedliches Niveau aufweist – nicht umsonst 
gilt es als offenes Geheimnis, dass eine CSMS-Zertifizierung in bestimmten Mitgliedsländern
der Europäischen Union eher leicht zu erlangen ist, während man in anderen Ländern
sich einer Vielzahl kritischer Fragen stellen muss, die im Gesamtunternehmenskontext
das zu planende Budget für die ´Compliance-gerechte Erreichung des geforderten Sicherheitsniveaus
für das Fahrzeug in durchaus beachtliche Höhen katapultiert. Insoweit ist es dann
auch verständlich, wenn beispielsweise das deutsche KBA für eine zur erteilende 
Typgenehmigung in Deutschland darauf besteht, dass das hierfür erforderliche CSMS
als normativ gefordertes Managementsystem ebenfalls ein lokales Zertifikat aufweist.

Hiermit haben wir dann auch die “bottom line” der Diskussion erreicht: Wenn wir 
nicht einmal innerhalb der Europäischen Union eine konsistente, von Vertrauen geprägte
Prüfungspraxis zur Automotive Cybersecurity basierend auf der UN R155 etablieren
können, wie wollen wir dann als europäischer Markt gegenüber Handelspartnern weltweit
mit einer Stimme auftreten und auf die Einhaltung einer Vertragsvereinbarung dringen,
die offenkundig so viel Spielraum auf Seiten der Aufsichtsbehörden eröffnet? Vielleicht
sollte sich die EU Kommission zunächst einmal die Zeit nehmen, diese operativen 
Fragen im Kontext der europaweiten Umsetzung der [Regulation (EU) 2019/2144](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32019R2144)
zu klären, statt ständig neue regulatorische Baustellen aufzumachen, die dann wiederum
mit immer neuen Harmonisierungsbemühungen in das bestehende Gemeinschaftsrecht inkorporiert
werden müssen – [Cybersecurity Act](https://digital-strategy.ec.europa.eu/en/library/proposal-regulation-eu-cybersecurity-act),
[EU ICTS](https://cadeproject.org/updates/eu-prepares-ict-supply-chain-toolbox-amid-tensions-over-chinese-vendors/),
[ECCF](https://digital-strategy.ec.europa.eu/en/policies/cybersecurity-certification-framework)
und [Digitaler Omnibus](https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-regulation-proposal)
lassen grüßen!

## Geopolitical Risks in Automotive Security

- Link: https://smartnuts.com/2026/02/01/geopolitical-risks-in-automotive-security/
- Veröffentlicht: 2026-02-01T00:27:09+01:00
- Autor: Michael Bunzel

**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”](https://dgap.org/en/research/publications/connected-vehicle-cybersecurity-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 ](https://data.consilium.europa.eu/doc/document/ST-5611-2026-INIT/en/pdf)
[address](https://data.consilium.europa.eu/doc/document/ST-5611-2026-INIT/en/pdf)
[ “non-technical risks”](https://data.consilium.europa.eu/doc/document/ST-5611-2026-INIT/en/pdf)
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”](https://dgap.org/en/research/publications/connected-vehicle-cybersecurity-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 ](https://data.consilium.europa.eu/doc/document/ST-5611-2026-INIT/en/pdf)
[horizontale](https://data.consilium.europa.eu/doc/document/ST-5611-2026-INIT/en/pdf)
[ Logik entwickelt, um „non-technical risks“ in ICT-Lieferketten zu adressieren](https://data.consilium.europa.eu/doc/document/ST-5611-2026-INIT/en/pdf).
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.

## EU-Roadworthiness-Reform: Die politische Instrumentalisierung von PTI und RSI

- Link: https://smartnuts.com/2026/01/28/eu-roadworthiness-reform-die-politische-instrumentalisierung-von-pti-und-rsi/
- Veröffentlicht: 2026-01-28T22:18:55+01:00
- Autor: Michael Bunzel

Mit der [Reform des europäischen Roadworthiness ](https://www.europarl.europa.eu/RegData/docs_autres_institutions/commission_europeenne/com/2025/0180/COM_COM%282025%290180_EN.pdf)
[Package](https://www.europarl.europa.eu/RegData/docs_autres_institutions/commission_europeenne/com/2025/0180/COM_COM%282025%290180_EN.pdf)
wird ein altes Prüfregime i[n eine neue Welt gezwungen](https://transport.ec.europa.eu/news-events/news/updated-rules-safer-roads-less-air-pollution-and-digital-vehicle-documents-2025-04-24_en).
Periodische technische Inspektionen (PTI) und Roadside Inspections (RSI) sollen 
nicht mehr nur mechanische Zustände, sichtbare Mängel und klassische OBD-Artefakte
abklopfen, sondern zunehmend das prüfen, was moderne Fahrzeuge tatsächlich steuert:
elektronische Sicherheitssysteme. In diesem Zuge tauchen „Softwareversion“ und „
Software-Integrität“ nicht als nette Zusatzidee auf, sondern als Mangelkriterien
in einem digitalisierten Prüfkonzept. Der Effekt ist simpel und brutal: Software-
Integrität wird von einer internen Security-Kategorie zu einem öffentlich relevanten
Roadworthiness-Merkmal.

Das klingt zunächst nach gesundem Menschenverstand. Schließlich kann ein Fahrzeug
technisch „intakt“ aussehen und dennoch über manipulierte oder funktional degradierte
Software gefährlich sein. Das Problem beginnt an der Stelle, an der Politik „Integrität“
fordert, aber Technik entscheiden muss, was „Integrität“ überhaupt heißt und wie
sie beweisbar wird.

### ePTI und elektronische Schnittstelle: Das neue Prüfregime entsteht über einen digitalen Kanal

[Die EU-](https://transport.ec.europa.eu/news-events/news/updated-rules-safer-roads-less-air-pollution-and-digital-vehicle-documents-2025-04-24_en)
[Kommission](https://transport.ec.europa.eu/news-events/news/updated-rules-safer-roads-less-air-pollution-and-digital-vehicle-documents-2025-04-24_en),
[der ](https://data.consilium.europa.eu/doc/document/ST-15613-2025-INIT/en/pdf)[Rat](https://data.consilium.europa.eu/doc/document/ST-15613-2025-INIT/en/pdf)
[ ](https://data.consilium.europa.eu/doc/document/ST-15613-2025-INIT/en/pdf)sowie
[die ETSC](https://etsc.eu/wp-content/uploads/2025_ETSC-Briefing-on-Roadworthiness-Final-August.pdf)
setzen erkennbar auf ePTI, also digitalisierte Prüfprozesse, die stärker über strukturierte
Daten und standardisierte elektronische Zugänge funktionieren. Der entscheidende
operative Hebel ist die Nutzung der elektronischen Fahrzeugschnittstelle für Prüfzwecke.
Damit wird faktisch ein offizieller Kommunikationskanal etabliert, über den Prüfer
elektronische Sicherheitssysteme beurteilen sollen. Im Textkontext ist das nicht
als „Option für Enthusiasten“ gedacht, sondern als Mechanismus, um moderne Systeme
überhaupt sinnvoll bewerten zu können.

Aus Cybersecurity-Sicht ist das ein Paradigmenwechsel: Prüfungen werden nicht nur
digital, sie werden digital _interaktiv_. Ein Prüfregime, das sich früher über sichtbare
Artefakte und mechanische Logik absicherte, hängt plötzlich an einem Interface, 
das in jeder Angriffsflächenanalyse ganz oben steht.

### Die CSMS-Relevanz: PTI/RSI bringt neue Akteure und neue Angriffsflächen, ohne dass das Auto „mehr Vertrauen“ verdient hätte

Sobald Integrität über PTI/RSI geprüft wird, entsteht eine neue Klasse legitimer
Interaktoren. Es gibt dann nicht mehr nur OEM, Werkstatt und Diagnose im „Service“-
Sinne, sondern Prüforganisationen, Prüftools, Betreiberketten und eventuell nationale
Datenpfade, die im Namen der Verkehrssicherheit systematisch an Fahrzeuge herantreten.
Das ist regulatorisch gewollt, sicherheitstechnisch aber ein Geschenk an jede Person,
die gerne mit geklonten Tools, gestohlenen Zertifikaten oder manipulierten Prüfpfaden
arbeitet.

Gleichzeitig vergrößert sich der Compliance-Beweisraum. Ein CSMS muss nicht mehr
nur zeigen, dass Fahrzeuge intern gegen Angriffe robust sind, sondern dass der neue
Prüfkanal selbst missbrauchsresistent gestaltet ist und die Prüfaussagen verlässlich
sind. Damit landet ein Teil der „Roadworthiness“-Zukunft plötzlich in Threat Modeling,
Key Management, Authentisierung und Zugriffskontrolle.

### Der zentrale Denkfehler: „Integrität“ ohne Kryptographie ist ein Self-Report, und Self-Reports sind ein Witz

Die Versuchung ist groß, „Software-Integrität“ über Dinge wie Versionsnummern, Konfigurationsstände
oder irgendeinen Diagnosestatus abzubilden. Genau das ist jedoch der Punkt, an dem
das Ganze in Security-Theater kippt. Sobald ein Angreifer ECU- oder Gateway-Kontrolle
hat, lassen sich solche Signale fälschen. Das System behauptet dann seine eigene
Unschuld, während es längst kompromittiert ist.

Damit ist die harte Wahrheit ausgesprochen: Eine Integritätsprüfung, die vom potenziell
kompromittierten System selbst berichtet wird, ist kein Integritätsnachweis. Sie
ist bestenfalls ein Indikator für „ungefähr so, wie es aussieht“, und schlimmstenfalls
ein offizieller Stempel für eine sauber gefälschte Realität.

### Was stattdessen benötigt wird: Prüfen heißt attestieren, nicht plaudern

Wenn „Software integrity incorrect“ als Mangelkriterium ernst genommen werden soll,
braucht es eine Aussage, die nicht auf Vertrauen basiert, sondern auf Verifikation.
Das führt direkt zu kryptographischer Attestation. In einem robusten Modell sendet
das Prüfgerät eine frische Challenge, typischerweise in Form einer Nonce (einmaliger
Zufalls-Token), und das Fahrzeug antwortet mit einem signierten Token, der die Integrität
prüfrelevanter Domänen in minimaler Form belegt. Dieser Token muss so aufgebaut 
sein, dass eine Prüfstelle die Signatur mit einer Trust Chain verifizieren kann,
idealerweise auch offline. Der Token muss außerdem sparsam sein, damit keine unnötigen
Datenflüsse entstehen, die später als „praktisch“ missbraucht werden.

Die Semantik ist dabei wichtiger als das Buzzword. Es reicht nicht, „irgendetwas“
zu signieren. Relevant ist, dass ein messbarer, manipulationsresistenter Bezug zu
sicherheitsrelevanten Softwarezuständen besteht, und dass Replay oder einfache Nachahmung
technisch unattraktiv werden. Ohne Freshness und ohne Root-of-Trust-nahe Messkette
ist auch Attestation schnell nur ein hübscher Anstrich.

### Die Schnittstelle selbst ist das Risiko: Eine staatlich legitimierte Angriffsfläche ist immer eine Angriffsfläche

Sobald ePTI über eine elektronische Schnittstelle funktioniert, ist diese Schnittstelle
zwangsläufig attraktiv. Ein CSMS, das hier nicht radikal auf least privilege setzt,
baut einen „legalen“ Seiteneingang. Deshalb muss der PTI-Kanal als eng definierter
read-only Dienst konzipiert werden, der keinen Pfad in Programmierung, Codierung
oder Security-Unlock-Funktionalität besitzt. Es muss außerdem eine klare logische
Trennung gegenüber Werkstatt- und OEM-Engineering-Funktionen geben, damit der PTI-
Kanal nicht versehentlich zu einem alternativen Steuerungsweg wird. Und weil selbst
legitime Kanäle missbraucht werden, sind Rate-Limits, Abuse Detection und manipulationsgeschützte
Logs keine Kür, sondern Hygiene.

Das alles ist nicht akademisch. Es ist die Differenz zwischen „TÜV als Sicherheitskontrolle“
und „TÜV als neuer Standard-Angriffspfad“.

### Trust für Prüfer: Ohne Authentisierung und Revocation endet das im Chaos

Ein weiteres Problem wird gerne unterschätzt: Wer darf eigentlich prüfen? Wenn der
PTI-Kanal offen ist, ist er offen für alle. Wenn er zu restriktiv oder national 
fragmentiert ist, endet das in Interoperabilitätsfrust und Schattenlösungen, die
später sicherheitstechnisch nicht mehr einholbar sind.

Ein tragfähiges Modell muss daher Prüftools und Betreiber eindeutig authentisieren.
Es muss autorisieren, welche Daten und Funktionen im PTI-Kontext zulässig sind. 
Es muss Revocation unterstützen, weil kompromittierte Prüfgeräte oder Schlüssel 
in der realen Welt kein theoretisches Risiko sind, sondern eine Frage der Zeit. 
Ohne Revocation ist „Trust“ lediglich eine einmal ausgestellte Einladung zur Daueranwendung.

### „Integrity incorrect“ ist ein Incident

Wenn Integrität als Mangelkriterium auftaucht, wird ein Fail-Zustand regulatorisch
relevant. Das führt zwingend zu einem Incident-Pfad. Ein Fahrzeug darf bei einem
Integritätsbefund nicht gefährlich degradieren oder sich selbst unkontrolliert lahmlegen.
Die Kommunikation muss so gestaltet sein, dass sie nicht versehentlich Angriffsdetails
liefert. Die Beweissicherung muss funktionieren, weil der Streitfall nicht hypothetisch
ist: Er entsteht genau dann, wenn ein Prüfer „nicht okay“ sagt und der Halter oder
der Hersteller widerspricht.

Damit wird deutlich, warum das CSMS hier nicht „nur am Rand“ betroffen ist. Es geht
um sichere Fail-States, nachvollziehbare Diagnostik im Security-Sinne und forensische
Verwertbarkeit, ohne dabei neue Datenschutz- oder Missbrauchsprobleme zu erzeugen.

### Der kritische Punkt: Pseudo-Compliance mit echter Angriffsfläche

Die gefährlichste Konstellation ist eine, in der „Integrität“ politisch gefordert
wird, aber technisch als Versionscheck implementiert werden darf. Dann entsteht 
eine neue Schnittstelle, ein neuer Datenfluss und ein neuer Pass/Fail-Mechanismus,
während die Aussagekraft gering bleibt und die Missbrauchsfläche steigt. Das ist
der Moment, in dem Roadworthiness nicht sicherer wird, sondern nur bürokratisch 
beruhigt.

Die saubere Schlussfolgerung aus Cybersecurity-Sicht ist unspektakulär, aber zwingend:
Eine Integritätsprüfung im PTI/RSI-Kontext muss auf verifizierbarer Attestation 
basieren. Alles andere ist im Kern ein Self-Report, und Self-Reports sind kein Sicherheitsnachweis.

### CSMS: Was in den Scope gehört, wenn Roadworthiness digital wird

Im CSMS gehört PTI/RSI als eigener Actor und eigener Abuse-Cluster in die TARA, 
inklusive Szenarien wie Rogue Tester, geklonte Tools, Replay, Man-in-the-Middle 
und gezielte Datenmanipulation. Im Requirements-Set müssen Attestation, Authentisierung,
Autorisierung, least privilege, Segregation und Revocation explizit auftauchen. 
In den Evidence-Artefakten müssen Crypto-Design, Trust-Chain, Key-Management, Abuse-
Monitoring und manipulationsgeschützte Logging-Architektur nachweisbar sein. Und
operativ muss ein Playbook existieren, das „integrity incorrect“ als Incident behandelt
und nicht als kosmetischen Mangelcode.

Das ist keine Überreaktion. Es ist die Mindestantwort auf einen Gesetzgeber, der
gerade dabei ist, aus dem TÜV einen softwarebasierten Vertrauensrichter zu machen.