The Black Box of a Car: What It Remembers, What Forensics Can Tell Us
CyberPeace | Automotive Cybersecurity & Digital Forensics
Introduction
After a crash, the story usually comes from the driver, a witness or a police report. But a modern vehicle can leave another version behind - a digital one. An Event Data Recorder (EDR), commonly called a car's black box, can preserve selected information from the seconds around a crash. NHTSA describes EDRs as recording vehicle dynamics, driver inputs, crash characteristics, restraint status and some post-crash information.[1] The exact fields depend on the vehicle. A black box is not a magical device that records everything; it is one evidence source inside a much larger vehicle.
A modern vehicle can also contain safety controllers, diagnostic interfaces, ADAS, telematics and software-update systems. For an investigator, the question is what evidence can be linked to the EDR and what that combined record can actually support.
What Is Actually in the Black Box?

An EDR is best understood as a short event record, not a continuous driving diary. Depending on the vehicle and its configuration, forensic extraction may reveal items such as speed, acceleration, delta-V, engine RPM, throttle position, brake status, steering input, ABS or stability-control activity, seat-belt status and airbag or restraint events. NHTSA's published EDR material shows that data elements can include longitudinal and lateral acceleration, delta-V, vehicle speed, engine speed, throttle, service-brake status, roll/pitch/yaw information and steering input.[2] Do not overread the data: A field that exists in one model should not automatically be assumed to exist in another. A forensic report must identify exactly which module and fields were available and actually recovered.
What Can a Forensic Examination Recover?

A Brake Failure Example
Consider a driver who reports: “I pressed the brake, but nothing happened.” The statement should be preserved, but a forensic investigation should test it. Was brake status captured? What was the speed before the event? Did ABS activate? What were the acceleration and delta-V patterns? Were there relevant fault codes? Was the vehicle recently repaired or updated? Suppose the recovered records show a brake input, ABS activity and a change in vehicle speed before impact. That does not prove the brakes were mechanically perfect. It does, however, make the sentence “nothing happened” too simple. Conversely, a relevant fault appearing just before the event may give investigators a stronger lead. The important part is the comparison: human account, vehicle record, physical evidence and technical history should be examined together.
Smart Vehicles, Digital Evidence and Cybersecurity Investigation
A connected vehicle can communicate through cellular networks, Bluetooth, Wi-Fi, mobile applications, workshop tools and cloud services. If unusual activity appears around a safety-critical incident, investigators may need to look beyond the EDR. Useful questions include:
• Was there unusual diagnostic or service activity before the incident?
• Was a software update or configuration change recently applied?
• Do timestamps from different modules line up, or is there clock drift?
• Can the extracted record be tied back to the original vehicle and module?
• Is there a non-cyber explanation - such as a hardware fault or software defect - that fits the evidence better?
The mindset matters: A cyberattack should be a conclusion supported by evidence, not the default explanation for strange vehicle behaviour.
The Forensic View: From Data to Evidence

Automotive forensics is not simply plugging in a tool and exporting a report. The investigator should document the vehicle identity, module involved, extraction method, tool version, acquisition time and evidence-preservation steps. The goal is to make the work repeatable and defensible.
• Identify the relevant modules and evidence sources.
• Preserve the vehicle and extracted data against unnecessary alteration.
• Acquire data using a documented and appropriate method.
• Validate provenance, integrity, timestamps and completeness.
• Correlate EDR, diagnostics, software history, connected records and physical evidence.
• Report both findings and uncertainty.
A useful forensic rule: “Recorded” does not mean “proven.” Evidence becomes persuasive when its source, integrity and context are clear.
What the Law and Standards Are Changing
India is moving toward a more formal automotive cybersecurity lifecycle. IS-189 focuses on vehicle cybersecurity and the Cyber Security Management System (CSMS), while AIS-190 deals with software updates and the Software Update Management System (SUMS).[4][5] The wider statutory and type-approval framework is provided by the Motor Vehicles Act, 1988 and the Central Motor Vehicles Rules, 1989. For vehicle prototypes, Rule 126 provides for testing and approval by authorized testing agencies.[6][7]
In June 2026, the Ministry of Road Transport and Highways (MoRTH) came out with draft G.S.R. 503(E). The draft proposes new CMVR Rules 125-T and 125-U covering cybersecurity and software-update requirements. Since G.S.R. 503(E) is still a draft notification, its proposed requirements and the dates from which they may apply should be verified with the latest final notification before treating them as applicable law.[8]
At the international level, UN Regulation No. 155 addresses vehicle cybersecurity, while UN Regulation No. 156 covers software updates and their management.[9][10] This matters to forensics because lifecycle cybersecurity creates an expectation that manufacturers should be able to understand and manage security risks over time. In other words, logs, software-state information, vulnerability records and incident evidence can become part of the security story, not merely post-incident paperwork.
The Real Takeaway
The black box is valuable because it can reduce guesswork. It may tell us how fast the vehicle was moving, whether the driver applied the brake, how the vehicle responded, and what certain safety systems were doing around the event. But it rarely answers the whole case on its own. The strongest investigation is built by joining several pieces: EDR data, diagnostics, software context, connected-system evidence and what was found at the crash scene.
For cybersecurity professionals, the lesson is simple: a secure vehicle should not only resist attacks. It should also leave trustworthy evidence when something goes wrong. Good access controls, reliable timestamps and careful evidence handling help turn “something failed” into a defensible explanation.
Conclusion
The phrase “car black box” sounds simple, but the evidence behind it is not. An EDR can preserve a small but valuable window into a crash. During forensic examination, investigators may also be able to recover diagnostic, safety-system, software and connected-vehicle information, depending on the vehicle and what has been retained. The job is not to collect the largest possible amount of data. It is to collect the right data, preserve it properly and understand what each record can - and cannot - prove.
That is where automotive cybersecurity and digital forensics meet. As vehicles become more connected and software-driven, the ability to reconstruct an incident becomes part of security itself.
References
1. National Highway Traffic Safety Administration (NHTSA), Event Data Recorder (EDR) overview and research resources.
2. NHTSA, Use of Event Data Recorder (EDR) Technology for Highway Crash Data Analysis.
3. NHTSA, Light-Vehicle Event Data Recorder Technologies Update.
4. Automotive Research Association of India (ARAI), AIS-189, Approval of Vehicles with Regards to Cyber Security and Cyber Security Management System, April 2024.
5. Automotive Research Association of India (ARAI), AIS-190, Approval of Vehicles with Regards to Software Update and Software Update Management System, April 2024.
6. Government of India, Motor Vehicles Act, 1988.
7. Government of India, Central Motor Vehicles Rules, 1989, Rule 126.
8. Ministry of Road Transport and Highways, G.S.R. 503(E), 17 June 2026, draft Central Motor Vehicles (Amendment) Rules concerning cybersecurity and software updates.
9. UNECE, UN Regulation No. 155, Cyber Security and Cyber Security Management System.
10. UNECE, UN Regulation No. 156, Software Update and Software Update Management System.
11. NIST, SP 800-86, Guide to Integrating Forensic Techniques into Incident Response.


