Security Concerns in CAN, CANopen, and J1939 Networks

The Controller Area Network (CAN) is a vehicle/industrial network bus standard developed in the 1980s for efficient, real-time communication between microcontrollers. It has since become ubiquitous in automobiles, trucks, heavy machinery, medical devices, and industrial equipment​. Higher-layer protocols built on CAN include CANopen (used in industrial automation, robotics, and medical equipment) and SAE J1939 (used in heavy-duty vehicle and diesel engine networks like trucks, buses, and agricultural machinery). These higher-layer protocols define standardized message formats and application-level functions (for example, J1939 defines parameter group numbers for engine data, and CANopen defines object dictionaries for device control). Crucially, however, all of these protocols inherit the core CAN bus characteristics – notably the lack of any built-in security features​.

CAN communication is message-oriented and broadcast-based: any node on the bus can send a frame, and all others receive it. CAN frames contain an identifier (which also serves as priority) and up to 8 bytes of data (extended to 64 bytes in CAN FD, and 2048 bytes in the new CAN XL). There is no concept of an origin address or authentication in the CAN standard – nodes implicitly trust received messages as if they were from legitimate senders​. CANopen and J1939 operate on this same trust model. CANopen is used to coordinate devices (sensors, motors, etc.) in industrial systems, and J1939 coordinates engine, brake, and other control units in commercial vehicles. Both add useful high-level protocols but do not add security mechanisms like encryption or authentication by default​. This design approach, born in an era when networking was isolated, has made CAN-based systems a ripe target for attackers in modern, connected environments.

Inherent Security Vulnerabilities of CAN Bus Systems

Because of its trust-by-default design, the CAN bus and protocols built atop it have numerous theoretical and practical vulnerabilities. Security was not a consideration in the original design of CAN, so it lacks the defenses found in modern network protocols​. Key vulnerabilities include:

• Spoofing and Message Injection: Any device with access to the bus can transmit counterfeit CAN frames. There is no authentication of sender, so an attacker can masquerade as any ECU/device by sending a message with the appropriate ID. It is “trivial to…spoof traffic” on CAN​. For example, an attacker can inject a false engine RPM message or a forged command (like “unlock doors” or “inject more medication”) and other nodes will accept it as legitimate because the protocol cannot distinguish fake from real messages. This vulnerability is both theoretical and very much practical, as demonstrated by many real attacks (detailed in the next section).

• Lack of Confidentiality (Eavesdropping): CAN traffic is unencrypted. An adversary who taps into the bus (even via an exposed wire or connector) can read all data being transmitted​. In sensitive applications (e.g., a medical device network carrying patient data or an industrial robot reporting operations), this could leak confidential information. While eavesdropping on CAN is easier with physical access, researchers have also shown it can be done remotely if an attacker compromises a connected component that bridges into the CAN network (such as an automotive telematics unit or a medical device’s network interface).

• Denial-of-Service (DoS): A CAN attacker can easily perform DoS in multiple ways. Because CAN is a shared bus with priority arbitration, a malicious node can transmit continuous high-priority messages to flood the bus, preventing lower-priority traffic from getting through. More insidiously, researchers discovered that by abusing certain aspects of the CAN protocol (sending malformed frames or forcing error states), an attacker can knock CAN nodes offline. In 2017, one team showed a method to manipulate CAN protocol bits to force critical nodes into an error state, resulting in a bus-off condition (essentially crashing the CAN controller)​. The U.S. ICS-CERT alert on this CAN vulnerability warned it could let an attacker disrupt the availability of arbitrary functions in vehicles or devices by triggering a CAN bus shutdown​. Unlike simple flooding, this attack exploited the CAN error handling mechanism and could be achieved with just a few crafted frames, making it harder to detect with traditional frame-based intrusion detection​.

• Replay and Injection Attacks: Since CAN lacks sequence numbers or freshness checks, an attacker can record legitimate CAN messages and replay them later to cause unauthorized actions. For instance, a replayed “brake = ON” command could activate brakes at an improper time. Similarly, malformed or unexpected CAN frames can confuse or exploit firmware bugs in receivers. Security researchers have created maliciously crafted multi-frame packets in J1939 (which uses a transport protocol for messages larger than 8 bytes) to overflow memory or trigger logic errors in ECUs​. These attacks go beyond the standard CAN frame format and target implementation flaws in how higher-layer protocols (like J1939’s multi-packet transport) are handled.

