Securing Automotive Ethernet: A Survey of In-Vehicle Protocol Threats and Defense Mechanisms from CAN to 5G

Securing Automotive Ethernet: A Survey of In-Vehicle Protocol Threats and Defense Mechanisms from CAN to 5G

The modern vehicle has stopped being a closed electromechanical system. A mid-range 2024 model typically carries 60–120 electronic control units (ECUs), several gateway domains, a telematics unit with cellular connectivity, and a growing number of wireless entry points. The attack surface now spans legacy buses (CAN, LIN, FlexRay, MOST), a backbone that is increasingly switched Automotive Ethernet, and external interfaces such as USB, Bluetooth Classic/BLE, Wi-Fi, and 5G. The commercial stakes are concrete: a single unpatched gateway vulnerability can trigger a recall covering hundreds of thousands of vehicles, and the UN R155/R156 regulatory framework now makes a cybersecurity management system (CSMS) a condition of type approval in the EU.

This article is written for engineers and product decision-makers who need to evaluate security architectures, not for readers who want a generic introduction to the topic. We focus on what is practically exploitable, what mitigations actually cost in latency and BOM, and how competing approaches compare. Automotive Ethernet occupies the center of the discussion because its best-effort, switched nature changes the threat model fundamentally compared with the broadcast, deterministic CAN bus it replaces.

1. Why the Bus Topology Determines the Threat Model

The security posture of an in-vehicle network is largely a function of its physical and logical topology. Legacy buses are broadcast media: every node sees every frame, and arbitration is by identifier priority, not by sender identity. Ethernet is switched and point-to-point, with MAC addressing, VLANs, and IP routing. This shift matters for three reasons.

• Observability: On CAN, any compromised node passively receives all traffic on its bus. On a switched Ethernet backbone, a compromised ECU sees only traffic routed to it unless it performs VLAN hopping, MAC flooding, or ARP/NDP spoofing.
• Determinism: CAN provides bounded worst-case latency through priority arbitration. Standard Ethernet is best-effort, which is why TSN (IEEE 802.1Qbv/802.1Qav) and Audio Video Bridging extensions exist. Security controls that add processing delay directly threaten timing budgets on safety-critical paths.
• Blast radius: A CAN bus is a single collision domain; a fault or attack propagates to every node instantly. A switched backbone allows segmentation (zones), but a misconfigured switch or gateway becomes a single point of failure that bridges zones.

The practical consequence is that defense-in-depth must be layered per domain, and the gateway between domains is the highest-value target in the vehicle. Any security evaluation that does not start at the central gateway and the telematics ECU is misallocated.

2. Threat Survey by Protocol

2.1 CAN and CAN FD

CAN remains the workhorse for powertrain, chassis, and body domains. Its known weaknesses are well documented and still relevant:

• No authentication or encryption. Any node can inject frames with any identifier. A classic demonstration is injecting a forged frame with a high-priority ID to override a legitimate command.
• No sender identity. The identifier denotes message content, not origin, so spoofing and replay are trivial once an attacker has bus access.
• Bus-off attacks. Deliberately transmitting error frames can force a target ECU into bus-off state, causing denial of service on safety functions.
• Physical access. The OBD-II port exposes CAN directly. Diagnostic sessions (UDS over ISO-TP) are a common entry vector, and security access seeds are sometimes weak or static across a fleet.

CAN FD increases payload to 64 bytes and improves throughput, which helps security because it enables message authentication codes (MACs) to be carried in-frame. The trade-off is bandwidth: a 4-byte truncated MAC plus a freshness counter consumes a meaningful fraction of an 8-byte classic CAN frame, which is why authentication on classic CAN is usually limited to safety-critical IDs and uses truncated MACs with counter-based freshness.

2.2 LIN, FlexRay, and MOST

LIN is a single-wire, low-speed bus for actuators and sensors (mirrors, seats, climate flaps). It has no security mechanisms at all and is typically bridged to CAN through a LIN master ECU. Attacks on LIN are usually local (physical access to a harness) but can be used to manipulate sensor readings that feed higher-level functions. FlexRay offers 10 Mbit/s and time-triggered determinism for chassis and steer-by-wire applications; it has no native authentication, and its static and dynamic segments can be disrupted by a malicious node that transmits in the wrong slot. MOST (Media Oriented Systems Transport) is largely legacy infotainment; it is being displaced by Ethernet AVB/TSN, but vehicles in service still carry it, and its ring topology means a single compromised node can disrupt the whole ring.

