Automotive and mobility
A vehicle is a distributed system of control units, buses, radio interfaces and backend services. The attack surface does not end at the vehicle: it includes workshop diagnostics, the OTA chain and the supply chain.
What has already been demonstrated on vehicles
In 2015 two researchers took remote control of a moving SUV. The path ran through the mobile connection of the infotainment system, from there onto the vehicle bus, and finally to the brakes and transmission. The manufacturer then recalled around 1.4 million vehicles. It was the case that moved the industry from product safety to cybersecurity.
Since then the emphasis has shifted, away from the spectacular remote access and towards everyday theft. In what is known as CAN injection, a message is put onto the bus through an accessible cable on the outside of the vehicle, faking a valid unlock to the gateway. All it takes is a bus on which anyone who can reach it physically may transmit.
The radio interfaces remain a constant alongside that: relay attacks on keyless systems have worked for years and are not fixed in software but by timing measurement in the protocol.
Three points of attack, depending on your role
Whether you build vehicles, supply components or run a fleet decides which of them counts first for you.
Testing the vehicle and the control unit
Bus communication, the effectiveness of the gateway filters, behaviour under manipulated messages, diagnostic access over OBD and workshop tooling, and the firmware itself with its debug interfaces and hard-coded credentials.
Testing the backend and the update chain
The connection to the backend, the handling of certificates and key material, and the question of whether an update is delivered signed, rollback-proof and tamper-resistant. That is classic application and infrastructure testing, only with vehicles at the other end.
Detecting what happens in the field
A security operations centre for vehicles evaluates what control units and telematics report. We developed such a vehicle SOC in a research project, including intrusion detection for vehicle buses.
How a vehicle penetration test runs
Not necessarily on the vehicle. A great deal can be covered on individual control units, on test benches and in the lab. For attack paths that connect several domains, a complete rig or a vehicle does say more.
We work from the outside in: first the interfaces reachable without dismantling anything, then the bus behind the gateway, then the control unit itself. Each step answers the question of whether a separation that appears in the architecture document also holds in the vehicle.
What we have contributed on vehicle diagnostics
Diagnostic access is the route every workshop uses in practice and every attacker checks first. In a funded joint project we produced two things on it, both peer-reviewed and published.
First, a systematic ordering of the attack techniques against the diagnostic protocol, presented at an IEEE conference on communications and network security. Second, detection strategies from the control unit through to fleet-wide analysis, in three categories: patterns in the vehicle protocol, assessment in the context of vehicle state and maintenance activity, and the inclusion of public vulnerability information. Checked against the taxonomy, those strategies cover nearly every technique it records.
It is implemented in a detection that actually interprets the protocol rather than only counting frames, and it can be followed on our portable demonstrator. Alongside it sits the tactics and techniques model for vehicles that we presented at an ACM symposium in 2023.
Training for development and the security team
Developers learn where vehicle architecture and classic application security part company: a bus has no user permissions, segmentation comes from the domain split and the gateway filters, and a control unit stays in the field for ten years and more.
Security teams work on protocol analysis, intrusion detection and the question of which report from a vehicle can be analysed at all. The practice happens on the demonstrator, not on slides.
R155 and R156 do not address the same role
UN R155 requires a cybersecurity management system from the manufacturer and makes it a precondition of type approval. UN R156 governs the software update side: processes, traceability and the security of updates over the vehicle lifetime. ISO/SAE 21434 supplies the technical method for both.
The approval side and the operator side are frequently confused. R155 addresses the manufacturer and the vehicle type. A fleet operator or mobility provider satisfies none of the duties arising from its own role that way, for instance when it connects telematics or sharing platforms to its own IT.
We settle that question of role at the start, because it decides the scope and the form the evidence has to take.
What manufacturers, suppliers and fleet operators ask
Not necessarily. Control units, test benches and lab rigs cover most of it. A vehicle or a complete rig becomes worthwhile as soon as attack paths connect several domains.
Before type approval, as an independent technical assessment beside your own evidence; when integrating a new control unit or supplier; and before rolling out an over-the-air update function.
Not directly. Your duties arise from your role as an operator and from connecting telematics and platform services to your own IT. That is a different test scope from a type approval.
Firmware analysis, the update path and the handling of key material are part of the test scope. A control unit comes with the security properties its manufacturer gave it.