Cryptography is an engineering mechanism for achieving CRA cybersecurity outcomes, not a substitute for the risk assessment. Product teams should define what needs confidentiality, integrity, authenticity or trust, select appropriate maintained mechanisms, control the full key lifecycle and preserve enough agility to replace cryptographic choices when risk or the state of the art changes.
The CRA Requires Outcomes Rather Than One Cryptographic Suite
Annex I does not tell every manufacturer to use one specific cipher, key size, certificate system or protocol. Point 2(e) requires protection of confidentiality and expressly gives encryption of relevant data at rest or in transit using state-of-the-art mechanisms as an example. Point 2(f) separately requires protection of integrity against unauthorised manipulation or modification. The cybersecurity risk assessment should therefore determine where cryptography is appropriate and which security property the mechanism is intended to provide.
- Identify the required security property.
- Use the cybersecurity risk assessment to define scope.
- Select maintained and appropriate mechanisms.
- Document why the selected mechanism fits the product risk.
Do Not Treat Encryption as Evidence for Every Security Property
Encryption is primarily associated with confidentiality, but some cryptographic constructions can also provide integrity and authenticity. The product team should be precise about the property being delivered. Encrypting data does not automatically prove that unauthorised modification will be detected, and a digital signature can provide authenticity and integrity without making the signed data secret. CRA evidence should therefore map each cryptographic control to the relevant security objective rather than simply state that the product uses encryption.
- Separate confidentiality from integrity.
- Separate integrity from authenticity.
- Identify which mechanism provides each property.
- Test each security property independently.
Use Maintained Cryptographic Libraries and Protocols
Custom cryptographic algorithms and improvised protocols create unnecessary implementation risk. Product teams should normally rely on maintained, reviewed cryptographic libraries and established protocols appropriate to the product environment. Developers should not disable certificate checks, signature verification or other protections merely to resolve integration problems. Approved usage patterns should be documented so developers understand which APIs, algorithms and configurations are permitted.
- Prefer maintained cryptographic libraries.
- Avoid designing custom cryptographic algorithms.
- Define approved protocol configurations.
- Review security-sensitive cryptographic changes.
Key Management Is Part of the Cryptographic Design
Strong algorithms do not compensate for weak key management. Product teams should define how keys are generated, provisioned, stored, accessed, rotated, revoked and retired. Different keys can have very different consequences if compromised. An update-signing key may affect many product installations, while a per-device key may affect only one device. The architecture should therefore match protection and operational controls to the authority of each key.
- Define key purpose.
- Define key generation.
- Restrict key access.
- Define rotation and revocation.
- Plan key replacement after compromise.
Protect High-Authority Signing Keys
Keys used to sign firmware, software packages or security updates can create a particularly large blast radius. A compromised signing key can allow an attacker to produce artefacts that appear authorised. Signing authority should therefore be separated from ordinary developer access and limited to controlled release processes. Depending on the product risk, additional protections can include hardware-backed storage, multi-person approval, isolated signing environments or tightly restricted CI/CD access.
- Separate signing keys from developer credentials.
- Restrict signing operations.
- Audit high-value signing activity.
- Prepare a signing-key compromise response.
- Support replacement of trusted signing keys.
Randomness and Nonces Need Deliberate Design
Cryptographic systems often depend on unpredictable random values and correct nonce behaviour. Weak randomness can undermine otherwise sound algorithms by producing predictable keys, tokens or challenges. Reusing values where a protocol requires uniqueness can also break important security guarantees. Product teams should use appropriate platform or library randomness sources and test behaviour across startup, reset, cloning and constrained-device conditions.
- Use appropriate secure randomness sources.
- Avoid predictable key generation.
- Follow protocol nonce requirements.
- Review behaviour after reset or cloning.
Certificate Validation Needs Full-Path Testing
Products using certificates should test more than the successful connection path. Verification can include trust anchors, hostname or identity checks, validity periods, signature verification and relevant revocation behaviour. Development shortcuts that disable validation can create permanent product vulnerabilities when they reach production. Failure paths should reject unauthorised peers rather than silently falling back to insecure communication.
- Validate the expected peer identity.
- Validate trust chains.
- Handle expired or invalid certificates safely.
- Do not silently disable verification.
Plan for Cryptographic Agility
Products can remain in use for years while cryptographic guidance and attack capabilities change. Cryptographic agility means the architecture can replace algorithms, trust anchors, keys or protocol settings without requiring an impractical redesign. It does not mean accepting arbitrary algorithms or automatically negotiating weak legacy options. The product should retain controlled migration paths that allow the manufacturer to respond when a previously acceptable mechanism no longer provides an appropriate level of protection.
- Inventory cryptographic dependencies.
- Avoid unnecessary hard-coded assumptions.
- Plan trusted migration mechanisms.
- Remove obsolete mechanisms when appropriate.
Cryptographic Failure Should Fail Safely
Cryptographic operations can fail because verification fails, keys expire, trust stores are damaged or secure storage becomes unavailable. The product should define what happens in these cases. Silently accepting unverified software or falling back to plaintext communication can undermine the security objective entirely. Some products may require constrained recovery mechanisms, but those paths should be deliberately designed and tested rather than emerging from generic error handling.
- Reject failed integrity or authenticity checks.
- Avoid silent downgrade to insecure communication.
- Define secure recovery paths.
- Test expired and invalid credentials.
Maintain a Cryptographic Inventory and Evidence
Useful evidence can include a cryptographic inventory, algorithm and protocol decisions, key-management architecture, certificate design, signing controls and verification tests. The inventory should identify where cryptography is used and which security property it provides. This makes later review easier when the state of the art changes or a library, algorithm or protocol needs replacement.
- Cryptographic inventory.
- Algorithm and protocol rationale.
- Key lifecycle design.
- Signing architecture.
- Cryptographic verification results.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.