Terms and Definitions

CAN Protocols and Higher-Layer Protocols

• CAN. Controller Area Network. A multi-master, message-oriented serial bus standardized in ISO 11898, widely deployed in machinery, industrial automation, and embedded systems. Classical CAN supports 8-byte payloads at up to 1 Mbit/s.
• CAN FD. CAN with Flexible Data-rate. Extension of classical CAN with payloads up to 64 bytes and a higher bit rate during the data phase. Standardized in ISO 11898-1:2015.
• CAN XL. Third-generation CAN, sitting above CAN FD in the CAN family. Payloads up to 2048 bytes and higher data-phase bit rates than CAN FD. Standardized in ISO 11898-1:2024. The cryptographic security extension defined for the CAN XL data-link layer is CANsec.
• CANopen. Higher-layer protocol on top of CAN, maintained by CiA. CANopen CC (for Classical CAN) is specified in CiA 301; CANopen FD (for CAN FD) is specified in CiA 1301. Both define object dictionaries, PDOs, SDOs, and network management primitives.
• CiA (CAN in Automation). International users' and manufacturers' group based in Nuremberg, Germany. Maintains the CANopen specifications (CiA 301 for Classical CAN, CiA 1301 for CAN FD) and the broader CiA document series, including many device and application profiles.
• J1939. SAE higher-layer protocol on CAN used in off-highway, agricultural, construction and some stationary applications. Uses 29-bit identifiers and PGN-based message structure supporting source and destination adressing.
• FireCAN. CAN-based higher-layer protocol used in fire fighting equipment. Original version was "loosely based" on CANopen, now standardization process is underway to harmonize it with CANopen.
  
• CleANopen. CANopen application profile for municipal special-purpose vehicles (refuse collection, street cleaning, winter service). Standardizes the device profiles and process-data exchange between truck body, chassis, and operator console. Specified in CiA 422.

Regulations

• CRA (Cyber Resilience Act). EU Regulation 2024/2847 establishing horizontal cybersecurity requirements for products with digital elements. Annex I lists the essential cybersecurity requirements.
  See Why Now.
• NIS 2 (Network and Information Security Directive). Directive (EU) 2022/2555. Cybersecurity obligations for essential and important entities across critical sectors.
  
  See Why Now.
• Machinery Regulation. Regulation (EU) 2023/1230, applicable from 20 January 2027. Replaces the Machinery Directive and adds explicit cybersecurity-related essential health and safety requirements for machinery, including protection of safety-relevant control signals carried over CAN.
  See Why Now.
• RED (Radio Equipment Directive). Directive 2014/53/EU. Activated for cybersecurity by Commission Delegated Regulation (EU) 2022/30, which adds essential requirements for connected radio equipment. Harmonized standards EN 18031-1/-2/-3:2024 specify the risk-assessment and risk-reduction process.
  
  See Why Now.

Standards and Guidelines

• IEC 62443. Series of international standards for security of industrial automation and control systems. Defines Security Levels SL1–SL4 and detailed system and component requirements. Part 3-2 covers risk assessment, 3-3 system requirements, 4-1 product development lifecycle, 4-2 component requirements.
  See IEC 62443-Style Assessment.
• ISO/IEC 27005. Information security risk management. IT-leaning; oriented to enterprise information assets rather than control-system equipment.
• ISO/IEC 27019. Energy-sector control-systems overlay on ISO/IEC 27002. Used where the deployment is specifically a power-utility installation.
• NIST SP 800-30. NIST Special Publication 800-30. US federal guidance for information-system risk assessments. Documentation-heavy, common in government and government-supplier contexts.
• NIST SP 800-82. NIST Special Publication 800-82, the Guide to Operational Technology Security. The leading US reference for industrial control system cybersecurity, complementary to IEC 62443.
• EN 303 645. ETSI EN 303 645: cybersecurity baseline for consumer Internet of Things devices.
  
• EN 18031. Harmonized standards EN 18031-1/-2/-3:2024 under the Radio Equipment Directive 2014/53/EU as activated by Commission Delegated Regulation (EU) 2022/30. Includes a risk-assessment and risk-reduction process for connected radio equipment.
• BSI TR-02102. BSI Technical Guideline on cryptographic mechanisms: recommended algorithms, key lengths, and operating modes. The reference for "BSI-approved" in this site.
• ISO/IEC 9798. Entity authentication. Multi-part international standard defining mechanisms by which two parties prove their identities to each other. Part 1 covers the general model; Part 2 (ISO/IEC 9798-2) specifies mechanisms using symmetric encipherment algorithms, including the one-pass, two-pass, and three-pass challenge/response constructions.
  
  Used by Secure Object Fieldbus Access.
