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 IEC 62443-4-2
The EU Cyber Resilience Act Sets Outcomes, Not Mechanisms
The 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
What IEC 62443 Asks at Security Level 2
Where the CRA is deliberately abstract, 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
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 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
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 CR 3.1 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
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 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 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 quick-reference and the 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 walkthrough. Once you know what the rules ask, the 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.