KARR/SWDS Shows Why Aftermarket Vehicle Authority Must Be Constrained

The security problem is not Bluetooth. It is authority.

A dealer-installed accessory can sit outside the OEM's original ECU architecture while still gaining meaningful authority over the vehicle. That makes the trust relationship more important than the technology used to transport commands.

When a common authentication secret is reused across products, possession of that secret can collapse what should be vehicle-specific trust. The useful chain is:

The consequence is determined by what that identity is permitted to do. A compromised accessory with narrowly constrained services creates a different risk from one that inherits broad reach across in-vehicle communications.

Do not solve an aftermarket governance problem with unlimited vehicle trust

It is unrealistic to assume that a vehicle manufacturer can control the complete lifecycle of every dealer-installed or aftermarket component. Products may be selected, installed, serviced and replaced through ecosystems that extend beyond the OEM's direct engineering governance.

The scalable response is therefore architectural containment. The vehicle should assume that third-party components can fail, become obsolete or be compromised, and should limit the authority available to them accordingly.

A stronger model is:

The gateway becomes the enforcement point between accessory identity and vehicle authority. Authentication establishes which component is requesting access. Authorization determines which services it may invoke. Filtering constrains commands and data to what the accessory actually requires.

The gateway should enforce least authority, not only connectivity

Traditional gateway discussions often focus on which buses or network segments can communicate. That remains important, but modern vehicle architectures require a finer-grained question: which logical functions may this identity invoke?

A third-party anti-theft component may legitimately require a small set of body or immobilisation functions. That does not imply a need for unrestricted diagnostic access, broad ECU reachability or authority over unrelated services.

If the accessory is compromised, the gateway should therefore constrain the blast radius by limiting reachable ECUs, accepted services, command types and rates. Logging and attributable identities should make abnormal use visible, while policy update and revocation mechanisms provide a path to remove trust when a product or credential becomes unsafe.

Zonal and service-oriented architectures make this more important

As vehicles move toward zonal controllers and service-oriented architectures, physical bus topology becomes a weaker proxy for authority. Multiple functions can share compute, networks and gateways while remaining logically separated by identity and policy.

That creates an opportunity to make aftermarket integration safer. Instead of granting a device network presence and assuming that downstream ECUs will defend themselves, the architecture can expose only the services the accessory is entitled to consume.

The design objective is not to eliminate useful aftermarket functionality. It is to integrate it without expanding trust beyond what the function requires.

Related context. The same authority problem appears in automotive update paths that inherit legitimate installation authority and in vehicle APIs where authentication and authorization must remain distinct. Third-party integration is safest when identity never implies broader authority than the function requires.