2.3 Automotive Ethernet

Automotive Ethernet (100BASE-T1, 1000BASE-T1, and emerging 10GBASE-T1) is now the backbone for ADAS sensor fusion, infotainment, and OTA updates. Its switched nature gives defenders new tools (VLANs, ACLs, port security) but also introduces Ethernet-specific attack classes that do not exist on CAN:

• ARP/NDP spoofing and MAC flooding: a compromised ECU can poison neighbor caches to intercept traffic between zones, or flood the switch's MAC table to force fallback to hub-like flooding behavior.
• VLAN hopping: misconfigured trunk ports allow an attacker to reach zones that should be isolated (e.g., from infotainment into the chassis domain).
• DoS via broadcast/multicast storms: best-effort Ethernet has no inherent congestion control at layer 2; a storm can starve time-critical TSN traffic if priority scheduling is not enforced correctly.
• Timing attacks on TSN: manipulation of gPTP (IEEE 802.1AS) synchronization can shift time gates and disrupt scheduled traffic, which is a safety issue as much as a security one.
• Protocol stack vulnerabilities: the IP stack (TCP/IP, SOME/IP, DoIP, DDS) introduces the same class of memory-safety and parsing bugs found in IT systems, now on a safety-critical network.

This is the core reliability-and-security tension the survey highlights: Ethernet's best-effort delivery means a security control that drops or delays packets can break a safety function, and a switch that prioritizes availability over integrity can be exploited to cause exactly the timing failures TSN was designed to prevent. Defenders must therefore treat bandwidth, latency, and jitter budgets as security constraints, not just performance targets.

2.4 External Interfaces: USB, Bluetooth, Wi-Fi, 5G

External interfaces are the most exposed part of the vehicle because they are reachable without physical disassembly.

• USB: media ports in the head unit parse filesystem images and media codecs. Malformed files or USB descriptor abuse have historically been a route into the infotainment OS. Mitigation is strict input validation, sandboxing of the media stack, and disabling USB data (charging-only) when not needed.
• Bluetooth: pairing, key exchange, and profile implementations (HFP, A2DP, PBAP) are a large attack surface. BLE adds GATT-based services that must be authenticated. The Bluetooth Core Specification 6.2 adds Channel Sounding Amplitude-based Attack Resilience, which is directly relevant to secure ranging in digital key and passive entry systems — an attacker attempting to amplify or relay ranging signals is now addressed at the specification level. Version 6.2 also introduces Shorter Connection Intervals, which reduces the latency window available to a relay attacker, and HCI USB LE Isochronous Support plus LE Test Mode Enhancements, which matter for validating LE Audio and for RF conformance testing of security-relevant timing behavior. For product teams, the practical takeaway is that digital-key and phone-as-a-key designs should target Core 6.2-capable controllers rather than retrofitting relay mitigation in application software.
• Wi-Fi: in-vehicle hotspots and Wi-Fi-based OTA create a large layer-2/3 surface. WPA3 and proper network isolation between the hotspot and the vehicle's internal zones are baseline requirements.
• 5G: the telematics unit (TCU) is the primary remote attack path. Threats include SIM/eSIM compromise, misconfigured APNs exposing internal services, and vulnerabilities in the cellular modem's baseband or its IP stack. The 5G network itself provides strong subscriber authentication, but the vehicle-side trust boundary is the TCU's firewall and the OTA client's signature verification, not the radio link.

3. Defense Mechanisms and Their Practical Costs

Security controls on in-vehicle networks fall into four layers: network segmentation, message authentication, intrusion detection, and secure update/identity management. Each has measurable cost in latency, bandwidth, and BOM, and the right mix depends on the domain.

3.1 Segmentation and Gateways

Domain/zonal architecture with a central gateway and Ethernet backbone is the dominant 2024–2026 design. Practical recommendations:

• Enforce VLAN separation between infotainment, telematics, ADAS, and chassis domains, with default-deny ACLs on the gateway.
• Disable unused switch ports and lock MAC learning on access ports (port security) to blunt MAC flooding.
• Use a firewall with deep packet inspection for SOME/IP and DoIP at the central gateway; this is where most commercial IDS/IPS products (e.g., from automotive cybersecurity vendors) are deployed.
• Keep the OBD-II diagnostic path behind an authentication gateway (gateway-level security access), not directly bridged to powertrain CAN.