• Physical Layer Access and Simple Interfaces: On many systems, gaining physical access to the CAN wiring or connector is relatively easy. All cars have an OBD-II diagnostic port that directly exposes the CAN network; heavy machinery often have accessible diagnostic or expansion connectors; medical devices might have maintenance ports. Once plugged in, an attacker has full access to send/receive CAN messages. Even without direct ports, attackers have found creative points of entry – as we’ll see in the car theft example, even a headlight wiring harness can serve as a CAN entry point. Additionally, tools to interface with CAN (dongles, transceivers, even open-source hardware) are inexpensive and widely available, lowering the bar for attackers. In summary, the CAN bus by itself provides no resistance to a determined intruder. The lack of authentication, encryption, or any baseline security in CAN means that if an adversary can talk on the bus, they can potentially control the system​.

Real-World Attacks and Incidents in Different Domains

Despite being theoretical for many years, CAN vulnerabilities have fully materialized in practice. Below we highlight real-world examples of hacking or intrusions on CAN/CANopen/J1939 systems across several domains, illustrating the consequences of these security gaps.

Automotive (Passenger Cars) – CAN Bus Car Hacking

Modern cars contain dozens of ECUs (electronic control units) interconnected via CAN. Attacks on automotive CAN networks have been extensively documented. A famous early example was the 2015 Jeep Cherokee hack, where researchers remotely compromised a Jeep over the internet and then injected CAN messages to disable the brakes and engine, leading to a recall of 1.4 million vehicles​. In that case, the attackers entered through an unsecure cellular-connected infotainment system and pivoted to the CAN bus, demonstrating the danger of CAN’s trust model once any entry-point is breached.

More recently, an epidemic of car thefts via CAN bus has emerged. Thieves are exploiting CAN vulnerabilities to bypass vehicle security without needing the owner’s key. One prevalent method is called “CAN Injection”. In vehicles like the Toyota RAV4, criminals access an exposed CAN wiring harness (often behind a headlight or other easily reachable component) and use a small electronic device to inject fake authorization messages onto the CAN bus​. For example, the attacker sends a message impersonating the smart key receiver ECU, indicating “Key validated” – which the engine control unit then trusts, thus deactivating the immobilizer and allowing the car to start​. They can similarly spoof a “door unlock” command on the CAN bus to open the doors​. All of this is done without the actual key: the car’s internal network believes a legitimate key was used when in fact it was a CAN injection attack. This keyless CAN bus attack has been used to steal vehicles in minutes. Indeed, black-market “emergency start” kits (CAN injector devices) have been found for sale online, enabling thieves to perform such attacks quickly by simply plugging into lighting connectors or other access points​. Because “most cars on the road today…aren’t protected” against forged internal messages, the CAN injection attack has proven effective across many models and manufacturers​. This real-world crime trend underscores how the lack of authentication in CAN directly leads to financial and safety impacts.

Beyond theft, researchers have shown many other automotive exploits via CAN. Attackers with internal access have manipulated critical functions: turning off lights or brakes, falsifying speedometer readings, or even hijacking steering (in vehicles with electric power steering). These attacks often involve sending CAN commands that the target ECU (e.g., brake controller) accepts as valid because it cannot distinguish source. In sum, car CAN buses are highly vulnerable if an attacker can gain a foothold, as demonstrated by both lab research and actual criminal activities.

Commercial Vehicles & Diesel Engine Networks (SAE J1939)

If passenger cars are vulnerable, heavy-duty vehicles (like trucks, buses, agricultural and construction machines) are equally at risk – perhaps even more so, given their often standardized J1939 CAN networks and potentially easier physical access points (fleet maintenance ports, etc.). In fact, researchers point out that security issues for commercial vehicles are especially serious because the stakes are higher – a compromised 18-wheeler or a bus could cause greater damage due to its mass and the critical cargo or passengers involved​.

A landmark demonstration in this domain was the “Truck Hacking” experiment (WOOT 2016) by researchers Burakova et al. They analyzed the SAE J1939 protocol used in trucks and buses and successfully executed multiple attack scenarios​. The attacks targeted instrument cluster, engine, and braking systems on actual heavy vehicles​. For example, the researchers were able to inject CAN messages on a truck’s J1939 network to manipulate the dashboard gauges, showing false readings to the driver​. They also injected messages to randomly change the engine’s RPM (revolutions per minute) without driver input, and even to disable the engine retarder/braking system on command​. These are not just benign tricks – disabling engine braking or spoofing engine control can have safety implications on downhill grades or heavy loads. The fact that they could do this on tractor trailers and school buses demonstrated that J1939 attacks span across different heavy vehicle types​.

