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.
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
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 IEC 62443
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
The individual security functions a device should provide, and which keys each one needs, compared symmetric against asymmetric.
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
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
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 shell needs keys to authenticate bus traffic. Secure Object Fieldbus Access needs an authentication key to gate Object Dictionary access. The 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.
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.