A modern vehicle can be unlocked by app, started remotely, updated, diagnosed, assigned to a fleet and shared through digital keys. That creates a new security question: just because an action is technically possible does not mean it is currently authorized.
Many security models stop at login, key, role or signature. CMEG starts there. An account may still be active after a vehicle was sold. A key may still be technically valid after a driver assignment ended. An update may be correctly signed after its rollout was revoked. A workshop may be authentic without having write authority for every ECU.
Possible today: technical access may outlive organizational revocation.
CMEG: ownership transfer becomes an Authority event. Previous owner-bound rights must be reassessed or terminated.
Possible today: rights disappear only after manual cleanup.
CMEG: driver assignment is separated from the account. When assignment ends, no vehicle right may survive from it.
Possible today: a valid key is treated as sufficient access.
CMEG: key, holder, vehicle, time and permitted effect must all still match.
Possible today: integrity is confused with current deployment authority.
CMEG: signature alone is insufficient. Vehicle, ECU, version, jurisdiction, rollout and Authority are evaluated through installation time.
Possible today: diagnostic access is treated too broadly.
CMEG: read, write, flash and configuration are separate effects with separate rights.
Possible today: technical ability and permission blur together.
CMEG: model intent stays outside Authority. An agent may request a right, but it may not grant one to itself.
A connected vehicle is no longer only a vehicle. It is an app endpoint, cloud client, software platform, data source, digital-key carrier, fleet object and increasingly an autonomous actor. Each layer creates new paths to trigger effects. CMEG prevents those access paths from becoming authority by themselves.
The idea is intentionally simple: reachability is not a right. Authentication is not a right. A signature is not a right. A role is not unlimited authority. A vehicle effect can become executable only when the currently required Authority still exists.
This does not end at login. Authority is revalidated immediately before effect. If something material changes between approval and effect — owner, driver, rollout, regulatory state or grant — executability must be determined again.
Remote services, digital keys, OTA and vehicle functions receive one common Authority boundary instead of isolated permission silos.
Driver changes, lease termination, temporary assignment and cross-tenant boundaries become technically enforceable rather than merely documented.
Diagnostics become granular: read, write, flash and configuration changes can be separately authorized.
App or API access is separated from the actual Vehicle Execution Right.
Receipts can preserve the Authority and vehicle state under which an effect was allowed, blocked or reassessed.
Legitimate holds, recall states and other regulatory Authority changes can affect current executability without creating an unlimited super-admin channel.
An app, API, workshop, fleet system or autonomous agent requests a concrete effect such as unlock, start, update, diagnostic action, data export or configuration change.
CMEG brings together vehicle, actor, purpose, time, tenant, jurisdiction, assignment, software state and regulatory state.
It does not ask only whether something was once allowed. It determines whether the required right still exists in the current state.
Immediately before real vehicle effect, Authority is revalidated. Revocation or a material state change can stop an earlier approval.
The result is bound into a receipt: not only what happened, but under which Authority and vehicle state the effect was allowed or denied.
For manufacturers, fleets, supervisors or later investigations, it is often more important to know why an effect was allowed at all. CMEG can bind that decision basis to the effect: actor, vehicle, purpose, Authority source, version, jurisdiction, time, revocation state, closure, capability and outcome.
This does not magically prove physical truth. It creates a traceable, tamper-evident evidence chain for the Authority state actually evaluated and the decision produced from it.
CMEG replaces neither cybersecurity management, type approval nor engineering standards. It adds a distinct question: may this concrete vehicle effect occur now under current Authority?
CMEG was not designed in response to later BSI guidance; it was already part of our architecture. The fact that BSI now publicly highlights risks around connected vehicles, vehicle accounts, access rights and secure revocation independently reinforces the relevance of the problem CMEG already addresses.
Independent confirmation of the need ≠ BSI audit, certification, approval or endorsementCybersecurity Management and Software Update Management remain distinct regulatory layers. CMEG adds current executability of the concrete effect.
Mapping ≠ Type ApprovalCybersecurity Engineering and Software Update Engineering are not replaced. CMEG adds an Authority and point-of-effect boundary.
Alignment ≠ Certification38 scenarios were blocked, 2 triggered mandatory reassessment and 10 legitimate controls were executed. No bypass was observed in the executed suite.
Below the explanatory layer, CMEG remains formal: 30 sector-specific invariants, 32 registered Vehicle Execution Surfaces, point-of-effect revalidation, capability-bound execution and forensic Vehicle Execution Receipts. This is the proof layer translating the described real-world situations into repeatable enforcement and test logic.
Claim boundary: “No bypass observed in the executed suite” means only that no bypass was observed in that executed suite. It is not a universal claim that no attack is conceivable or possible.
No. CMEG is a governance layer between digital vehicle services and real effects. Apps, APIs, workshop systems and fleet systems may sit in front of it.
Because an account may still work after the underlying vehicle right has expired, been revoked or disappeared through an ownership or user change.
Because a technically valid key does not automatically prove that holder, vehicle, time, scope and current Authority still match.
It may prove integrity and origin. It does not by itself answer whether this vehicle may still install this update now.
CMEG was already part of our architecture before the current BSI guidance publicly highlighted these Connected Mobility risks. We regard that as strong independent confirmation of the problem statement and operational need CMEG addresses. It is not a BSI audit, certification, approval or endorsement of the system.
Connected does not mean authorized. A vehicle may remain technically reachable without reachability itself becoming Authority.
CMEG separates technical capability from current Authority — up to the moment a digital request becomes a real vehicle effect.
