# EU In-Vehicle-Data-Access vs. Automotive Cybersecurity (ACS)

- Link: https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/
- Veröffentlicht: 2025-09-11T22:26:43+02:00
- Autor: Michael Bunzel

Im November 2023 verabschiedete die EU** **die [Verodnung (EU) 2023/2854](https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202302854)“
über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung“(
nachfolgend als “Data Act” bezeichnet). Der Data Act wird zum 12. September 2025
anwendbar und regelt ab diesem Zeitpunkt Nutzer- und Drittzugriffsrechte auf Daten
vernetzter Produkte, zugleich aber Sicherheits- und Integritätsausnahmen sowie den
Schutz von Geschäftsgeheimnissen. Hierbei gilt die Prämisse: Der Zugriff auf Daten
endet dort, wo die Sicherheit beginnt. Darüber hinaus hat die Europäische Kommission
2025 Maßnahmen zu „Access to vehicle data, functions and resources“ angekündigt 
und verweist parallel auf eine laufende NIS2-Risikobewertung für Connected Vehicles;
hier sind bei Bedarf regulatorische Folgeschritte vorgesehen.

Diese Aktivtäten sind dabei in den Kontext bestehender Regulierung zu setzen – hier
liegt der Fokus  insbesondere auf der UN R155^([1](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#55353e19-ef7b-4912-80fd-5a89f92a5884)),
dem EU Cyber Resilience Act^([2](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#33fcfd7e-576e-4af5-aece-199a77c80250)),
der europäischen Antwort auf die US Rule on Connected Vehicles^([3](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#6638bdfa-02d3-47e6-86a0-5e28cd98adbc)),
der Verordnung (EU) 2018/858 (mit Blick auf die SERMI-Zertifizierung)^([4](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#f647f36d-08e0-4bc5-b4e6-640a90dfaedf))
sowie die Motor Vehicle Block Exemption Regulation (MVBER)^([5](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#b7789407-543e-469e-86cf-c6d8036e7429)).

In dieser Gemengelage der verschiedenen normativen Themenfelder sollte das Ziel 
einer europäischen Regulierung der Automotive Cybersecurity Kohärenz statt Kumulation
sein. Fahrzeuge unterliegen mit der UN R155 bereits einem strengen, lebenszyklusweiten
Cyber-Regime. Data-Act-Zugriffe dürfen diese (Homologations-)Pflichten weder schwächen
noch verlangsamen. Erstrebenswert wäre somit ein lex-specialis-Vorrang des Typgenehmigungsrechts,
read-only auf Daten im Fahrzeug als Default, least-privilege je Zweck das Datenzugriffs
sowie Zertifizierung aller Dritten mit Zugriffsinteresse.

Eine weitere Facette in diesem Konglomerat aus regulatorischen Puzzlesteinen ist
die ausstehende Antwort der europäischen Kommission auf die US Rule on Connected
Vehicles. Soweit sich eine solche Antwort beispielsweise in Form eines EU-„Trusted-
Stack“ manifestiert, würde sich eine solche Regulierung nahtlos in die Gesamtlandschaft
der Cybersecurity für Fahrzeuge einfügen – natürlich nur unter der Voraussetzung,
dass diese Anforderungen risikoorientiert und Vendor-neutral ausgeprägt werden. 
Das damit erzielbare Ergebnis wäre dann eine höhere Sicherheit, eine klare Haftung
und ein fairer Wettbewerb – ohne parallele Doppelregulierung. Hierbei ist freilich
zu beachten, dass zwischen der Bewertung des Data Acts und der Formulierung der 
Anforderungen an einen EU-„Trusted-Stack“ kein unmittelbarer Sachzusammenhang besteht.
Allerdings kann die Etablierung eines fahrzeugbezogenen EU-„Trusted-Stack“ denklogisch
nicht aus dem Gesamtkontext der Automotive Cybersecurity-Fahrzeugregulierung herausgelöst
werden – denn eben auch hier droht eine konkfliktbehaftete Kumulation von verschiedenen
Regelungsnormen: NISx als Anknüpfungspunkt der Regelung von Fahrzeugen als kritische
Infrastrukturen auf der einen Seite und produktspezifische, homologationsrechtliche
Regulierung des Fahrzeugs durch die UN R155 i.V.m. VO (EU) 2019/2144 auf der anderen
Seite.

---

## Normative PuzzleSteine im Kontext: Data AcT und Automotive Security

Der **Data Act** schafft horizontale Zugriffsrechte auf Daten vernetzter Produkte(
auch Fahrzeuge), jedoch mit expliziten Sicherheits-/Integritätsvorbehalten sowie
Schutz von Geschäftsgeheimnissen innerhalb der sog. FRAND (fair, reasonable and 
non-discriminatory)‑Grundsätzen. Die Kommission bereitet hierzu Leitlinien und Modellklauseln
vor. Parallel kündigte die Kommission 2025 Maßnahmen zu „Access to vehicle data,
functions and resources“ an.

Auf Homologationsseite gelten **UN R155/R156** via VO (EU) 2019/2144 in der EU, 
wodurch CSMS/SUMS, Risikoanalysen, VSOC/Monitoring und streng kontrollierte Update‑
Prozesse zwingend sind. Die Öffnung zusätzlicher Datenpfade durch den Data Act –
insbesondere bidirektional – berührt somit unmittelbar die homologationsrechtliche
Nachweisführung der Compliance des Produkts Fahrzeug und erhöht zugleich die Angriffsfläche
gegenüber gängigen Gefährdungsvektoren (vgl. hierzu [Annex 5 der UN R155](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)).

Für den OEM-relevanten Aftermarket evaluiert die EU derzeit die **MVBER**; zudem
läuft **SERMI** als EU‑weit akkreditiertes Zugangsmodell für sicherheitsrelevante
RMI – ein praktischer Präzedenzfall für kontrollierten Zugang.

Abschließend wird durch die EU-Kommission als Antwort auf die US Rule on Connected
Vehicles eine **NIS2‑basierte Risikoanalyse für Connected Vehicles **mit Folgeschritten
in Betracht gezogen (ggf. Anpassungen im motorfahrzeugrechtlichen Rahmen). Dies 
Aktivität adressiert die steigende Komplexität vernetzter Fahrzeuge, OTA‑Updates,
Datenintermediäre und Plattformökonomien.

---

## Kollidierende Interessen in der Automotive Security Domäne

Mit Inkrafttreten des Data Acts und dessen Anwendung im Regulierungsumfeld der Automotive
Cybersecurity kristallisieren sich bei genauer Betrachtung verschiedene Zielkonflikte
aufeinandertreffender Interessen heraus:

 * **Zielkonflikt Sicherheits-/Integritätspflicht vs. Datenzugriffspflicht:** OEMs
   sind regulatorisch angehalten, über alle Lebensphasen ihrer Produkte deren CSMS‑
   Konformität zu gewährleisten. Mit der normativen Eröffnung neuer Zugriffspfade
   auf Daten im Fahrzeug oder im fahrzeugnahen Backend erhöht sich aus architektureller,
   konzeptioneller und technischer Sicht die Komplexität, die Angriffsvektoren und
   Nachweislast für die Sicherheit dieser Zugriffspfade.
 * **OEM-Produktgestaltung vs. Berücksichtigung von Drittinteressen:** Die Cybersecurity
   des Produkts wird maßgeblich beeinflusst durch architekturelle Design- sowie 
   technische Umsetzungsentscheidungen, die teilweise zeitlich weit vor dem Start-
   of-Production-Zeitpunkt (SoP) und auch weit vor Inkrafttreten des Data Acts getroffen
   wurden. Nunmehr verlangen unabhängige Werkstätten, Versicherer, Flottenbetreiber
   und Datenintermediäre zeitnahe, standardisierte Zugänge, teils inklusive Hard-
   und Softwarefunktionen. Die Umsetzung derartige Zugriffsmöglichkeiten muss die
   technischen Realitäten von möglichen Änderungen in Bestandsderivaten zwingend
   berücksichtigen.
 * **Gewährleistung eines fairen Wettbewerbs vs. Automotive Cybersecurity:** Die
   sogenannte Gruppenfreistellungsverordnung für Kraftfahrzeuge (Motor Vehicle Block
   Exemption Regulation, MVBER) adressiert innerhalb der EU die intendierte Marktöffnung
   im Automobilsektor und regelt parallel hierzu die Befreiung von vertikalen Vereinbarungen
   unter bestimmten Bedingungen von den EU-Wettbewerbsregeln. Auf der anderen Seite
   kann die MVBER jedoch nicht die Sicherheitsanforderungen für Fahrzeuge substituieren,
   die durch die UN R155 den Marktteilnehmern auferlegt werden – d.h. die Anforderungen
   der Cybersecurity-Regulierung sind durch die OEMs zwingend zu erfüllen und zwar
   unabhängig davon, welche Regelungen die MVBER trifft.

---

## Potentielle ACS-Risiken bei der Implementierung des Data Acts

Mit der Pflicht zur Implementierung der Anforderungen aus dem Data Act sehen sich
die OEMs und deren Zulieferer verschiedenen Risiken aus Sicht der Automotive Cybersecurity
ausgesetzt, die technischer Natur, Compliance-bezogen oder operativer Art sind:

**Technische Risiken:**

 * **Domänen‑Kopplung**: Unklare Trennung zwischen Infotainment, Gateway und Safety-/
   Drive‑Domänen verschiebt mögliche, eher unkritischen Angriffspfade in bestimmte
   sicherheitskritische Bereiche. Darüber hinaus verlangt die UN R156 strenge Update‑
   Kontrollen, d.h. “Dritt‑Kommandos” (u.a. Funktionsaufrufe durch Dritte) wären
   unter Umständen systemwidrig.
 * **Exfiltration/Manipulation:** Unlimitierte API‑Zugriffe erhöhen das Risiko von
   DoS/Brute‑Force‑ und Supply‑Chain‑Angriffen. Insoweit wären ein Schema‑Whitelisting,
   mTLS/FIDO und sowie hardwaregebundene Credentials eine Pfleichtmaßnahme für Data
   Act-Umsetzungsmaßnahmen im Fahrzeug.

**Compliance-Risiken**:

 * **ACS-Homologationsfähigkeit:** Die Öffnung des E/E-Systems für Datenzugriffe
   Dritter i.S.d. Data Acts ohne eine hinreichende Einbettung in bestehende CSMS/
   SUMS‑Strukturen würde die Typgenehmigungs‑Konformität von Derivaten gefähren.
 * **CRA‑Haftung:** Soweit bestimmte Offboard-Umfänge aus dem CSMS-Kontext dem Cyber
   Resilience Act unterworfen sind, skalieren ab dem 11.12.2027 bestimmte Sorgfalts‑,
   Überwachungs- und Patch‑Pflichten auch für fahrzeugnahe Umfänge. In der Konsequenz
   steigen somit auch bei Vorfällen mit Drittzugängen damit verbundene Haftungs‑
   und Sanktionsrisiken.
 * **Data‑Act‑Grenzen:** Die Sicherheits-/Integritätsausnahmen im Data Act ermöglichen
   die Verweigerung/Suspendierung von Datenzugriffen. Auf diese Weise bleiben Geschäftsgeheimnisse
   grundsätzlich geschützt. Die diesbezüglichen Vereinbarungen für einen Datenzugriff
   auf das Fahrzeug durch Dritte müssen “fair, reasonable and non-discriminatory”(
   FRAND) sein. Die Konkretisierung dieser FRAND-Kriterien im Automobilsektor im
   Allgemeinen sowie im Kontext der Automotive Cybersecurity im Besonderen ist freilich
   mit vielen Fragezeichen behaftet und damit auch aus Compliance-Gesichtspunkten
   kritisch zu bewerten.

**Operative Risiken**;

 * **VSOC- und Forensik Prozesse:** Externe Zugriffe auf On- und Offboardsysteme
   benötigen im Kontext des nach UN R155 verpflichtenden Fahrzeug-Monitorings lückenlose
   und nicht abstreitbare Audit‑Trails. Darüber hinaus muss eine kurzfristige Entziehung
   von Zugriffsrechten im Falle von Angriffen oder Incidents möglich sowie die Anomalie-
   Erkennung perspektivisch sichergestellt sein. Diese Anforderungen aus der UN 
   R155 sind in Ausgleich zu bringen mit den Data Act-bezogenen Zugriffsrechten.

---

## Mögliche Leitlinien zur Data-Act-Umsetzung im Automotive-Sektor

**Sicherheitsvorrang**: Bei Produkten im Anwendungsbereich der UN R155 hat die Sicherheit
und Integrität des Gesamtfahrzeugs Vorrang. Zugriffs- und Weitergaberechte nach 
Kapitel II des Data Act gelten nur, soweit sie keine Sicherheits- oder Integritätsrisiken
erzeugen oder Update-Prozesse nach UN R156 beeinträchtigen.

**Read-only & Least-Privilege**: Datenzugang erfolgt grundsätzlich als Read-only,
aggregiert, pseudonymisiert, gepuffert und Rate-limited. Realtime nur, soweit relevant
und technisch machbar; Sicherheits-/Integritätsrisiken schließen „technische Machbarkeit“
aus.

**Domänentrennung**: Zugriffe werden auf nicht-sicherheitskritische Domänen beschränkt
und ausschließlich über zertifizierte Security-Gateways mit mTLS/FIDO, HW-gebundenen
Credentials, Schema-Whitelisting, Rate-Limits, DoS-Schutz und vollständigem Security-
Logging (VSOC-Anbindung) bereitgestellt.

**Zertifizierung („SERMI++“) & Audit**: Drittparteien erhalten Zugang nur bei vorheriger
Zertifizierung (Identität, Toolchain-Sicherheit, Cyber-Reife, Haftpflichtdeckung),
laufender Auditfähigkeit und sofortiger Widerrufbarkeit der Berechtigungen (Kill-
Switch).

**FRAND & Kostendeckung**: Sicherheits- und Betriebskosten der Datenschnittstellen
sind im Rahmen von FRAND vollständig kostendeckend zu vergüten (inkl. Gateway-Betrieb,
Schlüssel-/Token-Management, SIEM/VSOC, Audits, Pseudonymisierung).

---

## Konkrete Lösungsvorschläge

(**a) Sicherheitsvorrangklausel**
„Zugangs- und Nutzungsrechte zu fahrzeuggenerierten
Daten dürfen nicht die Sicherheit, Integrität oder Typgenehmigungs‑Konformität beeinträchtigen.
Remote‑Schreib-/Steuerzugriffe auf sicherheits- oder emissionsrelevante Systeme 
sind ausgeschlossen; zulässig sind ausschließlich vom Hersteller kontrollierte Update-/
Kommandopfade nach UN R156.“

**(b) Trusted Supply-Chain-Pflicht (u.a. EU-Antwort auf US-Rule)**
„Zugriff setzt
vertrauenswürdige VCS/ADS‑Stacks voraus. Die Bewertung der Vertrauenswürdigkeit 
setzt dabei auf zertifizierbare Kriterien (Secure-by-Design, SBOM, Code-Provenance,
Key-Souveränität EU, No-Backdoor/No-Remote-Admin, unabhängige Audits) und nicht 
auf ein pauschales Clustering von Komponenten/Software mit Herkunfts‑ bzw. Einflussbeziehungen
zu bestimmten Risikojurisdiktionen. Hersteller legen jährliche Konformitätserklärungen
vor.“

**(c) Zertifizierung (“SERMI++”) als Zugangsvoraussetzung auf Daten im Fahrzeug**
„
Nicht‑öffentliche Datenzugriffe erhalten ausschließlich akkreditierte Marktteilnehmer
mit nachgewiesener Toolchain‑Sicherheit, Cyber‑Reife, Haftpflichtdeckung, Echtzeit‑
Revokation und verpflichtenden Audits in ihren jeweiligen Strukturen.“

**(d) Daten-/Funktions‑Klassifizierung**
Auf der Grundlage folgender Datenklassen
ist die Zulässigkeit des Datenzugriffs gem. Data Act zu bewerten:

 * Klasse A: unkritische Telemetrie/Diagnose (read‑only, aggregiert)
 * Klasse B: personen-/geschäftssensible Daten (pseudonymisiert, minimiert)
 * Klasse C: sicherheitskritische Daten/Funktionen – externer Zugriff ausgeschlossen

**(e) API‑Governance**
„Zugriff ausschließlich über zertifizierte OEM/neutral betriebene
APIs; mTLS/FIDO, HW‑gebundene Credentials, Rate‑Limits, Schema-/Payload‑Whitelisting,
Security‑Telemetry, Kill‑Switch; keine Roh‑Bus/UDS‑Zugriffe außerhalb definierter
Diagnosefenster.“

**(f) FRAND/Compensation**
„Zulässig ist angemessene Vergütung einschließlich Sicherheits‑/
Betriebskosten und Aufbereitung; Geschäftsgeheimnisse bleiben geschützt (Data Act).“

**(g) Streitbeilegung/Ablehnungsgründe**
„Verbindliche, zertifizierte Schlichtung;
Ablehnung/Suspendierung bei Sicherheits‑/Integritätsrisiko oder Gefährdung von Geschäftsgeheimnissen.“

---

 1. UN R155/R156 verankern Cybersecurity- und Software-Update-Pflichten als Homologationsvoraussetzung(
    EU: neue Typen ab Juli 2022, alle neuen Fahrzeuge ab Juli 2024). Öffnungsschritte
    dürfen diese Pflichten nicht aushöhlen. [↩︎](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#55353e19-ef7b-4912-80fd-5a89f92a5884-link)
 2. Der Cyber Resilience Act (Hauptpflichten ab 11. Dezember 2027) verschärft Produkt-
    Cyber-Pflichten und Haftungsrisiken; unkontrollierter Drittzugang erhöht Exponierung
    und Non-Compliance-Gefahr. [↩︎](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#33fcfd7e-576e-4af5-aece-199a77c80250-link)
 3. Die US‑„Connected Vehicles“-Final Rule (wirksam ab 17. März 2025) untersagt VCS/
    ADS‑Hardware/-Software mit Russland/China‑Nexus (Software ab Modelljahr 2027, Hardware
    ab 2030). Sie setzt eine Sicherheitsbaseline, die die EU im Sinne eines Level‑Playing‑
    Fields spiegeln sollte. [↩︎](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#6638bdfa-02d3-47e6-86a0-5e28cd98adbc-link)
 4. SERMI zeigt, dass akkreditierter Zugriff (Identität, Toolchain, Audit) für sensible
    Reparatur-/Sicherheitsdaten praktikabel ist – Blaupause für Datenzugänge: „SERMI
    ++“. [↩︎](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#f647f36d-08e0-4bc5-b4e6-640a90dfaedf-link)
 5. Die MVBER‑Evaluation adressiert Aftermarket‑Wettbewerb, ist aber kein Sicherheitsrahmen;
    Cyberfragen gehören ins Typgenehmigungs- und Produktsicherheitsrecht. [↩︎](https://smartnuts.com/2025/09/11/eu-in-vehicle-data-access-vs-automotive-cybersecurity-acs/#b7789407-543e-469e-86cf-c6d8036e7429-link)
