Automotive Network Security: Threats, Standards, and Solutions for Connected Vehicle Safety

“Automotive network security is the practice of protecting data within and beyond the vehicle to ensure secure, reliable communication.”

Let’s be honest, vehicles were not designed as connected systems.

Vehicles were originally built as standalone machines. In-vehicle architectures were designed for performance and reliability, not security.

That changed as vehicles became connected. Vehicles now interact with cloud platforms, mobile apps, and other systems. This shift opened new entry points for cyber threats.

In 2024 Upstream released a Cybersecurity Report that highlights: physical access is no longer needed to control your vehicle and 95% of automotive attacks are executed remotely. Unlike an IT security breach, automotive attacks just don’t keep data at stake, it risks human life.

To fix this gap, automotive cybersecurity regulations like ISO 21434 and UN WP.29 were introduced.

Vehicle networks form the core of overall automotive security posture, and this guide will walk you through its importance. It will break down the network and protocol vulnerabilities in modern vehicles and how compliance requirements are mapped and implemented to secure them.

---

What is Automotive Network Security?

Vehicles today rely on constant communication between distributed electronic components. Automotive network security secures this communication layer directly.

It protects the data pathways, ensuring messages are authentic, authorised, and resistant to disruption. It also defines how gateways control routing and isolation and manages how external interfaces connect with internal systems.

To understand how this works in practice, let’s dive deeper to understand the in-vehicle network stack and how external attack surfaces affect them.

In-Vehicle Network (IVN)

The in-vehicle network uses multiple specialised communication protocols, each optimised for specific performance, latency, and cost requirements.

Engineered long before cybersecurity became a concern, these protocols lack built-in security. Therefore, each protocol introduces a vehicle to distinct threats which are mitigated through security layers’ integration within AUTOSAR architectures and policy-defined access controls.

Given the architectural limitations of these protocols, there is a lack of inherent security, and they require additional safeguards. CAN protocol, for example, prioritises deterministic timing and minimal overhead. While this enables real-time control, it allows any connected node to transmit messages without authentication. As a result, security cannot reside in the protocol. It depends on gateway enforcement, message validation, and domain segmentation to control trust and limit blast radius.

However, only securing in-vehicle communication is not enough. The risk emerges at the boundaries where internal networks interact with external interfaces and services.

External Attack Surface

Automotive network security extends beyond internal buses. Every external interface that exchanges data with the vehicle introduces a potential attack path.

These interfaces differ in range, accessibility, and operational risk but are connected to the same internal communication infrastructure. Security researchers classify these entry points across three ranges:

1. Local surfaces that require physical access (i.e., OBD-II port, USB connections, JTAG connectors and direct wiring access)
2. Short-range surfaces that extend the threat wirelessly but within proximity (i.e., Bluetooth, Wi-Fi access points, and NFC).
3. Long-range services that operate over public or shared infrastructure and require no physical presence at all (i.e., cellular telematics, OTA updates, V2X communications, and backend API connections).

Now that we understand the attack vectors and likely entry points, let’s see how a threat progresses.

---

Threat Landscape in Automotive Networks

Attackers rarely target an ECU directly. They exploit the weakest entry point and move inward. While the entry point varies by vehicle, the pattern is consistent.

Attackers most commonly pivot through four entry points, using the one that presents the weakest authentication boundary:

Once inside the vehicle, the attacker targets the central gateway ECU, the routing hub that connects all network domains, including braking and steering systems.

Note: A compromised gateway can expose the entire vehicle network. When an attacker reaches a flat, permissive gateway, there is no need to pivot further. The gateway routes traffic straight into safety critical domains.

In a vehicle where the gateway does not enforce access control between domains, a foothold in the infotainment system becomes direct access to CAN buses with protocol-level attacks and ecosystem-scale threats.

1. Protocol Level Attacks

Protocol-level attacks in automotive networks follow a small set of repeatable communication manipulation patterns. These patterns do not depend on exploiting software vulnerabilities. They exploit the trust assumptions built into vehicle communication protocols.

The most common protocol attack behaviours include:

Nevertheless, these attack patterns form the operational baseline for more specialised techniques. Attackers also use an advanced variant of CAN bus denial-of-service (DOS) attacks called a ‘bus-off’ attack.

What is a bus-off attack?

Bus-off is a confirmed production-viable DoS tool used primarily for node silencing, not data exfiltration. It doesn’t inject malicious commands at all; it abuses CAN’s own error-handling protocol.

In this attack scenario, an attacker repeatedly flags a target ECU’s messages as faulty. The CAN controller, interpreting this as self-malfunction, removes itself from the bus entirely. The targeted node goes silent, and diagnostic tools register it as a hardware fault rather than an attack.

2. Ecosystem-Scale Threats

