Cryptographic Agility

Cryptographic agility is a design property that enables a system to switch cryptographic algorithms — for encryption, signing, key exchange, or hashing — without requiring a full redesign of the product architecture. A cryptographically agile product negotiates or selects algorithms from a configurable set, rather than having algorithms hardcoded into the firmware or software. This is important because cryptographic algorithms have finite lifetimes: advances in computing power, mathematical techniques, and ultimately quantum computing make today's strong algorithms potentially weak in future decades. Products that hardcode a single algorithm (e.g., 3DES, SHA-1) cannot be updated when that algorithm is deprecated, forcing complete hardware replacement rather than a software update.

The CRA's Annex I requires that products use state-of-the-art cryptography appropriate to the product's context and that security mechanisms can be updated. Cryptographic agility is the architectural property that makes compliance with this requirement maintainable over the product's support period. ENISA's guidance on cryptographic recommendations (published as the ENISA Algorithms, Key Sizes and Parameters Report) provides annual recommendations on acceptable algorithms and key sizes. A product designed in 2025 must be able to implement ENISA's 2030 or 2035 recommendations through a software update, not by being replaced entirely. This has practical implications for products with long support periods (5-10 years), such as industrial equipment, medical devices, and infrastructure components.

The most pressing driver for cryptographic agility today is the anticipated threat from quantum computers to current public-key cryptography (RSA, ECDSA, DH). NIST published its first post-quantum cryptography (PQC) standards in 2024 (ML-KEM, ML-DSA, SLH-DSA — formerly Kyber, Dilithium, and SPHINCS+). The EU's NIS2 Directive and ENISA guidance are progressively recommending PQC transition planning. For CRA-covered products with support periods extending beyond 2030, cryptographic agility is critical:

• Products must be able to update their key exchange and signature algorithms to PQC variants through OTA updates.
• Hardcoded RSA or ECDSA key sizes or algorithms will require firmware replacement rather than update.
• Hybrid classical/PQC modes (running both current and PQC algorithms simultaneously during transition) require algorithm negotiation capability — the foundation of cryptographic agility.

Practical cryptographic agility implementation involves:

• Algorithm abstraction layers: Use cryptographic libraries (OpenSSL, mbedTLS, Bouncy Castle) that provide algorithm-agnostic APIs, so the calling code does not need to be rewritten when an algorithm changes.
• Configurable cipher suites: For TLS-based communications, configure the product to support multiple cipher suites ranked by preference, enabling deprecation of weak suites by simply removing them from the configured list via an OTA update.
• Negotiated algorithm selection: Where protocols allow, implement algorithm negotiation so the product and its counterpart can select the strongest mutually supported algorithm.
• Avoid hardcoded algorithm constants: Never hardcode algorithm identifiers (e.g., AES-128, SHA-256) directly into protocol logic — reference them through a configurable constants file.
• Key size configurability: Design key generation to accept key size parameters rather than hardcoding key sizes, enabling key size increases through configuration updates.