Follow-up studies have continued to expose J1939-specific issues. Researchers have classified various denial-of-service attacks on truck networks, such as spamming the J1939 Request message or abusing the transport protocol connection management (TP.CM) to disrupt multi-packet data flows​. Others found that the address claiming mechanism in J1939 (which dynamically assigns addresses to ECUs) can be exploited – a malicious device can usurp the address of another, causing network confusion or masquerading as a critical ECU​. Another worrying vector is J1939’s support for multi-frame messages: if an ECU firmware doesn’t handle out-of-spec sequences properly, an attacker might send a series of fragmented packets to overflow buffers or put the ECU into an unstable state​. Recent work in 2023 expanded known J1939 attacks to a total of 14 scenarios (11 of which were proven feasible on real hardware), including novel attacks that inject a single malicious CAN frame to cause disproportionate effects​.

Real-world incidents on heavy vehicles are less publicized than car hacks, but the risk is recognized. The Cyber Truck Challenge, an annual event, now brings together experts to probe and improve truck cybersecurity​. One can imagine the potential outcomes if attackers gained control: a truck’s engine could be killed on the highway, or a forklift’s hydraulics could be weaponized. In the agriculture sector, where tractors and combines increasingly use CAN (often ISO 11783, which is similar to J1939), there have been reports of farmers “jailbreaking” tractor software for repair – a benign use-case, but the same methods could be used maliciously to disable safety controls. Overall, heavy vehicles’ CAN-based networks share the same lack of security as cars, and demonstrations have proven they can be hacked with effects ranging from mischief (dashboard manipulation) to serious safety hazards.

Medical Devices – Infusion Pumps and Diagnostics

Medical devices have become smarter and more networked, and many larger devices (like infusion pump systems, ventilators, or imaging machines) internally use embedded networks akin to CAN to coordinate components. CANopen is sometimes used in medical equipment for its reliability in real-time control. Unfortunately, the medical field has seen its share of CAN-related vulnerabilities as well, often with direct patient safety implications.

A striking example came in 2021, when McAfee’s Advanced Threat Research disclosed vulnerabilities in the widely used B. Braun Infusomat Space infusion pump system. This infusion pump (and its docking station called SpaceStation) uses an internal CAN bus to allow multiple pumps and modules to communicate when docked​. The researchers found that the pump’s communication interface did not require authentication and transmitted data unencrypted – essentially the CAN-based protocol between pump and station was wide open​. By exploiting software flaws in the pump, they were able to inject commands over this CAN bus to modify the pump’s configuration and dosing parameters. In fact, an attacker with network access to the device could put it in maintenance mode and then send CAN messages (via a compromised component) to trick the pump into delivering an unexpected dose of medication to the patient, all without any valid credentials​. This is a chilling scenario: a hacker could potentially cause an overdose or stop medication delivery by exploiting the lack of security on the CAN-based control messages.

The infusion pump case highlights how the lack of CAN security directly translates to patient risk. The device’s designers assumed the internal CAN network would be shielded from threats, but once researchers got in, they found “the protocol is both unencrypted and unauthenticated, posing a serious risk”​. The U.S. FDA and DHS have similarly warned about vulnerabilities in medical devices that use standard communication buses. In 2017, ICS-CERT specifically alerted that CAN bus vulnerabilities could affect healthcare systems​. Besides infusion pumps, think of other examples: an insulin pump or a dialysis machine could have internal CANopen networks coordinating sensors and actuators – if an attacker breaches the device (perhaps via an update port or connected hospital network), they could inject CAN messages to alter treatment. Diagnostic machines (like MRI or CT scanners) also have many subsystems; an internal CAN bus might link the gantry movement, the cooling system, etc. Insecure CAN could allow an attacker to damage the machine or injure a patient (for instance, by disabling interlocks or mis-positioning a laser). While no public case of a patient harm via CAN hack has been reported to date, researchers have demonstrated proof-of-concept attacks on medical devices, urging manufacturers to not ignore these risks.

Industrial Automation and Robotics – ICS Attacks via CAN/CANopen

