Securing
CAN and CAN FD
Systems
This collection of security information is a
practical reference for engineers and security architects
working with CAN and CAN FD networks. It explains why
cybersecurity has become a regulatory requirement even for
CAN-based products and what attacks the protocol is
exposed to. We review how to assess related risks and
which countermeasures are available, including how these
map to IEC 62443 security levels and EU Cyber Resilience
Act obligations. Where used, higher-layer protocols such
as CANopen CC (CiA 305, EN 50325-4), CANopen FD (CiA
1305), J1939, FireCAN, CleANopen or other non-automotive
protocols are taken into account.
Why CAN Security Matters Now
The EU Cyber Resilience Act (CRA), NIS 2 Directive and the EU
Machinery Regulation - supported by IEC 62443 and related
guidance - converge on a clear expectation: products with
digital elements, including CAN nodes, need a documented
security posture.
Read the regulatory case →
Understanding the Threats
Classical CAN was not designed with security in mind. Any
node can transmit any CAN ID, there is no message
authentication. Physical access enables sniffing, frame
injection, replays and other attacks. CAN FD changes the
picture: the larger frame size provides more room for
cryptography information but which methods and algorithms to
use in which cases is not standardized.
Survey the threats →
Assessing and Managing Risk
Both the EU CRA and IEC 62443-3-2 require a documented risk
assessment. Risk assessment is a process that frames the
system and selects mitigations; this reference uses IEC
62443-3-2. Vulnerability scoring with CVSS v4.0 is a separate,
complementary activity, done per finding when reporting a
specific weakness to ENISA or to customers.
Learn the methodology →
Solutions
No single measure secures a CAN bus completely. The Solutions
catalog lists the in-scope defensive controls for CAN and CAN
FD: bus load monitoring, local injection detection, frame
security, anomaly event monitoring, Secure Object Fieldbus
Access, zoning and segmentation, and the secure bootloader
that gates what code runs on the device in the first place.
Each control answers one specific failure mode; the Defense in
Depth section then explains how to combine them into layered
protection for a given IEC 62443 security level.
Browse the Solutions catalog
→
Filling the Regulation–Standard Gap
EU regulations such as the CRA spell out outcomes (risk
assessment, secure update, vulnerability handling) but leave
the technical methods to standards. CAN-specific security
standards take years to mature through CiA or other
standardization processes and several requirement areas are
not yet fully covered. The pages here describe solutions that
are available today and designed to fill those gaps: CANcrypt
V2 / SPsec (Small Packet Network Security) for CAN FD
authentication and encryption, CANcrypt V1 for classical CAN,
Secure Object Fieldbus Access (SOFA) and the CANopen secure
bootloader, both currently under definition at CiA.
Read the gap argument →
Where to Start
Pick the situation that matches your task. Each goes straight to the most relevant page:
- Building a CRA case for a CAN-based product
- Picking countermeasures and matching them to IEC 62443 security levels
- Scoring a CAN vulnerability for ENISA reporting
- Selecting cryptographic solutions for securing CAN communication
Frequently Asked Questions
Does the EU Cyber Resilience Act apply to my CAN device?
The EU CRA applies to almost every product with digital elements placed on the EU market, including CAN-based components. The full scope, timelines, and exemptions are covered on the Why Now page.
What CVSS score does a classical CAN node have by default?
An unprotected classical CAN node scores 5.2 (Medium) under CVSS v4.0 with vector AV:P/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N. The full derivation is on the CVSS for CAN page; source: EmSA-WP-103.
Can CAN FD be encrypted?
Yes. SPsec (CANcrypt 2.0) defines a security sublayer for CAN FD with authentication and encryption for ALL frames exchanged. See Frame Security.
Is physical isolation enough security for my CAN system?
Physical access limitation is the foundational measure and supports IEC 62443 SL2, but it cannot fully prevent attacks. Network monitoring obligations were defined to at least recognize and capture possible attacks. See the Risk Assessment page.
What IEC 62443 security level can I reach with CAN?
Combining frame authentication (CANcrypt or SPsec) with anomaly event monitoring makes IEC 62443 SL3 reachable for many CAN systems. See the Defense in Depth coverage matrix.