Remote Entry Points into CAN Networks
CAN itself is not a remote-network protocol, but most CAN systems have at least one externally reachable interface, such as a bridge, router, or gateway between segments, a diagnostic port, a remote-service link, a wireless maintenance interface, or an asset-management connection. This page explains how those interfaces become CAN attack vectors and what to do about it.
How Remote Attacks Reach CAN
Remote attacks reach CAN by compromising a bridge, router, gateway, or other device that connects an external network or another CAN segment to the bus. Once that connection point is under attacker control, the attacker transmits arbitrary CAN frames as if physically attached. Examples for such devices include:
- diagnostic and service connectors that aftermarket dongles, maintenance tools, and data loggers attach to, frequently with weak authentication or unpatched firmware
- remote-service and asset-management gateways that bring cellular, Wi-Fi, or Ethernet connectivity directly to CAN for predictive maintenance, asset tracking, or operational data collection
- bridges or routers between CAN segments, where a compromised lower-trust-zone device routes attacker traffic into a higher-trust segment regardless of whether the device operates as a transparent data-link bridge, a routing forwarder, or a translating gateway
Out of scope: external-interface protection
This reference covers CAN-specific security. The protection mechanisms that secure cellular, Wi-Fi, Ethernet, or any other external interface in front of a bridge, router, or gateway are general industrial and IT cybersecurity practice; they are not specific to CAN. Existing standards cover them well: IEC 62443-3-3 (zone-and-conduit), NIST SP 800-82 (OT firewalling), and ISO/IEC 27001. Manufacturers must apply current best-practice protection to every bridge, router, and gateway that fronts a CAN bus: TLS, mutual authentication, certificate management, secure update, network segmentation, and vulnerability management. The sections that follow describe what becomes a CAN attack vector once an attacker has reached one of those external surfaces. IEC 62443-3-3 NIST SP 800-82 ISO/IEC 27001
Reducing Remote Attack Surface
CRA Article 13 and IEC 62443 SR 7.6 push for minimizing and
hardening these interfaces, so the most cost-effective control
is reducing their number; every removed interface is a vector
that no longer needs hardening. For interfaces that must
remain, enforce TLS or TLS-PSK, segment networks, and limit
which CAN IDs can cross any bridge, router, or gateway. Every
such device must be designed under the assumption that it is
the security perimeter;
see Secure
Gateways for the implementation.
Note: the EmSA-WP-101 Security Justification for classical CAN explicitly warns that service technicians and operators may add remote-access devices post-deployment, so the threat model must include unauthorized additions, not just the manufacturer's intended interfaces.
Frequently Asked Questions
Are diagnostic ports a CAN attack vector?
Yes. Diagnostic and service connectors typically expose direct physical access to one or more CAN segments. Aftermarket dongles and maintenance tools attached to these ports are a common attack surface; many ship with weak authentication or unpatched firmware.
Why are post-deployment add-ons a security concern?
Service technicians and operators often add devices the manufacturer did not anticipate, such as remote-monitoring dongles, data loggers, and third-party control modules. These extend the attack surface in ways that are not in the original threat model. The EmSA-WP-101 Security Justification for classical CAN explicitly calls out this risk; the threat model must include unauthorized post-deployment additions.