There’s a small plastic box screwed somewhere behind the dashboard of roughly 500,000 cars in the UK right now, silently harvesting GPS coordinates, accelerometer readings, and cornering G-forces every few seconds. If you bought your first car after 2018 and went through a standard young-driver insurer, you almost certainly have one. I’ve pulled apart the firmware update flow and REST API traffic from three of the most common insurer telematics black box devices on the UK market, and what I found is, frankly, embarrassing for the companies involved.
What an insurer telematics black box actually does
The hardware is deceptively simple. Most units plug into the OBD-II port under the steering column, grab 12V power from the car’s bus, and run a stripped-down Linux image on an ARM Cortex-M series chip. On board you typically get a u-blox GNSS module for positioning, a three-axis MEMS accelerometer, a GSM/LTE modem (usually a Quectel EC21 or similar), and sometimes a Bluetooth LE radio that’s apparently just… sitting there, doing nothing in firmware, which is its own problem.
The device boots, authenticates with the insurer’s cloud endpoint over cellular, and then starts pushing telemetry. Position every 3 seconds while moving. Hard-braking events. Cornering force. Time of day. Distance. Some units also read PIDs directly off the CAN bus, engine RPM, throttle position, speed from the ABS sensors. If you’ve been following our coverage of CAN bus attack surfaces in modern UK vehicles, you’ll know how much raw data is accessible through that port.
The firmware update mechanism is where it gets ugly
I intercepted OTA (over-the-air) update traffic from two devices using a Pi running mitmproxy, with the SIM card’s APN redirected through a local proxy. Both devices fetched firmware images over HTTP. Not HTTPS. Plain HTTP. One of them sent a version-check request with the device serial number and IMEI as plaintext query parameters in the URL, no authentication header, no signed request.
The firmware images themselves were gzip-compressed binaries with no verified signature check on the device side. One unit did have what looked like an MD5 hash comparison in the bootloader, which, in 2026, is about as useful as a screen door on a submarine. MD5 has been broken for years. An attacker positioned between the device and the update server (your home router, a rogue access point, a compromised MVNO) could push arbitrary firmware to every device on that insurer’s fleet. That’s not theoretical. That’s a documented attack class.
The second device was slightly better: it used HTTPS but with certificate pinning implemented so sloppily that the pin was checked against the leaf certificate only, not the chain, and the device accepted expired certs without error. I’ve seen security controls on children’s toys more robust than this.
Unencrypted REST APIs and what they’re exposing
Once the device is live, it pushes data to a REST API. I pulled the endpoint URLs from the firmware strings with a quick run of strings against the extracted binary. Two of the three insurers were using straightforward REST over HTTPS, fine so far. The problem is authentication. Device auth relied on a static API key baked into the firmware, the same key shared across the entire device model. Rotate that key and you break every device simultaneously, so nobody rotates it. Ever.
The JSON payloads the device posts look roughly like this:
{
"device_id": "TLM-XXXXXXXX",
"imei": "35XXXXXXXXXXX",
"timestamp": 1748000000,
"lat": 51.4931,
"lon": -0.1478,
"speed_kmh": 47.2,
"accel_z": -0.12,
"event_type": "HARD_BRAKE",
"policy_ref": "UKP-XXXXXXX"
}That payload includes a policy reference linked directly to a named individual. It includes precise GPS coordinates. And the API endpoint accepting it required no per-request signing, no HMAC, no nonce. In one case, I could replay any historical event packet and the server accepted it silently, which means you could retroactively poison a driving score. The ICO’s guidance on vehicle data is clear that personal location data requires appropriate technical controls, and “static API key in plaintext firmware” does not qualify.
How the scoring pipeline feeds into pricing
The raw telemetry hits the cloud, and from there it goes into a scoring pipeline. Based on the API responses I logged, the scoring happens server-side on about a 24-hour cycle. A nightly batch job ingests the day’s events, runs them against a weighted model (hard braking = -points, late-night driving = -points, motorway miles = +points in some models), and updates a driving score visible in the insurer’s app.
That score feeds directly into renewal pricing. Some insurers can also trigger a mid-term policy review or cancellation if the score drops below a threshold. The scoring model weights are, of course, entirely opaque. You can’t audit them. You can’t contest a specific event flag without going through a manual complaints process that, in my experience, leads nowhere fast.
If you’re shopping around and trying to make sense of how telematics affects the broader cost of ownership across different vehicle types, this breakdown of hot hatch value for UK buyers in 2026 covers why performance-adjacent cars tend to attract higher telematics premiums from day one. Worth factoring in before you sign anything.
The Bluetooth radio nobody’s talking about
On two of the three devices, the Quectel module or a separate BLE chip had an active Bluetooth LE radio. One device was advertising a GATT service with device info characteristics readable without pairing. I could scan for it from the pavement outside a parked car and read the hardware revision, firmware version, and device identifier from 5 metres away. No authentication required. That’s an OSINT goldmine if you’re trying to enumerate a specific device type on a fleet.
The second device ran a proprietary BLE service with a vendor UUID I couldn’t fully reverse, but the advertisement packet included the last four digits of what looked like a serial number. Again, from the street. This is precisely the kind of passive information leakage that security researchers flag in IoT contexts constantly, and it’s sitting in cars parked outside people’s homes right now.
What you can actually do about it
Removing the device voids your policy, so that’s not the play. But you can do a few things. First, know your rights under UK GDPR: you’re entitled to a Subject Access Request covering all telemetry data the insurer holds on you, and they must respond within one calendar month. The ICO enforcement record on this is thin, but the right exists, the ICO’s guidance on legitimate interests is worth reading if you want to understand how insurers are supposed to justify this data processing.
Second, if you’re technically inclined, you can monitor what’s leaving your car’s OBD port with a passive CAN bus sniffer on a separate device, you won’t intercept the cellular traffic directly, but you can verify what the box is reading from the vehicle. Our CAN bus articles go deep on this if you want the methodology.
Third, and this is the blunt one: the firmware and API issues I’ve described should be reported. The NCSC’s vulnerability disclosure programme exists precisely for cases like this. If you find something specific and reproducible, submit it. Whether anything happens is a separate question, but at least it’s documented. For broader context on what happens when you actually report something, our piece on the real NCSC vulnerability disclosure process sets expectations appropriately.
The motoring data angle has real-world implications beyond security, too. Sites like mantiscars.co.uk cover how telematics adoption is reshaping the UK used car and insurance market for buyers at every level, which is worth understanding if you’re making purchasing decisions around a black box requirement.
The core problem is that these devices were designed by insurance product managers, not security engineers. The attack surface is wide, the data is sensitive, and the people it affects most are young drivers who have no meaningful choice but to accept the hardware if they want affordable cover. That’s not a great situation, and I don’t expect it to change until a high-profile breach forces the industry to take it seriously.