---
title: "Remote Attack on CAN — Service Interfaces and Gateways"
canonical_url: https://can-security.net/threats/remote-attack/
description: "Gateways, diagnostic ports, remote-service interfaces, and wireless maintenance links open indirect remote attack paths into otherwise isolated CAN networks."
last_updated: 2026-08-27
---
# 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](https://can-security.net/resources/iec-62443-sl2-requirements/) [NIST SP 800-82](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-82) [ISO/IEC 27001](https://can-security.net/resources/terms-and-definitions/#term-iso-iec-27001)

## Reducing Remote Attack Surface

[CRA](https://can-security.net/resources/terms-and-definitions/#term-cra) Article 13 and [IEC 62443](https://can-security.net/resources/terms-and-definitions/#term-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](https://can-security.net/resources/terms-and-definitions/#term-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](https://can-security.net/risk-assessment/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.