# Autonomous Vehicle Cybersecurity
Autonomous vehicle (AV) cybersecurity addresses the security of self-driving and connected vehicles, with a particular focus on the intersection of cyber vulnerabilities and physical safety consequences. Unlike most IT security domains where a successful attack leads to data loss, financial fraud, or service disruption, a successful attack against a vehicle in motion can result in loss of physical control with direct implications for human life. This safety-critical dimension distinguishes AV cybersecurity from conventional IT security and places it closer in character to industrial control system security.
The term "connected vehicle" refers to any modern vehicle with wireless communication capabilities, whether or not it has autonomous driving features. Virtually all new vehicles sold in major markets today are connected vehicles, capable of communicating via cellular networks (telematics), Bluetooth (mobile device pairing), and in some cases Wi-Fi. Autonomous driving adds layers of complexity: the vehicle must now process sensor data, execute driving decisions, and respond to external inputs without a human in the loop to recognize anomalous behavior.
The 2015 Jeep Cherokee demonstration by security researchers Charlie Miller and Chris Valasek established that connected vehicle vulnerabilities are not theoretical. Their remote exploit chain gave them control of a Jeep Cherokee's steering and brakes while the vehicle was on a highway, leading to a recall of approximately 1.4 million Chrysler vehicles. The research changed how the automotive industry, regulators, and the security community understood the vehicle attack surface.
Modern vehicles are controlled by dozens to over 100 Electronic Control Units (ECUs), each responsible for a specific vehicle function: engine management, anti-lock braking, power steering, airbag deployment, infotainment, telematics, and others. These ECUs communicate over internal networks, the most pervasive of which is the Controller Area Network (CAN bus), a standard developed in 1986 by Bosch originally for industrial automation and adapted for automotive use.
CAN bus architecture has a fundamental design limitation from a security perspective: it was designed as an isolated in-vehicle network with no concept of authentication. Any node on the CAN bus can broadcast messages to all other nodes, and there is no mechanism in the base protocol to verify that a message came from the expected source. An ECU receiving a brake command cannot confirm whether it came from the brake controller or from a compromised infotainment unit that has gained access to the bus. This authentication gap is the root cause of many automotive security vulnerabilities.
The Miller and Valasek attack exploited a chain of vulnerabilities: they gained initial access through Chrysler's Uconnect cellular interface (the vehicle's telematics head unit, internet-connected and running a compromised version of the QNX operating system), escalated privileges to reach the D-Bus communication layer, and then moved laterally to the CAN bus from the infotainment system. Once on the CAN bus, they could inject commands to any ECU on the network. The attack was fully remote and required no physical access to the vehicle.
For autonomous vehicles, sensor inputs to the driving decision system become additional attack surfaces. LiDAR spoofing involves introducing false objects into the LiDAR point cloud (using targeted laser pulses to create phantom obstacles that the vehicle's perception system interprets as real) or removing real objects from the point cloud (creating sensor blind spots). Adversarial examples for camera systems involve physical modifications to road signs (stickers, patterns) that human eyes read correctly but that the computer vision model misclassifies. A stop sign modified with a specific high-contrast patch can be reliably classified as a speed limit sign by certain vision models. GPS spoofing manipulates the vehicle's navigation by feeding false positioning signals.
The scale of deployment makes automotive cybersecurity a systemic concern. There are approximately 1.4 billion vehicles in operation globally, and virtually all new production vehicles include connectivity features. If a significant fraction of those vehicles share a common vulnerability in a connected platform (as Chrysler vehicles shared the Uconnect vulnerability), a single exploit could affect millions of vehicles simultaneously.
The over-the-air (OTA) update capability that Tesla pioneered and other manufacturers have since adopted creates both a security strength and a risk. The strength: manufacturers can push security patches to the entire vehicle fleet without requiring owners to visit a dealership, dramatically reducing the time from vulnerability discovery to remediation. The risk: if the OTA update mechanism is compromised, it becomes a vehicle-wide remote code execution vector at scale. An attacker who can inject a malicious OTA update into a manufacturer's update distribution chain can potentially reach the entire fleet.
Vehicle-to-Everything (V2X) communication, where vehicles communicate with each other (V2V) and with infrastructure (V2I) to improve safety and traffic flow, adds another communication channel to the attack surface. DSRC (Dedicated Short-Range Communications) and Cellular V2X (C-V2X) protocols both include certificate-based authentication designed to prevent injection of false messages. However, the public key infrastructure required to support V2X certificate management at scale is still being deployed. Until that infrastructure is mature, the security guarantees of V2X authentication are not fully operational in most markets.
The liability dimension is significant. A cyberattack that causes a vehicle crash creates complex liability questions spanning the vehicle manufacturer, the software vendor, the network provider, and potentially the operator of any compromised infrastructure. Legal frameworks for autonomous vehicle liability are still evolving in most jurisdictions.
The automotive security research community has developed a body of attack taxonomy for connected vehicles. The attack surface includes: Bluetooth interfaces (pairing vulnerabilities, man-in-the-middle attacks during pairing), cellular telematics units (the broadest remote attack surface, often running full operating systems with internet connectivity), Wi-Fi interfaces where present, OBD-II diagnostic ports (physical access required, but represent a direct CAN bus interface), USB ports in infotainment systems, and the OTA update mechanism.
Defenses against CAN bus exploitation include: network segmentation (implementing gateways between vehicle network segments that filter traffic by expected message type and source, preventing lateral movement from infotainment to safety-critical ECUs), CAN bus intrusion detection systems (monitoring for anomalous message patterns that could indicate injection), and message authentication codes (MAC) applied to CAN messages (an extension to the base protocol that enables sender authentication, supported in CAN FD implementations and being retrofitted in some vehicle platforms).
UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) adopted Regulation No. 155 in 2021, requiring that vehicles sold in the European Union, Japan, and South Korea implement a Cybersecurity Management System (CSMS) as a condition of type approval. This regulation, effective for new vehicle types from July 2022 and all new vehicles from July 2024, mandates that manufacturers identify and manage cyber risks throughout the vehicle lifecycle, including post-sale monitoring and incident response. It is the most significant automotive cybersecurity regulation currently in force.
ISO/SAE 21434 (Road Vehicle Cybersecurity Engineering, published 2021) provides the technical standard underlying the CSMS requirement. It defines a threat analysis and risk assessment (TARA) methodology for automotive development, parallel in concept to STRIDE/DREAD threat modeling used in enterprise software.
Software-defined radio vulnerabilities apply to vehicles that use SDR-based components (particularly keyless entry systems operating on 433 MHz or 315 MHz). Relay attacks (amplifying the key fob signal to unlock a vehicle from a distance) and replay attacks (capturing and replaying the unlock signal) remain practical against vehicles without rolling code implementations.
Within the SPH domain, CDA's Autonomous Posture Command (APC) methodology applies to organizations that operate vehicle fleets as part of their physical security posture and operational infrastructure. For enterprise fleets, autonomous shuttles, and logistics operators, the connected vehicle attack surface must be inventoried and managed as part of the overall security posture program. This includes: maintaining an inventory of vehicle platforms and their connected features, tracking manufacturer security advisories and OTA update status across the fleet, and establishing policies for OBD-II port access and third-party telematics devices that plug into that interface.
Within the VSD domain, Continuous Surface Reduction (CSR) applies to minimizing the connectivity footprint of fleet vehicles where operational requirements permit. Fleet operators who do not require certain wireless features can often configure vehicle head units to disable Wi-Fi hotspot functionality or restrict Bluetooth pairing. Third-party telematics devices (insurance company dongles, fleet management OBD-II dongles) that plug directly into the CAN bus interface represent an added attack surface that should be evaluated against the operational benefit.
The safety-critical dimension of automotive security creates unique liability considerations for CDA's RGA clients in fleet management, logistics, and transportation. The intersection of UNECE WP.29 compliance for vehicle manufacturers and emerging regulatory frameworks for autonomous vehicle operators means the governance and compliance dimension of automotive cybersecurity will expand significantly through the late 2020s. Organizations operating autonomous vehicles in commercial service should anticipate regulatory requirements modeled on the WP.29 CSMS framework.