Benchmark note: an inline gateway firewall performing SOME/IP DPI typically adds tens to low hundreds of microseconds per frame depending on rule complexity and hardware acceleration. On a 100BASE-T1 link carrying ADAS sensor fusion traffic, this must be validated against the end-to-end latency budget (often single-digit milliseconds for safety functions). Hardware offload or a dedicated security MCU is usually required to keep jitter within TSN bounds.

3.2 Message Authentication (SecOC and MACsec)

On CAN/CAN FD, AUTOSAR SecOC provides per-PDU authentication using a truncated MAC and a freshness counter. On Ethernet, IEEE 802.1AE MACsec provides hop-by-hop link encryption and integrity at layer 2, and IPsec/TLS protect end-to-end flows above it.

• SecOC on classic CAN: feasible for a limited set of critical IDs. A 24–32-bit truncated MAC plus a 4–8-bit freshness counter is a common compromise. Full authentication of all traffic is not bandwidth-feasible on classic CAN.
• SecOC on CAN FD: much more practical; 64-byte payloads allow stronger MACs and larger counters, at the cost of payload capacity for application data.
• MACsec on Ethernet: line-rate integrity and confidentiality with hardware support, but it is hop-by-hop — every switch must terminate and re-originate, so trust in intermediate switches is required. For end-to-end protection across zones, combine MACsec at layer 2 with TLS/IPsec for application flows (e.g., OTA, diagnostics).

Commercial trade-off: MACsec-capable automotive switches carry a BOM premium and require key management infrastructure (MKA, 802.1X). For many OEMs the pragmatic path is MACsec on the backbone and SecOC on the CAN domains behind the gateway, rather than attempting uniform end-to-end authentication.

3.3 Intrusion Detection and Prevention (IDS/IPS)

Host-based IDS on ECUs (monitoring CAN traffic for unexpected IDs, frequency anomalies, and payload ranges) and network-based IDS at the gateway are now standard in production programs driven by UN R155. Practical evaluation criteria:

• Detection latency: host-based CAN IDS typically detect anomalies within a few frames; network IDS at the gateway adds the forwarding path latency. For bus-off and DoS attacks, detection must be fast enough to trigger mitigation before safety functions degrade.
• False positive rate: rule-based IDS on CAN produces false positives when legitimate traffic patterns change (diagnostics, OTA, mode transitions). ML-based approaches reduce this but require fleet data and careful validation; they are harder to certify.
• Response actions: detection without a response (rate limiting, quarantine of a zone, logging to a secure element) has limited value. Define the response policy per attack class.

3.4 Secure Boot, Key Management, and OTA

Hardware root of trust (HSM or secure element) with secure boot, signed firmware, and per-vehicle key provisioning is the foundation. OTA update pipelines must verify signatures end-to-end and support rollback protection. The TCU's cellular link is the highest-risk path, so the OTA client should verify signatures independently of the transport and never trust the 5G network as an authentication boundary.

4. Comparison: Legacy Bus vs. Ethernet Security Posture

The following table summarizes the practical security comparison for engineering and procurement decisions. Entries reflect commonly deployed mechanisms, not theoretical maxima.

• CAN/CAN FD: Native security — none. Practical controls — SecOC (partial), gateway filtering, host IDS. Latency cost — low to moderate. Key weakness — broadcast, no identity.
• LIN: Native security — none. Practical controls — physical protection, master-side validation. Latency cost — negligible. Key weakness — fully trusted local bus.
• FlexRay: Native security — none. Practical controls — schedule monitoring, gateway isolation. Latency cost — low. Key weakness — time-slot disruption.
• MOST: Native security — none. Practical controls — ring isolation, replacement with Ethernet. Latency cost — N/A. Key weakness — legacy, limited tooling.
• Automotive Ethernet: Native security — MACsec, VLANs, ACLs, 802.1X. Practical controls — gateway DPI, TSN-aware firewalls, IDS. Latency cost — moderate (hardware offload required). Key weakness — best-effort timing, IP stack exposure.
• Bluetooth/BLE: Native security — pairing, LE Secure Connections; Core 6.2 adds Channel Sounding amplitude attack resilience and shorter connection intervals. Practical controls — authenticated GATT, ranging validation. Key weakness — relay attacks on passive entry.
• Wi-Fi: Native security — WPA3. Practical controls — network isolation, hotspot segmentation. Key weakness — large L2/L3 surface.
• 5G: Native security — strong subscriber auth, encrypted air interface. Practical controls — TCU firewall, OTA signature verification, APN isolation. Key weakness — TCU and modem stack as trust boundary.

