Key takeaways
- Not fully, and only the newest generation attempts to.
- Treat bus access as the actual security boundary, not a formality.
CAN (Controller Area Network) is the broadcast serial bus Bosch released in 1986 and ISO standardized as ISO 11898 — every node sees every message, any node can transmit, and the protocol has no field for a sender identity, a credential or a message signature anywhere in its design. That design choice shows up directly in two real CISA ICS alerts, and it has not changed through CAN FD; only the newest generation, CAN XL, has an optional (and still maturing) security layer called CANsec. For machine builders putting CAN-connected controllers into industrial equipment, vehicles or off-highway machinery, the practical question is less "is CAN secure" and more "what, if anything, sits on top of CAN to compensate for the fact that it isn't."
What is CAN, and why was it never designed with security in mind?
Robert Bosch GmbH developed CAN in the early 1980s to reduce the point-to-point wiring harness complexity of automotive electronics, publicly releasing the protocol in 1986; it became an ISO standard in 1993 (commonly referenced as CAN 2.0A) and was extended for longer identifiers in 1995 (CAN 2.0B). ISO splits the standard into two parts: ISO 11898-1 specifies the data link layer, and ISO 11898-2 specifies the physical layer for high-speed CAN. CAN's defining architectural property is that it is a multi-master, broadcast bus: when the bus is idle, any connected node may transmit, and every other node on the same electrical segment receives and can act on every frame, with message priority resolved by a non-destructive bitwise arbitration scheme rather than a central controller granting permission. That design — optimized for deterministic low latency and minimal per-node silicon cost inside a single trusted wiring harness — is also exactly why CAN has no sender-authentication field: the protocol was never meant to distinguish a legitimate electronic control unit (ECU) from any other device electrically connected to the same bus. CAN today runs far beyond passenger cars: SAE J1939, a higher-layer protocol built on CAN's data link and physical layers, standardizes its use in trucks, buses, construction equipment and agricultural machinery, and industrial automation uses CANopen as its own higher-layer CAN protocol for motor drives, I/O modules and other machine-control devices.
| CAN design property | Security implication |
|---|---|
| Broadcast, multi-master | Every node reads every frame; there is no way to address a message privately to one recipient at the protocol level |
| No sender-identity field | A receiving node cannot verify which physical device actually sent a given frame |
| No authentication or encryption in the base frame | Any device electrically connected to the bus can inject, by design, as valid a frame as any legitimate ECU |
| Priority-based arbitration, no central access control | Nothing in the protocol itself limits which node may transmit or when, beyond message priority |
Do CAN FD or CAN XL fix CAN's lack of security?
Not fully, and only the newest generation attempts to. CAN FD (Flexible Data Rate), added to ISO 11898-1 in 2012, increases the maximum data rate and the payload per frame (from CAN classic's 8 bytes up to 64 bytes), but it keeps the same broadcast, no-authentication frame model — CAN FD is a throughput and payload upgrade, not a security one. CAN XL, standardized in the current ISO 11898-1:2024 (Edition 3 — an 82-page document that, for the first time, specifies three protocol generations together: CAN CC/classic, CAN FD and CAN XL, with data fields up to 2048 bytes under CAN XL), is the first generation where a real security mechanism exists as an option: CANsec, documented by CAN in Automation as CiA 613-2, is explicitly modeled on IEEE 802.1AE MACsec (Ethernet's own frame-authentication standard) and defines authenticated, optionally encrypted CAN XL frames using AEAD (Authenticated Encryption with Associated Data). As of this guide's research, CANsec is a working specification under active development — published technical research describes ongoing work on which cryptographic cipher suite to standardize and on reusing existing MACsec hardware/software as CANsec's underlying security engine, which indicates an evolving ecosystem rather than one with broad, settled deployment. A device or vehicle described as "running CAN XL" is not automatically running CANsec; the two are separate claims a buyer should verify against the specific product's documentation, not infer from one another.
What have real CISA alerts found in CAN bus deployments?
Two CISA alerts, years apart, both requiring physical or electrical access to the bus rather than a remote network attack — consistent with CAN's design as a bus for a physically enclosed wiring harness, not a networked, internet-facing protocol.
| Alert | Year | What it found | Access required | CISA's mitigation |
|---|---|---|---|---|
| ICS-ALERT-17-209-01 | 2017 (last revised) | A bit-level manipulation technique (targeting individual recessive/dominant bits rather than whole frames) that forces a CAN node into its "bus-off" error state, silencing it — disclosed by researchers Andrea Palanca, Eric Evenchick, Federico Maggi and Stefano Zanero | Electrical connection to the bus, typically via an automobile's OBD-II port | "Limit access to input ports (specifically OBD-II) on automobiles" |
| ICS-ALERT-19-211-01 | 2019 | Insecure CAN bus implementation in small-aircraft avionics, reported by Rapid7: an attacker could inject false engine, compass/attitude, altitude, airspeed or angle-of-attack readings indistinguishable from real ones by a pilot reading cockpit instruments | Unsupervised physical access to the aircraft, to attach a device to the avionics CAN bus | Restrict physical aircraft access; manufacturers evaluate CAN bus filtering, whitelisting and network segregation |
Neither alert resulted in a CVE identifier (both predate the routine CVE-tagging now standard on most CISA ICS advisories), and neither is remotely exploitable over a network — the common thread is that CAN's complete absence of sender authentication means that whoever can physically or electrically reach the bus can act as any other node on it, whether that bus sits in a car, a small aircraft, or an industrial machine's control cabinet.
What should a machine builder or integrator check first?
Inventory every CAN-connected ECU and controller, and every physical access point to the bus — OBD-II or diagnostic connectors, wiring harness junctions, service ports — since CAN's security model, such as it is, depends entirely on controlling who can physically or electrically reach the bus. Treat bus access as the actual security boundary, not a formality. Restrict and monitor diagnostic ports and harness access points the way ICS-ALERT-17-209-01's mitigation implies, rather than assuming a locked enclosure or a vehicle's body panels are sufficient on their own. Segment safety- or mission-critical CAN domains from less-trusted ones— powertrain or protection-relevant traffic from infotainment, telematics modems, or aftermarket diagnostic tools — behind a gateway ECU that limits what can cross between segments, rather than running every function on one flat bus. Check whether a higher-layer authentication mechanism is actually designed in, such as AUTOSAR SecOC for automotive ECUs or CANsec for CAN XL deployments, rather than assuming "runs on CAN" implies any message-level integrity protection exists — the base protocol provides none. Fold CAN-connected controller firmware into the same SBOM and firmware risk review as any other embedded deviceThe ECU or industrial controller's firmware — not the CAN bus itself — is usually where hard-coded keys, outdated protocol stacks or other exploitable weaknesses actually live, and that firmware needs the same scrutiny regardless of which bus the device happens to use.
Checking a CAN-connected controller's actual firmware — what keys and credentials are embedded in it, what components and versions it's built from, and whether it implements message authentication where the design calls for it — is firmware-level work, not something a bus-protocol specification alone can confirm: see SoftWSP's device & firmware security services.
This guide draws on ISO's own catalogue and scope text for ISO 11898-1 (2015 and 2024 editions), two CISA ICS alerts fetched directly, SAE International's published top-level J1939 document description, and a Fraunhofer IPMS whitepaper on CANsec alongside other widely corroborated independent technical research on CAN, J1939 and CANsec. CiA 613-2's full specification text was not purchased or independently reviewed for this guide, so treat CANsec implementation details as general description, to be confirmed against the current CiA specification and a specific product's documentation. This guide is general information, not a substitute for the purchased ISO/SAE/CiA standard texts, a vendor's product-specific security documentation, or a current CISA ICS advisory search for your exact hardware.
Sources
- ISO: ISO 11898-1:2024 — Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical coding sublayer (Edition 3, published 2024-05, 82 pages, supersedes the 2015 edition)
- ISO: ISO 11898-1:2015 — Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling (withdrawn edition, scope record)
- CISA ICS Alert ICS-ALERT-17-209-01: CAN Bus Standard Vulnerability (last revised 3 August 2017)
- CISA ICS Alert ICS-ALERT-19-211-01: CAN Bus Network Implementation in Avionics (30 July 2019)
- SAE International: J1939_202306, Serial Control and Communications Heavy-Duty Vehicle Network — Top-Level Document
- Fraunhofer IPMS: CANsec — Security for the Third Generation of the CAN Bus (whitepaper PDF)
Frequently asked questions
Does the CAN bus have any built-in authentication or encryption?
No. CAN (Controller Area Network) is a broadcast, multi-master serial bus: per its design, any node connected to the bus can transmit when the bus is idle, and every other node receives and processes every frame — there is no concept of a sender identity field, a credential, or a message-origin check anywhere in the base protocol. Bosch released CAN publicly in 1986 for automotive wiring-harness reduction, and it became an ISO standard (ISO 11898) in 1993; the standard has been revised several times since — most recently as a three-edition structure (ISO 11898-1:2024, covering the data link layer and physical coding sublayer, superseding the 2015 edition) — but no revision has added authentication, encryption or integrity-checking to the base CAN frame itself. This is a direct consequence of CAN's original design goals: minimal per-node hardware cost and deterministic, low-latency arbitration between electronic control units (ECUs) in a trusted, physically enclosed wiring harness, not resistance to an attacker who can already reach the bus electrically.
What have real CISA alerts found in CAN bus deployments?
Two, both requiring physical or electrical access to the bus rather than remote network access, and neither resulting in a CVE assignment (both predate CISA's routine CVE tagging of every ICS finding). CISA's ICS-ALERT-17-209-01 (last revised 3 August 2017) describes a denial-of-service technique researchers Andrea Palanca, Eric Evenchick, Federico Maggi and Stefano Zanero disclosed through coordinated vulnerability disclosure: rather than targeting whole frames, the technique manipulates individual recessive/dominant bits to force a CAN node into its error-handling "bus-off" state, silencing it. CISA's stated mitigation was narrow — "limit access to input ports (specifically OBD-II) on automobiles" — reflecting that the underlying weakness is architectural to CAN itself, not a single vendor's bug to patch. CISA's ICS-ALERT-19-211-01 (30 July 2019), based on a report from Rapid7, covers insecure CAN bus implementations in small-aircraft avionics: an attacker with unsupervised physical access to the aircraft could attach a device to the avionics CAN bus and inject false engine telemetry, compass/attitude, altitude, airspeed or angle-of-attack data that a pilot reading cockpit instruments would have no way to distinguish from legitimate readings. CISA's recommended mitigations were physical-access restriction plus manufacturer-level CAN bus filtering, whitelisting and segregation — the same category of control the automotive industry had already begun adopting for the 2017 finding.
Do CAN FD and CAN XL fix CAN's lack of security?
CAN FD (Flexible Data Rate, added to ISO 11898-1 in 2012) increases maximum data rate and payload size per frame but adds no authentication, encryption or integrity mechanism — it inherits the same broadcast, no-sender-identity design as classic CAN. CAN XL, standardized in the current ISO 11898-1:2024 (Edition 3, which specifies three protocol generations — CAN CC/classic, CAN FD and CAN XL — in one 82-page document replacing the 2015 edition), is the first generation where an optional security layer exists: CANsec, documented as CiA 613-2 by CAN in Automation, is explicitly modeled on IEEE 802.1AE MACsec (the Ethernet security standard) and provides authenticated, optionally encrypted CAN XL frames using AEAD. As of this guide's research, CANsec is a working specification under active development by a CiA task force, not a settled, broadly deployed standard — independent published research describes ongoing work on cipher-suite selection and on reusing existing MACsec implementations as CANsec's security engine, which is a sign of an evolving rather than finished ecosystem. A buyer or integrator should treat "the device uses CAN XL" and "the device has CANsec enabled and configured" as two separate claims to verify, not one.
Is there anything already deployed today that authenticates CAN messages?
Yes, but it sits above CAN itself, not inside it, and it is not universal. AUTOSAR — the automotive software architecture standard most passenger-vehicle and many commercial-vehicle ECUs are built on — defines SecOC (Secure Onboard Communication), a module that adds a message authentication code and freshness counter to selected CAN messages at the application layer, using a symmetric key shared between sender and receiver ECUs. SecOC has to be deliberately designed into a vehicle's or machine's electrical architecture message-by-message (which signals get authenticated, which don't, and how keys are provisioned and rotated) — it is not a property CAN itself provides, and a machine builder cannot assume a CAN-based control system has it just because the ECUs happen to run AUTOSAR. Industrial equipment built on SAE J1939 — the higher-layer protocol standardizing CAN use in trucks, construction equipment, agricultural machinery and other off-highway vehicles via extended 29-bit CAN identifiers — has no equivalent built-in authentication layer of its own; published security research on J1939 describes the same broadcast trust model and resulting attack surface as classic automotive CAN, just applied to a different fleet of machines.
In this cluster