• NIST SP 800-57. NIST recommendation for key management: the full lifecycle of cryptographic keys, including generation, establishment, storage, rotation, and destruction. The reference for key-management practice cited throughout this site.
• ISO/IEC 27001. International standard specifying the requirements for an information-security management system (ISMS): the organizational processes for managing security risk, distinct from the product and component controls of IEC 62443.
• FIPS 140-2. US federal standard of security requirements for cryptographic modules, covering key storage and protection. Commonly cited alongside its international counterpart ISO/IEC 19790.
• ISO/IEC 19790. International standard of security requirements for cryptographic modules, the counterpart to FIPS 140-2. The reference for hardware-backed key storage above Security Level 2.
• IEEE 802.1AR. Secure Device Identifier (DevID) standard: a per-device identity credential and certificate provisioned at manufacture. One well-known form of asymmetric device identity.
• SUIT (Software Updates for Internet of Things). IETF firmware-update architecture and manifest information model (RFC 9019 and RFC 9124), often paired with signed firmware updates on constrained devices.
• ANSI X9.24-3. Financial-industry standard for symmetric key management, the home of DUKPT (Derived Unique Key Per Transaction): deriving a unique key per device from a shared master key. Prior art for the derive-from-master approach used on fieldbuses.

Risk-Assessment Vocabulary

• Risk Assessment. Structured process covering identification of assets, threats, attack paths, risk derivation, and treatment selection, as required by CRA Article 13. The CRA does not prescribe a specific methodology.
  See Risk Assessment.
• Vulnerability Scoring. A per-finding severity metric for a specific weakness, distinct from risk assessment.
  See CVSS for CAN.
• CVSS (Common Vulnerability Scoring System). Industry-standard scoring scheme for the severity of software vulnerabilities. CVSS v4.0 is the version expected for CRA vulnerability reporting to ENISA.
  See CVSS for CAN.
• SL (Security Level). IEC 62443 categorization of attacker capability. SL1 is incidental misuse; SL2 is intentional, low resources; SL3 is intentional, moderate resources with technology-specific skills; SL4 is intentional, extended resources with technology-specific skills.
  See IEC 62443 SL2 Requirements.
• SBOM (Software Bill of Materials). Machine-readable list of all software components in a product, in formats such as SPDX or CycloneDX. Required by the CRA.
• Defense in Depth. Security architecture principle of combining multiple, overlapping defensive measures so that the failure of any single measure does not expose the asset. Endorsed by IEC 62443 (zone-and-conduit + SR layering) and NIST SP 800-82.
  See Defense in Depth.
• Zone and Conduit. IEC 62443-3-2 partitioning model. A zone groups components that share security requirements and exposure; a conduit is a communication path that crosses a zone boundary.
  See Zoning and Segmentation.
• EmSA-WP-103. EmSA white paper that establishes a default CVSS v4.0 baseline for an unprotected CAN node, used as the scoring reference throughout this site.
  See the EmSA security white papers.

Threats and Attacks

• Frame Injection. Transmitting CAN frames with arbitrary CAN IDs from a node not authorized to use those IDs, exploiting the absence of source authentication on classical CAN.
  See Protocol Weaknesses.
• Spoofing / Masquerading. Transmitting CAN frames under another node's CAN ID to impersonate a legitimate sender. Closely related to frame injection: injection is the act of transmitting unauthorized frames, spoofing or masquerading is doing so under a borrowed identity.
  
  See Protocol Weaknesses.
• Replay Attack. Re-sending previously captured legitimate frames to cause unintended state changes. Classical CAN has no native replay protection.
  See Protocol Weaknesses.
• Sniffing. Passive observation of bus traffic by a node with physical or logical access to the medium. CAN is a broadcast bus, so every node on a segment sees every frame by design; sniffing requires no privilege escalation, only access. T
  See Protocol Weaknesses.
• Bus Flooding. Transmitting frames at higher priority than legitimate traffic, or forcing error frames, to deny legitimate communication on the bus. On CAN the dynamic is inverted relative to internet DoS: a single malicious node can overload an entire network because every node sees every frame.
  See Bus Load Monitoring.

Cryptographic Primitives and Keys

• AES-128-GCM. Advanced Encryption Standard with 128-bit key in Galois/Counter Mode. Authenticated encryption (AEAD) algorithm, recommended by BSI TR-02102 and the AEAD primitive used by SPsec on CAN FD, Secure Object Fieldbus Access (SOFA) at the application layer, and the CANopen secure bootloader.
• AEAD (Authenticated Encryption with Associated Data). A cryptographic mode that provides confidentiality, integrity, and authenticity in a single operation. Supports multiple algorithms including AES-128-GCM , Ascon and ChaCha20-Poly1305.
• Ascon. NIST-standardized lightweight cryptography family (selected 2023, published as the NIST Lightweight Cryptography standard). Includes Ascon-AEAD and Ascon-Hash variants. Designed for resource-constrained devices.
  
• ChaCha20-Poly1305. AEAD construction combining the ChaCha20 stream cipher with the Poly1305 message-authentication code. Specified in RFC 8439. Often faster than AES-GCM in software when AES hardware acceleration is unavailable; widely used in TLS 1.3 and SSH.
  