5. Real-World Scenarios and What They Reveal

Scenario A — OBD-II dongle compromise. A third-party insurance dongle plugged into OBD-II bridges CAN to a cellular modem. If the dongle's firmware is unsigned and its diagnostic access is not gated, it becomes a remote CAN injection path. Mitigation: gateway-level diagnostic authentication and restricting OBD-II to a filtered, rate-limited diagnostic VLAN.

Scenario B — Infotainment to chassis lateral movement. A malicious media file exploits the head unit's codec stack. If the head unit shares a VLAN with the chassis domain or the gateway ACLs are permissive, the attacker can reach safety-critical ECUs. Mitigation: strict VLAN separation, default-deny gateway ACLs, and sandboxing of the media stack.

Scenario C — Digital key relay attack. An attacker relays BLE ranging signals between the phone and the vehicle to unlock and start it. Core 6.2's Channel Sounding amplitude-based attack resilience and shorter connection intervals directly reduce this window, but the vehicle-side implementation must actually enable and validate these features, and the phone must support them. Procurement should require evidence of ranging validation testing, not just spec compliance.

Scenario D — OTA supply-chain compromise. A signed but malicious update is pushed through a compromised build server. Mitigation: multi-party signing, reproducible builds, and staged rollout with rollback. The 5G link is not the weak point here; the signing pipeline is.

6. Actionable Recommendations

• Start at the gateway. Treat the central gateway and TCU as the primary trust boundaries. Deploy DPI-capable firewalls with default-deny ACLs and validate latency against TSN budgets with hardware offload.
• Segment by domain, not by convenience. VLANs between infotainment, telematics, ADAS, and chassis; disable unused ports; enforce port security.
• Authenticate selectively. SecOC on the highest-risk CAN IDs and on CAN FD where bandwidth allows; MACsec on the Ethernet backbone; TLS/IPsec for OTA and diagnostics.
• Deploy IDS with a response policy. Host-based CAN IDS plus gateway network IDS, with defined quarantine/rate-limit actions and logging to a secure element.
• Harden external interfaces. Charging-only USB by default, authenticated GATT for BLE services, WPA3 and hotspot isolation for Wi-Fi, and a hardened TCU firewall for 5G.
• Target current Bluetooth Core for digital key. Specify Core 6.2-capable controllers to obtain Channel Sounding amplitude attack resilience and shorter connection intervals, and require ranging validation test evidence from suppliers.
• Build the CSMS around UN R155/R156. Threat analysis and risk assessment per domain, documented mitigations, and a monitored incident response process are now procurement and type-approval requirements, not optional extras.

7. Buying and Evaluation Guide

For OEMs and Tier-1s evaluating security solutions, the following criteria separate credible products from marketing claims:

• Latency evidence: demand measured per-frame latency and jitter for gateway firewall and IDS functions at line rate on 100BASE-T1 and 1000BASE-T1, not just throughput numbers.
• Certification readiness: ISO/SAE 21434 process compliance and UN R155 CSMS evidence from the supplier.
• Key management: HSM-backed provisioning, secure boot, and rollback protection demonstrated end-to-end, including the OTA signing pipeline.
• Standards currency: for wireless components, confirm support for Bluetooth Core 6.2 features where digital key or ranging is in scope; for Ethernet, confirm TSN and MACsec hardware support with 802.1X/MKA.
• Fleet operability: IDS tuning workflow, false-positive management, and OTA remediation path across the vehicle lifetime.

The bottom line: Automotive Ethernet gives defenders better tools than CAN ever could, but its best-effort nature means every security control must be validated against timing budgets, and the highest-value investments remain the gateway, the TCU, and the OTA signing pipeline. Protocol-level features such as Bluetooth Core 6.2's ranging attack resilience help, but only if the product actually implements and tests them.

💬 Join the discussion on our forum: Share your thoughts or ask questions