Inherent Security Weaknesses of the CAN Protocol
CAN was designed in the 1980s for reliability on a closed wired bus, not for adversarial environments. CAN FD inherits the same frame format and the same threat-model assumptions. This page explains why neither protocol carries authentication or confidentiality by design, and what becomes a security weakness once the physical-isolation assumption no longer holds.
What CAN Was Designed For
Bosch began the CAN protocol development in the early 1980s as a deterministic, real-time, multi-master broadcast bus for embedded control. The primary design goals were reliability, low message latency, and tolerance to wiring faults on long, electrically noisy harnesses. The protocol delivered on those goals. CAN FD, introduced in 2012, extended the payload from 8 bytes to 64 bytes and raised the data-phase bit rate, but inherited the same frame format and the same broadcast addressing. The threat model behind both was a physically enclosed harness with trusted nodes inside it. In the 1980s, that assumption was reasonable: bus diagnostic equipment cost several thousand euros or dollars and lived in OEM service shops. Today, an OBD2 (On-Board Diagnostic) CAN adapter capable of full read and transmit retails for under 10 euros and ships from any consumer marketplace.
Authentication: not required
Inside a 1980s harness, every cable was visible and
physically protected. Whoever could send a frame was
already a trusted node inside the cabinet. A per-frame
cryptographic check would have cost cycles, payload bytes,
and key management - potentially on an 8-bit
microcontroller. At the time, it made no sense.
Confidentiality: not required
CAN payloads carry control values: a temperature, a setpoint, a switch state. None of these were considered sensitive, and the harness itself prevented anyone outside the cabinet from listening. Encryption would have added latency to a real-time bus to protect data that, at the time, no one was trying to read.
Security Consequences When Isolation Breaks
Once the physical-isolation assumption no longer holds, every
consequence of those original choices becomes a security
weakness. Any node attached to the bus can transmit any CAN ID
and data, and receivers cannot tell legitimate frames from
spoofed or injected ones. The error-handling mechanism that
protects the bus against electrical faults can be turned
against it: an attacker forces error frames at precise bit
positions to corrupt or suppress legitimate traffic, or pushes
a victim node into bus-off. Frames carry no sequence number or
nonce, so captured traffic replays cleanly. Every node sees
every frame, so confidentiality is impossible at the protocol
level. CAN FD inherits all of the above. Each of these is
addressed by a specific defensive shell:
see Frame
Security, Local
Injection Detection, and Anomaly
Event Monitoring.
CVSS Vector Breakdown for an Unprotected CAN Node
The protocol weaknesses translate into the CVSS v4.0 baseline
derived in EmSA-WP-103: vector CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N,
score 5.2 / Medium. VI:H and VA:H reflect frame
injection, replay, and DoS impacts; VC:N reflects the lack of
confidentiality protection but also the lack of confidential
data on a typical CAN node.
See CVSS
for CAN for a metric-by-metric walkthrough.
Frequently Asked Questions
Why is there no authentication in CAN?
CAN was designed in the early 1980s for embedded real-time
communication on a closed wired bus. The threat model
assumed a physically protected harness and trusted nodes, so
authentication and confidentiality were not required.
What is CAN ID spoofing?
Transmitting a frame with a CAN ID and data that the sending node is not authorized to use, in order to impersonate a different control unit. Because CAN and CAN FD have no source authentication, receivers cannot tell legitimate frames from spoofed ones. CAN ID guarding at the legitimate sender provides detection; cryptographic authentication provides prevention.