In industrial automation, CAN buses and their higher-layer variants are used in various contexts: factory robots, programmable logic controllers (PLCs) with CAN interfaces, motor controllers, and even building automation. Two common CAN-based protocols in industry are DeviceNet (used in some PLC and I/O networks, mainly in North America) and CANopen (common in Europe and for robotics). These protocols, being based on CAN, suffer the same inherent weaknesses. In fact, as one security study noted, “DeviceNet inherits all the vulnerabilities that were already illustrated on CAN in-vehicle communication”​ – meaning attacks pioneered on cars can often be repurposed against industrial CAN systems.

Industrial control system (ICS) security researchers have indeed explored this. For instance, a 2018 analysis by Murvay et al. examined DeviceNet and showed how an attacker could exploit the lack of authentication in the network join process to masquerade as a new node or disrupt node addressing​. They demonstrated that by sending crafted CAN frames during the DeviceNet MAC ID assignment, a malicious device could cause a legitimate controller to enter a fault state​. Other work has shown how lack of encryption on CANopen/DeviceNet traffic means an intruder could sniff sensitive data from industrial sensors or even insert false sensor readings that lead to dangerous actions (for example, tricking a robot arm’s controller into thinking a safety sensor was tripped, causing abrupt stops or moves).

Real incidents in the ICS world have included attacks where fieldbus networks were accessible. While many ICS compromises focus on Ethernet-based protocols (like OPC UA, Modbus/TCP), there have been reports of attackers manipulating lower-level fieldbuses once inside. In one hypothetical scenario, an attacker who penetrated a manufacturing plant’s IT network pivoted to the control network and sent forged CANopen commands to a robot’s motor controllers, causing unexpected movements. Robotics researchers at a Black Hat conference showed how lacking security, industrial robots could be forced to operate outside safety limits by sending unauthorized commands to actuators – potentially causing physical harm or production faults (e.g., a “rogue robot” that could ignore safety stop commands due to a spoofed state message).

Another illustrative case is in building automation or transportation systems. Some light rail and train systems use CAN for control (sometimes called CANopen Lift in elevators, or similar). Without security, an attacker on the network could send a command to a CANopen-based elevator controller to move to a different floor or disable safety sensors. The broad use of CAN in critical manufacturing and transportation led the U.S. government to warn that sectors like “Critical Manufacturing and Public Health (healthcare) rely on CAN, and exploitation could disrupt operations”​. In summary, industrial CAN networks, just like automotive ones, are vulnerable to malicious injections, eavesdropping, and DoS – and while not as publicized, the threat is very real as factories and utilities become more connected.

Lack of Native Security Mechanisms in CAN Systems

Across all these domains, a common theme is the absence of built-in security in CAN and its protocols. Classic CAN offers no native encryption, no source authentication, and no integrity checking​. CANopen and J1939, being higher-layer implementations, historically also did not mandate any cryptographic security. This means that CAN-based systems are essentially operating on a model of trust, assuming that anything on the bus is supposed to be there and is valid. Unlike IP networks, where one can deploy firewalls, require TLS for authentication, etc., CAN networks traditionally had no such defenses.

Why is there such a lack of native security? Largely it’s historical and technical: when CAN was designed (1980s), it was intended for closed, physically secure environments (inside a car or machine) where external threats were not a concern. The primary goals were real-time performance and reliability, not security​. CAN achieves low latency by being lightweight – but that leaves no room in the frame for extras like source addresses or cryptographic hashes (each classic CAN frame has at most 8 data bytes, and adding security would consume some of that, potentially impacting real-time performance​). As a result, most CAN implementations implicitly trust messages, and any node can act as any other node if it simply sends a message with the appropriate identifier​. There is also no built-in notion of access control – every node sees all traffic and could attempt to send on any ID.

Furthermore, CAN lacks a native concept of message freshness or sequencing. This makes detecting replay attacks very difficult without higher-layer logic. Error handling in CAN is robust for random faults, but it wasn’t intended to handle intentional malicious behavior – thus, targeted attacks can abuse the error mechanism (as in the bus-off attack) since the protocol doesn’t have an anti-abuse feature there​.

The higher-layer standards like SAE J1939 and CANopen did not originally include security extensions either. They presumed the underlying bus was trusted. For example, J1939’s address claiming can be overtaken by a spoofed claimant because there’s no cryptographic handshake to verify identity. CANopen’s Safety extension (EN 50325-5) ensures functional safety (consistency of data) but not cybersecurity – it detects communication errors, not malicious tampering. The net effect is that most CAN-based systems up through the 2010s had zero cyber security at the protocol level. Any security had to be provided externally (e.g., by isolating the network or adding custom checks in the application software).

