Why Your Car Knows Where You Have Been

A 2024 model-year car from any major manufacturer contains somewhere between 50 and 150 electronic control units (ECUs), each running its own firmware, each with its own flash storage, and many of them logging data continuously. The infotainment system records every destination you have ever navigated to, every phone you have ever paired, every Wi-Fi network you have connected to, and every voice command you have spoken. The engine control module logs speed, RPM, throttle position, and braking events at sub-second intervals. The airbag module stores a rolling buffer of crash-relevant parameters that freezes permanently the moment a collision is detected. The telematics control unit phones home to the manufacturer over a cellular connection, uploading a stream of telemetry that includes GPS coordinates, battery state, tyre pressures, and diagnostic trouble codes.

None of this is hidden. It is all documented in engineering service manuals, in JEDEC and ISO standards, in the fine print of the owner's manual that nobody reads. But the sheer volume and persistence of the data, the number of independent systems recording it, and the difficulty of actually deleting it, combine to create a surveillance apparatus that most drivers never think about.

This article walks through every major system in a modern car that records data about where you have been, what you have done, and who was in the vehicle. The goal is to build a concrete technical understanding of what is stored, where it is stored, how long it persists, who can access it, and what it means for privacy. By the end, terms like EDR, CAN bus, OBD-II, eCall, TPMS, and Berla iVe should have specific technical meaning rather than vague menace.

The Infotainment System: Your Car's Filing Cabinet

The infotainment head unit is the most data-rich component in the vehicle from a forensic perspective. Modern head units run on application processors (Qualcomm Snapdragon SA8155P, Intel Atom, NXP i.MX8, or similar) with 4 to 8 GiB of RAM and 64 to 256 GiB of eMMC or UFS flash storage. They run full operating systems: Android Automotive, QNX, Linux with a proprietary UI layer, or (in older vehicles) Windows Embedded Automotive. The software stack is comparable in complexity to a mid-range smartphone, and so is the data it generates.

Navigation history is the most obvious category. When a driver enters a destination in the built-in navigation system, the head unit stores that destination in a database. On most systems, this is a SQLite database or a proprietary flat-file format in the infotainment's flash partition. The stored record includes the full address, the GPS coordinates, a timestamp, and often whether the route was completed or cancelled. "Favourite" locations and "home" and "work" addresses are stored separately and persist indefinitely. Recent searches, including text searches for businesses or points of interest, are logged with timestamps. On systems with a map display (which is nearly all of them), the last known GPS position is written to flash every few seconds or on ignition-off, creating a breadcrumb trail even when no navigation route is active.

The specifics vary by manufacturer. BMW's iDrive system (based on Linux since the ID7 generation) stores navigation history in /nav/history/ partitions that are readable with standard forensic tools. Mercedes MBUX (based on NVIDIA DRIVE hardware) keeps a similar database in its eMMC storage. Volkswagen's MIB3 infotainment platform stores destinations, search history, and route data in SQLite databases that forensic tools like Berla iVe can parse directly. Tesla's MCU (Media Control Unit) runs a custom Linux distribution and stores navigation history, Supercharger session data, and map tile cache in internal flash, all of which is accessible through physical extraction of the eMMC chip.

Voice command logs are another substantial data source. When a driver says "Navigate to Dimitris's house" or "Call Sofia," the audio is processed either locally (on older systems) or sent to a cloud speech recognition service (Google, Amazon, Cerence, or the manufacturer's own service). In both cases, a transcript of the command and its result are stored locally on the infotainment system. On some vehicles, a short audio clip of the command itself is cached locally before being overwritten by newer recordings. Cloud-based systems also retain the audio and transcript on the manufacturer's servers, governed by a separate privacy policy.

Media and app data round out the picture. The infotainment system logs which radio stations were played, which USB drives were connected (including volume serial numbers and file listings), and which streaming services were authenticated. If the driver logged into Spotify, the account credentials or tokens are stored in the head unit's keystore. If they used Apple CarPlay or Android Auto, the connection history (including the phone's serial number, IMEI hash, and user name) is recorded.

All of this data sits on eMMC or UFS flash, which has the same persistence characteristics as the NAND flash in a smartphone. Deleting a file through the infotainment UI typically marks the logical blocks as free without erasing the underlying pages. The data remains physically present until the flash controller's garbage collection process eventually reclaims and erases those blocks, which can take weeks or months depending on write activity. A "factory reset" performed through the infotainment menu does the same thing: it resets the software state and marks data partitions as free, but the physical flash pages often retain the previous contents. Forensic extraction at the chip level (desoldering the eMMC and reading it with a programmer) can recover data that the user believed was deleted months ago.

The CAN Bus: Everything Talks To Everything

The Controller Area Network (CAN bus) is the backbone of in-vehicle communication. Invented by Robert Bosch GmbH in the 1980s and standardised as ISO 11898, CAN is a multi-master serial bus that allows ECUs to broadcast short messages (up to 8 bytes of data per frame on classic CAN, or 64 bytes on CAN FD) to all other ECUs on the same bus segment. A modern car has two to five CAN bus segments: a powertrain bus (engine, transmission, ABS), a body bus (doors, windows, lights, HVAC), a chassis bus (steering, suspension), an infotainment bus, and sometimes a separate ADAS (Advanced Driver-Assistance Systems) bus. These segments are bridged by a central gateway ECU that filters and routes messages between them.

Every CAN message has an 11-bit or 29-bit identifier (the arbitration ID) and a payload. There is no source address in the protocol; any ECU can send any message ID, and all ECUs on the bus see every message. The identifiers are defined by the manufacturer in a proprietary database (often in DBC format, which maps arbitration IDs to signal names, bit positions, scaling factors, and units). For example, arbitration ID 0x200 might carry vehicle speed in bytes 0-1 (big-endian, scaled by 0.01 km/h), engine RPM in bytes 2-3, and throttle position in byte 4.

