As cars transform into computers on wheels, they offer cutting-edge functionality but also open up to new cyber attacks.
Modern vehicles, both internal combustion engine (ICE) and electric vehicles (EVs), contain dozens of powerful electronic control units (ECU), multiple wireless interfaces (cellular modems, Bluetooth and Wi-Fi) and physical connection ports (EV charging ports, diagnostic interfaces, etc). Due to the numerous interconnected computerised sensors in a typical car, communication equipment, and high-speed network, it is more appropriate to think of the vehicle as a data centre on wheels.
Car connectivity with the external world brings tremendous convenience and features, but it also expands the attack surface that hackers and malicious actors can target. In this brief, we explore recent dynamics in automotive cybersecurity: from data-telemetry privacy concerns to high-profile vehicle hacks, and we examine whether today’s cars are prepared for specialised, add-on security modules (like insertable firewalls or monitoring agents). We compile key industry announcements, research findings, and expert insights to help craft an engaging, informative tech blog series on this topic.
The target audience is general IT and security specialists, as well as IT consumers. Our goal is to raise the general awareness and, as a result, help to protect our everyday essential service.
The car as the next cyber battleground
Modern vehicles rival laptops in complexity, but with far higher stakes. A typical 2025 model car may have 100+ million lines of code and dozens of networked components controlling everything from engine timing to door locks. Historically, these systems were isolated and used proprietary protocols (like the CAN bus) with minimal external connectivity. Today, however, connected cars integrate multiple external interfaces:
- Cellular & Wi-Fi: Many cars come with built-in 4G/5G modems for navigation, entertainment, telemetry, and emergency services. These create continuous links between the vehicle and cloud services.
- Bluetooth: Used for hands-free devices and media, but also a point of entry to the car’s infotainment system. A recent Bluetooth-related flaw called “PerfektBlue” exposed millions of cars (Mercedes-Benz, Volkswagen, Škoda) to remote hacking of their infotainment units, potentially enabling attackers to unlock doors or even access critical ECUs without physical contact.
- USB/OBD-II ports: The on-board diagnostics port (standard in all modern cars) allows mechanics – or any plugged-in device – to read data and even send commands on a car’s internal network. This has been abused by both researchers and criminals to inject CAN bus messages.
- EV Charging Interfaces: Electric vehicles increasingly rely on smart charging protocols to communicate with public and private charging stations. Standards like TLC (Tesla Charging Language), ISO 15118, and OCPP (Open Charge Point Protocol) enable features such as plug-and-charge, billing, and load balancing. However, these interfaces can also introduce vulnerabilities – from man-in-the-middle attacks during authentication to malicious firmware updates pushed via compromised chargers. The lack of a unified, secure integration layer across OEMs and charger networks creates blind spots in threat detection and patching.
- V2X and more: Emerging vehicle-to-everything communications, advanced driver assist systems with over-the-air updates, and other smart features further blur the line between vehicles and IoT devices.
The expanding attack surface has led to a surge in discovered vulnerabilities and exploits. Automotive-related software vulnerabilities hit an all-time high in 2024. Over 530 distinct security bugs were reported that year.
How did we end up with so many chips and sensors?
The evolution began with basic engine control units in the 1980s, followed by safety systems (ABS, airbags), infotainment, and eventually advanced driver assistance systems (ADAS). Each new feature brought its own sensors and microcontrollers. Instead of consolidating, manufacturers layered new modules on top of existing ones—leading to a fragmented, distributed architecture.
During the COVID-era chip shortage, many predicted that OEMs would accelerate the shift to zonal architectures—centralised hubs that replace dozens of standalone ECUs and sensors. But that transition has been slower than expected. Why?
- Legacy platforms are hard to re-engineer mid-cycle.
- Supplier ecosystems are deeply entrenched.
- Regulatory certification for new architectures is time-consuming.
As a result, most vehicles still operate with distributed sensor networks, each with its own firmware, communication protocol, and security posture. These figures vary by segment – premium EVs may exceed 150 sensors, while budget models remain closer to 80. The table below illustrates an explosive growth of number of onboard sensors
| Year | Estimated sensors per vehicle | Key drivers of growth |
|---|---|---|
| 1980 | ~5–10 | Basic engine sensors (e.g. oxygen, coolant temp); early electronic fuel injection |
| 1990 | ~15–25 | Introduction of ABS, airbag systems, and onboard diagnostics (OBD-I) |
| 2000 | ~30–50 | Expansion of OBD-II, emissions control, early infotainment, and basic ADAS (e.g. parking sensors) |
| 2010 | ~60–80 | Rise of telematics, Bluetooth, TPMS, and more advanced ADAS (lane assist, adaptive cruise) |
| 2020 | ~80–100 | Integration of radar, lidar (in premium models), camera systems, and V2X pilots |
| 2023 | ~110+ | Growth in cabin intelligence, biometric sensors, and environmental monitoring |
| 2025 | ~130–150+ | Software-defined vehicles, zonal architectures, and full-stack sensor fusion in EVs and autonomous platforms |
Software eats the car:
From real-time OS to Linux containers
For decades, cars were ruled by proprietary firmware and real-time operating systems (RTOS) designed for speed, determinism, and isolation. Each ECU (Electronic Control Unit) ran its own tightly scoped software, often written in C, with no concept of updates, containers, or virtualization. But that era is ending.
Today’s vehicles are evolving into software-defined platforms—more like mobile data centres than mechanical machines. And under the hood, they’re running technologies you’d expect to find in cloud infrastructure, not a chassis.
What’s Actually Inside a Modern Infotainment System?
Infotainment updates from OEMs like Tesla, BMW, Hyundai, and Volvo routinely exceed 20–30GB, suggesting full system images or container bundles. Researchers and white-hat hackers analysing these updates have uncovered:
- Linux-based operating systems, often built with Yocto and Automotive Grade Linux (AGL) or custom distros.
- Android Automotive OS in infotainment domains (Volvo, Polestar, Renault)
- QNX or AUTOSAR Classic in safety-critical zones (instrument clusters, braking)
- Docker containers or similar sandboxing tools for modular apps
- Encrypted partitions, secure boot, and signed binaries to prevent tampering
Example: Tesla’s infotainment stack includes a custom Linux distro, Chromium-based browser, and encrypted update packages validated via secure boot. Researchers have found evidence of 10–20 containers running simultaneously to support navigation, media, telemetry, and diagnostics.
What Is a Software-Defined Vehicle (SDV)?
A Software-Defined Vehicle is one where core functions—steering, braking, infotainment, ADAS—are controlled, updated, and enhanced via software. Hardware becomes a platform; software becomes the product.
Key Characteristics:
- Functionality decoupled from hardware: Features can be added or modified post-sale.
- OTA updates: Deliver new capabilities, bug fixes, and security patches remotely.
- Cloud integration: Enables telemetry, diagnostics, and remote control.
- Service-oriented architecture: Apps and services run in containers or VMs, often on centralized compute nodes.
In high-end SDVs, it’s not uncommon to find 30–50 virtualized services running across zonal controllers and central compute units.
Zonal Architecture: The Backbone of SDVs
To support this software-centric model, OEMs are shifting from domain-based to zonal architecture. The table below compares legacy Domain-Based Architecture and modern Zonal Architecture:
| Feature | Domain-Based Architecture | Zonal Architecture |
|---|---|---|
| Structure | ECUs grouped by function (e.g. powertrain, infotainment, body control) | ECUs grouped by physical location (e.g. front-left zone, rear-right zone) |
| Wiring | Long harnesses connecting function-specific modules | Shorter, localised harnesses |
| Software | Monolithic, tightly coupled firmware | Modular, containerised, service-based |
| ECUs | Often 100+ per vehicle | Reduced to ~30–50, with centralised compute |
| Update Model | Dealer-based, slow, fragmented | OTA-enabled, cloud-integrated, real-time capable |
Zonal architecture reduces complexity, weight, and cost—while enabling SDV features like real-time updates, cross-domain orchestration, and cybersecurity monitoring.
This architectural shift isn’t just about performance or convenience—it’s about accessibility. By adopting familiar technologies like Linux, containers, and virtualization, automakers are opening the door to a much broader ecosystem of developers, researchers, and yes, hackers.
In the past, automotive systems ran on proprietary real-time operating systems (RTOS) with obscure toolchains and limited documentation. Reverse engineering required deep embedded expertise and expensive hardware. Today, many vehicle subsystems run on platforms that resemble cloud servers or smartphones:
- Linux distros with recognisable file structures
- Docker containers with standard orchestration
- Android-based infotainment systems with app-level APIs
In short, the number of people capable of probing, modifying, or attacking vehicle software has grown exponentially.
This democratisation of access is a double-edged sword. It accelerates innovation and transparency—but also increases the urgency for robust cybersecurity, secure boot chains, and real-time anomaly detection.
The hidden complexity of vehicle communication networks
While sensor counts have exploded, the communication backbone of modern vehicles is still in a transitional phase, caught between legacy protocols and emerging high-bandwidth standards.
Modern vehicles don’t just have more sensors—they have multiple overlapping communication networks that connect those sensors to ECUs, gateways, and cloud services. These networks are the nervous system of the car, and they’ve evolved in layers over decades.
Why aren’t we using just Ethernet?
Despite the rise of Automotive Ethernet (e.g., 100BASE-T1, BroadR-Reach), most vehicles today still rely on a mix of legacy and modern protocols. The reason? Transition complexity.
- Legacy ECUs still depend on CAN, LIN, or FlexRay.
- Infotainment systems often use MOST (Media Oriented Systems Transport).
- ADAS and autonomous platforms increasingly require Gigabit Ethernet for camera, radar, and lidar data.
- Gateways are used to bridge these domains, translating between protocols and managing traffic.
Rather than replacing older networks outright, OEMs are layering Ethernet on top—creating multi-domain architectures with 2–5 distinct communication protocols operating simultaneously. The following table provides the snapshot of common in-vehicle networks:
| Protocol | Typical Use Case | Speed | Notes |
|---|---|---|---|
| CAN (Controller Area Network) | Powertrain, chassis, body control | Up to 1 Mbps | Reliable, widely used; CAN-FD and CAN XL offer higher speeds |
| LIN (Local Interconnect Network) | Seat motors, window controls | Up to 20 Kbps | Cost-effective, single-wire |
| FlexRay | Safety-critical systems (e.g., brake-by-wire) | Up to 10 Mbps | High reliability, now declining in favor of Ethernet |
| MOST | Infotainment, media streaming | Up to 150 Mbps | Optical or electrical; being phased out |
| Automotive Ethernet | ADAS, cameras, OTA updates | 100 Mbps to 1 Gbps | Becoming dominant in new architectures |
Why the transition is slow
- Legacy ECUs can’t be easily re-engineered mid-cycle.
- Supplier ecosystems are deeply entrenched with protocol-specific tooling.
- Real-time requirements vary—some systems need deterministic latency (CAN), others need bandwidth (Ethernet).
- Gateways must translate across domains, adding complexity and latency.
- Certification and safety validation for new architectures is time-consuming.
External connectivity in cars:
From audio-in to always online
Twenty years ago, the most “connected” part of your car might’ve been the cigarette lighter powering a clunky GPS unit. Fast forward to today, and your vehicle is likely juggling multiple wireless protocols, cloud services, and remote control capabilities – all while driving itself down the motorway.
This transformation didn’t happen overnight. It’s the result of consumer demand, regulatory pressure, and the automotive industry’s race to stay relevant in a world where connectivity is no longer optional—it’s expected.
How did we get here?
The evolution of external connectivity in vehicles mirrors the rise of mobile tech. What started as a simple audio-in jack has become a full-stack wireless ecosystem.
| Era | Connectivity Milestone | Description |
| Pre-2000 | Audio-in jack | Limited to analog stereo input; no data |
| Early 2000s | Mobile phone integration via cable | Basic hands-free calling; no app support |
| Mid-2000s | Bluetooth introduced | Wireless audio and phone calls; infotainment pairing begins |
| 2010s | Wi-Fi hotspots, embedded SIMs | Cars begin acting as mobile routers; OTA updates emerge |
| 2020s–2025 | Multi-modem architecture, V2X, OTA, immobilization | Full-stack connectivity with cloud, infrastructure, and remote control capabilities |
What’s Inside a 2025 connected car?
Today’s vehicles are equipped with multiple wireless interfaces—often operating simultaneously and serving different domains.
In-Car Wireless Interfaces
- Bluetooth: Still the workhorse for audio and hands-free calling, now used for app pairing and diagnostics.
- Wi-Fi: Powers infotainment, passenger devices, and increasingly, software updates.
- NFC / UWB: Enables secure keyless entry and phone-as-key systems.
Cellular Modems (Yes, More Than One)
Modern vehicles often include:
- A primary modem for telematics, navigation, and OTA updates.
- A secondary modem for infotainment, streaming, and hotspot services.
- An optional third modem for V2X communication or satellite fallback.
Some platforms now integrate satellite connectivity and AI-based network optimisation, turning the car into a roaming edge device.
EV Charging Ports
Electric vehicles feature charging ports that do more than deliver power—they also exchange data. These ports utilise encryption and authentication protocols to verify identity, manage billing, and ensure safe operation. However, multiple vulnerabilities have been discovered in both vehicles and chargers, exposing risks ranging from unauthorised access to data interception and remote manipulation.
Remote Telemetry and Control
OEMs have quietly rolled out powerful remote capabilities:
- Real-time telemetry: Location, speed, diagnostics, and driver behaviour are streamed to cloud platforms.
- Remote immobilisation: Used for theft recovery, fleet control, or subscription enforcement. These systems can disable ignition or limit vehicle functionality via secure cloud commands.
The aftermarket boom: additional DIY connectivity
While OEMs build connectivity into the chassis, the aftermarket world is exploding with add-ons that extend, enhance, or duplicate these features. Here’s what drivers are installing today:
| Category | Device | Connectivity | Purpose |
|---|---|---|---|
| CCTV / Dash Cams | Smart dash cams | Bluetooth, Wi-Fi | AI hazard detection, parking surveillance, cloud uploads |
| Trackers | AirTags, CarLock, Viper, GPS tags | Cellular, Bluetooth | Theft prevention, teen driver monitoring |
| LED Accessories | LED strips, ambient lighting kits | Wired, app-controlled via Bluetooth | Aesthetic customization |
| Diagnostics | OBD-II dongles (e.g. FIXD, BlueDriver) | Bluetooth, Wi-Fi | Real-time fault codes, performance data |
| Charging | Wireless mounts, fast-charging pads | Qi wireless, USB-C | Convenience and cable-free operation |
| Smart Assistants | Voice-enabled HUDs, Alexa integrations | Wi-Fi, Bluetooth | Navigation, music, smart home control |
This isn’t just about convenience anymore. Every new sensor and connection—whether factory-installed or aftermarket—adds complexity and potential risk. In the next post, we’ll explore how these systems are being exploited, who’s behind the attacks, and how industry and governments are responding.
WRITTEN BY:
Sergej Gurenko, Cloud Security Architect, Reliance Cyber
Sergej Gurenko is a Cloud Security Architect at Reliance Cyber, where he focuses on building and fortifying complex security infrastructures across AWS, Azure, VMware, and Nutanix. He specialises in defining and implementing critical security controls, including Zero Trust Architecture, robust IAM policies, and cutting-edge EDR and CNAPP tooling. A strategic professional, Sergej is skilled at translating complex security roadmaps into actionable plans for both executive and engineering teams, ensuring they align with key industry standards like NIST CSF and CIS Security.
About Reliance Cyber :
Reliance Cyber delivers world class cybersecurity services tailored to the unique needs of our customers. With extensive in-house expertise and advanced technology, we protect organisations across a wide range of sectors — from enterprise to government —against the most sophisticated threats, including those from nation-state actors. Our teams safeguard critical assets, people, data, and reputations, allowing customers to focus on their core business objectives with confidence.
Get in touch with our experts
+44 (0)845 519 2946
contact@reliancecyber.com