The Regulatory Case for CAN Security
Several overlapping European and International regulations now require systematic cybersecurity for CAN-based products, backed by standards and guidance. Worldwide, more and more regulations emerge strengthening the security of electronics and embedded systems. This page separates selected binding legal instruments from supporting standards a manufacturer can use to demonstrate compliance.
Regulations
EU Cyber Resilience Act (CRA)
The CRA, Regulation (EU) 2024/2847, is a horizontal regulation applying to products with digital elements placed on the EU market. It introduces essential cybersecurity requirements (Annex I), conformity assessment obligations, vulnerability handling duties, and incident reporting. CAN-based devices and end products with internal CAN buses are generally in scope. CRA
Some of the key obligations include risk assessment (Article 13), security by design and by default, vulnerability handling with timely patches, SBOM maintenance, and 24-hour reporting of actively exploited vulnerabilities to ENISA.
EU NIS 2 Directive
The NIS 2 Directive, Directive (EU) 2022/2555, sets cybersecurity obligations for "essential" and "important" entities across sectors including energy, transport, water, manufacturing, and digital infrastructure. While NIS 2 targets the operating organization rather than the product, its risk-management and incident-reporting requirements flow downstream to suppliers of CAN-based control equipment used in those operations. NIS 2
For a CAN component vendor selling into a NIS 2 operator, this typically means contractual obligations to support the operator's risk management, vulnerability disclosure and incident-response processes.
EU Machinery Regulation
The Machinery Regulation, (Regulation (EU) 2023/1230, adopted 14 June 2023) replaces the 2006 Machinery Directive (2006/42/EC) and applies from 20 January 2027. It introduces explicit cybersecurity-related essential health and safety requirements. Annex III requires that safety functions are protected against accidental or intentional corruption, including corruption of CAN-borne control signals, and that connected functionality cannot be exploited to compromise safety. Machinery Reg.
For CAN networks inside machinery, this drives concrete protection of safety-relevant control messages, configuration locking and secure update for safety components.
Helpful Standards and Guidelines
IEC 62443
IEC 62443 defines Security Levels SL1–SL4 for industrial automation and control systems. The series provides a system-of-systems framework: 62443-3-2 for risk assessment, 62443-3-3 for system security requirements, 62443-4-1 for product development lifecycle, and 62443-4-2 for component-level requirements: SR 1.x (access control), SR 3.x (system integrity), SR 4.x (data confidentiality), SR 6.x (timely response to events), and SR 7.x (resource availability) translate directly into CAN-level countermeasures. IEC 62443
ETSI EN 303 645
ETSI EN 303 645 is the cybersecurity baseline for consumer Internet of Things devices. Where CAN appears in consumer-facing equipment such as building automation, white goods or recreational machinery, EN 303 645's provisions on default passwords, secure update, vulnerability disclosure, and minimum data exposure complement the CRA and Machinery Regulation requirements. EN 303 645
NIST SP 800-82
NIST Special Publication 800-82, the "Guide to Operational Technology (OT) Security", is the leading US reference for industrial control system cybersecurity. It overlaps substantially with IEC 62443 in scope but uses different vocabulary. For CAN systems sold globally, mapping controls to both 62443 and SP 800-82 simplifies cross-jurisdiction conformity arguments. SP 800-82
BSI TR-02102
The German BSI's TR-02102 series specifies recommended cryptographic algorithms and key lengths. For CAN, the relevant choices are AES-128-GCM (for CAN FD authenticated encryption) and HMAC-SHA-256 truncated for short MACs. Secure Object Fieldbus Access (SOFA) and the CANopen secure bootloader both build on AEAD with AES-128-GCM, aligning with these recommendations and providing a defensible algorithm choice for CRA-relevant implementations. TR-02102
The Gap Between Regulation and Standard
Regulations like the CRA, NIS 2, and the Machinery Regulation specify outcomes: a documented risk assessment, security by design and by default, vulnerability handling, secure update, and timely incident reporting. They do not prescribe the technical methods. Standards are where those methods are defined, and that is where gaps appear.
Producing a new security standard inside CiA (or an IEC working group) typically takes several years from initial draft to published document. Meanwhile the CRA's essential cybersecurity requirements apply from December 2027 and the Machinery Regulation from January 2027. Several requirement areas are not yet fully covered by published (CAN-specific) standards:
- Cryptographic frame or message authentication on
CAN, CAN FD, CANopen CC or CANopen FD.
Required outcome under CRA Annex I (integrity, authenticity). SPsec is the available specification today, ahead of any formal CiA standard at the same scope. - Secure Object Fieldbus Access (SOFA) for CANopen.
Required outcome (BSI TR-02102-aligned algorithm selection plus CRA Annex I integrity and access control on configuration data). SOFA covers authenticated read or write of selected Object Dictionary entries based on AEAD with AES-128-GCM, with a challenge/response exchange that aligns with a combination of TLS-PSK (RFC 4279) and ISO/IEC 9798-2 for authentication of identification and for configuration locking. Currently under definition at CiA. - Secure bootloader for CAN/CANopen devices.
Required outcome (CRA secure-update and vulnerability-handling obligations). EmSA's reference implementation predates a formal CiA bootloader-security profile. CiA /10 defines a generic CANopen Bootloader, but not security specifics.
- Risk assessment guidance for CAN-specific systems.
IEC 62443-3-2 specifies the process at the system level, but not CAN-level guidance. This reference and the EmSA white papers fill that gap.
The pages that follow describe what these solutions cover, how they map to IEC 62443 security levels and CRA articles or requirements, and where remaining gaps still require engineering judgment.
What This Means for CAN Product Manufacturers
For a typical CAN component manufacturer, the practical to-do
list is: perform a documented risk assessment, implement
security by design measures matching the assessed risk,
maintain an SBOM (Software Bill of Materials), set up a
coordinated vulnerability disclosure process including
preparation for vulnerability scoring (CVSS) and incident
reporting. The standards (IEC 62443 in particular) provide the
structured controls that satisfy the regulatory obligations.
With all of that, Defense
in Depth is the architectural pattern that ties those
controls together. A CAN system with documented layered
defenses directly satisfies CRA's risk-treatment expectations
and IEC 62443's zone-and-conduit model.
Frequently Asked Questions
Does the EU CRA apply to CAN bus components?
Yes. The EU Cyber Resilience Act applies to products with digital elements placed on the EU market. CAN-based components and end products generally fall in scope unless explicitly carved out by sector-specific regulation already covering them.
When does the CRA come into force?
The CRA entered into force in late 2024 with phased application. Vulnerability and incident reporting obligations apply September 2026, with the full essential cybersecurity requirements applying from December 2027 onward. Manufacturers should plan their roadmap with this date as the hard deadline for full compliance.
Does the EU Machinery Regulation cover CAN networks inside machines?
Yes. Regulation (EU) 2023/1230 introduces explicit cybersecurity requirements for safety components in machinery. CAN networks that carry safety-relevant control signals must be protected against malicious or unintentional corruption and connected functionality must not be exploitable in ways that compromise safety.
What is an SBOM and is it required for CAN products?
A Software Bill of Materials lists all software components (including firmware libraries, RTOS, communication stacks) in a product. The CRA requires manufacturers to maintain an SBOM in a commonly used machine-readable format such as SPDX or CycloneDX. CAN nodes shipping firmware fall in scope.
Does compliance mean securing everything?
No. The CRA and the Machinery Regulation both require security appropriate to the risk, not a fixed maximum. That is why this reference leads with risk assessment: it is the step that decides how much protection a given product and its exposure actually warrant. A well-protected, low-risk node can meet the obligation with a light, documented set of measures.