This lack of native security has been explicitly recognized in the industry. For instance, the ODVA (which manages DeviceNet) acknowledged that adding modern security on the resource-limited CAN devices is challenging, and initial efforts have focused on the newer Ethernet-based protocols​. In the meantime, it’s well-understood that “the lack of security in DeviceNet [or CANopen] can be exploited”, just as in automotive CAN​. To put it bluntly, CAN bus is inherently insecure by design, and all devices/networks that rely on it must treat it as a vulnerable channel.

Emerging Security Enhancements and Mitigations (Post-2020)

Recognizing the severity of CAN’s vulnerabilities, the automotive and industrial communities have in recent years accelerated efforts to bolster CAN security. Post-2020, several new standards, protocols, and best practices have been developed or adopted to mitigate these issues:

• Secure CAN Protocol Extensions (CAN FD Secure / CANsec and J1939-91C): One promising avenue is to build security into updated versions of CAN at the protocol level. The latest generation of CAN, known as CAN XL (or CAN 3.0), introduces a feature called CANsec. “CANsec is part of the third CAN bus generation CAN XL and allows authentication, encryption, and integrity checking of CAN frames.”​. In essence, CANsec is analogous to a light-weight security layer for CAN, ensuring that each frame can carry a cryptographic authentication tag (and encryption if needed) without sacrificing too much performance. This was made practical by CAN XL’s much larger frame size (up to 2048 bytes, vs 8 bytes in classic CAN)​. With more payload, adding a security footer (e.g., a message authentication code and maybe an encrypted payload segment) becomes feasible. CANsec is still in development (as of mid-2020s) but is a major step toward “securing CAN communication through authentication, encryption, and integrity checks”​. Similarly, in the heavy vehicle realm, SAE has developed J1939-91C, a new recommended practice for security on J1939 networks. J1939-91C is designed to work over CAN FD (the CAN with Flexible Data-rate) and defines a method to authenticate and optionally encrypt J1939 messages​. The standard “ensures message authenticity, integrity, and confidentiality by implementing complex cryptographic operations” for CAN-based communications​. In practical terms, J1939-91C introduces a key management scheme and message signing so that ECUs in a truck can trust that critical commands (like brake controls or engine messages) are coming from valid sources and haven’t been tampered. As a trade-off, it will require more bandwidth (hence the need for CAN FD’s larger frames) and compatible hardware. Both CANsec and J1939-91C emerged after 2020 and represent the industry’s acknowledgement that security must be built into CAN at the protocol level going forward.

• Higher-Layer Message Security (AUTOSAR SecOC and CANcrypt): Even before CANsec, the automotive industry introduced software-layer security for CAN messages. The AUTOSAR consortium (which standardizes automotive software architecture) created the Secure Onboard Communication (SecOC) module. SecOC, widely adopted in vehicles around 2020+, adds authentication to critical CAN messages by sending a Message Authentication Code (MAC) alongside the normal data (either in unused bits of CAN frames or in separate frames)​. It basically implements a form of challenge-response or rolling code to detect if a message was spoofed or altered. While effective, it has overhead and can strain the bus (since CAN was not designed for extra bytes)​. Nonetheless, many modern cars are now using variations of this to secure things like diagnostic commands or safety signals. In the industrial space, there are also initiatives like CANcrypt – an open protocol by CAN experts that provides group key management and encrypted messaging on CAN. CANcrypt can work with CANopen or other higher-layer protocols by using a portion of CAN bandwidth for security messages, allowing up to 15 nodes to communicate securely with symmetric encryption and authentication tags​. It’s a retrofit approach that can be added to existing CAN networks at the application layer. These higher-layer solutions are not standardized across all manufacturers but offer ways to significantly harden CAN communications against spoofing (by detecting unexpected messages) and eavesdropping (by encrypting payloads).

• Intrusion Detection Systems (IDS) and Anomaly Detection: Another post-2020 trend is deploying CAN Intrusion Detection Systems in vehicles and ICS environments. Because CAN traffic consists of many periodic, predictable messages, an IDS can learn the normal patterns and flag anomalies (e.g., an ID that should never be sent by a certain ECU suddenly appears, or message frequency changes). Several commercial automotive cybersecurity firms have developed IDS solutions that integrate into car network gateways or firewalls. While IDS doesn’t prevent an attack by itself, it can at least alert or trigger failsafes. Research efforts (and competitions like the Car Hacking CTFs) have spurred improved detection algorithms that can catch even single-frame attacks in some cases​. Automakers are starting to include such monitoring in new models, especially as required by new standards (described next). In industrial settings, similar monitoring can be done on CANopen/DeviceNet segments to detect unusual commands (for example, a sudden Emergency Stop message on a robot’s CAN bus when no maintenance is scheduled).

