Twenty years ago, a car’s electronics were a closed system. An ECU talked to other ECUs over a CAN bus that never left the vehicle, and the biggest security concern was someone jimmying a door lock. Today, a modern vehicle is a distributed network of 100+ microcontrollers, several of which — the telematics control unit (TCU), the infotainment head unit (IVI), the gateway — are directly reachable from the internet, from a paired phone, from a cellular modem, or from a charging station. The car didn’t get less complex. It got connected. And connectivity without commensurate security engineering is how you turn a convenience feature into an attack surface.
This isn’t a hypothetical concern. It’s showing up in the vulnerability data in real time.
The numbers are moving in the wrong direction
Automotive-specific vulnerability disclosures rose sharply through 2025 and into 2026. One industry tracker recorded 345 unique automotive vulnerabilities in Q2 2026 alone — a 30% jump from Q1 2026 and a 220% year-over-year increase from Q2 2025. High-severity findings more than doubled quarter over quarter. Ninety-four percent of those vulnerabilities required only low attack complexity to exploit, and in-vehicle and backend systems together accounted for over 96% of the targets researchers were finding issues in.
The specific findings are the more instructive part. Researchers have documented telematics units shipping with unencrypted GPS logs and hardcoded credentials, infotainment platforms that trusted firmware signed with publicly known test keys (allowing arbitrary code execution), and cloud backends for EV charging infrastructure that used weak identifier schemes with no authentication, enabling attackers to disable public chargers at fleet scale. None of these are exotic zero-days requiring nation-state resources — they’re the kind of defect that a basic secure-development lifecycle is designed to catch before a part ever ships.
Here’s the uncomfortable pattern: the vehicle’s most exposed systems — telematics, infotainment, connected backend services — are also frequently the ones with the least mature security engineering, because they were historically treated as consumer-electronics-adjacent rather than safety-adjacent. That distinction doesn’t hold anymore. A compromised IVI or TCU isn’t just a privacy or data problem; depending on the vehicle’s network architecture, it can be a pivot point toward chassis, powertrain, or ADAS domains.
Why embedded devices are a different problem than IT security
Security teams that come up through enterprise IT often assume the playbook transfers directly to embedded and vehicle systems. It mostly doesn’t, for a few structural reasons:
Lifecycle mismatch. A laptop gets replaced in three to five years. A vehicle stays on the road for ten to twenty. The microcontroller and RTOS choices made at program start have to remain defensible against threats that don’t exist yet at the time of design — and the OEM is still liable for the platform’s security posture a decade after SOP.
Resource constraints. Many embedded ECUs run on hardware with kilobytes, not gigabytes, of RAM, and no spare cycles for a heavyweight security stack. Cryptographic operations, secure boot chains, and intrusion detection all have to fit inside a real-time, safety-certified budget — you can’t just bolt on an EDR agent the way you would on a server fleet.
Supply chain depth. A single ECU can carry firmware and silicon from a Tier 1, a Tier 2 semiconductor vendor, and one or more third-party software libraries, each with its own patch cadence — or lack of one. An SBOM (software bill of materials) that stops at the Tier 1 boundary tells you very little about what’s actually running.
Physical and RF exposure. Unlike a data center asset, an embedded automotive device is physically accessible to anyone who buys or rents the vehicle, and several of its interfaces — cellular, Wi-Fi, Bluetooth, USB, OBD-II, V2X — are wireless or physically exposed by design. The attack surface isn’t hypothetical network diagram; it’s sitting in a driveway.
Safety consequence. In IT, a breach usually means data loss or downtime. In a vehicle, depending on what’s compromised and how deep the pivot goes, the consequence tier can include physical safety — which is why regulators, not just OEMs, have gotten involved.
The regulatory floor has been set — and it’s binding
This is no longer a “best practice” conversation. UN Regulation No. 155 requires vehicle manufacturers selling into UNECE-regulated markets to operate a certified Cybersecurity Management System (CSMS) covering the full vehicle lifecycle — from concept through decommissioning. UN R156 does the same for software update management, requiring a certified Software Update Management System (SUMS) for any vehicle capable of receiving OTA updates. Both are legally binding type-approval requirements in the EU and a growing list of other markets, not voluntary guidance.
ISO/SAE 21434 is the technical standard that operationalizes R155 — it defines the engineering process: threat analysis and risk assessment (TARA), cybersecurity goals and requirements derived from those risks, verification and validation activities, and incident response obligations that persist post-production. It’s formally voluntary, but in practice it’s how a CSMS gets demonstrated to a type-approval authority, so most Tier 1s and OEMs now treat it as a de facto requirement flowing down through contracts.
The practical effect for anyone building or integrating a telematics, IVI, or gateway module: cybersecurity has to be designed in at the requirements stage and carried through TARA, architecture, implementation, verification, and post-production monitoring — not retrofitted after a pen test finds the hardcoded credential.
What actually moves the needle
None of this requires reinventing security engineering — it requires applying discipline consistently, at every ECU that touches an external interface, and treating that discipline as a lifecycle commitment rather than a launch gate:
- Secure boot and verified firmware, with production signing keys that are never reused from test/debug builds, and a documented, protected chain of trust from the boot ROM up.
- Secure, authenticated OTA update pipelines (the SUMS requirement isn’t just paperwork — rollback protection and update authentication are what stop a compromised update server from becoming a fleet-wide compromise).
- Credential and key management that assumes physical access — no hardcoded secrets, no shared fleet-wide keys, hardware security modules or secure elements where the BOM allows it.
- Network segmentation inside the vehicle, so a compromised infotainment or telematics domain doesn’t have an unmediated path to safety-critical domains — gateway ECUs enforcing that boundary need to be treated as a primary security control, not a convenience router.
- TARA as a living document, revisited as new interfaces, suppliers, or connectivity features are added late in a program — not a one-time exercise closed out at the design freeze.
- SBOM visibility past the Tier 1 boundary, so a disclosed CVE in a third-party TCP/IP stack or RTOS component can actually be traced to which vehicles are affected.
- Post-production monitoring and incident response, because R155 doesn’t end at SOP — it requires the capability to detect, triage, and respond to vulnerabilities discovered after millions of units are already on the road.
The bottom line
The vulnerability data, the regulatory framework, and the incident history are all pointing at the same conclusion: embedded devices — and vehicles most visibly — have crossed the line from “hardware that happens to run software” to “networked endpoints that happen to also be hardware.” They need to be engineered, tested, and monitored with that reality in mind, from the first architecture review through the last OTA update the platform will ever receive. The organizations treating this as a compliance checkbox are going to keep showing up in next quarter’s vulnerability report. The ones treating it as core systems engineering are the ones that will still have customer trust — and a clean safety record — a decade from now.
Sources:
– Automotive Cybersecurity Standards: A 2026 Compliance Guide — Finite State
– Relationship between UN R155, UN R156 and ISO/SAE 21434 — Autocrypt
– 38 Statistics on Automotive Cybersecurity Breaches: A Q2 2026 Update — CyberSecStats
– 2026 Automotive Cybersecurity Report — Upstream
– Crossroads: VicOne 2026 Automotive Cybersecurity Report
– Driving into the Unknown: Investigating and Addressing Security Breaches in Vehicle Infotainment Systems — MDPI Sensors
