# CAN Security Reference: full text
> Every page of https://can-security.net concatenated as Markdown, for agents that prefer one document over following links. Per-page mirrors live at each page URL with `index.md` appended.
---
# 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](https://can-security.net/resources/terms-and-definitions/#term-iec-62443) security levels and EU Cyber Resilience Act obligations. Where used, higher-layer protocols such as CANopen CC ([CiA](https://can-security.net/resources/terms-and-definitions/#term-cia) 305, EN 50325-4), CANopen FD (CiA 1305), [J1939](https://can-security.net/resources/terms-and-definitions/#term-j1939), [FireCAN](https://can-security.net/resources/terms-and-definitions/#term-firecan), [CleANopen](https://can-security.net/resources/terms-and-definitions/#term-cleanopen) or other non-automotive protocols are taken into account.
## Why CAN Security Matters Now
The EU Cyber Resilience Act ([CRA](https://can-security.net/resources/terms-and-definitions/#term-cra)), [NIS 2](https://can-security.net/resources/terms-and-definitions/#term-nis-2) Directive and the EU [Machinery Regulation](https://can-security.net/resources/terms-and-definitions/#term-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 →](https://can-security.net/why-now/)
## 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 →](https://can-security.net/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](https://can-security.net/resources/terms-and-definitions/#term-cvss) v4.0 is a separate, complementary activity, done per finding when reporting a specific weakness to ENISA or to customers.
[Learn the methodology →](https://can-security.net/risk-assessment/)
## 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 →](https://can-security.net/solutions/)
## 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](https://can-security.net/resources/terms-and-definitions/#term-cancrypt) V2 / [SPsec](https://can-security.net/resources/terms-and-definitions/#term-spsec) (Small Packet Network Security) for CAN FD authentication and encryption, CANcrypt V1 for classical CAN, Secure Object Fieldbus Access ([SOFA](https://can-security.net/resources/terms-and-definitions/#term-sofa)) and the CANopen secure bootloader, both currently under definition at CiA.
[Read the gap argument →](https://can-security.net/why-now/#gap)
## 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](https://can-security.net/why-now/)
- [Picking countermeasures and matching them to IEC 62443 security levels](https://can-security.net/solutions/)
- [Scoring a CAN vulnerability for ENISA reporting](https://can-security.net/risk-assessment/cvss-for-can/)
- [Selecting cryptographic solutions for securing CAN communication](https://can-security.net/solutions/frame-security/)
> ### EmSA Training — start with the free CRA-CAN intro
> Self-paced and instructor-led courses on CRA compliance for CAN-based products. The free CRA-CAN-Opener introduces the series; deeper classes cover the lifecycle, threats, mapping, and risk assessment.
> [Open the free intro →](https://emsa.courses/course/cra-can-opener)
## 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](https://can-security.net/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](https://can-security.net/risk-assessment/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](https://can-security.net/solutions/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](https://can-security.net/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](https://can-security.net/risk-assessment/defense-in-depth/).
---
# Contact EmSA
Most of what we offer is described under [Solutions](https://can-security.net/solutions/) (off-the-shelf solutions mapped to EU CRA and IEC 62443 requirements) and at [emsa.courses](https://emsa.courses/) (training classes for EU CRA and CAN/CANopen related topics). For the two cases that do not fit, customizing a Solutions shell for your CAN system or reviewing your [risk assessment](https://can-security.net/resources/terms-and-definitions/#term-risk-assessment) record, reach us directly.
## Reach Us
All written inquiries across the EmSA platforms go through our central contact point:[
Go to the ESAcademy contact form →](https://www.esacademy.com/en/contact-us.html?subject=cansecurity.net)
**
Embedded Systems Academy GmbH**, Germany / Europe
Phone: +49 5105 582 7897
**Embedded Systems Academy, Inc.**, US / Americas
Phone: +1 877 812 6393 (toll-free, North America)
## Frequently Asked Questions
### How do I request a risk assessment review?
Use the [ESAcademy contact form](https://www.esacademy.com/en/contact-us.html?subject=cansecurity.net) or call the number for your region and describe your CAN or CAN FD system. EmSA reviews your existing [risk assessment](https://can-security.net/resources/terms-and-definitions/#term-risk-assessment) record against EU CRA and IEC 62443 expectations and reports where the gaps are.
### Which EmSA product fits my CRA obligation?
It depends on the threat you need to cover. The [Solutions](https://can-security.net/solutions/) catalog maps each control to the [CRA Annex I requirements](https://can-security.net/resources/cra-requirements/) it supports. If none fit your system as shipped, EmSA can customize a Solutions shell for your application.
### Do you offer training on CAN security and the EU CRA?
Yes. EmSA runs scheduled and on-site classes on CAN, CANopen, and EU CRA topics. The current catalog and dates are listed at [emsa.courses](https://emsa.courses/).
---
# Imprint
Legal information about the operator of this website, as required under §5 TMG (German Telemedia Act) and §18 Abs. 2 MStV (Interstate Media Treaty), with notes on liability and copyright.
[Diese Seite auf Deutsch →](https://can-security.net/imprint/de/)
## 1. Provider
This website is operated by:
**Embedded Systems Academy GmbH**
Bahnhofstr 17
30890 Barsinghausen
Germany
Phone: +49 5105 582 7897
Email:
## 2. Register Entry
Commercial register: Amtsgericht Hannover, HRB 204156.
## 3. VAT Identification
Value-added tax identification number per §27a UStG: **DE 813075152**.
## 4. Authorized Representative
Managing Director (Geschäftsführer): **Olaf Pfeiffer**.
## 5. Responsible for Content
Responsible for the content of this website per §18 Abs. 2 MStV: Olaf Pfeiffer, address as above.
## 6. EU Online Dispute Resolution
The European Commission provides a platform for online dispute resolution at [ec.europa.eu/consumers/odr](https://ec.europa.eu/consumers/odr/). Embedded Systems Academy GmbH does not offer online sales or contractual services through this website and is neither obliged nor willing to participate in dispute-resolution proceedings before a consumer arbitration board.
## 7. Liability for Content
The contents of this website have been compiled with the greatest possible care. As a service provider, Embedded Systems Academy GmbH is responsible for its own content on these pages in accordance with §7 (1) TMG and general statutory provisions. Under §§8 to 10 TMG, however, we are not obliged to monitor transmitted or stored third-party information, nor to investigate circumstances that indicate unlawful activity. Obligations to remove or block the use of information under general statutory provisions remain unaffected. Liability in this respect is only possible from the point in time at which a concrete infringement of the law becomes known. Upon notification of any such infringements, we will remove the content concerned without delay.
## 8. Liability for External Links
This website contains links to external third-party websites whose content we have no influence over. For this reason, we cannot accept any liability for this third-party content. The respective provider or operator of the linked pages is always responsible for their content. The linked pages were checked for possible legal infringements at the time of linking; unlawful content was not recognisable at that time. A permanent monitoring of the linked pages is not reasonable without concrete indications of an infringement. Upon notification of any such infringements, we will remove such links without delay. All external links on this site open in a new browser tab and use `rel="noopener"`.
## 9. Copyright
The content of this website, including texts, illustrations, and structural arrangement, is © Embedded Systems Academy GmbH unless otherwise indicated.
Reproduction of the textual content for **non-commercial educational purposes** is permitted, provided that:
- attribution to "Embedded Systems Academy" is given,
- a link back to the source page on this website is included, and
- the content is not modified in a way that misrepresents EmSA's positions or recommendations.
Any other use, in particular commercial reuse, redistribution, or inclusion in for-profit products, courses, or publications, requires prior written permission. Logos, product names, and brand assets (including but not limited to "CANcrypt", "SPsec", "CAN Dragon", "CANopenIA") are trademarks of Embedded Systems Academy GmbH and are not covered by this educational-reuse permission.
Third-party trademarks and registered marks referenced on this site are the property of their respective owners.
---
# Impressum
Anbieterkennzeichnung gemäß §5 TMG (Telemediengesetz) und §18 Abs. 2 MStV (Medienstaatsvertrag) sowie Hinweise zu Haftung und Urheberrecht.
[View this page in English →](https://can-security.net/imprint/)
## 1. Anbieter
Diese Website wird betrieben von:
**Embedded Systems Academy GmbH**
Bahnhofstr 17
30890 Barsinghausen
Deutschland
Telefon: +49 5105 582 7897
E-Mail:
## 2. Registereintrag
Handelsregister: Amtsgericht Hannover, HRB 204156.
## 3. Umsatzsteuer-Identifikationsnummer
Umsatzsteuer-Identifikationsnummer gemäß §27a Umsatzsteuergesetz: **DE 813075152**.
## 4. Vertretungsberechtigte
Geschäftsführer: **Olaf Pfeiffer**.
## 5. Inhaltlich Verantwortlicher
Inhaltlich verantwortlich gemäß §18 Abs. 2 MStV: Olaf Pfeiffer, Anschrift wie oben.
## 6. EU-Online-Streitbeilegung
Die Europäische Kommission stellt eine Plattform zur Online-Streitbeilegung bereit unter [ec.europa.eu/consumers/odr](https://ec.europa.eu/consumers/odr/). Über diese Website werden keine Online-Verkäufe oder vertraglichen Leistungen angeboten. Die Embedded Systems Academy GmbH ist nicht verpflichtet und nicht bereit, an einem Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.
## 7. Haftung für Inhalte
Die Inhalte dieser Website wurden mit größtmöglicher Sorgfalt erstellt. Als Diensteanbieter sind wir gemäß §7 Abs. 1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden entsprechender Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.
## 8. Haftung für externe Links
Diese Website enthält Links zu externen Websites Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen. Alle externen Links auf dieser Website öffnen in einem neuen Tab und verwenden `rel="noopener"`.
## 9. Urheberrecht
Die durch die Embedded Systems Academy GmbH erstellten Inhalte und Werke auf diesen Seiten, einschließlich Texte, Abbildungen und strukturelle Anordnung, unterliegen dem deutschen Urheberrecht. © Embedded Systems Academy GmbH, soweit nicht anders gekennzeichnet.
Die Vervielfältigung der textlichen Inhalte zu **nicht-kommerziellen Bildungszwecken** ist gestattet, sofern
- die Quelle "Embedded Systems Academy" genannt wird,
- ein Link auf die jeweilige Quellseite dieser Website gesetzt wird und
- der Inhalt nicht so verändert wird, dass die Position oder Empfehlung der EmSA verfälscht erscheint.
Jede andere Nutzung, insbesondere die kommerzielle Verwendung, Weiterverbreitung oder Aufnahme in gewerbliche Produkte, Schulungen oder Veröffentlichungen, bedarf der vorherigen schriftlichen Zustimmung. Logos, Produktnamen und Markenzeichen (einschließlich, aber nicht beschränkt auf "CANcrypt", "SPsec", "CAN Dragon", "CANopenIA") sind Marken der Embedded Systems Academy GmbH und nicht von dieser Bildungs-Wiederverwendungs-Erlaubnis erfasst.
Marken und Registrierungen Dritter, die auf dieser Website genannt werden, sind Eigentum ihrer jeweiligen Inhaber.
---
# Key Management
Every defensive control on this site eventually depends on a key. We wrote this section as a getting-started orientation for manufacturers and integrators who have not had to deal with key management before. It is deliberately not a recommendation for installing or integrating a full public-key infrastructure. The goal is to make the moving parts visible, name the standards that bound them, and show where the simplest workable option lies.
## Why Key Management Is the Hard Part
Implementing the cryptography is a bounded engineering task. A device computes an AES-128-GCM authentication tag, verifies a signature, or derives a session key, and that code, once written and tested, simply runs. The lasting effort is everywhere else: deciding who generates each key, how it reaches the device without exposure, how a device proves it is genuine at handover, how authority is scoped and later revoked, and how key material is destroyed when a device leaves service.
These are organizational processes, not algorithms, and they run for the entire life of the product. A manufacturer that ships a thousand devices has to know which key went to which unit, what to do when a service laptop is lost, and how to re-key a fleet that outlives its first integrator. In practice this is where most of the ongoing work and maintenance live. Treating key management as a process problem from the start, rather than an afterthought once the crypto compiles, is the single most useful decision a newcomer can make.
Much of that process rests on one piece of hardware. A small [hardware security module](https://can-security.net/resources/terms-and-definitions/#term-hsm) holds the secret keys and performs operations with them inside a protected boundary, so the keys never appear in ordinary memory or in a database. The common pattern on a fieldbus is to keep a single root in the module and derive the per-device and firmware keys from it on demand, which keeps secure storage bounded however large the fleet grows. [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/) shows how that derivation works.
## What This Section Covers
The pages below move from what the regulations expect, through the basic choices, to the device-level functions and the lifecycle processes that surround them. Read them in order for an orientation, or jump to the one that matches the decision in front of you.
### [Regulations & Standards](https://can-security.net/key-management/regulations-standards/)
What the EU Cyber Resilience Act and IEC 62443 actually require about keys. The short answer: a risk-based, mechanism-neutral baseline that per-device symmetric keys can satisfy at Security Level 2. [CRA](https://can-security.net/resources/cra-requirements/) [IEC 62443](https://can-security.net/resources/iec-62443-sl2-requirements/)
### [Symmetric vs Asymmetric](https://can-security.net/key-management/symmetric-vs-asymmetric/)
The core choice, in plain language. Shared secrets versus key pairs, what each costs to provision and verify, and the algorithms involved on each side.
### [Fieldbus Device](https://can-security.net/key-management/fieldbus-device/)
The individual security functions a device should provide, and which keys each one needs, compared symmetric against asymmetric.
### [Handover](https://can-security.net/key-management/handover/)
The security steps when a manufacturer hands a device to an integrator, and later when an integrator passes a whole system to an operator.
### [Asymmetric Key Management](https://can-security.net/key-management/asymmetric-key-management/)
What a full public-key infrastructure entails and where it is documented, plus a minimal alternative that a smaller company can actually run.
### [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/)
Per-device key diversification, the options for storing or deriving keys, and the rotation, refresh, and revocation cycles that keep a fleet healthy.
## Where This Fits With the Rest of the Site
Key management is the layer underneath the controls catalogued elsewhere. The [Frame Security](https://can-security.net/solutions/frame-security/) shell needs keys to authenticate bus traffic. [Secure Object Fieldbus Access](https://can-security.net/solutions/secure-object-fieldbus-access/) needs an authentication key to gate Object Dictionary access. The [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/) needs an Update Key to authenticate firmware. None of those controls is complete until the question of where its keys come from, and where they go, has an answer. This section provides that answer at an orientation level; the product pages cover how each control consumes the keys.
> ### SPsec: A Secure Communication Layer for CAN FD
> SPsec is the EmSA secure communication layer for CAN FD, published as an open specification set. It puts the key-management ideas in this section into practice: per-device keys established and rotated to authenticate, and where needed encrypt, the frames on the bus. The full specification, documents 101 through 302, is available on esacademy.com.
> [Explore SPsec →](https://www.esacademy.com/en/library/spsec.html)
## Frequently Asked Questions
### Does the EU CRA or IEC 62443 require a full PKI for CAN devices?
No. Both frameworks are risk-based and mechanism-neutral. Neither makes a manufacturer-rooted public-key infrastructure a baseline requirement. At IEC 62443 Security Level 2, unique per-device symmetric keys satisfy the component requirements for identification and authentication. A full PKI becomes worthwhile when scale, multiple integrators, or anti-counterfeiting needs justify the extra process.
### Why is key management harder than the cryptographic implementation?
Writing an AES-128-GCM routine is a bounded task. Deciding who generates each key, how it reaches the device, how a device is claimed at handover, how a compromised credential is revoked, and how keys are destroyed at decommission are organizational processes that run for the life of the product. Those processes, not the algorithm, are where most of the ongoing work and maintenance sit.
---
# Asymmetric Key Management
Asymmetric key management is what most people picture when they hear public-key infrastructure: a certificate authority, device certificates, and a chain of trust. That full arrangement is powerful and well documented, but it is also a standing organizational commitment. This page outlines what a full PKI involves and where to read the detail, then describes a minimal version that a smaller manufacturer or integrator can run without a dedicated certificate team.
## What a Full PKI Involves
A full public-key infrastructure separates a rarely-used signing root from the keys that do the daily work, so that a compromise of a working key does not compromise the root. The public half of that root, placed in every device, is the trust anchor they verify against. The structure is layered, and each layer has a clear job.
### Offline Signing Root
The signing root kept offline and used only at infrequent ceremonies to sign the production keys below it. Its private half lives in a hardware security module, backed up under wrapping; its public half is the trust anchor placed in every device. A compromise of the signing root enables counterfeit signing, so it is protected accordingly. Losing or leaking it does not brick deployed devices, since a new root can serve future production, but recovery is not automatic: every device already carrying the old trust anchor keeps trusting anything signed under it until it is reached and re-anchored, whether by a field update that installs the replacement anchor or by physical service. Plan that reach-back path before you need it, and keep the registry of which unit holds which trust-anchor generation so the affected population can be identified.
### Production Signing Keys
Warmer keys, also in a hardware security module, that sign at volume: one to sign each firmware release, one to sign per-device identity certificates. The signing root signs the public halves of these once, then returns to the safe. All high-volume signing uses these production keys.
### Per-Device Identity
Each device receives an asymmetric identity key, generated on-chip so the private half never leaves, or injected from the production module. A certificate signed by the identity signing key binds the device public key to its serial and product line. On-chip generation depends on a hardware random number generator, and running the elliptic-curve operations is far faster where the part carries a public-key accelerator. The [Secure CAN MCUs](https://can-security.net/resources/secure-can-mcus/) reference lists CAN FD parts by these features.
### Public Registry
A low-sensitivity record of public material: the trust anchor public key, the production certificates, and per-device serial, line, firmware version, and identity certificate. It never holds private keys, so it does not need the protection that the signing keys do.
The mechanics here are industry-standard and documented. NIST SP 800-57 covers the key-management lifecycle of establishment, rotation, and destruction. FIPS 140-3 (which superseded FIPS 140-2 in 2026) and ISO/IEC 19790 set the requirements for the hardware security modules that hold private keys. IEEE 802.1AR describes one well-known form of device identity certificate, and the Software Updates for Internet of Things (SUIT) specifications, RFC 9019 and RFC 9124, describe a firmware-manifest architecture often paired with signed updates. Certificates can be encoded as X.509 or in more compact forms suited to constrained devices. The point for a newcomer is that this is a real, ongoing operation: ceremonies, module custody, registry maintenance, and revocation handling all become standing responsibilities. [NIST SP 800-57](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-57) [FIPS 140-2](https://can-security.net/resources/terms-and-definitions/#term-fips-140-2) [ISO/IEC 19790](https://can-security.net/resources/terms-and-definitions/#term-iso-iec-19790) [IEEE 802.1AR](https://can-security.net/resources/terms-and-definitions/#term-ieee-802-1ar) [SUIT](https://can-security.net/resources/terms-and-definitions/#term-suit)
## A Minimal PKI a Small Manufacturer or Integrator Can Run
Most of the benefit of public-key trust is available without standing up a full certificate authority. Two roles tend to ask whether they can run a smaller version: a small manufacturer, often with no staff dedicated to IT, security, or compliance, that still has to sign its own firmware, and a small integrator that owns a closed deployment. Both can, and the shape is the same in each case: one carefully kept signing root, a short record of what it signed, and revocation by signed statement rather than by re-keying devices.
### The Small Manufacturer Case
A manufacturer without dedicated IT, security, or compliance staff does not need a certificate-authority team and should not pretend to run one. The work reduces to protecting one private key well and keeping a list. Generate a single signing-root key pair, where Ed25519 is a sound default, on an air-gapped machine or a hardware token, and keep it offline. Use it to sign the firmware signing key that the build process uses from day to day, and, where devices carry asymmetric identity at all, the key that signs device certificates. The public half of that root becomes the trust anchor placed in every device at manufacture.
Everything else is bookkeeping rather than infrastructure. The record of which firmware version and which trust-anchor generation went to which serial can live in an ordinary database, because it holds only public material. The discipline that matters is custody of the one offline signing root: who holds the token, where the backup lives, and what happens if the person who set it up leaves. At this scale per-device asymmetric identity is often not worth it. Many small manufacturers stay with per-device symmetric keys for identity and use the minimal signing root only to sign firmware, which keeps the device side to AES-128-GCM and the office side to one key and a list.
### The Small Integrator Case
A small integrator that owns a closed deployment runs the same idea from the other end. The arrangement keeps a single asymmetric signing root, held by the integrator, that governs the per-device operational keys rather than issuing a certificate for every device. The device holds only the integrator trust anchor, the public half of that root, and the per-device operational key is generated by the device and never leaves it, so the integrator database holds public material and references, never secrets.
Authority is granted and revoked by signing short records with the integrator signing root. To withdraw a credential, the integrator signs a new record that marks the old one revoked, and tools and devices that hold the trust anchor refuse it from then on. Because a device trusts the most recent record it has seen, these signed records need a freshness marker, a monotonic sequence number or an expiry, and a way to reach the device, so that an attacker cannot replay an old record that still reads as authorized or simply withhold the revocation and leave a compromised credential looking valid. This delivers the properties that make asymmetric trust attractive, a leak-tolerant database and revocation without re-keying every device, while the day-to-day cost stays close to that of a symmetric system.
The trade is honest, and it is the same for both roles. A minimal PKI gives up the deep, certificate-per-device identity that anti-counterfeiting and very large multi-party programs rely on. For a small manufacturer signing its own firmware, or a single integrator running a closed deployment, in our experience it is usually the right amount of infrastructure. Where this asymmetric governance layer sits on top of symmetric per-device keys, the result is a hybrid covered on the [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/) page. If even the minimal signing root feels like more than you need, staying fully symmetric remains the lowest-burden option, a firmware update key plus a provisioning key, as described under [Fieldbus Device](https://can-security.net/key-management/fieldbus-device/).
## Frequently Asked Questions
### What does a full public-key infrastructure for devices involve?
An offline signing root used only at infrequent signing ceremonies, whose public half is the trust anchor placed in devices, warmer production keys that sign firmware and per-device identity certificates at volume, a per-device identity key issued at manufacture, and a public registry that records which key and certificate went to which unit. Private key material lives in hardware security modules. Guidance for the lifecycle comes from NIST SP 800-57, and module security from FIPS 140-3 (which superseded FIPS 140-2) or ISO/IEC 19790.
### Can a small manufacturer or integrator run a minimal PKI?
Yes, and it applies to both: a small manufacturer signing its own firmware, and a small integrator running a closed deployment. The minimal arrangement keeps one carefully protected signing root, offline on a token or air-gapped machine, that signs firmware and, where used, device certificates; its public half is the trust anchor devices carry. The device holds only public material, the registry of what went where can be an ordinary database, and authority is revoked by signing a short record rather than re-keying devices. An organization with no dedicated IT, security, or compliance function can run this; the discipline it demands is key custody, not IT scale.
---
# What a Fieldbus Device Must Protect Over Its Life
Security on a fieldbus device is not a single feature but a set of obligations that shift as the device ages. At manufacture it must protect its firmware and its first credentials; at handover it must prove its identity and accept a new owner; in operation it must guard both software updates and configuration; at end of life it must destroy its keys. This page organizes those obligations by lifecycle stage and shows which key answers each one, so the design follows the device rather than a single moment in it.
## Manufacture: Protect Firmware and First Credentials
A device is born with keys, not blank. At build the manufacturer loads a firmware update key, used to encrypt and authenticate every firmware image, so that firmware confidentiality and integrity hold from the very first power-up. Alongside it goes the one-time credential that lets the first owner claim the device, often printed as a label on the unit or supplied on the delivery note. There is no standardized name for that credential, and both [provisioning key](https://can-security.net/resources/terms-and-definitions/#term-provisioning-key) and [device claim token](https://can-security.net/resources/terms-and-definitions/#term-device-claim-token) are in use for it; designs also differ on whether the manufacturer ships it or the integrator installs it as the first act of claiming. Where the design calls for asymmetric identity, the device also generates an Ed25519 key pair on-chip, keeping the private half forever and exporting only the public half for certification.
The division of control set here lasts for the life of the product. The manufacturer holds the firmware signing or update key and therefore stays in control of the firmware file, and nothing else. The device leaves the factory locked, carrying only public anchors and its own secrets. Everything operational is installed later, by the owner, which is what keeps the manufacturer out of the day-to-day key business.
## Handover: Prove Identity and Accept an Owner
The first transfer turns a generic unit into one that belongs to a specific integrator. The device proves it is genuine, and the integrator claims it using that one-time credential. That first activation is decisive: whoever performs it takes possession, must immediately assign new per-device symmetric keys, and from then on holds full responsibility for the device. The newly assigned key, not the credential that gated the claim, secures device identity, integrator authorization, and the update session from that point forward. The mechanics of claiming, the choice between trust on first use, a token, or a voucher, and the later transfer of a whole system to an operator are covered on the [Handover](https://can-security.net/key-management/handover/) page.
## Operation: Secure the Software Update
Through its working life the device accepts firmware updates, and four things have to hold for each one to be safe. Each maps to a key.
### Device Identity
The updater must know it is really talking to that device, not a substitute or an emulator. The device proves itself with a challenge-response using a key only it and the authorized party share: the assigned per-device key, or an Ed25519 identity key.
### File Authenticity and Anti-Rollback
The image must be genuine, untampered, intended for this device or class, and not an older version rolled back to reintroduce a fixed flaw. AES-128-GCM under the firmware update key gives integrity and authenticity, and confidentiality where the image is encrypted; a monotonic version check blocks rollback.
### Integrator Authorization
Authenticity of the file is not the same as permission to install it. Many designs require the presenting party to prove it is allowed to update this particular device, using the assigned per-device key, so a genuine image offered by an unauthorized party is still refused. Others rest the whole check on the image and the signed list that covers it, and accept it from whoever delivers it.
### Update Session
Transfer and activation must be replay-protected and fail-safe. The session is bound so captured traffic cannot be replayed to force a re-flash, the device re-verifies the complete image before committing, and a failure partway through leaves the device recoverable rather than bricked.
The bootloader that enforces this on the device is covered in depth under [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/).
## Operation: Protect Configuration
Configuration deserves the same care as firmware, because a malicious configuration change can be as damaging as malicious code. A remapped object, a widened limit, or a disabled check can defeat a perfectly secure firmware image. There are three clean ways to protect it, and a real system often uses more than one.
### Load the Whole Configuration as a File
Treat the entire configuration as a single signed and authenticated object and load it exactly like a firmware image. It inherits the same guarantees as a software update, including authenticity, integrity, and anti-rollback, and it is protected under the same firmware or update key.
### Manual Configuration, Then Lock
Where settings are entered by hand on the bench, commit them and then lock the configuration cryptographically, so it cannot be altered without the proper key. The device moves from an open, writable state to a sealed one, and the seal is what an audit can later check.
### Authenticated Per-Object Writes
Where individual settings must change in the field, each write is authenticated and gated by the operational key, so only an authorized party can change a permitted object. This is the model behind [Secure Object Fieldbus Access](https://can-security.net/solutions/secure-object-fieldbus-access/).
Whichever method is used, two properties matter across the lifecycle. The device should verify its configuration at boot, so a tampered configuration is detected before it takes effect, and it should refuse an older configuration that would reopen a closed gap, the configuration equivalent of firmware anti-rollback. A configuration that the device cannot verify is a configuration an attacker can quietly rewrite.
## End of Life: Destroy the Keys
The lifecycle closes where it is most often forgotten. When a device is reset, decommissioned, resold, or returned, its secret key material must be zeroized, that is, purged so it cannot be recovered from released storage. IEC 62443-4-2 CR 4.2 requires exactly this. The practical reason is ownership: a device that returns to an unowned state must not carry the previous owner's keys, or a later re-claim would inherit stale trust and a returned unit would leak the secrets of the fleet it came from. Designing the erase path at the start is far easier than retrofitting it when an audit asks where the old keys went. The erase can be graded: a routine reset wipes operational key material yet leaves the device owned, while a full [factory restore](https://can-security.net/resources/terms-and-definitions/#term-factory-restore) clears ownership so the unit is genuinely unowned again. [CR 4.2](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-4-2)
## The Symmetric Baseline in Practice
Put end to end, the common practice keeps the device side small. The device needs only authenticated encryption with AES-128-GCM, and it holds at least two keys for most of its life: the firmware update key loaded at manufacture, and the operational key assigned at handover that secures identity, authorization, sessions, and locked configuration. That is enough to meet the obligations at every stage above without an on-device certificate authority. These are distinct keys held by distinct parties, the manufacturer and the owner, yet within one party's own key program each can be derived from a single root rather than stored separately: the firmware key from a fixed firmware label, a per-device key from the serial, as [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/) describes.
The reason this baseline is symmetric is cost, not security. The public-key primitives take considerably more time and resources than the symmetric ones: an Ed25519 signature or verification also pulls in SHA-512 on top of the SHA-256 a device already carries, and the elliptic-curve work runs in software even on parts that accelerate AES, so it costs far more flash, RAM, and time per operation than protecting a frame with AES-128-GCM. That gap is why most CAN and CAN FD devices stay symmetric. The [MCU Crypto Benchmarks](https://can-security.net/resources/crypto-benchmarks/) page reports the measured code size, stack, and per-operation time for each primitive on representative CAN FD parts. We recommend reserving public-key methods for where your system genuinely needs open distribution or delegation. The [Symmetric vs Asymmetric](https://can-security.net/key-management/symmetric-vs-asymmetric/) page weighs that choice, and [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/) covers how the operational keys are diversified, rotated, and revoked. The [Secure CAN MCUs](https://can-security.net/resources/secure-can-mcus/) reference lists which CAN FD parts carry that hardware AES and where a hardware random number generator and public-key accelerator are available for on-chip key generation and signatures.
> ### CAN Dragon: Symmetric Key Assignment for CAN
> CAN Dragon is the EmSA tooling family for CAN and CAN FD, with functions for assigning and managing the per-device symmetric keys this lifecycle depends on, from the operational key set at handover through rotation in the field.
> [Visit can-dragon.com →](https://can-dragon.com/)
## Frequently Asked Questions
### What keys does a device receive at manufacture, and what does it keep for life?
At build the device receives a firmware update key, loaded by the manufacturer to encrypt and authenticate firmware images, and a one-time credential used to claim it at handover, which different products call a provisioning key or a device claim token. After the first owner claims the device, they assign new per-device keys that secure identity, authorization, and sessions from then on. The manufacturer keeps control only of the firmware update file; everything operational belongs to the owner.
### How is configuration protected across the lifecycle?
Three ways, which can be combined. Load the whole configuration as a single signed and authenticated object, like a firmware image; enter it manually on the bench and then lock it cryptographically; or accept authenticated per-object writes gated by the operational key. In every case the device should verify its configuration on boot and refuse an older configuration that would reopen a closed gap, the configuration equivalent of firmware anti-rollback.
### What has to happen to a device's keys at end of life?
They must be zeroized. IEC 62443-4-2 CR 4.2 requires that key material be purged so it cannot be recovered when a device is reset, decommissioned, resold, or returned. A device that goes back to an unowned state must not carry the previous owner's keys, which is what makes a later re-claim safe.
---
# Handover Across the Supply Chain
A device is rarely used by the company that built it. A manufacturer hands it to an integrator, who builds it into a system and later passes that system to an operator. Each transfer is a point where trust has to be established, keys have to move, and authority has to be scoped. This page describes the security steps and the realistic options at each handover, at a level that helps you plan the process rather than implement a specific product.
## Manufacturer to Integrator
The first handover turns a generic, factory-fresh unit into a device that belongs to a specific integrator and carries that integrator's operational keys. The steps below are sequential, and the early ones can be skipped on minimal devices that do not carry an identity.
### 1. Verify Genuineness
Before trusting a unit, the integrator confirms it is a genuine device of the expected type and serial. Where the device carries a manufacturer-issued identity, the integrator tool validates it against the manufacturer's public anchor. On minimal devices without an identity, this step is replaced by physical provenance and supply-chain controls.
### 2. Claim Ownership
The integrator installs its own trust material and locks the device to itself. The device gates this by a [claim gate](https://can-security.net/resources/terms-and-definitions/#term-claim-gate) chosen at production: trust on first use, a printed one-time token, or a manufacturer-signed voucher. Each trades friction against assurance. The claim holds until the device is decommissioned.
### 3. Update Firmware
The integrator brings the unit to the current manufacturer release. The device verifies the manufacturer signature or authentication tag and applies anti-rollback. Because the firmware protects itself, no integrator key is required for this step; it relies only on the manufacturer's verification anchor or Update Key.
### 4. Provision Operational Keys
The heavy step: the integrator establishes the per-device operational keys the system will use. These can be delivered over an authenticated channel set up with the device's identity, or injected locally on a trusted bench. After this, routine traffic is symmetric and lightweight.
Two further steps close out the handover. The integrator configures the device into the system, assigning its address and pushing any configuration, optionally signed so the device can verify its authority. Finally the integrator records the unit in its own database: which node sits where, its serial and firmware version, and the key material or derivation parameters appropriate to the chosen approach. That record is what makes later refresh, revocation, and audit possible.
## Two Ways to Anchor the Trust
Behind these steps sits a single architectural choice: who installs the roots of trust, and when. The two ends of the spectrum are worth understanding before you pick a product or a process.
### Manufacturer-Rooted
The device is born locked and already carrying identity and anchors installed at production. The integrator claims an already-trustworthy device and layers its keys on top. There is no window where the device is open and unprovisioned. This fits broad markets, multiple integrators, and anti-counterfeiting needs.
### Integrator-Rooted
The device is born open, and the integrator installs all roots at first commissioning, then locks it. The manufacturer keeps only firmware-update authority. This is simpler for the manufacturer but creates a window, from factory to integrator lock, that must be closed by physical and supply-chain security. It fits a single integrator owning a closed deployment.
## Integrator to Operator
The second handover is usually a delivery model rather than a transfer of ownership. The integrator keeps the roots and installs a scoped operator credential on the device, a [delegation](https://can-security.net/resources/terms-and-definitions/#term-delegation) of part of its own authority. The credential is deliberately limited: it may let the operator trigger manufacturer-signed firmware updates and write permitted configuration, while it may not change keys, transfer ownership, alter anchors, or install operator-authored firmware or configuration. The device enforces this scope per action, so an operator can keep the system running without ever gaining the authority to re-key or re-own it. How such a delegation is later withdrawn depends on the design. Replacing or erasing the credential that carries it is the direct route and needs no clock. Where the design carries a monotonic ownership counter, advancing that counter invalidates grants issued under an earlier value. Neither route relies on an expiry, which a device with no reliable clock cannot enforce. Firmware authenticity remains rooted in the manufacturer throughout; the operator only delivers signed images, it does not sign them.
The mechanics of provisioning, scoping, and later revoking these credentials are covered on the two management pages. For symmetric deployments, see [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/); where an asymmetric governance layer is used to grant and revoke operator authority without re-keying devices, see [Asymmetric Key Management](https://can-security.net/key-management/asymmetric-key-management/).
## Frequently Asked Questions
### What does it mean to claim ownership of a device at handover?
Claiming ownership is the step where an integrator installs its own trust material onto a device and locks the device to that owner until it is decommissioned. The device gates this step by a method chosen at production: trust on first use, a printed one-time token, or a manufacturer-signed voucher. After a successful claim the device accepts operational keys only from its new owner.
### How is authority limited when a system is handed to an operator?
The integrator installs a scoped operator credential. It may permit the operator to trigger manufacturer-signed firmware updates and to write permitted configuration, while denying key changes, ownership transfer, anchor changes, and operator-authored firmware. The device enforces the scope per action, so the operator can run the system without gaining the authority to re-key or re-own it.
---
# Regulations & Standards for Key Management
Newcomers often assume the regulations prescribe a particular key technology. They do not. The EU Cyber Resilience Act and IEC 62443 are both risk-based and mechanism-neutral. This page summarizes what each one expects about keys specifically, so you can choose a mechanism on its merits rather than on a misreading of the text. For the full requirement matrices, follow the cross-links to the Resources section. [CRA](https://can-security.net/resources/cra-requirements/) [IEC 62443-4-2](https://can-security.net/resources/iec-62443-sl2-requirements/)
## The EU Cyber Resilience Act Sets Outcomes, Not Mechanisms
The [CRA](https://can-security.net/resources/terms-and-definitions/#term-cra) (Regulation 2024/2847) states its essential cybersecurity requirements in Annex I as outcomes. Products must protect against unauthorized access, including by authentication; protect the confidentiality of stored and transmitted data by strong, current mechanisms; and protect integrity. The text names no algorithm, no key length, no certificate format, and no public-key infrastructure. Which mechanism is appropriate follows from the manufacturer's own risk assessment for the product and its intended use.
For key management this has a practical consequence. There is no regulatory obligation to issue per-device certificates or to operate a certificate authority. A manufacturer who can show, through a documented risk assessment, that per-device symmetric keys provide authentication and integrity appropriate to the risk has met the requirement. The obligations that do bite are organizational: the ability to ship security updates, to handle vulnerability reports from September 2026, and to meet the full essential requirements as the regulation applies from 11 December 2027. [CRA Annex I](https://can-security.net/resources/cra-requirements/)
## What IEC 62443 Asks at Security Level 2
Where the CRA is deliberately abstract, [IEC 62443](https://can-security.net/resources/terms-and-definitions/#term-iec-62443)-4-2 is concrete. It states component requirements that, read at Security Level 2, give a clear and achievable target for a CAN device. The requirements that touch keys are the ones worth knowing before you choose a mechanism. [IEC 62443-4-2](https://can-security.net/resources/iec-62443-sl2-requirements/)
### CR 1.2 and CR 1.14: Identification and Authentication
A device must authenticate itself at SL2. CR 1.14 recognizes symmetric-key authentication using CMAC, GMAC, or GCM, and treats the requirement as satisfied when the secret is diversified per device. Uniqueness of identity does not require an asymmetric key pair. [CR 1.2](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-1-2) [CR 1.14](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-1-14)
### CR 1.5: Authenticator Management
The device must support an initial key, allow detection that a default has not been changed, and offer a way to refresh the authenticator over its life. This is a lifecycle capability, not a one-time provisioning step. [CR 1.5](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-1-5)
### CR 4.3 and CR 3.1: Cryptographic Use
Cryptographic mechanisms must follow internationally recognized and proven practice, with guidance pointing to NIST SP 800-57. Communication authentication can provide integrity and origin authenticity without confidentiality, so an authentication tag without encryption is compliant. [CR 4.3](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-4-3) [CR 3.1](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-3-1) [NIST SP 800-57](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-57)
### CR 4.2: Zeroization
Sensitive data, including key material, must be purged so that it cannot be recovered once storage is released or the device is decommissioned. Key destruction is an explicit requirement, not an optional courtesy. [CR 4.2](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-4-2)
Asymmetric mechanisms appear in IEC 62443-4-2 only conditionally, in requirements that begin in effect with the phrase when a PKI is utilized. Hardware-backed key storage is likewise not an SL2 baseline; it is deferred to Security Level 3. The headline for a newcomer is therefore reassuring: unique per-device symmetric keys, properly managed across their lifecycle, satisfy the SL2 baseline. A public-key infrastructure is something you adopt when scale or governance makes it worthwhile, not because the standard forces it.
## Choosing a PKI Does Not Force the Full Nine Yards
A common worry is that the moment you use public-key cryptography, IEC 62443 obliges you to stand up an enterprise certificate authority. It does not. The PKI-related component requirements, CR 1.8 for certificates and CR 1.9 for the strength of public-key authentication, set correctness conditions, not a scale requirement. When public-key authentication is used, the device has to validate the certificate signature, validate the chain to a trust anchor, check revocation status, ensure the holder controls the private key, and map the key to an identity. That is a floor on how well the mechanism works, not a floor on how large the organization behind it must be. [CR 1.8](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-1-8) [CR 1.9](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-1-9)
A minimal PKI clears that floor with very little machinery. With a single root, chain validation is trivial, because the device verifies one leaf against the one anchor it holds. Revocation can be handled with short signed records checked against the anchor rather than a full revocation-list service, and on-chip key generation gives the device control of its private key. What the standard does close off is the middle option: a scheme that issues certificates but quietly skips revocation or chain validation. That fails CR 1.9 regardless of how small it is. The practical result is three honest positions, all of which the standard supports: no PKI with per-device symmetric keys under CR 1.14, a minimal PKI that meets CR 1.8 and CR 1.9 with a small footprint, or a full certificate authority justified by scale. The [Asymmetric Key Management](https://can-security.net/key-management/asymmetric-key-management/) page describes what the minimal and full versions involve.
## How This Page Relates to the Rest of the Site
This page covers only the key-management reading of the two frameworks. For the complete, clause-by-clause matrices, use the dedicated reference pages: the [CRA Annex I Requirements](https://can-security.net/resources/cra-requirements/) quick-reference and the [IEC 62443 SL2 Requirements](https://can-security.net/resources/iec-62443-sl2-requirements/) list. For a worked example of running an IEC 62443-style assessment on a CAN device, see the [IEC 62443-Style Assessment](https://can-security.net/risk-assessment/iec-62443/) walkthrough. Once you know what the rules ask, the [Symmetric vs Asymmetric](https://can-security.net/key-management/symmetric-vs-asymmetric/) page helps you pick the mechanism that meets them with the least lasting overhead.
## Frequently Asked Questions
### Does the EU CRA mandate asymmetric cryptography or device certificates?
No. The CRA states essential requirements in terms of outcomes: protection from unauthorized access including authentication, confidentiality by strong, current mechanisms, and integrity. It names no specific algorithm, no certificate format, and no public-key infrastructure. The appropriate mechanism follows from the manufacturer's own risk assessment.
### Do per-device symmetric keys satisfy IEC 62443 at Security Level 2?
Yes. CR 1.14 explicitly recognizes symmetric-key authentication using mechanisms such as CMAC, GMAC, and GCM, and treats the requirement as met when the secret is diversified per device. Asymmetric mechanisms appear only conditionally, when a PKI is utilized. Unique per-device identity does not imply asymmetric identity.
### If we use a PKI, does IEC 62443 require a full certificate authority?
No. The PKI-related requirements, CR 1.8 for certificates and CR 1.9 for the strength of public-key authentication, set correctness conditions rather than a scale requirement. When public-key authentication is used, the device must validate the certificate signature and chain, check revocation status, ensure the holder controls the private key, and map the key to an identity. A minimal PKI with a single trust anchor can meet all of these, so the choice is not between no PKI and a full enterprise authority. What the standard rules out is a partial scheme that issues certificates but skips revocation or chain validation.
---
# Symmetric Key Management
Symmetric key management is the lower-burden path for most CAN and CAN FD products, and it is where the day-to-day discipline lives. The cryptography is light; the work is in giving every device its own key, deciding whether to store or derive those keys, and running the rotation and revocation cycles that keep a fleet healthy. This page lays out the approaches at a framework level so you can match one to your deployment.
## Before You Diversify, Ask What the Key Is For
Whether every device needs its own symmetric key depends on what the key is for, so start with purpose rather than with a rule. Two questions settle most of it. Is this the only key on the device, carrying identity, firmware protection, and session traffic at once? If not, are firmware protection and device identification handled by separate keys? A key that is the sole means of trust, and whose job is to tell one device from another, has to be unique per device, because a single shared value would let one extracted secret stand in for the whole fleet. A key whose only job is to protect a firmware image for a product family does not carry that requirement, because it is not what distinguishes one unit from the next.
Per-device diversification is therefore core in one specific case, when the key identifies and authenticates the individual device. IEC 62443-4-2 makes the same point from the compliance side, treating the authentication requirement as met when the secret that carries identity is diversified per device. The sections below follow that order: decide what each key is for, diversify the keys that carry identity, and let a firmware or family key stay common where its purpose calls for it. [IEC 62443-4-2](https://can-security.net/resources/iec-62443-sl2-requirements/)
## One Root, Two Kinds of Key
The decision to diversify does not force a separately stored key for every purpose. One root key can produce both kinds at once, because the derivation input decides what comes out. Feed in a device serial number and the root yields a per-device key that identifies and authenticates that one unit. Feed in a fixed string that names a firmware version or a product family and the same root yields a firmware protection key shared across that family. Both come from the one root, differing only in the input mixed in.
A label bound into each derivation keeps the two purposes cryptographically separate, so the identity key and the firmware key can never stand in for one another even though they share a parent. A single stored secret therefore answers the opening question two ways at once: unique where the key carries identity, common where it protects a shared image. The mechanics of holding that one secret, and deriving the rest on demand, are the subject of the sections that follow.
## Where the Randomness Comes From
Every key on this page is only as unpredictable as the source that generated it. A per-device key drawn from a weak or unseeded generator is guessable no matter how carefully it is stored afterward. Generate keys from a hardware random number generator feeding a deterministic random bit generator of the kind specified in NIST SP 800-90A, with an entropy source assessed and health-tested along the lines of SP 800-90B. On a microcontroller that means using the on-chip TRNG rather than a software pseudo-random function seeded from predictable state such as a timer or a serial number. The [Secure CAN MCUs](https://can-security.net/resources/secure-can-mcus/) page lists the CAN FD parts that carry a hardware random number generator for exactly this purpose. [NIST SP 800-90A](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-90a) [NIST SP 800-90B](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-90b)
## Three Ways to Manage the Keys
*Three ways to manage symmetric keys, and where each fits.*
| Approach | How It Works | Trade-Off | Potential Use Cases |
| --- | --- | --- | --- |
| Store Per-Device Keys | Generate a random key for each device and keep it in an integrator database, organized by serial. | Simplest to build, but the database becomes a crown jewel: a leak exposes every device it lists, and refreshing one device means rewriting its key. | Closed, low-Security-Level systems with tight database control, and small fleets where the database stays manageable. |
| Derive From a Root | Hold one root key in a small hardware module and derive each device key on demand from public inputs such as the serial and a key-revision counter. | No per-device database, a leak exposes no secrets, and refreshing a device is a counter bump, but the root must be backed up. | Most CAN and CAN FD fleets meeting the SL2 baseline with low maintenance, and larger fleets where a key database would be a liability. |
| Add an Asymmetric Governance Layer | Keep the derived-from-root scheme and place a lightweight asymmetric signing key above the root, distributing its public half as a trust anchor, to sign which root generation is current. | Adds the ability to revoke a root generation and to check currency, which pure symmetric derivation cannot do, at the cost of an asymmetric signing key to protect. | Deployments that must revoke a root generation or verify currency, and systems that combine symmetric efficiency with governed authority. |
The derivation in the second and third options uses a standard key-derivation function, with HKDF (specified in RFC 5869) the usual choice, fed with values that are not secret. The technique of deriving many keys from one root and tracking generations has long-standing prior art in ANSI X9.24-3, the DUKPT (Derived Unique Key Per Transaction) scheme from the payments world. The lifecycle discipline around all of this, generation, rotation, and destruction, follows NIST SP 800-57. [RFC 5869](https://can-security.net/resources/terms-and-definitions/#term-rfc-5869) [ANSI X9.24-3](https://can-security.net/resources/terms-and-definitions/#term-ansi-x9-24-3) [NIST SP 800-57](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-57)
## Producing Many Keys From Bounded Secure Storage
Deriving keys from one root removes most per-key storage, yet two storage questions remain. Where is the root itself held, and what happens when a program needs several base keys, one per product line or one per security domain, rather than a single one? A hardware security module protects what it holds, yet it holds only a handful of slots. Storing every base key in a secure database can seem the appropriate answer at first glance, yet there are better ones that keep secure storage constant no matter how many base keys the program uses.
### Derive a Key Ladder
Hold one root in the module and derive every working key beneath it on demand, so only the root occupies secure storage and everything else is recomputed when it is needed. As the section above describes, the derivation input sets the purpose: a serial yields a per-device identity key, a firmware or family label yields a shared firmware key. Extending the same idea, the root can derive base keys as an intermediate tier, one per product line or purpose, and those base keys derive the working keys beneath them, so a whole program of keys reduces to one stored secret. NIST SP 800-108 defines the counter-mode derivation this uses. [NIST SP 800-108](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-108)
### Wrap Keys for External Storage
When the individual keys must be independent random values rather than branches of one root, keep a single key-encryption key in the module and store each key encrypted under it in ordinary storage. The module unwraps a key only at the moment it is used, so secure storage holds one key-encryption key however many keys exist. AES key wrap is the standard construction. The trade against a ladder is that the wrapped material is the only copy, so it must be backed up. [NIST SP 800-38F](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-38f)
### The following animation illustrates how symmetric keys can be managed by the manufacturer using USB-HSMs (Hardware Security Modules):
The symmetric key management described here can be used in a similar fashion on the integrator level. The following cryptographic solutions depend on such symmetric keys:
- [Frame Security](https://can-security.net/solutions/frame-security/) authenticates each frame on the bus.
- [Secure Object Fieldbus Access](https://can-security.net/solutions/secure-object-fieldbus-access/) protects object-level reads and writes.
- [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/) authenticates firmware updates.
## Rolling, Rotation, Refresh, and Revocation
A symmetric deployment is not finished when the keys are provisioned; it runs for the life of the fleet. Four mechanisms keep it healthy, and it pays to keep them distinct, because the first two sound alike yet differ in which key they touch and how often:
### Rolling
The short-lived session key changes automatically on a fixed time base, with no human action. SPsec, for example, rolls the session key continuously this way, so the key protecting traffic is never the same for long. Rolling limits how much data any single key ever protects, and it is part of normal running rather than maintenance.
### Rotation
The longer-lived operational or root key is replaced on a planned schedule, far less often than the session key rolls. Where rolling is continuous and automatic, rotation is deliberate and policy-driven. It is the periodic re-keying of the keys that persist across sessions and that the rolling layer is derived from.
### Refresh
An operational key is replaced on demand, for hygiene or after a suspected exposure. With a derived scheme this is a key-revision bump that the device re-derives from; with a stored scheme it is a rewrite plus a database update.
### Revoke
Authority is withdrawn after a credential is compromised. Where an asymmetric governance layer is present, a technician or operator grant can be denied without re-keying devices; in a pure stored or derived scheme, revocation means refreshing the affected devices.
One more obligation closes the lifecycle. IEC 62443-4-2 CR 4.2 requires that key material be zeroized, that is, purged so it cannot be recovered, when a device is reset, decommissioned, or has its storage released. Key destruction is as much a part of symmetric key management as key creation, and it is easy to forget until an audit asks for it. [CR 4.2](https://can-security.net/resources/iec-62443-sl2-requirements/#cr-4-2)
## Frequently Asked Questions
### Does every device need its own symmetric key?
It depends on what the key is for. A key that identifies and authenticates the individual device has to be unique per device, because it is what tells one unit from another and one extracted secret would otherwise stand in for the whole fleet. A key whose only job is to protect a firmware image for a product family does not need per-device diversification, because it does not distinguish one unit from the next. IEC 62443-4-2 treats the authentication requirement as met when the secret that carries identity is diversified per device, so per-device keys are the baseline for identity even where a shared firmware key is acceptable.
### Can one root key both protect firmware and identify devices?
Yes. One root can derive both kinds of key, because the derivation input sets the purpose. A device serial number yields a per-device identity key unique to that unit, and a fixed firmware or family label yields a firmware protection key shared across the family. A label bound into each derivation keeps the two cryptographically separate, so neither can stand in for the other.
### Is it better to store per-device keys or derive them from a root?
Deriving from a root held in a small hardware module usually wins for maintenance. There is no per-device key database to protect, a database leak exposes no secrets because the derivation inputs are public, and a single device can be refreshed by bumping its key-revision counter. The trade is that the root must be backed up, since its loss means the fleet's keys can no longer be derived.
---
# Symmetric vs Asymmetric Keys
This is the first real decision in key management, and it shapes every process that follows. The two families are not ranked by strength; they trade different costs. Symmetric cryptography keeps the device light but pushes the work into secure provisioning. Asymmetric cryptography solves key distribution but asks more of the hardware and of the organization that runs the trust anchors. This page explains the difference in plain language and names the algorithms on each side.
## The Essential Difference
A symmetric key is a single shared secret. The two parties that use it hold the same value, and anyone holding that value can both produce and verify protected messages. An asymmetric key is a pair: a private half that never leaves its holder, and a public half that can be handed to anyone. What the private half produces, the public half verifies, and vice versa. That asymmetry is the whole point, because it lets a device publish its public half openly while keeping the private half secret.
For a fieldbus device the consequence is concrete. With symmetric keys, every device that must be individually identifiable needs its own distinct key, and that key has to be placed on the device and recorded somewhere secure. With asymmetric keys, a device can carry a private identity key it generated itself, and the rest of the system only ever needs the public half. The trade is between the simplicity of one shared value and the distribution freedom of a published public half.
## What Each Side Costs
The two families trade their costs in opposite directions:
### Symmetric: Cheap on the Device, Careful in Provisioning
Verification is a fast tag check, well within reach of a small microcontroller, often with hardware acceleration. The cost moves to logistics: every secret must be generated, transported, and stored without exposure, and diversified per device so that one extracted key does not unlock the fleet. A leaked key database compromises every device whose key it held.
### Asymmetric: Heavier Compute, Easier Distribution
Signature and key-agreement operations are heavier and use larger keys, which matters on constrained parts and at session-setup time. In return, key distribution is largely solved: public halves can be published freely, and trust is established by verifying a chain to a known trust anchor. The concentrated risk shifts to the offline signing key behind that anchor, which signs everything.
## The Algorithms Involved
Both families draw on a small, well-established set of primitives. None of these are exotic, and all are documented in international standards, which matters for the IEC 62443 requirement that cryptography follow recognized practice. [IEC 62443-4-2](https://can-security.net/resources/iec-62443-sl2-requirements/)
### Symmetric Primitives
AES-128 or AES-256 in GCM mode provides authenticated encryption, giving confidentiality and integrity together. AES-GMAC and CMAC provide authentication without encryption, which IEC 62443 accepts for communication integrity. HKDF derives per-purpose keys from a root secret, and SHA-256 is the standard hash underneath them. ChaCha20-Poly1305 is a common lightweight alternative to AES-GCM.
### Asymmetric Primitives
Ed25519 signs and verifies, and X25519 performs key agreement; both are modern, compact, and fast as elliptic-curve schemes go, and make sensible defaults. RSA-2048 and ECDSA P-256 remain in use where existing toolchains or certificate infrastructures require them. These pair naturally with the symmetric primitives: an asymmetric handshake establishes a session, then symmetric keys carry the routine traffic.
Whichever set you pick, treat the algorithm as replaceable rather than permanent. An industrial device stays in the field for a decade or more, longer than any single primitive is guaranteed to stand, so the update mechanism should be able to carry a new algorithm and the protocol should identify which one a message uses. This crypto-agility matters most on the asymmetric side, where the migration to post-quantum signature and key-agreement schemes is already on the standards horizon; the symmetric side is more durable, since AES-256 and SHA-256 retain a comfortable margin. Designing the field-update path to change primitives now is far cheaper than retrofitting it once a curve or key length is deprecated.
## How to Decide
For most CAN and CAN FD products entering compliance for the first time, symmetric keys are the lower-burden path that still meets the Security Level 2 baseline described on the [Regulations & Standards](https://can-security.net/key-management/regulations-standards/) page. Asymmetric mechanisms earn their extra cost when you need open distribution of trust, [delegated authority](https://can-security.net/resources/terms-and-definitions/#term-delegation) that can be revoked without re-keying every device, or anti-counterfeiting identity that a manufacturer signs at scale. Many real systems use both: an asymmetric handshake to set up trust, and symmetric keys for everything afterward. The [Fieldbus Device](https://can-security.net/key-management/fieldbus-device/) page shows which device functions pull in which kind of key, and the two management pages cover the lifecycle of each.
The table below sketches four common capability tiers, from a very constrained controller to a part with a dedicated security subsystem, and the key-management infrastructure that fits each. The device capability and the infrastructure escalate together, so most products settle on one row rather than mixing across them. The tiers follow the ordered [device capability ladder](https://can-security.net/resources/terms-and-definitions/#term-device-capability-level): symmetric only, verify a signature it is given, sign with an identity of its own, and agree a key. Frameworks number these tiers differently and the numbering is not interchangeable, so each row below is named by what the device can do rather than by a level number.
*Device capability and the key-management infrastructure that matches each tier.*
| Device Class | On-Device Cryptography | Key-Management Infrastructure | What It Enables |
| --- | --- | --- | --- |
| **Symmetric only**: Very constrained. Little budget to spare for security. | Symmetric only. AES-128-GCM authenticated encryption, with per-purpose keys derived by HKDF. The device verifies tags and never a signature. | Minimal. One root in a small [hardware security module](https://can-security.net/resources/terms-and-definitions/#term-hsm), from which a key ladder derives per-device identity keys and firmware keys on demand. | The IEC 62443 SL2 baseline, per-device identity, and firmware protected by a symmetric tag. |
| **Can also verify a signature**: Mid-range. Headroom for verification, from a hardware AES block or from clock margin. | Symmetric traffic, plus verification of a manufacturer signature over firmware and configuration. Only a public key sits on the device. | The ladder above, plus signed files. The manufacturer holds a signing key and publishes the matching public key to devices. | Firmware origin proof and anti-rollback through a signature, with no private key on the device. |
| **Can sign under its own identity**: Capable. Headroom for signing, on a public-key accelerator or a fast core. | Symmetric traffic plus a device identity of its own. The device holds its own private identity key and uses Ed25519 to sign, so it can attest what it is and authorize actions under its own name. | A registry of device public keys, or a minimal PKI. The identity can be distributed as a raw public key recorded against the serial, or wrapped in a certificate where a PKI is already in play. | Self-generated device identity, open trust distribution, and delegated authority. |
| **Full asymmetric operation**: State of the art. Ample headroom, usually with secure key storage. | Full asymmetric operation adding X25519 key agreement, so a fresh session key is agreed for each session and confidential key install becomes possible. | A full PKI. Certificate hierarchies, revocation, and lifecycle governance. | Dynamic re-keying, revocation without re-provisioning devices, and large delegated deployments. |
Each row points to a deeper page. The symmetric ladder and its key derivation are covered on [Symmetric Key Management](https://can-security.net/key-management/symmetric-key-management/), the signature option for firmware is covered on [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/), and the PKI tiers are covered on [Asymmetric Key Management](https://can-security.net/key-management/asymmetric-key-management/). Reaching a tier depends on the compute budget the application can spare, not on a specific accelerator: acceleration helps on a tight time budget, but a fast core with clock margin can do without it. The [Secure CAN MCUs](https://can-security.net/resources/secure-can-mcus/) reference lists CAN FD controllers by the hardware security features they carry. The [MCU Crypto Benchmarks](https://can-security.net/resources/crypto-benchmarks/) page measures what each primitive costs in flash, stack, and time on those parts.
> ### CANcrypt: A Symmetric-First Layer for CAN
> CANcrypt implements the symmetric path end to end for CAN and CAN FD: per-device keys, secure grouping, and rotation, sized for the constrained controllers typical on a fieldbus. It is the practical option when you want the lighter device burden without standing up a public-key infrastructure.
> [Explore CANcrypt →](https://www.cancrypt.net/)
## Frequently Asked Questions
### Is asymmetric cryptography more secure than symmetric for CAN?
Not inherently. Both can meet the same security goals. Asymmetric cryptography solves key distribution by letting the public half be published, at the cost of larger keys and heavier verification. Symmetric cryptography is lighter on the device but requires every secret to be provisioned securely and diversified per device. The right choice depends on scale, governance, and the constraints of the hardware.
### Which algorithms are typical on each side for CAN devices?
On the symmetric side: AES-128 or AES-256 in GCM for authenticated encryption, AES-GMAC or CMAC for authentication only, HKDF for key derivation, and SHA-256 for hashing. On the asymmetric side: Ed25519 for signatures and X25519 for key agreement as modern defaults, with RSA-2048 or ECDSA P-256 where legacy interoperability is needed.
---
# Privacy Notice
This is a static informational website. It sets no cookies, runs no analytics, embeds no third-party scripts or fonts, and contains no contact forms. The notice below explains the limited processing that does occur, your rights under the GDPR, and how to exercise them.
[Diese Seite auf Deutsch →](https://can-security.net/privacy/de/)
## 1. Controller
The controller for the processing of personal data on this website within the meaning of Art. 4 No. 7 GDPR is:
**Embedded Systems Academy GmbH**
Bahnhofstr 17
30890 Barsinghausen
Germany
Phone: +49 5105 582 7897
Email:
For the full legal-entity record (commercial register, VAT identification, managing director), see the [Imprint](https://can-security.net/imprint/).
## 2. Scope of this Notice
This notice applies **only** to the CAN Security Reference website, served from the primary domain `can-security.net`, with the secondary domain `cansecurity.net` redirecting to it. Other Embedded Systems Academy properties, including esacademy.com, esacademystore.eu, emsa.courses, cancrypt.net, and canopenmagic.com, operate under their own privacy notices. Following any external link will leave the scope of this notice.
## 3. What This Site Does Not Do
For clarity, this website explicitly does **not**:
- set any cookies, including no consent or session cookies;
- use `localStorage`, `sessionStorage`, or any other client-side persistent storage;
- load analytics, tag managers, or tracking pixels (no Google Analytics, no Plausible, no Matomo, no Meta Pixel, etc.);
- load fonts, scripts, stylesheets, images, or media from third-party content delivery networks, including no Google Fonts, no Cloudflare, no jsDelivr, no Gravatar;
- embed videos, social-media widgets, or maps;
- contain HTML `