Automotive Cybersecurity: Connected Vehicle Protection

The Connected Vehicle Attack Surface

A modern vehicle contains anywhere from 30 to over 100 electronic control units (ECUs) governing the engine or motor, braking, steering, transmission, body electronics, infotainment, advanced driver assistance and more. These ECUs communicate over in-vehicle networks (Controller Area Network or CAN, CAN FD, LIN, FlexRay and increasingly Automotive Ethernet). On top of this sits a connectivity layer: the telematics control unit with cellular and sometimes satellite links, Bluetooth and Wi-Fi for device pairing, the key fob radio interface, the OBD-II diagnostic port, and the over-the-air update pipeline.

Each of these interfaces is a potential entry point. Researchers have demonstrated remote compromise through cellular telematics, infotainment exploitation pivoting to the CAN bus, key-fob relay and rolling-code attacks, and malicious diagnostic tooling on the OBD-II port. The defensive challenge is that a vehicle is a long-lived product (10 to 15 years on the road) built from components sourced across a deep supplier chain, with limited ability to retrofit security after sale except through the OTA channel that is itself a sensitive asset.

Practical scoping for an automotive engagement therefore spans four planes: the in-vehicle networks and ECUs, the wireless and physical interfaces, the backend cloud (telematics platform, OTA server, fleet portal, mobile app API), and the production and development tooling (diagnostic tools, key provisioning, software signing infrastructure). A test that covers only the vehicle and ignores the backend misses where the highest-leverage attacks now live.

CAN Bus and ECU Security

The Controller Area Network is the workhorse of in-vehicle communication, and it was designed in an era when physical access to the bus was assumed to be the trust boundary. CAN frames carry no source authentication and no encryption by default. Any node on the bus can transmit any message, and receiving ECUs act on well-formed frames without verifying the sender. This means that once an attacker can inject frames (through a compromised ECU, a malicious OBD-II dongle, or a bridged infotainment unit), they can potentially trigger functions on other ECUs.

Defensive architecture has shifted toward domain isolation and a central gateway. Safety-critical ECUs (braking, steering, powertrain) are placed on segregated bus segments separated from comfort and infotainment functions. A gateway ECU mediates traffic between domains and enforces a message allowlist, dropping frames that should never cross a boundary. Where the platform supports it, message authentication (for example AUTOSAR SecOC, which adds a truncated MAC and freshness counter to selected frames) raises the bar against injection on the most sensitive signals.

At the ECU level, the controls that matter are secure boot (the ECU verifies a signed firmware image before execution), hardware-backed key storage (a Hardware Security Module or secure element rather than keys in flash), authenticated diagnostic access (UDS security access using strong challenge-response rather than fixed seeds), and debug-interface lockdown (JTAG and SWD disabled or authenticated in production units). Codesecure ECU assessments combine firmware extraction and analysis, fuzzing of diagnostic and communication interfaces, and review of the secure-boot and key-management chain.

Telematics and Backend Cloud Security

The telematics control unit (TCU) is the vehicle's gateway to the outside world. It connects the car to the OEM cloud for remote services (remote lock and unlock, location, climate preconditioning, charge management, stolen-vehicle tracking, usage-based insurance telemetry) and frequently serves as the conduit for OTA updates. Because the TCU bridges the cellular network and the in-vehicle bus, a TCU compromise is among the highest-impact outcomes in vehicle security.

On the backend, the telematics platform exposes APIs to vehicles, to mobile apps, to fleet portals and to partner integrations (insurers, charging networks, dealers). The recurring API findings mirror the wider OWASP API Top 10. Broken Object Level Authorization is the standout: a vehicle identifier or account identifier substituted in an API call that returns another customer's vehicle data or accepts a remote command. We also routinely see weak device authentication (vehicles sharing a credential class rather than per-vehicle identity), over-permissive partner scopes, and remote-command endpoints without sufficient rate limiting or anomaly detection.

The defensive priorities are per-vehicle cryptographic identity (each vehicle authenticates with its own provisioned credentials, ideally hardware-bound), strict object-level authorization on every API that references a vehicle or account, mutual TLS between vehicle and backend, anomaly detection on remote commands (a single account issuing unlock commands to thousands of vehicles should trigger an alert), and a tested ability to revoke a compromised vehicle credential without bricking the car. Codesecure runs combined vehicle-plus-backend engagements so that the path from a single car to the whole fleet is explicitly tested.

Over-the-Air Update Security

