Ein modernes Fahrzeug kann per App geöffnet, gestartet, aktualisiert und diagnostiziert werden. Digitale Schlüssel lassen sich teilen, Fahrzeuge Flotten zuweisen und Funktionen aus der Ferne auslösen. Doch technische Erreichbarkeit beantwortet nicht die wichtigste Frage: Darf diese Wirkung jetzt überhaupt stattfinden?
Viele heutige Sicherheitsmodelle enden bei Anmeldung, Schlüssel, Rolle oder Signatur. CMEG beginnt dort erst. Denn ein Account kann noch aktiv sein, obwohl das Fahrzeug verkauft wurde. Ein digitaler Schlüssel kann technisch gültig sein, obwohl die Fahrerzuweisung beendet ist. Ein Update kann korrekt signiert sein, obwohl der Rollout widerrufen wurde. Und ein Werkstattzugang kann echt sein, ohne Schreibrechte für jede ECU zu besitzen.
Heute möglich: Technischer Zugang kann organisatorischem Entzug hinterherlaufen.
CMEG: Eigentümerwechsel wird zum Authority-Ereignis. Frühere eigentümergebundene Rechte müssen neu bewertet oder beendet werden.
Heute möglich: Rechte verschwinden erst bei manuellem Cleanup.
CMEG: Fahrerzuweisung und Benutzerkonto sind getrennt. Endet die Zuweisung, darf daraus kein fortbestehendes Fahrzeugrecht entstehen.
Heute möglich: Ein gültiger Key wird als ausreichender Zugang interpretiert.
CMEG: Schlüssel, Inhaber, Fahrzeug, Zeit und erlaubte Wirkung müssen gemeinsam passen.
Heute möglich: Integrität wird mit aktueller Ausführungsberechtigung verwechselt.
CMEG: Signatur reicht nicht. Fahrzeug, ECU, Version, Rechtsraum, Rollout und Berechtigung werden bis zum Installationszeitpunkt bewertet.
Heute möglich: Diagnosezugriff wird zu breit behandelt.
CMEG: Lesen, Schreiben, Flashen und Konfiguration sind getrennte Wirkungen mit eigenen Rechten.
Heute möglich: Technische Fähigkeit und Handlungserlaubnis verschwimmen.
CMEG: Die Absicht des KI-Modells ist keine Berechtigung. Ein Agent darf ein Recht anfordern, aber sich nicht selbst erteilen.
Ein vernetztes Fahrzeug ist heute nicht nur ein Fahrzeug. Es ist gleichzeitig App-Endpunkt, Cloud-Client, Software-Plattform, Datenquelle, digitaler Schlüsselträger, Flottenobjekt und zunehmend autonomer Akteur. Jede dieser Ebenen erzeugt neue Zugriffswege. CMEG verhindert, dass aus diesen Zugriffswegen automatisch Handlungsmacht wird.
Die zentrale Idee ist deshalb bewusst einfach: Erreichbarkeit ist kein Recht. Authentifizierung ist kein Recht. Eine Signatur ist kein Recht. Eine Rolle ist kein unbegrenztes Recht. Erst wenn die aktuell erforderliche Authority für die konkrete Wirkung noch besteht, kann diese Wirkung ausführbar werden.
Das gilt nicht nur beim Login. Die Authority wird unmittelbar vor der Wirkung erneut bewertet. Ändert sich zwischen Freigabe und Effect etwas Wesentliches — etwa Eigentümer, Fahrer, Softwarefreigabe, regulatorischer Status oder Grant — muss die Executability neu bestimmt werden.
Remote Services, Digital Keys, OTA und Fahrzeugfunktionen erhalten eine gemeinsame Berechtigungsgrenze statt isolierter Rechteinseln.
Fahrerwechsel, Leasingende, temporäre Zuweisungen und Mandantengrenzen werden technisch durchsetzbar statt nur administrativ dokumentiert.
Diagnose wird granular: Lesen, Schreiben, Flashen und Konfigurationsänderungen können getrennt autorisiert werden.
App- oder API-Zugang wird vom eigentlichen Ausführungsrecht am Fahrzeug getrennt.
Receipts können später festhalten, unter welchem Berechtigungs- und Fahrzeugzustand eine Wirkung erlaubt, blockiert oder neu bewertet wurde.
Legitime Holds, Recall-Zustände und andere regulatorische Berechtigungsänderungen können die aktuelle Executability beeinflussen, ohne einen unbegrenzten unbegrenzten Administrationskanal zu schaffen.
Eine App, API, Werkstatt, Flotte oder ein autonomes System fordert eine konkrete Wirkung an — etwa Entriegeln, Starten, Aktualisieren, Diagnose, Datenexport oder eine Konfigurationsänderung.
CMEG betrachtet Fahrzeug, Akteur, Zweck, Zeit, Mandant, Rechtsraum, Zuweisungen sowie Software- und Regulierungszustand gemeinsam.
Es wird nicht nur geprüft, ob etwas früher einmal erlaubt war, sondern ob das erforderliche Recht im aktuellen Zustand noch besteht.
Unmittelbar bevor die reale Fahrzeugwirkung ausgelöst wird, wird die Berechtigung erneut geprüft. Ein Widerruf oder eine Zustandsänderung kann die frühere Freigabe stoppen.
Das Ergebnis wird in einem kryptografisch gebundenen Nachweis festgehalten: nicht nur, was passiert ist, sondern unter welchem Berechtigungs- und Fahrzeugzustand die Wirkung erlaubt oder verweigert wurde.
Für Hersteller, Flotten, Aufsicht oder spätere Untersuchungen ist oft entscheidender, warum eine Wirkung überhaupt stattfinden durfte. CMEG kann genau diese Entscheidungsgrundlage mit dem Effect verbinden: Akteur, Fahrzeug, Zweck, Berechtigungsquelle, Version, Rechtsraum, Zeitpunkt, Widerrufsstatus, Entscheidungskontext, Ausführungsfähigkeit und Ergebnis.
Das macht aus einem technischen Log keine magische Wahrheit über die physische Welt. Es schafft aber eine nachvollziehbare, manipulationserkennbare Nachweiskette für die tatsächlich bewertete Berechtigung und die daraus entstandene Entscheidung.
CMEG ersetzt weder Cybersecurity-Management noch Typgenehmigung oder Entwicklungsstandards. Es ergänzt sie um die Frage, ob eine konkrete Fahrzeugwirkung unter der aktuell gültigen Berechtigung jetzt ausgeführt werden darf.
CMEG wurde nicht auf einen späteren BSI-Hinweis hin entworfen, sondern war bereits Bestandteil unserer Architektur. Dass das BSI inzwischen genau die Risiken rund um vernetzte Fahrzeuge, Fahrzeugkonten, Zugriffsrechte und deren sicheren Entzug hervorhebt, bestätigt unabhängig die Relevanz der Problemstellung, die CMEG bereits adressiert.
Unabhängige Bestätigung des Handlungsbedarfs ≠ BSI-Prüfung, Zertifizierung oder FreigabeCybersecurity-Management und Software Update Management bleiben eigenständige regulatorische Ebenen. CMEG ergänzt die aktuelle Executability der konkreten Wirkung.
Mapping ≠ TypgenehmigungCybersecurity Engineering und Software Update Engineering werden nicht ersetzt. CMEG ergänzt eine Authority- und Point-of-Effect-Boundary.
Ausrichtung ≠ Zertifizierung38 Szenarien wurden blockiert, 2 lösten verpflichtendes Reassessment aus und 10 legitime Kontrollen wurden ausgeführt. In der ausgeführten Suite wurde kein Bypass beobachtet.
Unterhalb der erklärenden Ebene bleibt CMEG formal: 30 sektorale Invarianten, 32 registrierte Vehicle Execution Surfaces, erneute Prüfung unmittelbar vor der Wirkung, an die Ausführungsberechtigung gebundene Ausführung und forensische Fahrzeug-Ausführungsnachweise. Diese Technik ist die Belegschicht dafür, dass die beschriebenen Alltagssituationen in wiederholbare Durchsetzungs- und Testlogik übersetzt wurden.
Aussagegrenze: „Kein Bypass in der ausgeführten Testsuite beobachtet“ bedeutet ausschließlich, dass in dieser ausgeführten Suite kein Bypass beobachtet wurde. Es ist keine Behauptung, dass kein Angriff denkbar oder möglich sei.
Nein. CMEG ist eine Governance-Schicht zwischen digitalen Fahrzeugdiensten und der realen Wirkung. Apps, APIs, Werkstatt- oder Flottensysteme können davor liegen.
Weil ein Account noch funktionieren kann, obwohl das zugrunde liegende Fahrzeugrecht bereits abgelaufen, widerrufen oder durch einen Eigentümer- oder Nutzerwechsel entfallen ist.
Weil ein technisch gültiger digitale Schlüssel nicht automatisch beweist, dass Inhaber, Fahrzeug, Zeitpunkt, Umfang und aktuelle Berechtigung noch zusammenpassen.
Sie kann Integrität und Herkunft belegen. Sie beantwortet aber nicht allein, ob genau dieses Fahrzeug genau dieses Update jetzt noch installieren darf.
CMEG war bereits Teil unserer Architektur, bevor die aktuellen BSI-Hinweise diese Connected-Mobility-Risiken öffentlich hervorhoben. Wir werten das als starke unabhängige Bestätigung der Problemstellung und des Handlungsbedarfs, den CMEG adressiert. Es ist keine BSI-Prüfung, Zertifizierung, Freigabe oder Anerkennung des Systems.
VERNETZT HEISST NICHT BERECHTIGT. Ein Fahrzeug darf technisch erreichbar sein, ohne dass Erreichbarkeit selbst zur Authority wird.
CMEG trennt technische Fähigkeit von aktueller Berechtigung — bis zu dem Moment, in dem aus einer digitalen Anfrage eine reale Fahrzeugwirkung wird.
