I have grown tired of seeing CAN Bus described as a vulnerable technology simply because someone demonstrates that they can interfere with a vehicle after connecting equipment to its internal network.
What, exactly, does that prove?
If I have sufficient physical access to a vehicle or an industrial machine, I can probably disable it without sending a single CAN message. Damage the right electrical connection or mechanical component, and the application stops working. Nobody would consider that a discovery about the shortcomings of its communication protocol.
Yet connect a computer to the CAN network, transmit disruptive messages, and suddenly CAN itself becomes the problem.
I believe that conclusion reflects a persistent misunderstanding of what CAN provides, what it was designed to do, and where responsibility for system security belongs.
CAN earned its reputation through reliable communication in electrically demanding environments. Its arbitration, error detection, and fault confinement mechanisms serve real engineering purposes. Those capabilities do not disappear because a deliberately transmitted message can interfere with an application.
However, reliable communication and trustworthy communication are separate requirements. Classical CAN can detect transmission errors. It does not inherently establish whether the device transmitting a valid message is authorized to do so. A correctly transmitted message can still carry a malicious instruction.
That limitation is real. Engineers must account for it. But treating it as proof that CAN is an unreliable technology confuses two different subjects.
Physical Access Changes the Argument
My patience is particularly limited when a demonstration requires physical access, a connection to the internal network, and enough knowledge of the application to produce the intended effect—then presents the result as though CAN has failed some fundamental test of engineering competence.
If the achievement is simply making equipment stop working, I remain unimpressed. Physical sabotage was possible long before CAN existed.
There is, however, a distinction I cannot dismiss. Disabling a machine and secretly manipulating its behavior are different objectives. Someone might want a vehicle to continue operating while behaving incorrectly, or leave behind a modification that takes effect later. Such interference can be harder to detect than obvious physical damage.
That is a legitimate reason to protect access to a CAN network. My objection concerns what we claim a demonstration proves. Showing that an accessible internal network can be abused does not, by itself, establish that the underlying communication technology was a poor choice.
Remote Access Is a System Design Responsibility
Remote attacks deserve serious attention because they change the conditions completely. The attacker may never approach the vehicle or machine.
But CAN does not provide its own Internet connection. It does not independently establish a Bluetooth session or join a Wi-Fi network. Something else provides that access: a telematics unit, an infotainment system, a diagnostic device, a connected controller, or another gateway.
If compromising that equipment gives an attacker access to critical controls, I want to know why the system architecture permits it.
What authority does the connected device have? Which messages can cross the gateway? What prevents a compromised accessory from reaching functions it has no business controlling?
Those are engineering questions for the people designing the complete system. NHTSA’s cybersecurity guidance explicitly recommends segmentation and isolation between wireless-connected equipment and safety-critical vehicle controls.
Ethernet, Bluetooth, and Wi-Fi are not automatically at fault either. The problem lies in how an external connection is implemented, protected, and connected to the control system.
CAN’s lack of inherent sender authentication remains relevant after an attacker gets inside. That is precisely why engineers must design around its trust assumptions. Protecting the entrance matters, and so does limiting what a compromised device can do once through it.
Blaming CAN alone lets the rest of the architecture escape scrutiny.
Curiosity, Malice, and Independent Development
I also dislike treating everyone who investigates a CAN network as though they have the same intentions.
Some hobbyists experiment for the satisfaction of understanding a system. Responsible experimentation can reveal weaknesses that deserve attention. Reckless interference deserves criticism, but curiosity alone does not.
Malicious attackers have a different objective. They want unauthorized access, manipulation, theft, or disruption. Their methods and opportunities must be addressed as part of system security.
Then there are engineers and hobbyists who want to add functionality without the manufacturer’s involvement. I have no interest in declaring independent development illegitimate merely because a manufacturer did not approve it. Useful products and improvements often begin outside the original manufacturer’s plans.
Nevertheless, anyone adding equipment to a control network assumes an engineering responsibility. Even a well-intentioned device can introduce excessive traffic, conflicting messages, or an unintended path for remote access.
All three situations justify appropriate protection. They do not justify treating every experiment as an attack or every modification as irresponsible.
Give CAN the Criticism It Actually Deserves
I am not arguing that CAN networks should be left unprotected. I am arguing for an accurate diagnosis.
Classical CAN has security limitations. Those limitations belong in the design requirements of any system using it. Engineers who ignore them deserve criticism.
But CAN cannot compensate for an insecure connected device, an overly permissive gateway, or an architecture that gives external equipment unrestricted access to critical functions.
My position is straightforward: CAN remains a reliable communication technology whose security limitations are frequently described without enough context. A physical-access demonstration may reveal a meaningful weakness—or merely show that someone with access can cause damage.
The useful question is what access was required, what protection failed, and what the attacker could actually accomplish.
That is where the engineering discussion should begin. Too often, “CAN was hacked” is where it ends.
The Car Hacker’s Handbook: A Guide for the Penetration Tester
Modern vehicles are complex computing platforms. Infotainment, navigation, wireless connectivity, and automatic software updates offer greater convenience, but they also introduce entry points that must be secured. Understanding these connections—and how they interact with internal control networks—is essential to understanding automotive cybersecurity.
The Car Hacker’s Handbook explores the computer systems, embedded software, and communication networks behind modern vehicles. It introduces threat modeling and examines how vulnerabilities in connected devices, diagnostic interfaces, and system architecture can expose vehicle functions to unauthorized access.
The book explains CAN Bus communication and shows how to analyze traffic, investigate interactions between electronic control units, and evaluate security weaknesses. These demonstrations also illustrate an important distinction: gaining access to a vehicle’s network and exploiting that access are separate problems. CAN’s communication reliability does not provide authentication or replace the need for a secure system architecture.
Using low-cost hardware and open-source tools such as Metasploit, Wireshark, Kayak, can-utils, and ChipWhisperer, the book covers how to:
– Develop a vehicle threat model
– Analyze CAN traffic and reverse engineer vehicle messages
– Investigate vulnerabilities in diagnostic and data-logging systems
– Examine electronic control units, firmware, and embedded systems
– Explore attack paths through infotainment and vehicle-to-vehicle communications
– Understand performance tuning and changes to factory settings
– Build physical and virtual test benches for controlled security research
For engineers, developers, and technically curious readers, The Car Hacker’s Handbook offers a practical introduction to automotive security—and a foundation for understanding where vulnerabilities arise and how better engineering can address them. More information…