Penetration testing a vehicle: scope, method, deliverables

Testing to prove a control, not to break a car

A vehicle penetration test is not a stunt. Its purpose is narrow and useful: to find where a security control the programme claims to have does not actually hold. The TARA says a threat is mitigated; the pentest is how you find out whether that is true before an assessor, or an attacker, does. Framed that way, the value of the exercise is measured not in dramatic exploits but in findings that map cleanly back to risks and can become type-approval evidence.

This is why a good pentest starts from the paperwork. The TARA and the architecture define which assets carry the highest-impact risk and which attack paths reach them, and the test plan concentrates effort there. Testing everything equally is a way to run out of time before reaching what matters. Under ISO/SAE 21434, verification and validation exist precisely to confirm that the cybersecurity concept survives contact with a real attacker, and penetration testing is a core part of that confirmation.

What is in scope

The scope follows the attack surface a real adversary would reach. In practice that means:

Surface	What is tested	Typical weakness
In-vehicle network (CAN, CAN-FD)	Frame injection, spoofing, fuzzing on the bus	No authentication on the wire
Diagnostics (UDS)	SecurityAccess (0x27), session control, protected services	Weak seed-key, replay, no lockout
OBD-II port	Access from the physical diagnostic connector	Direct bus reach, weak gating
Wireless interfaces	Bluetooth, Wi-Fi, cellular, key fob, TPMS	Exposed services, weak pairing
ECU firmware	Extraction, analysis, secure-boot bypass	Unsigned images, debug left enabled
Backend / telematics links	The connection between vehicle and back-end	Weak authentication, trust of the channel

Two of these deserve their own study, because they are where a large share of findings land. The in-vehicle network has no built-in authentication, so much of the work reduces to CAN bus attacks — injection, spoofing and fuzzing with bus access. And the diagnostic stack is often the shortest path to firmware, which is why UDS SecurityAccess and the 0x27 problem is a standing item on every test plan.

Method: benches, not production vehicles

Most serious vehicle security testing runs against representative ECU benches rather than a whole car. A bench is a rig that reproduces the target ECUs, their network and the relevant signals, so that the behaviour under test is faithful without the cost, safety constraints and scheduling difficulty of a production vehicle. It also allows destructive and repeated testing that a driveable car cannot tolerate.

The method typically moves through recognisable phases:

1. Scoping and rules of engagement. Agree the targets, the interfaces, the depth, and what is off-limits, in writing, before anything is touched.
2. Reconnaissance. Map the network, enumerate services, identify the ECUs and their diagnostic capabilities.
3. Attack execution. Work the surfaces — bus injection, diagnostic access, firmware extraction, wireless — against the agreed scope.
4. Impact analysis. For each successful finding, establish what an attacker gains and what it means for the vehicle and its occupants.
5. Reporting and verification support. Document reproducibly and stay available to confirm fixes.

The bench-based approach also makes findings transferable. A demonstrated weakness on a representative ECU is evidence about the type, not about one hand-built car, which is what a type-approval regime needs.

What a good report contains

A report is the deliverable, and its quality determines whether the whole exercise was worth running. Each finding should carry:

• The setup — enough to reproduce it independently.
• The steps taken and the observed result.
• The impact, stated in terms of what the attacker achieves.
• A severity rating that a non-specialist can act on.
• Concrete remediation and the evidence needed to verify the fix.

The single most important property is traceability. A finding that maps back to a specific TARA entry and to a UN R155 Annex 5 threat category is not just a security observation — it is audit evidence that a mitigation does or does not hold. A worked demonstration such as the instrument cluster attack, where crafted CAN frames change what the dashboard shows with no fault raised, illustrates the point: the value is not the spectacle, it is the clear line from crafted frame to missing authentication to Annex 5 category to remediation.

How it feeds the assessment

A UN R155 CSMS assessment expects the organisation to have verified its cybersecurity claims, and penetration test results are a natural part of that evidence. But the results are only useful if they are tied to the risk picture. A pile of findings with no mapping to the TARA tells an assessor little; a set of findings that each close, or leave open, a specific claimed mitigation tells them exactly where the programme stands. That mapping is what turns testing spend into approval progress rather than a parallel activity.

The timing matters too. Findings surfaced on a bench during development are cheap to fix; the same findings surfaced during an assessment are expensive, and the same findings surfaced in the field are a recall or a reporting event. Testing early and testing against the TARA is how a programme keeps the cost of a weakness low.

The AutoSifu view

We scope pentests from the TARA and write the report to be assessment evidence, not a standalone document, so every finding traces to a risk and a mitigation. Running this on one route with CIRT — compliance, solutioning and CoC/VTA support — means findings are closed with the approval body in the room, so a demonstrated weakness becomes verified evidence rather than an open question at audit.