Beyond protocol-level attacks, the automotive threat landscape also includes ransomware campaigns that target OEMs and dealer infrastructure. Common examples of such attacks include:

Ransomware Attack

A clear example of the same is the ransomware attack on CDK Global in June 2024. It disrupted thousands of dealerships across North America, causing an estimated $1 billion in collective losses.

Unlike in-vehicle exploits, this attack targeted the connected ecosystem around it: dealer management systems, OEM cloud platforms, and telematics backends.

OTA Update Manipulation

The OTA update pipelines present another systemic risk. In such attack scenarios, adversaries target the update pipeline that lacks end-to-end digital signature validation and A/B partition rollback capabilities.

A compromised update channel allows an attacker to push malicious firmware to an entire fleet without triggering a single safety fault. The vehicle accepts the update; the vehicle executes whatever the update tells it to.

AI-Driven Attacks

The 2026 Upstream Security report introduced an evolving threat category of GenAI-driven attack automation. Large language models (LLMs) are now being used to analyse CAN database (DBC) files, ECU firmware, and OEM documentation to identify communication patterns and vulnerabilities.

Such attacks not only reduce the attacker’s time-to-exploit, but the reconnaissance that previously required embedded systems expertise can now be partially automated.

The implication for security teams is clear:

• The window between vulnerability discovery and exploitation is narrowing, and
• Patching cycles designed for an older threat pace are no longer adequate.

---

How Do Automotive Cybersecurity Regulations Work to Close the Gap?

Knowing the threat is only half the obligation, regulators now mandate requirements to respond to it. Primarily two regulatory pillars shape how OEMs and suppliers implement network security controls: ISO/SAE 21434 and UN WP. 29.

ISO/SAE 21434

ISO/SAE 21434 sets the engineering standard and the risk assessment process of every vehicle component, including the network protocols. While it does not prescribe specific technologies. Instead, it mandates a process that forces security decisions to be made, explicitly documented, and revisited as the threat environment changes.

Its most operationally significant requirement is the Threat Analysis and Risk Assessment (TARA) defined under Clause 15. A TARA structures the engineering process that produces cybersecurity goals for every asset in the vehicle network.

To learn in detail how TARA process works in practical checkout our guide on Threat Analysis and Risk Assessment.

UNECE WP.29 R155 / R156

In addition to the ISO 21434, UNECE WP.29 states the audit requirements to validate if vehicles are fit for roads with R155 and R156.

While most requirements of automotive cybersecurity are covered under UN WP.29, OEMs operating across multiple markets also need to comply with other global regulations.

Now that the compliance requirements are clear, let’s break down how security controls are mapped and engineered to secure each attack surface
.

---

Security Engineering in Connected Vehicle Architecture

Standards define what must be protected. However, it’s the architecture that determines where those protections must be applied. This mapping follows a structured method where security mechanisms are configured at trust boundaries based on the risks identified during TARA assessment.

1. Central Gateway ECU Security

The Central Gateway ECU sits at the intersection of every vehicle network domain carrying external cellular traffic.

In production programmes, permissive routing is often found to be the most common misconfiguration in the gateway ECU. It forwards inter-domain traffic unless explicitly blocked. It creates a flat network where any domain breach becomes immediate access to every other.

To prevent this, ECU gateway security follows a structured implementation combining the following:

1. Default deny posture
2. Safe TCU Bridging
3. Firewall Implementation



During deployment, engineers enforce a default-deny posture, allowing only precomputed inter-domain communication paths defined by message types, CAN IDs, sources, and destinations. The gateway drops all traffic not explicitly authorised and, where required implements rate‑limits and logs it without forwarding.

Next, safe TCU bridging is enforced for hard domain isolation. This configures the TCU to communicate only with a dedicated telematics and blocks its access to the powertrain and chassis buses. Before crossing this boundary, the gateway validates every message against the ‘allowlist’ and authenticates the TCU’s cellular identity using hardware‑backed certificates.

Additionally, firewall design is integrated, governed under strict timing constraints. Under worst‑case, end‑to‑end gateway processing of a CAN frame must be under 100–200 microseconds. This ensures deep packet inspection is confined to diagnostic and telematics interfaces, where higher latency is acceptable, while safety‑critical paths rely on deterministic allowlist validation. Further, it also requires gateway firmware to demonstrate compliance with these latency targets under stress, including simulated attack saturation.

2. Protocol-Level Security

Protocol-level security controls the message communication trust within each domain. To ensure the protocols are safely authenticated and encrypted, OEMs implement the following:

1. AUTOSAR Secure Onboard Communication (SecOC)
2. MACsec
3. HSM integration