Over-the-air updates are essential for a product that lives on the road for a decade. They are also a uniquely sensitive asset: the OTA pipeline can write new firmware to ECUs across an entire fleet, so a compromise of the signing infrastructure or the update server is close to a worst-case scenario. The threat model includes a malicious update pushed by an attacker who has compromised the backend, a tampered package delivered by a network-level adversary, a rollback to a known-vulnerable version, and a partial or interrupted update that leaves an ECU in an unsafe state.

Robust OTA design follows the principles popularised by frameworks such as Uptane: every update package is cryptographically signed, ECUs verify signatures before installation, version metadata prevents rollback to vulnerable firmware, signing keys are held in hardware and separated by role so that no single compromised key authorises a fleet-wide push, and the update process is atomic with a verified fallback so an interrupted flash does not strand the vehicle. The update server, the package repository and the key-management system are all in scope for assessment, not just the in-vehicle client.

EV Charging Infrastructure Security

Electric vehicles add an entirely new interface: the charging connection. This is both a power link and a data link. The vehicle and the charge point negotiate over protocols such as ISO 15118 (which enables Plug and Charge, where the vehicle authenticates and authorises billing automatically) and the communication between charge points and back-end management systems runs over the Open Charge Point Protocol (OCPP). Each protocol layer introduces attack surface that did not exist for combustion vehicles.

The risks span the full chain. At the connector, a malicious charge point could attempt to exploit the vehicle's charging controller or harvest the certificates used for Plug and Charge. At the charge-point level, weakly secured OCPP back-haul (unencrypted WebSocket connections, default credentials, no firmware signing on the charger) lets an attacker manipulate billing, disrupt availability, or pivot into the charge-point operator's network. At the grid-interaction level, large numbers of compromised chargers acting in concert raise availability and load-manipulation concerns for the operator.

Defensive priorities for charging include TLS and certificate validation on OCPP back-haul, hardened charge-point firmware with secure boot and signed updates, proper handling and isolation of ISO 15118 contract certificates, and segmentation so a compromised public charger cannot reach the operator's billing or management core. Codesecure assesses both the vehicle charging controller and the charge-point and back-end estate for operators deploying public and fleet charging.

ISO/SAE 21434 and UNECE WP.29 Compliance

Two pillars dominate automotive cybersecurity governance. ISO/SAE 21434 (Road vehicles, Cybersecurity engineering) defines a structured engineering process across the vehicle lifecycle: cybersecurity governance, risk assessment using Threat Analysis and Risk Assessment (TARA), security requirements, verification and validation, incident response, and end-of-support handling. It is the engineering backbone that demonstrates a manufacturer built security in rather than bolting it on.

UNECE WP.29 Regulation No. 155 (R155) and Regulation No. 156 (R156) turn this into a market-access requirement in adopting regions. R155 requires a certified Cyber Security Management System (CSMS) covering the organisation's processes for managing vehicle cyber risk across development, production and post-production. R156 requires a Software Update Management System (SUMS) governing how updates (including OTA) are managed safely. Type approval in WP.29 contracting parties depends on demonstrating these systems, which links cybersecurity directly to the ability to sell vehicles.

For suppliers and OEMs serving these markets, the practical programme combines TARA workshops on each system, security requirements traced into design and test, vehicle and component penetration testing as verification evidence, an incident response capability with a defined disclosure path, and the documentation set that supports CSMS and SUMS audits. Codesecure supports ISO/SAE 21434-aligned TARA, penetration testing as verification evidence, and CSMS and SUMS readiness, with reports structured to support type-approval and customer-audit needs.

Fleet Monitoring and Vehicle SOC

Building security in is necessary but not sufficient for a product that stays in the field for a decade against an evolving threat. The mature operating model adds a Vehicle Security Operations Centre (VSOC): continuous monitoring of vehicle and backend telemetry for signs of attack, a process to triage and respond to in-field incidents, and a feedback loop into engineering and the OTA pipeline so that a discovered vulnerability can be patched across the fleet.

Practical VSOC scope includes anomaly detection on in-vehicle network behaviour (where an intrusion detection system is deployed on the gateway), monitoring of backend API abuse and remote-command anomalies, threat intelligence on automotive-specific vulnerabilities and exploits, a coordinated vulnerability disclosure programme so external researchers have a responsible reporting path, and tested incident response runbooks that account for the safety dimension (a security response must never itself create an unsafe vehicle state). For fleet operators (logistics, ride-hailing, leasing, public transport) the same monitoring extends to the operator's fleet portal and the integrations that connect it to dispatch, maintenance and billing. Codesecure helps OEMs and fleet operators stand up VSOC capability and run the disclosure and response processes that WP.29 and ISO/SAE 21434 expect.