CAN Security in 2026: What CANsec Changes—and What Machine Builders Must Secure Today

CAN networks are still a strong engineering choice for embedded control, machines, vehicles, distributed I/O and intelligent devices. The cybersecurity problem appears when a network that was once physically isolated becomes connected to Ethernet, remote service, cloud platforms, USB diagnostic tools or third-party gateways.

That is why CiA 613-2 CANsec for CAN XL matters. It is a useful step towards data-link-layer security, but it is not a magic retrofit for existing CAN or CAN FD machines. I would start by looking at the attack paths that already exist: gateways, diagnostics, firmware updates, remote service and engineering access. That usually tells you where the real work is.

Why CAN security deserves attention now

CAN in Automation (CiA) released version 1.0.0 of CiA 613-2 on 29 May 2026 as a Draft Specification Proposal. The CANsec data plane is intended to protect data integrity, freshness, authenticity of origin and confidentiality in CAN XL communication. It reuses security concepts from MACsec, while key exchange and distribution remain outside the scope of the current data-plane specification.

CiA’s current September 2026 material also shows that security work is broader than CAN XL alone. The organisation is highlighting CANopen and CANopen FD cybersecurity, its higher-layer-protocol cybersecurity group continues work on secure key management, and the latest CAN Community News discusses secure third-party access to vehicle networks under increasingly strict cybersecurity requirements.

For industrial users, the relevance is straightforward. A CAN bus inside a sealed machine is a very different threat model from the same bus exposed through a remote-maintenance gateway, an Ethernet-connected controller, an engineering laptop or a supplier’s service interface.

First principle: CAN robustness is not the same as cybersecurity

Classical CAN and CAN FD are designed for reliable communication in electrically noisy and fault-prone environments. Arbitration, CRC checking, acknowledgement, error detection and fault confinement are valuable engineering mechanisms, but they do not prove that a transmitting node is authorised.

A CAN identifier is not an identity credential. A valid frame can still be malicious if it comes from the wrong device, at the wrong time, or with intentionally altered application data. The security design must therefore sit across several layers: physical access, device identity, diagnostics, firmware, gateway policy, network monitoring and, where justified, cryptographic protection.

What CANsec adds to CAN XL

CANsec property	Engineering value
Integrity	Helps detect protected data that has been modified in transit.
Freshness	Helps defend against replay of previously valid protected communication.
Authenticity of origin	Allows a receiver to verify that protected communication came from the expected security association.
Confidentiality	Allows selected CAN XL data to be protected against passive reading where the application requires it.
Data-link integration	Makes security an optional CAN XL add-on rather than forcing every application to invent a proprietary protection format.

That is useful, particularly for long-life platforms and networks that will carry richer diagnostic, configuration and management data. However, the key-management architecture still has to be engineered. Keys must be provisioned, protected, renewed and recovered without creating an impossible service problem in the field.

What CANsec does not solve

It is equally important to understand the limits. CANsec does not automatically secure:

existing Classical CAN or CAN FD devices that do not implement a corresponding security layer;
an Ethernet or cloud gateway that has weak credentials or unnecessary open services;
a maintenance laptop that is already compromised;
an exposed JTAG/SWD/programming interface;
unsigned or poorly controlled firmware updates;
incorrect gateway rules that forward more traffic than required;
poorly managed cryptographic keys; or
availability against every denial-of-service scenario.

Cybersecurity and functional safety also remain different engineering disciplines. Security mechanisms can support a safety case by reducing malicious interference, but they do not replace safe-state design, safety-related communication or the required validation of the safety function.

What to secure on CAN and CAN FD systems today

1. Define the actual trust boundaries

Start with the network drawing rather than with an encryption algorithm. Identify every CAN segment, gateway, engineering port, wireless link, Ethernet connection, cloud connector, diagnostic connector and firmware-update path. Then decide which of those interfaces is trusted, conditionally trusted or untrusted.

This usually reveals that the highest-risk point is not the two-wire CAN bus itself. It is often the bridge between the CAN domain and something more accessible.

2. Segment networks instead of creating one large trust zone

A gateway should not automatically forward every identifier in both directions. Separate control, diagnostics, service and external connectivity where practical. Use explicit allow-lists, message filters and direction rules. If two CAN networks only need five signals exchanged, the gateway should not behave like an unrestricted cable between them.

Current devices such as the Ixxat CANbridge NT 420 support CAN/CAN FD segmentation together with filtering, identifier translation, mapping and configurable access levels for configuration or firmware upload. These functions are useful building blocks, but the security policy still has to be designed correctly.

3. Treat diagnostic access as privileged access

Commissioning and maintenance functions frequently have more authority than normal cyclic control traffic. Disable unused services, restrict engineering access, control who can change node parameters, and avoid leaving factory-default credentials or undocumented service commands in deployed machines.

For remotely maintained equipment, the remote-access system should authenticate the user before the CAN gateway becomes reachable. The CAN network should not be directly exposed to an IT or Internet-facing network simply because an Ethernet-to-CAN gateway makes it technically possible.

4. Secure firmware and configuration changes

