The Connected Vehicle Perimeter Includes Dealer APIs

The compromise did not begin on the CAN bus

Security researcher Sam Curry and collaborators disclosed a Kia web-portal attack chain in 2024 that used dealer-facing API behaviour to reassign control of connected-vehicle functions. The researchers demonstrated that a licence plate could be resolved to a VIN and used as part of a chain that exposed owner data and enabled remote commands on affected vehicles.

The important security boundary was not inside the vehicle. It sat in the cloud services that decided who was authorised to act as the owner. Once the backend accepted an attacker-controlled identity as legitimate, the downstream vehicle could receive commands through normal, trusted interfaces.

That is why secure boot, cryptographic in-vehicle communication and hardened ECUs cannot compensate for weak authorisation in dealer, fleet or customer-service systems. The control plane for a connected vehicle extends through the business systems capable of granting authority.

Identifiers must not become authority

VINs, licence plates, account numbers and device identifiers are useful lookup keys. They are not proof of identity. A robust backend should require server-side authorisation for every sensitive transition, especially changes of ownership, enrolment of new users and remote commands.

UN Regulation No. 155 reinforces the need to keep cyber risk assessments current and to monitor and respond to attacks over the vehicle lifecycle. That scope is difficult to satisfy if the TARA ends at the telematics ECU while the real privilege boundary lives in an external dealer portal.

For connected-vehicle programmes, the design question should therefore be stated in terms of authority: which external service can create, delegate or revoke the right to command a vehicle, and what independent evidence proves that each transition was legitimate?