# When you assess an OBD-II dongle, what's in scope — the dongle, the cellular path, or the vehicle network behind it? **slug:** `obd-ii-dongle-assessment-scope` · **URL:** `/knowledge/faq/obd-ii-dongle-assessment-scope/` · **category:** Automotive Engagement Scope · **reviewer:** Tatiana ### Short answer By default, all three. An OBD-II dongle creates a security boundary that touches three attack surfaces: the dongle's firmware and local interfaces (Bluetooth, USB), the cellular or wireless path to the dongle's backend (LTE, 5G, Wi-Fi, manufacturer cloud), and the vehicle network behind the OBD-II connector. We typically scope all three because exploitation of any single surface usually leverages the others, and the client's security posture depends on the complete chain. ### Long answer The OBD-II dongle category is broad: aftermarket diagnostics, insurance telematics, fleet-management trackers, consumer-grade engine performance monitors, after-sales infotainment add-ons. They share a common architecture — a small ARM or microcontroller-based device that connects to the OBD-II port, optionally bridges to a wireless network (Bluetooth to phone, Wi-Fi, cellular), optionally connects to a backend cloud service, and exposes some user-facing functionality. The dongle itself: firmware extraction (debug interfaces, eMMC sniff, chip-off where required), reverse engineering of the firmware to identify CAN-bus interaction logic, authentication-secrets handling, and update-mechanism integrity. For Bluetooth-equipped dongles we also cover BLE-pairing security, BLE-GATT enumeration, and the pairing-key provisioning model. The cellular or wireless backend path