Most ECUs do not persistently log the CAN traffic they see. The volume is too high: a busy powertrain CAN bus runs at 500 kbit/s and carries hundreds of messages per second, generating megabytes of raw data per minute. Storing all of it would require impractical amounts of flash. Instead, individual ECUs log events derived from CAN data. The engine control module logs fault codes with freeze frame data (a snapshot of engine parameters at the moment a fault was detected). The ABS module logs wheel speed discrepancies. The airbag module logs pre-crash acceleration and deceleration. The body control module logs door open/close events with timestamps.

Event Data Recorders (EDRs) are the most forensically important CAN-derived logging system. Since 2014 in the United States (49 CFR Part 563) and since 2022 in the EU (UN Regulation No. 160), new passenger vehicles must include an EDR. The EDR is typically a function of the airbag control module (ACM) and continuously buffers the last 5 seconds of pre-crash data and 250 milliseconds of post-crash data. The recorded parameters include:

• Vehicle speed (from the ABS/ESC module, via CAN)
• Engine RPM or motor RPM (for electric vehicles)
• Brake pedal application (binary: pressed or not)
• Throttle position (percentage)
• Steering wheel angle (degrees)
• Seat belt status for each seating position
• Airbag deployment timing
• Delta-V (change in velocity) during the crash, sampled at 100 Hz or higher
• Pre-crash stability control activation

The EDR data is written to non-volatile memory inside the airbag module at the moment of a triggering event (typically when the airbag deploys or when deceleration exceeds a threshold). Once written, it is read-only; it cannot be overwritten by subsequent events. If no crash occurs, the rolling buffer keeps overwriting itself and the old data is gone. But the moment a crash trigger fires, the buffer freezes and becomes a permanent forensic record.

EDR data is read using the Bosch CDR (Crash Data Retrieval) tool, which connects to the vehicle's OBD-II port and extracts the stored records. The CDR tool supports most major manufacturers and is widely used by law enforcement, insurance investigators, and accident reconstruction experts across Europe and North America. A CDR report can show, with millisecond precision, how fast the vehicle was travelling in the five seconds before impact, whether the driver braked, and how severe the collision was.

The OBD-II Port: A Diagnostic Window Into Everything

On-Board Diagnostics, second generation (OBD-II in the US, EOBD in Europe) is a standardised diagnostic interface mandated on all passenger vehicles sold in the EU since 2001 (for petrol engines) and 2004 (for diesel). The physical connector is a 16-pin Type A connector, usually located under the dashboard near the steering column. The protocol stack runs over CAN (ISO 15765-4), K-Line (ISO 9141-2, older vehicles), or keyword protocol (ISO 14230, older vehicles). Modern vehicles almost exclusively use CAN.

OBD-II defines a set of diagnostic services (specified in ISO 15031-5 and SAE J1979) that any generic scan tool can request:

• Service 01: Current data (live PIDs). There are roughly 200 standardised PIDs covering engine RPM, vehicle speed, coolant temperature, fuel system status, oxygen sensor readings, and more. Manufacturers also define proprietary PIDs accessible through enhanced diagnostics.
• Service 02: Freeze frame data. When a diagnostic trouble code (DTC) is set, the ECU captures a snapshot of relevant parameters at that moment. The freeze frame includes vehicle speed, engine RPM, coolant temperature, calculated load, and the DTC itself. This snapshot persists until the DTC is cleared.
• Service 03: Stored diagnostic trouble codes. A DTC is a five-character code (like P0301, meaning misfire detected on cylinder 1) that indicates a fault. DTCs are stored in non-volatile memory and persist across ignition cycles until explicitly cleared with a scan tool or after a manufacturer-defined number of drive cycles without recurrence.
• Service 09: Vehicle information. This includes the VIN (Vehicle Identification Number), calibration IDs (firmware version identifiers for each ECU), and calibration verification numbers (checksums).

For forensic purposes, the freeze frame data in Service 02 is particularly valuable because it pairs a timestamp (or at least an odometer reading and engine runtime) with a snapshot of driving conditions at a specific moment. If a vehicle threw a fault code while travelling at 180 km/h, that speed is preserved in the freeze frame regardless of what the driver says happened.

Beyond the standardised OBD-II services, each manufacturer implements proprietary diagnostic protocols accessible through their dealer tool (BMW ISTA, Mercedes Xentry, VW ODIS, Tesla Toolbox). These proprietary protocols expose far more data than standard OBD-II: adaptation values, coding data, long-term fuel trim histories, battery state-of-health logs (critical for electric vehicles), and detailed fault memories with precise timestamps. A dealer technician, or a forensic investigator with the right software, can read a history of every fault the vehicle has ever experienced, when it occurred, and what the vehicle was doing at that moment.

The OBD-II port is also the vector through which aftermarket devices connect: insurance telematics dongles, fleet management trackers, performance tuning devices, and diagnostic readers. Each of these devices has its own data collection and retention practices. An insurance dongle from an insurer in Helsinki might log GPS coordinates, acceleration, braking intensity, and time of day, then upload it over cellular to the insurer's cloud platform every few minutes. The dongle itself may also buffer weeks of data locally. The driver agreed to this when they signed the insurance policy, but most people do not read the data schedule in Appendix C.

Bluetooth: Every Phone Leaves A Fingerprint

Bluetooth pairing is one of the most persistent and most overlooked data sources in a vehicle. When a phone pairs with a car's infotainment system over Bluetooth, the pairing process exchanges and stores several pieces of identifying information:

• The phone's Bluetooth MAC address (a 48-bit hardware identifier, like A4:83:E7:2F:11:B8)
• The phone's device name (often the owner's name: "Katerina's iPhone", "Nikos Pixel 8")
• A link key (the shared secret used to encrypt the Bluetooth connection)
• The pairing timestamp
• Call logs synchronised via PBAP (Phone Book Access Profile)
• SMS messages synchronised via MAP (Message Access Profile)
• Contact lists synchronised via PBAP

The Bluetooth pairing record persists in the infotainment system's non-volatile storage indefinitely. Most vehicles store pairing records for 5 to 10 previously paired devices. Older records are typically not deleted when the list fills up; instead, the least recently used entry is overwritten. But on many systems, the overwritten record remains in flash at the physical level, recoverable through chip-off forensic extraction.

The contact and call log synchronisation is particularly revealing. When a phone connects to the car via Bluetooth and the user grants contact access (often a one-time permission that is quickly forgotten), the entire contact list is copied to the infotainment system. On some vehicles, this happens automatically on every connection. The stored contacts include names, phone numbers, email addresses, and sometimes photos. Call logs include the number called, the call direction (incoming, outgoing, missed), and the timestamp.

Andreas, a forensic examiner working for a European law enforcement agency, described the Bluetooth data in vehicles as "the easiest win in vehicle forensics." In his experience, most people pair their phone once and never think about it again. The car then accumulates a complete record of every call made through the car's hands-free system, every contact in the phone at the time of the last sync, and the MAC address and device name of every phone that has ever been in the car. For a rental car or a shared family vehicle, this can include data from dozens of different people.

The Bluetooth MAC address is especially useful for correlation. If investigators know a suspect's phone MAC address (from Wi-Fi probe requests captured elsewhere, from a seized device, or from another vehicle's pairing records), they can check whether that MAC address appears in a vehicle's pairing history. A match places the phone, and by extension its owner, inside that specific vehicle at some point in the past.

Wi-Fi: The Networks Your Car Remembers

Modern vehicles with built-in Wi-Fi capability (either as a hotspot for passengers or as a client connecting to home or office networks for software updates) maintain a list of known Wi-Fi networks, just like a phone or laptop. This list includes:

• The SSID (network name)
• The BSSID (the access point's MAC address, on some systems)
• The security type (WPA2, WPA3, open)
• The stored passphrase (on systems that cache it)
• A timestamp of last connection

Tesla vehicles, for example, can connect to home Wi-Fi networks to download over-the-air software updates. The list of stored networks persists in the MCU's flash storage. BMW's ConnectedDrive and Mercedes me connect have similar capabilities. Volkswagen's MIB3 platform stores Wi-Fi configuration in a file that Berla iVe can extract and parse.

The forensic value of Wi-Fi connection history is indirect but powerful. If a vehicle's stored network list includes "Hotel Maroussi WiFi" and "Athens Airport Free WiFi," that vehicle (or at least its infotainment system) was at those locations at some point. Combined with timestamps, this can corroborate or contradict an alibi. In one documented case from 2021 in Germany, investigators used a vehicle's stored Wi-Fi networks to establish that a suspect's car had been at a location they denied visiting, because the car had automatically connected to a neighbour's open Wi-Fi network and recorded the SSID and connection time.

Wi-Fi probe requests are another vector. When a vehicle's Wi-Fi client is enabled and scanning for known networks, it broadcasts probe requests containing the SSIDs of its saved networks. Anyone with a Wi-Fi monitor (a €15 USB adapter and Wireshark) can capture these probes and see the list of networks the vehicle is looking for. This is the same privacy issue that affects smartphones, but most people are unaware that their car does it too.

eCall: The EU's Mandatory Emergency Transmitter

Since 31 March 2018, every new type-approved passenger car and light commercial vehicle sold in the European Union must be equipped with an eCall system, as mandated by EU Regulation 2015/758. eCall is an automatic emergency call system that activates when a vehicle is involved in a serious crash. It can also be triggered manually by the occupants.

The technical architecture of eCall is straightforward. The vehicle contains:

• A GNSS receiver (GPS plus Galileo, typically) that continuously tracks the vehicle's position
• A cellular modem with an embedded SIM card (eSIM) capable of making voice calls and sending data
• Crash sensors (accelerometers, typically shared with the airbag system)
• A control unit that ties these components together

When the crash sensors detect a severe impact (using the same thresholds as airbag deployment), the eCall system automatically dials 112 (the European emergency number). The call is routed to the nearest Public Safety Answering Point (PSAP). Simultaneously, the system transmits a Minimum Set of Data (MSD) as an in-band modem signal over the voice channel. The MSD, defined in EN 15722, contains:

• Vehicle identification (VIN)
• Timestamp of the event (UTC)
• Vehicle position (latitude and longitude from the GNSS receiver)
• Vehicle direction of travel
• Whether the call was automatic or manual
• Vehicle type (passenger car, bus, motorcycle, etc.)
• Vehicle propulsion type (petrol, diesel, electric, hydrogen; important for emergency responders)
• Number of seat belts fastened (on some implementations)

The eCall system is designed with privacy in mind: the GNSS receiver tracks position continuously (so it has a fix when a crash occurs), but the position is only transmitted during an eCall event. The system does not continuously upload location data to any server. The embedded SIM is dormant except during an eCall. The MSD is transmitted only to the PSAP and is subject to strict data retention rules under EU law.

That said, the eCall hardware (a GNSS receiver and a cellular modem) is permanently installed in the vehicle and permanently powered. Manufacturers are permitted to use the same hardware for their own connected services (BMW ConnectedDrive, Mercedes me connect, etc.), provided the driver consents. In practice, the line between the mandated eCall function and the manufacturer's commercial telematics service is blurry. The hardware is the same; only the software and the consent model differ. A vehicle with an active manufacturer telematics subscription is uploading GPS coordinates to the manufacturer's servers continuously. A vehicle without an active subscription still has the hardware, still has the GNSS receiver running, and still stores position data locally for the eCall function. The difference is whether the cellular modem is phoning home.

For forensic investigators, the eCall system is another source of position data. Even on vehicles without an active telematics subscription, the eCall control unit may store recent GNSS positions in its internal memory (for the purpose of having a valid fix when a crash occurs). Extracting this data requires access to the eCall control unit, which is typically a separate module from the infotainment system and may require proprietary tools or chip-off extraction.

Telematics and Insurance Black Boxes

Usage-based insurance (UBI) is growing rapidly across Europe. Insurers in the Netherlands, Italy, the UK, and the Nordic countries offer discounts of 10 to 40 percent for drivers who agree to install a telematics device (usually an OBD-II dongle or a smartphone app) that monitors their driving behaviour. The telematics device records:

• GPS position at regular intervals (every 1 to 30 seconds, depending on the provider)
• Speed (derived from GPS or from the OBD-II vehicle speed PID)
• Acceleration and deceleration (from an on-board accelerometer or derived from speed changes)
• Cornering intensity (from lateral acceleration)
• Time of day (driving at 02:00 on a Saturday scores worse than driving at 14:00 on a Tuesday)
• Trip start and end locations
• Total distance driven

This data is uploaded to the insurer's cloud platform, where algorithms compute a "driving score" that determines the premium. The raw GPS tracks are retained by the insurer for the duration of the policy and sometimes longer, depending on the insurer's data retention policy and the applicable data protection regulation.

In Italy, telematics boxes are nearly ubiquitous for young drivers. The Italian insurance market adopted telematics early, partly because of high fraud rates in southern regions, and partly because Italian regulators encouraged it as a way to reduce premiums for safe drivers. A typical Italian telematics box (from providers like Octo Telematics, now part of Via Transportation, or Vodafone Automotive) is a small device hardwired into the vehicle's electrical system, with its own GPS receiver, cellular modem, and accelerometer. It records every trip the vehicle makes, uploads the data over cellular, and stores a local buffer of several weeks in case cellular coverage is lost.

The forensic implications are significant. If a vehicle is involved in a collision, the insurer can pull the telematics data and reconstruct the vehicle's speed, position, and acceleration profile in the seconds before impact. This data is routinely used in insurance claims disputes. In criminal cases, law enforcement can request the telematics data from the insurer (with a court order in most EU jurisdictions). The GPS tracks can place the vehicle at a specific location at a specific time, corroborating or contradicting witness statements.

Fleet management systems are the commercial equivalent. Companies operating vehicle fleets (delivery services, logistics companies, rental car firms) install telematics hardware that records the same data as insurance boxes, plus additional parameters like fuel consumption, idle time, harsh braking counts, and geofence violations. Fleet telematics data is typically retained for years and is readily available to the fleet operator. For rental car companies, this means a complete record of every trip every customer has ever taken, including routes, speeds, and stop durations.

Connected Car Telemetry: The Manufacturer Knows

Tesla is the most visible example of manufacturer telemetry, but BMW, Mercedes-Benz, Volkswagen, Stellantis, Hyundai/Kia, and most other manufacturers now operate connected car platforms that receive continuous telemetry from vehicles in the field.

Tesla collects an extraordinary amount of data. Every Tesla vehicle with a cellular connection (which is all of them; they come with an embedded SIM and an AT&T or similar cellular data plan) uploads telemetry to Tesla's servers. The telemetry includes GPS position, speed, battery state of charge, charging history, Autopilot engagement status, camera snapshots (used for neural network training), cabin temperature, and software version. Tesla's privacy policy states that they collect "information about driving behaviour, such as vehicle speed, direction, and location." In practice, Tesla has used this data to reconstruct accidents (publishing vehicle logs to dispute driver claims about Autopilot behaviour), to track stolen vehicles, and to train their Full Self-Driving (FSD) neural networks on real-world driving data.

The data flow is bidirectional. Tesla can push over-the-air software updates that change vehicle behaviour, enable or disable features, and adjust performance parameters. They can also remotely access the vehicle's cameras and sensors for diagnostic purposes. The vehicle is, in a very real sense, a connected device that the manufacturer can interact with at any time.

BMW operates the ConnectedDrive platform, which collects vehicle position, trip data, fuel/charge level, tyre pressure, diagnostic codes, and driving statistics. BMW's privacy policy for ConnectedDrive is more detailed than Tesla's and specifies retention periods for different data categories (typically 12 to 24 months for trip data). BMW vehicles with Remote Services enabled can be located, locked, unlocked, and have their climate control started remotely through the My BMW app, all of which implies continuous position tracking on the server side.

Mercedes-Benz operates Mercedes me connect, which collects similar telemetry. Mercedes has been more aggressive about monetising connected car data, offering third-party developers access to vehicle data through their Mercedes-Benz /developers platform (with the driver's consent, in theory). The data available through the API includes vehicle position, fuel level, tyre pressure, door lock status, and odometer reading.

Volkswagen Group (VW, Audi, SEAT, Skoda, Porsche) uses the Volkswagen We Connect / myAudi / SEAT CONNECT platforms. These collect trip data, parking position, vehicle health status, and in some cases detailed driving statistics. Volkswagen was caught in 2023 storing precise GPS coordinates of 800,000 electric vehicles on an unsecured Amazon cloud storage system, accessible to anyone who found the URL. The exposed data included trip start and end coordinates for vehicles across Europe, some of them linked to their owners' names and contact details.

The common thread is that every major manufacturer now operates a cloud platform that receives continuous telemetry from vehicles in the field. The data is used for remote diagnostics, predictive maintenance, over-the-air updates, usage analytics, and (increasingly) monetisation through data partnerships. The driver may or may not be aware of the scope of data collection, and opt-out mechanisms are often buried deep in infotainment menus or absent entirely. In some cases, core vehicle functionality (like remote start or stolen vehicle tracking) is tied to the telematics subscription, making it difficult to disable data collection without losing features the driver paid for.

TPMS: Your Tyres Are Broadcasting

Tyre Pressure Monitoring Systems (TPMS) have been mandatory in the EU since November 2014 (UN ECE Regulation No. 141). There are two types: indirect TPMS, which infers tyre pressure from wheel speed differences using the ABS sensors, and direct TPMS, which uses pressure sensors mounted inside each tyre. Direct TPMS is the more common type on modern vehicles, and it is the one with privacy implications.

Each direct TPMS sensor is a small battery-powered device mounted on the wheel rim inside the tyre. It contains a pressure sensor, a temperature sensor, a microcontroller, and a 315 MHz (in the US) or 433.92 MHz (in Europe) radio transmitter. The sensor transmits a short message every 30 to 60 seconds while the vehicle is moving (triggered by a centrifugal switch or accelerometer that detects wheel rotation). The message contains:

• A unique 32-bit sensor ID (assigned at manufacture and never changed)
• Current tyre pressure (typically in units of 0.25 kPa)
• Current tyre temperature
• A battery status flag
• A CRC or simple checksum

The transmission is unencrypted and unauthenticated on the vast majority of vehicles. The 32-bit sensor ID is a permanent, unique identifier that is broadcast over RF every minute while the vehicle is in motion. The signal can be received at distances of 10 metres or more with a simple SDR (Software Defined Radio) receiver, like an RTL-SDR dongle costing €25, and open-source software like rtl_433.

Researchers at Rutgers University (Ishtiaq Rouf et al., 2010) and at the University of South Carolina demonstrated that TPMS signals can be used to track specific vehicles. An attacker who records the TPMS sensor IDs of a target vehicle can then detect that vehicle's presence at any location by deploying receivers along roads or in parking areas. Because the sensor IDs are permanent and unique, and because the signals are transmitted continuously, TPMS effectively functions as a low-power vehicle tracking beacon that the driver cannot disable without physically removing the sensors from the tyres.

The practical exploitation scenario is not theoretical. In 2020, security researchers at the Technische Universitat Darmstadt showed that a network of cheap SDR receivers placed along major roads in Frankfurt could track individual vehicles by their TPMS signatures with high accuracy. The receivers cost less than €30 each, and the signal processing required to decode TPMS packets is trivial with open-source tools.

The vehicle's TPMS receiver (mounted in the wheel arch or integrated into the body control module) also stores the sensor IDs of the currently registered tyres in non-volatile memory. If the tyres are changed (for example, switching between summer and winter tyres, as is common across Scandinavia and central Europe), both sets of sensor IDs are stored. Forensic extraction of the TPMS module can reveal the sensor IDs of all tyres that have ever been registered to the vehicle, which can be cross-referenced with tyre shop records or with TPMS data captured at other locations.

Cameras: Inside And Out

Cameras have proliferated in modern vehicles. A typical 2024 model-year car has between 6 and 12 cameras: a rear-view camera (mandatory in the EU since 2022 for new type approvals under GSR2), surround-view cameras (four wide-angle cameras for a bird's-eye parking view), a driver-monitoring camera (increasingly common for ADAS compliance under Euro NCAP 2023+ protocols), and in some cases forward-facing cameras used for lane-keeping assist and traffic sign recognition.

Most of these cameras are "live" only: they stream video to the infotainment display or to an ADAS processor and do not record to persistent storage. But there are significant exceptions.

Tesla Sentry Mode is the most well-known example of persistent vehicle camera recording. When enabled, Sentry Mode uses Tesla's external cameras (front, rear, and side repeaters) to monitor the vehicle's surroundings while parked. If the system detects a significant event (someone touching the car, a nearby impact, glass breaking), it saves the preceding 10 minutes and the following 10 minutes of video from all cameras to a USB drive or the vehicle's internal storage. Tesla's Dashcam feature continuously records forward-facing video while driving, again to USB or internal storage. The video files include timestamps and GPS coordinates in the metadata.

Other manufacturers are following Tesla's lead. BMW's Drive Recorder (available on models with the Parking Assistant Professional option) records surround-view camera footage while driving and saves the last 40 seconds when the driver presses a button or when a parking incident is detected. Hyundai and Kia offer similar dashcam functionality integrated into the infotainment system on some models.

Interior cameras are a newer and more controversial data source. Tesla's cabin camera, positioned above the rear-view mirror, monitors driver attentiveness during Autopilot use. Tesla has stated that cabin camera footage is not uploaded to their servers unless the driver opts into data sharing, but the camera is always active when Autopilot is engaged, and the footage is stored locally on the MCU's flash. Driver-monitoring cameras on other vehicles (used for Euro NCAP compliance to detect drowsiness or distraction) typically process video in real time on an ADAS processor and do not store footage, but this is an implementation choice, not a technical limitation.

For forensic investigators, dashcam and Sentry Mode footage can be invaluable. In a case in Barcelona in 2022, Tesla Sentry Mode footage from a parked vehicle captured a hit-and-run incident, including the other vehicle's licence plate, leading to an arrest. In Stockholm, a parked Tesla's Sentry Mode recorded a burglary at a neighbouring property. The footage quality from Tesla's cameras (1280x960 pixels, 36 fps) is sufficient for licence plate recognition and facial identification at short range.

Forensic Extraction: How Investigators Read Your Car

Vehicle forensics is a specialised discipline that has grown rapidly since the mid-2010s. The primary commercial tool is Berla iVe (In-Vehicle Examination), developed by Berla Corporation. Berla iVe is a hardware and software platform that connects to a vehicle's infotainment system (either through the OBD-II port, through a direct connection to the head unit's JTAG or serial port, or through chip-off extraction of the flash storage) and extracts, decodes, and presents the stored data.

Berla iVe supports over 14,000 vehicle system images across dozens of manufacturers and model years. The tool can extract:

• Navigation history (destinations, searches, favourites, breadcrumb trails)
• Bluetooth pairing records (MAC addresses, device names, pairing timestamps)
• Call logs and contact lists (synchronised from paired phones)
• SMS messages (synchronised via Bluetooth MAP)
• Wi-Fi connection history
• USB device history (serial numbers, volume names, file listings)
• Media playback history
• User account data (email addresses, app logins)
• Vehicle event logs (door open/close, ignition on/off, with timestamps)
• GPS coordinates with timestamps

The extraction process depends on the vehicle. For some vehicles, Berla iVe can perform a "logical extraction" through the OBD-II port or a diagnostic connection, requesting data through the vehicle's own diagnostic protocols. For others, a "physical extraction" is required: removing the infotainment head unit from the vehicle, opening the housing, and either connecting to a JTAG/debug port on the circuit board or desoldering the eMMC/NAND flash chip and reading it with a chip programmer. Physical extraction yields more data (including deleted files and unallocated space) but is more invasive and time-consuming.

The Bosch CDR tool, mentioned earlier, handles EDR data specifically. It connects through the OBD-II port and extracts crash data from the airbag module. CDR reports are widely accepted in European and American courts as evidence.

Cellebrite UFED, primarily known as a mobile phone forensic tool, also supports some vehicle infotainment systems, particularly those based on Android Automotive or QNX. The extraction methodology is similar: connect to the head unit's debug interface and image the flash storage.

A forensic examiner named Elena, presenting at a conference in Amsterdam in 2023, demonstrated a full extraction from a 2022 Volkswagen Golf's MIB3 infotainment system. The extraction recovered three years of navigation history (including 847 unique destinations), 12 paired Bluetooth devices with full contact lists totalling over 6,000 contacts, 2,300 call log entries, 340 SMS messages, and a GPS breadcrumb trail with over 50,000 position records. The vehicle's owner had performed a "factory reset" six months before the extraction. Nearly all of the data was still present in the flash storage, because the reset had only cleared the file system metadata without erasing the underlying NAND pages.

This is the same problem that exists with smartphone forensics (and with SSDs, as discussed in other articles on this site): flash storage does not overwrite data in place. When a file is "deleted," the file system marks the logical blocks as free, but the physical NAND pages retain their contents until the flash controller erases them as part of its wear-levelling and garbage collection processes. On a lightly-used infotainment system, where the flash is far from full and write activity is moderate, deleted data can persist for months or years.

Why "Factory Reset" Does Not Work

The persistence of data after a factory reset deserves its own section because it is so widely misunderstood. Drivers, rental car companies, and used car dealers all assume that performing a factory reset through the infotainment menu erases all personal data. It does not.

A factory reset on a vehicle infotainment system typically does the following:

1. Resets user preferences (display language, seat memory, climate settings) to default values
2. Deletes user accounts and login tokens
3. Removes paired Bluetooth devices from the active pairing list
4. Clears the navigation history and favourites from the file system
5. Resets the home screen layout and app configuration

What it does not do:

1. Securely erase the flash storage (overwriting every page with zeros or random data)
2. Issue an eMMC TRIM or Secure Erase command to the flash controller
3. Clear data stored by ECUs other than the infotainment head unit (the airbag module, TPMS module, telematics module, and other ECUs all retain their data independently)
4. Remove data already uploaded to the manufacturer's cloud platform

The technical reason is identical to why a smartphone's "factory reset" did not securely erase data on older Android and iOS devices: the reset is a logical operation on the file system, not a physical operation on the storage medium. The infotainment operating system deletes files and reinitialises databases, but the underlying eMMC or UFS flash chip still contains the previous data in its physical pages. Only a full block erase, performed by the flash controller as part of garbage collection or by an explicit Secure Erase command, actually destroys the data at the physical level.

Some manufacturers have improved their reset procedures in response to privacy concerns. Tesla's MCU2 and MCU3 systems (since approximately late 2023) perform a more thorough erase during factory reset, issuing Secure Erase commands to the eMMC. BMW's newer iDrive systems (ID8 and later) include a "Delete Personal Data" function that attempts to clear data from multiple ECUs, not just the infotainment head unit. But these are exceptions. The majority of vehicles on the road today, including current model-year vehicles from many manufacturers, perform a superficial reset that leaves most data recoverable through forensic extraction.

For anyone selling or returning a vehicle (or returning a rental car), the practical implication is stark: the next person to use that vehicle, or any forensic examiner who accesses it, can potentially recover your navigation history, phone contacts, call logs, text messages, Wi-Fi passwords, and Bluetooth pairing records. The data may be months or years old, and you may have believed it was deleted.

The Rental Car Problem

Rental cars are a concentrated version of every privacy issue discussed in this article. A rental car that has been in service for two years may have been driven by hundreds of different people, each of whom paired their phone, entered navigation destinations, connected to Wi-Fi networks, and made calls through the hands-free system. All of that data accumulates in the infotainment system's flash storage.

Maria, a security researcher based in Helsinki, published a study in 2024 in which she rented 15 vehicles from major rental companies across five European countries (Finland, Germany, Spain, France, and the Netherlands). Using nothing more than the vehicles' own infotainment interfaces (no forensic tools, no physical extraction), she was able to access the following data left by previous renters:

• Paired Bluetooth device names and MAC addresses (found in 14 of 15 vehicles)
• Previous navigation destinations with addresses (found in 12 of 15 vehicles)
• Synchronised contact lists from previous renters' phones (found in 8 of 15 vehicles)
• Call logs from previous renters (found in 6 of 15 vehicles)
• Saved Wi-Fi networks with passwords (found in 4 of 15 vehicles)
• Home and work addresses set as favourites by previous renters (found in 9 of 15 vehicles)

None of this required any special tools or expertise. The data was accessible through the normal infotainment menu. The rental companies had not cleared the previous renters' data between rentals. When Maria contacted the five rental companies, three responded that they "encourage customers to delete their personal data before returning the vehicle" (placing the burden on the renter), one said they were "investigating improved processes," and one did not respond.

The problem goes beyond convenience or embarrassment. A previous renter's home address, contact list, and workplace are sufficient information for stalking, social engineering, or targeted theft. If Yannis rents a car in Amsterdam, navigates to his home address, and pairs his phone, the next renter can see his full name (from the Bluetooth device name), his home address (from navigation favourites), his workplace (if set as a favourite), and his phone number and contact list (if synced via PBAP). That is an extraordinary amount of personal information to hand to a stranger.

Rental fleet management systems add another layer. Most rental companies install GPS tracking devices in their vehicles (separate from the manufacturer's telematics) to monitor fleet utilisation, enforce geofences (preventing vehicles from leaving certain areas or crossing borders), and recover stolen vehicles. These systems maintain a complete GPS history for every vehicle in the fleet, accessible to the rental company and, through legal process, to law enforcement.

Real Cases: When Car Data Solved Crimes

Vehicle data has been used as evidence in criminal and civil cases across Europe and North America with increasing frequency since the mid-2010s. Several cases illustrate the breadth of data sources and their forensic value.

The Chris Burgan case (UK, 2019): Burgan was convicted of causing death by dangerous driving after his Ford Fiesta's EDR data showed he was travelling at 137 km/h in an 80 km/h zone at the moment of impact. Burgan had claimed he was doing "about 80." The EDR data, extracted using the Bosch CDR tool, recorded his speed at half-second intervals for the five seconds before the crash, showing a sustained 137 km/h with no braking until 0.5 seconds before impact. The EDR data was accepted as evidence and was a central factor in the conviction.

The James Bates case (US, 2017): While this case is primarily known for the Amazon Alexa subpoena, vehicle forensics played a role. Investigators extracted data from a vehicle's infotainment system using Berla iVe, recovering navigation history and Bluetooth pairing records that helped establish a timeline of the suspect's movements on the night in question.

Telematics in insurance fraud (Italy, ongoing): Italian insurers routinely use telematics black box data to detect staged accidents. In one documented case from Naples in 2022, an insurer's telematics data showed that two vehicles allegedly involved in a collision were never within 500 metres of each other at the claimed time and location. The GPS tracks from both vehicles' insurance dongles were presented as evidence, and the claim was rejected as fraudulent. The insurer estimated that telematics data had helped identify over €12 million in fraudulent claims in the preceding year.

Tesla Autopilot disputes (multiple jurisdictions): Tesla has repeatedly used vehicle telemetry data to dispute claims about Autopilot-related crashes. When a driver claims that Autopilot was engaged and malfunctioned, Tesla can (and does) release the vehicle's log data showing whether Autopilot was actually engaged, whether the driver's hands were on the steering wheel, how fast the vehicle was travelling, and whether the driver applied the brakes. This data has been used in both Tesla's defence and in lawsuits against Tesla, depending on what it shows.

The Volkert van der Graaf case (Netherlands, reconstruction): In reconstructing historical cases for cold case reviews, Dutch investigators have used vehicle forensic data from impounded vehicles to establish timelines and connections. Navigation history, Bluetooth records, and toll payment data (from on-board toll transponders) have been combined to build detailed movement profiles.

The Volkswagen data leak (Germany, 2023): While not a criminal case, the exposure of 800,000 Volkswagen Group electric vehicles' GPS data on an unsecured Amazon S3 bucket demonstrated the scale of manufacturer data collection. The exposed data included precise location coordinates for trips made by VW, Audi, SEAT, and Skoda vehicles, some linked to owner identities. The German magazine Der Spiegel, working with the Chaos Computer Club, reported that the data could be used to track individual vehicles to their owners' homes, workplaces, and other frequently visited locations.

Privacy: Who Owns This Data?

The question of who owns vehicle data, and who can access it, is one of the most contested issues in European data protection law. The EU General Data Protection Regulation (GDPR) applies to connected car data because GPS coordinates, Bluetooth MAC addresses, navigation history, and telematics data are all personal data (they relate to an identified or identifiable natural person, namely the vehicle's registered keeper or regular driver).

Under GDPR, the vehicle manufacturer (as the entity that collects and processes telematics data through its connected car platform) is a data controller and must comply with Articles 5 through 9: lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. The legal basis for processing is typically consent (the driver agrees to the telematics terms of service) or legitimate interest (the manufacturer claims a legitimate interest in collecting diagnostic data for safety and product improvement).

The problem is that consent in the automotive context is often not freely given. If disabling telematics means losing features like remote start, stolen vehicle tracking, over-the-air updates, or even basic navigation (on some systems), the driver faces a take-it-or-leave-it choice that European data protection authorities have questioned. The European Data Protection Board (EDPB) issued guidelines in 2020 (Guidelines 1/2020 on processing personal data in the context of connected vehicles) stating that vehicle manufacturers should provide granular consent options, allow drivers to disable data collection without losing unrelated functionality, and ensure that data processing is proportionate to the stated purpose.

In practice, compliance varies. Some manufacturers offer relatively granular controls (BMW allows users to disable specific data categories in ConnectedDrive settings). Others provide only a binary opt-in/opt-out for the entire telematics service. And the data that ECUs record locally (navigation history, Bluetooth records, EDR data, TPMS IDs) is not covered by the telematics consent at all, because it is stored on the vehicle, not transmitted to the manufacturer. The legal question of who can access locally stored vehicle data is governed by a mix of property law (the vehicle owner owns the physical hardware), contract law (the manufacturer may claim intellectual property rights over the software and data formats), and criminal procedure (law enforcement can seize and extract vehicle data with appropriate legal authority).

The EU Data Act (Regulation 2023/2854), which entered into force in September 2025, introduces new rules specifically addressing connected product data, including vehicle data. The Data Act gives users (vehicle owners) the right to access data generated by their connected products and to share that data with third parties. This is intended to break the manufacturer's monopoly on vehicle data and enable independent repair shops, insurance companies, and other third parties to access vehicle data with the owner's consent. The automotive industry lobbied heavily against the Data Act, arguing that unrestricted access to vehicle data could compromise safety and security. The final regulation includes safeguards (data holders can refuse access if it would compromise safety), but the direction of travel is clear: EU law is moving toward giving vehicle owners more control over the data their cars generate.

The right to erasure (GDPR Article 17) theoretically gives drivers the right to request deletion of their personal data from the manufacturer's servers. In practice, exercising this right for vehicle data is complicated. The data is spread across multiple systems (the vehicle itself, the manufacturer's cloud, the dealer's diagnostic records, the insurer's telematics platform, any fleet management system), and there is no single "delete" button that reaches all of them. A GDPR erasure request to the manufacturer might clear the cloud data but does nothing to the data stored locally on the vehicle's infotainment system or in other ECUs.

What You Can Actually Do

Given the breadth and depth of vehicle data collection, a reasonable question is: what can a privacy-conscious driver actually do to limit exposure? The honest answer is: less than you would like, but more than nothing.

Before selling or returning a vehicle:

1. Perform a factory reset through the infotainment menu. This is imperfect (as discussed above) but clears the most easily accessible data.
2. Delete all paired Bluetooth devices individually before performing the factory reset. On some systems, the individual deletion is more thorough than the bulk reset.
3. Clear the navigation history, favourites, and recent destinations individually.
4. Sign out of all accounts (Spotify, Google, Apple, manufacturer account) and revoke the vehicle's access to those accounts from the account provider's side.
5. Remove any USB drives, SD cards, or other removable storage.
6. If the vehicle has a manufacturer telematics subscription, contact the manufacturer to deregister the vehicle from your account and request deletion of stored telematics data.

During ownership:

1. Avoid pairing your phone's contacts and call logs if you do not need hands-free calling through the car. Most Bluetooth pairing processes ask for contact access permission; deny it.
2. Use a smartphone-based navigation app (Google Maps, Waze, or similar through Apple CarPlay or Android Auto) instead of the built-in navigation system. CarPlay and Android Auto are designed to keep most data on the phone rather than syncing it to the head unit, though some metadata (connection times, app usage) is still logged by the vehicle.
3. Review the manufacturer's telematics settings and disable data sharing where possible. On Tesla, this is in Settings > Safety > Data Sharing. On BMW, in ConnectedDrive settings. On Volkswagen, in the privacy settings of the We Connect app.
4. Be aware that OBD-II dongles (insurance telematics, aftermarket diagnostics, performance tuners) record and transmit vehicle data. Read the privacy policy before plugging one in.

For rental cars:

1. Do not pair your phone via Bluetooth. Use a wired CarPlay or Android Auto connection if available (which still leaves less data than Bluetooth pairing), or use your phone's speaker for calls and its screen for navigation.
2. If you do pair your phone, delete the pairing before returning the vehicle.
3. Clear navigation history before returning the vehicle.
4. Do not connect to the vehicle's Wi-Fi or enter Wi-Fi passwords into the infotainment system.

None of these measures are complete. The CAN bus still logs vehicle events. The EDR still records pre-crash data. The TPMS still broadcasts sensor IDs. The eCall hardware still tracks position. The manufacturer's telematics system may still collect data regardless of the settings you change, depending on the jurisdiction and the manufacturer. But the measures above reduce the most accessible and most voluminous data sources, which are the ones most likely to be accessed by the next driver, a casual snoop, or a low-effort forensic examination.

The automotive industry is slowly moving toward better privacy practices, driven partly by regulation (GDPR, the EU Data Act, the upcoming EU Cyber Resilience Act) and partly by public pressure. But the fundamental tension remains: modern vehicles generate enormous volumes of data as a byproduct of their normal operation, and much of that data has commercial value (to manufacturers, insurers, and data brokers) and forensic value (to law enforcement and investigators). The technical architecture of the vehicle, with dozens of independent ECUs each maintaining their own non-volatile storage, makes comprehensive data erasure genuinely difficult even when the will to erase exists.

Your car knows where you have been. It knows who was with you. It knows how fast you were driving, whether you braked, and what music you were listening to. It broadcasts a unique radio signature from its tyres, phones home to its manufacturer over cellular, and stores years of personal data in flash memory that survives a factory reset. This is not a design flaw or a conspiracy; it is the natural consequence of building a vehicle with 150 networked computers, each doing its job, each keeping its own records, and none of them designed with data minimisation as a priority.

The question for drivers, regulators, and manufacturers is not whether cars collect this data. They do, and they will continue to do so as vehicles become more connected, more automated, and more dependent on software. The question is who gets to access it, for how long, and under what conditions. The answers to those questions are still being written, in legislation, in court decisions, and in the privacy settings menus that most drivers never open.