AUTOSAR SecOC adds Message Authentication Codes to CAN and CAN FD frames. It pairs each message with a freshness counter and a truncated MAC derived from a symmetric key stored in the ECU’s Hardware Security Module (HSM). In software implementations, SecOC introduces 50–300 microseconds of latency, depending on ECU compute headroom. At signal frequencies exceeding 100 Hz, this overhead violates ISO 26262 timing budgets SecOC therefore cannot be applied uniformly across all signals. Instead, each component is profiled individually, relying on gateway‑enforced domain segmentation.

MACsec benefits from an architectural advantage that SecOC lacks. IEEE 802.1AE delivers hop‑by‑hop Layer‑2 encryption and authentication directly within the Automotive Ethernet stack. It executes at line rate with near‑zero latency through SoC or PHY integration. For ADAS pipelines carrying camera streams, radar point clouds, and LiDAR data, it is the only practical option. MACsec counters and statistics further provide a clean forensic signal in production, that helps distinguish security incidents from hardware faults.

Both AUTOSAR SecOC and MACSec depend on the same hardware root of trust: the HSM. Production deployments in vehicles span across three tiers: SHE at the AUTOSAR baseline; EVITA Light based on security criticality; and TPM 2.0 used in domain and zone controllers. Once the HSM is compromised, every cryptographic control layered above it becomes negotiable.

Is zero-trust implementation for in-vehicle networks production-ready today?

Zero-trust for in-vehicle networks is not yet fully production-ready. Partial implementation via gateway segmentation and Ethernet-layer security is viable today.

The blockers are concrete:

• ECU-level key management at scale requires an HSM per ECU and
• A robust key provisioning infrastructure that most OEM supply chains do not yet support

The practical path is incremental implementation of zero-trust. OEMs today use domain isolation at the gateway and MACsec on Ethernet segments. Additionally, SecOC is selectively implemented on the highest risk CAN signals.

3. Incident Response Integration

Control architectures are not built to eliminate the possibility of intrusion. This requires an additional operational layer that determines whether a breach is rapidly contained or allowed to persist across the fleet. This is usually done with a detection, alerting, and coordinated response mechanism typically via IDS and vSOC.



An in-vehicle Intrusion Detection System (IDS) is trained on real driving scenarios. The baseline uses edge cases like hard braking events, multi-domain burst traffic during ADAS activation, and diagnostic session communication patterns. A baseline trained only on steady highway driving generates unacceptable false positives under urban conditions. In production, the accepted false positive rate is below 1%, ideally near zero. At 1% on a 1,000-messages-per-second CAN bus, the IDS generates 10 alerts per second, which overwhelms both the monitoring ECU and any downstream system receiving its output.

However, the critical reality is most in-vehicle IDS deployments in production today function primarily as logging and forensic tools. Real-time blocking on a safety-critical CAN bus creates its own safety risk: a false positive that silences a braking command is a more immediate threat than the intrusion it was trying to stop. In the right architecture, detection and response are separate, which requires a Vehicle Security Operations Centre (vSOC) with a human operator in the loop.

What is a VSOC?

A VSOC aggregates fleet‑wide telemetry, including CAN anomalies, ECU state logs, OTA event streams and telematics data across a connected fleet, and correlates it into actionable threat intelligence using ML-trained baselines.

4. External Attack Prevention

The controls deployed for gateway, protocol and incident response secure the in-vehicle systems. However, emerging interfaces extend the threat model beyond what current vehicle architectures fully address.

A V2X onboard unit handles two distinct security domains simultaneously:

• The V2X radio interface communicating with roadside infrastructure and other vehicles
• The OTA management interface connecting to the OEM cloud backend

This requires all V2X messages to be signed using pseudonymous certificates issued by a V2X PKI, which rotate identity periodically to protect driver privacy while preserving message authentication.



OTA updates to the OBU require an A/B partition model: the new image is written to the inactive partition, its cryptographic signature verified against an OEM root certificate in the HSM, and a post-boot health check completed before the bootloader commits. A failed health check reverts to the known-good partition automatically. No rollback capability means a failed OTA update on a gateway or OBU can leave the vehicle undriveable.

Moreover, the EV charging ecosystem introduces OCPP between chargers and management systems. The key threats include OCPP endpoint compromise to exfiltrate payment and location data, ISO 15118 man-in-the-middle attacks to spoof vehicle identity, and DCFC internal network manipulation. Mitigation follows the same principles as in-vehicle security: TLS 1.3 for OCPP, certificate-based identity under ISO 15118-20, and network segmentation between charging management and grid control systems.

---

Conclusion

Automotive network security spans every layer of the modern vehicle. While regulations now impose strict obligations across more than 60 countries, effective risk reduction still depends on strong security controls.

The vehicles entering development today will be on the road by 2030. However, the threat actors targeting them are advancing even faster than most OEM security teams could patch. Investment in network security architecture now is not optional future-proofing; it is the minimum viable position for any manufacturer operating in a regulated connected mobility market.

If you are looking for the right solution to secure a vehicle network system checkout: Automotive Cybersecurity Solutions