• HMAC (Hash-based Message Authentication Code). RFC 2104. Used for short message authentication tags when full AEAD encryption is not feasible.
• MAC (Message Authentication Code). Cryptographic tag attached to a message to authenticate its origin and integrity. Distinct from "MAC address" (Media Access Control address).
• KDF (Key Derivation Function). Cryptographic function that derives one or more working keys from a master secret, typically combining the secret with a salt and context information. Common KDFs include HKDF (RFC 5869). Used in CAN security to derive per-session, per-channel, or per-purpose keys from a long-term pre-shared key without weakening or exposing the long-term key.
• Nonce. Number used once. Value (random or counter-based) that must not be reused with the same key in AEAD constructions. Reuse breaks the cryptographic guarantees of the construction. Nonce management is the trickiest correctness concern in AEAD-based CAN protocols.
• Salt. Value combined with the input to a key derivation function so the same secret produces a different derived key in different contexts. Does not need to be confidential, only unpredictable in the relevant scope. Prevents derived-key collisions across products, deployments, or protocol versions.
• PSK (Pre-Shared Key). Symmetric key established out-of-band between communicating parties. This reference names each PSK by its function rather than by an internal alias: the Update Key for software-update and configuration-update operations; the Provisioning Key loaded at manufacturing; the Integrator Key for system-level access.
• Update Key. Pre-shared key used to protect software updates and, depending on the system, also configuration updates where a whole configuration table is loaded at once. On CANopen, the Update Key authenticates and (where configured) encrypts the firmware image with AES-128-GCM, and gates entry into the bootloader's update mode via challenge/response.
  
  See Secure Bootloader.
• Provisioning Key. Pre-shared key loaded at manufacturing or initial provisioning, used to bootstrap further keys in the field. Distinct from operational keys; typically used to establish trust before the device enters service so that runtime keys can be loaded or derived securely.
  
• Integrator Key. Pre-shared key established by the system integrator, distinct from the manufacturer's Provisioning Key. Lets the integrator gate runtime access at the system level without exposing the manufacturer's keys. Aligns with the IEC 62443-3-2 split of responsibilities between manufacturer and integrator.
• TLS-PSK. TLS (Transport Layer Security) profile authenticated by pre-shared keys (RFC 4279). Suitable for constrained CAN gateways' external interfaces where certificate handling is impractical.
• cTLS. Compact TLS: IETF draft profile of TLS 1.3 designed for resource-constrained environments and small frames.
• RFC 5869. Specification of HKDF, the HMAC-based key-derivation function used to derive per-purpose keys from a shared secret. The common choice for the key-derivation function referenced under Symmetric Key Management.

Security Measures and Mitigations

• Anomaly Detection. Monitoring for deviations from a learned or specified baseline of bus traffic, including timing, frame counts, or content patterns. A measure rather than a specification: applied on top of whichever frame-level controls are in place to surface what slipped through.
  See Anomaly Event Monitoring.
• SPsec (CANcrypt V2.0). Security sublayer specification for classical CAN (with limitations) and CAN FD providing authentication and encryption. Specification documents 101–302 are published on esacademy.com.
  See Frame Security.
• CANcrypt. Authentication and encryption layer for classical CAN and CANopen, with a published book and reference implementation at cancrypt.net.
  See Frame Security.
• SOFA (Secure Object Fieldbus Access, aka FBsec). Application-layer cryptographic shell for CAN-based fieldbuses. For CANopen, SOFA provides authenticated read or write access to selected Object Dictionary entries using  pre-shared keys. The authentication-of-identification exchange aligns with a combination of TLS-PSK (RFC 4279) for the pre-shared-key model and ISO/IEC 9798-2 for the symmetric-key challenge/response mechanism.
  
  See Secure Object Fieldbus Access.
• CANsec. Cryptographic security extension defined for the CAN XL and potentially CAN FD data-link layer, adding frame-level authentication and optional confidentiality. Analogous in role to MACsec for Ethernet. AES-GCM based. The specification is currently under definition.
  See Frame Security.
• Secure Boot. Boot process that verifies firmware authenticity and integrity before execution, typically using a manufacturer-controlled signing key.
  
  See Secure Bootloader.

Frequently Asked Questions

How is this glossary scoped?

Industrial CAN and CAN FD security only. Entries cover the protocols (CAN, CAN FD, CAN XL, CANopen, J1939, FireCAN, CleANopen), the regulations that drive security obligations in the EU (CRA, NIS 2, Machinery Regulation), the standards that operationalize those obligations (IEC 62443, NIST SP 800-82, EN 303 645, ISO/IEC 9798), the threats and attacks the controls address (frame injection, spoofing / masquerading, replay, sniffing, bus flooding), and the security measures and mitigations on the CAN side (anomaly detection, SPsec, CANcrypt, SOFA, CANsec, secure boot) along with the cryptographic primitives and keys involved (AES-128-GCM, Update Key, Provisioning Key, Integrator Key, authentication key). Automotive vocabulary is deliberately excluded.

Where do these definitions come from?

Each term cites its source standard or specification where one exists. Where a term has multiple meanings across communities (for example MAC, which can mean Message Authentication Code or Media Access Control), the definition here is the one used by this reference and the disambiguation is called out.