A secure communication channel is of limited value if an attacker can install modified firmware. New designs should evaluate secure boot, signed firmware, controlled bootloader access, rollback strategy, version tracking and recovery procedures. Configuration changes should also be attributable and recoverable.

The maintenance question matters here: a security mechanism that cannot be serviced ten years later can become an operational liability. Key ownership, replacement devices, field recovery and supplier lifecycle support should be defined before production release.

5. Monitor the network for abnormal behaviour

Not every CAN/CAN FD security improvement requires encryption. A monitoring function can detect unexpected identifiers, impossible message rates, new nodes, abnormal diagnostic sessions, changing timing patterns or traffic appearing on a segment where it should not exist.

This is also where good analysis tools remain valuable. Kvaser CAN interfaces provide the engineering connection for capture, logging, diagnostics and test workflows. Warwick Control Technologies X-Analyser supports CAN, CAN FD, CANopen and J1939 analysis and testing. These are engineering and verification tools rather than security appliances; their value is in establishing what normal communication looks like and proving that the implemented gateway and diagnostic rules behave as intended.

6. Preserve evidence and change control

For connected industrial machines, keep firmware versions, configuration backups, gateway rule sets and diagnostic logs under revision control. When an abnormal event occurs, the engineering team needs to know what changed and when. This is equally useful for cybersecurity investigation, commissioning discipline and ordinary maintenance.

Practical security matrix for machine builders

Application	Priority controls	CANsec relevance
Legacy machine, isolated CAN, locked enclosure	Restrict physical/service access, document diagnostics, protect configuration and firmware, remove unnecessary interfaces.	Low for the installed base.
CAN FD machine connected to Ethernet/SCADA	Gateway segmentation, allow-listing, authenticated remote access, logging, secure firmware/update process.	Not a direct retrofit; design the boundary correctly now.
Mobile machine with multiple CAN/J1939/CANopen networks	Separate network domains, control diagnostic routing, identify trusted gateways, monitor abnormal cross-domain traffic.	Relevant to future CAN XL backbone design.
New long-life CAN XL platform	Design device identity, key provisioning, secure update, service recovery and gateway policy together with the network architecture.	High where protected CAN XL communication is required.
Product with remote service or export-market cybersecurity obligations	Formal threat/risk assessment, controlled software lifecycle, vulnerability response, authenticated service access and auditable changes.	One component of the overall security architecture, not the compliance strategy by itself.

Do not encrypt everything by default

Security engineering is a risk-allocation exercise. Cryptography adds processing, payload and key-management requirements. In a simple physically protected machine, the better investment may be locking down the gateway, disabling unused diagnostics, protecting firmware and adding monitoring. In a connected or safety-critical platform, stronger authentication and cryptographic controls may be justified.

I would ask a simpler question: what happens if this message is spoofed, replayed, altered or read by the wrong party? Protect the functions where the consequence matters instead of adding cryptography everywhere with no clear threat model.

I would not start a CAN security review with encryption. Start with the attack paths, gateways, diagnostic access and software-update process. In many machines, removing unnecessary access and controlling configuration will reduce more practical risk than trying to protect every frame. CANsec matters for CAN XL, but it still sits inside a much bigger security design.

How CANS can support a CAN security review

CANS can support CAN, CAN FD, CANopen and J1939 projects at the engineering level: network architecture, gateway design, diagnostics, traffic analysis, protocol mapping, commissioning and migration planning. The Kvaser interface portfolio, Ixxat/HMS gateways and bridges, and Warwick X-Analyser can be combined with application-specific engineering rather than treated as standalone catalogue items.

For a new machine platform or an installed network that is becoming Ethernet-, SCADA- or cloud-connected, CANS can review the trust boundaries and help define a practical migration plan. Contact CANS to discuss the architecture before adding security controls that are difficult to maintain later.

CAN Technology Watch — 3 September 2026

CANsec: CiA 613-2 version 1.0.0 is now available as a Draft Specification Proposal. It defines the CAN XL security data plane for integrity, freshness, origin authenticity and confidentiality, while key exchange/distribution remains outside its scope.
Higher-layer cybersecurity: CiA’s HLP cybersecurity group is actively working on CAN-based cybersecurity including secure key management, with a further virtual meeting scheduled for 7 September 2026.
September technology direction: CiA’s current September material highlights CANopen/CANopen FD security work, CAN FD in humanoid robots, CAN-FD-to-Ethernet gateways and integration of CANopen devices into ROS 2.
J1939: the 21 August CAN Community News says SAE plans to harmonise the differing “packet” and “segment” terminology used in J1939-21 and J1939-22 in future document issues.
CANopen measuring devices: CiA has called for experts to finalise updates to the CiA 404 series, including a CANopen FD parameter-mapping part.
Tools and infrastructure: Kvaser continues CAN XL development while maintaining a broad CAN/CAN FD interface ecosystem. Current Ixxat CANbridge/CAN@net products provide CAN/CAN FD segmentation, routing and Ethernet integration, while Warwick X-Analyser remains applicable to CAN/CAN FD/CANopen/J1939 engineering and test workflows.