# Will you exploit CAN bus during a pentest, or only document the path? **slug:** `can-bus-exploitation-scope` · **URL:** `/knowledge/faq/can-bus-exploitation-scope/` · **category:** Automotive Engagement Scope · **reviewer:** Tatiana ### Short answer It depends on the engagement target and the safety-of-life implications. On bench rigs with separated safety-critical actuators we exploit fully. On instrumented test vehicles we exploit with documented safety controls. On production vehicles we typically stop at proof-of-access and document the exploitation path rather than execute commands that could affect driver safety. ### Long answer CAN bus exploitation has three escalating depths: (1) bus access — establishing read/write capability on the target network segment; (2) command injection — sending arbitrary messages that the target ECU accepts; (3) functional manipulation — using the injected commands to change vehicle behavior (acceleration, braking, steering, lighting, infotainment, telematics). For each engagement we agree the depth in the [scope-of-work document](/trust/rules-of-engagement/) before testing starts. The decision is driven by three factors: the vehicle state during testing (bench rig with no driver, instrumented test vehicle with safety driver, production vehicle), the target ECU's role in safety-of-life functions (an infotainment ECU exploitation can be fully executed; a powertrain ECU exploitation typically stops at command-injection capability rather than functional manipulation), and the client's incident-response readiness if a test vehicle becomes inoperable mid-engagement. In our experience, OEM and Tier-1 clients ask us to go to depth 2 on instrumented test vehicles for safety-critical ECUs and to depth 3 for non-safety-critical ECUs (infotainment, telematics, body control). For aftermarket dongle assessments — where the dongle is a separate product attached to a production vehicle — we typically test the dongle on a bench setup and validate the documented exploitation path in a controlled test-vehicle environment with the client's safety team present. We document the chain of evidence required for the client to reproduce findings without the safety risk of re-exploiting on the vehicle: full message-capture logs, exploit-script source, ECU response captures, and a written reproduction guide. ### Related - [Automotive cybersecurity service](/services/automotive-security/) - [Rules of engagement](/trust/rules-of-engagement/) - [CAN bus](/knowledge/glossary/can-bus/) - [OBD-II](/knowledge/glossary/obd-ii/) ---