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

Im November 2023 verabschiedete die EU die Verodnung (EU) 2023/2854 “ü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¹, dem EU Cyber Resilience Act², der europäischen Antwort auf die US Rule on Connected Vehicles³, der Verordnung (EU) 2018/858 (mit Blick auf die SERMI-Zertifizierung)⁴ sowie die Motor Vehicle Block Exemption Regulation (MVBER)⁵.

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).

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. ↩︎
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. ↩︎
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. ↩︎
4. SERMI zeigt, dass akkreditierter Zugriff (Identität, Toolchain, Audit) für sensible Reparatur-/Sicherheitsdaten praktikabel ist – Blaupause für Datenzugänge: „SERMI++“. ↩︎
5. Die MVBER‑Evaluation adressiert Aftermarket‑Wettbewerb, ist aber kein Sicherheitsrahmen; Cyberfragen gehören ins Typgenehmigungs- und Produktsicherheitsrecht. ↩︎