• Segmentation and Gateway Security: Since many modern systems have multiple CAN buses connected via gateways (as shown in the RAV4 diagram above with red/green buses), one mitigation is to implement intelligent gateways that filter or firewall CAN traffic between segments. For instance, a vehicle gateway can be configured to not pass certain sensitive messages from an infotainment CAN segment to a powertrain CAN segment, or to enforce that only expected ECU IDs communicate across. This doesn’t solve in-segment attacks but can contain a compromise. Some vehicle architectures introduced after 2020 use a “zonal” architecture (grouping ECUs by physical zone) with strong gateway controls, effectively isolating critical CAN networks (like braking) from less-trusted ones (like door locks)​. In industrial control, an analogy is segmenting a CANopen machine network from the plant’s main network with a secured controller that checks commands.

• Regulations and Standards for Cybersecurity: Importantly, governance has caught up. In 2021, the United Nations Economic Commission for Europe (UNECE) implemented UN Regulation No.155 (R155) on vehicle cybersecurity, which has since been adopted in Europe, Japan, and elsewhere​. R155 mandates that manufacturers implement a Cybersecurity Management System and take measures against a list of attack vectors – including network message spoofing. In practice, this forces automakers to deploy some combination of the above techniques (message authentication, IDS, secure gateways) to protect the CAN bus. Similarly, the automotive cybersecurity standard ISO/SAE 21434:2021 provides a framework for car makers to assess risks and mitigate them throughout the electrical architecture – which invariably means addressing CAN weaknesses in design. For commercial vehicles, the upcoming SAE J3061/ISO 21327 guidelines and the existing J1939-91A (which deals with physical security of the diagnostic port) complement this by focusing on heavy-duty use cases​. In the medical device sphere, updated FDA guidance (per the 2022 FDA Safety and Performance Final Guidance) now expects manufacturers to secure communications in devices – which would include internal CAN links (e.g., ensuring that a pump’s therapy commands can’t be altered by an external attack). Standards like IEC 62443 for industrial control system security also encourage defense-in-depth, which covers securing lower-level fieldbus traffic or at least isolating it.

• Future Network Technologies: Finally, one mitigation is the gradual shift away from CAN for certain applications. Automotive designs are increasingly using Automotive Ethernet for high-bandwidth needs, and Ethernet-based protocols come with established security (TLS, IPsec, etc.). For example, the infotainment or advanced driver-assistance data might move to Ethernet (with encryption), reducing exposure of CAN to only the most time-critical controls. Similarly, some industrial systems might opt for Ethernet-based fieldbuses or use CAN-FD only within a single secure controller and not plant-wide. Where CAN is still the best fit (for real-time control), the above-mentioned additions of authentication (either via new CANsec/J1939-91C or via software like CANcrypt) aim to make “zero-trust” CAN networks a reality – i.e., each critical message carries proof of authenticity​ so that nodes no longer blindly trust every message.

In conclusion, the CAN bus and its derivatives (CANopen, J1939) have historically been a security blind spot, lacking native protections and thus exposing vehicles, medical devices, and industrial systems to potential cyberattack. The vulnerabilities are both theoretical (rooted in design) and practical (exploited in the field by researchers and criminals alike). We have seen cars overtaken, trucks manipulated, and medical pumps subverted by leveraging CAN’s weaknesses. The industry has learned hard lessons from these examples – and post-2020 we are finally seeing substantive steps to secure CAN-based communications, from new secure protocol standards to regulatory mandates. While legacy CAN systems in the field will remain vulnerable for some time, future implementations with features like CANsec or J1939-91C, combined with better network segmentation and monitoring, promise to greatly reduce the attack surface. The path forward for CAN is to evolve from an open, unguarded network to one that can cryptographically verify the integrity of critical messages, ensuring the safety and security of the countless embedded systems that rely on this technology.

Sources: The analysis above is based on a range of recent research and reports on CAN vulnerabilities and security enhancements, including academic studies of vehicle CAN bus attacks​, real-world incident investigations (car theft via CAN injection)​, industrial control system assessments​, medical device vulnerability disclosures​, and new security standards documentation​, among others. These illustrate both the problems and the solutions in securing CAN-based networks.