CRA encryption requirements for product makers

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sets its encryption requirement in Annex I, Part I (2)(e): protect the confidentiality of stored, transmitted or otherwise processed data, for example by encrypting relevant data at rest or in transit by state-of-the-art mechanisms. It does not name post-quantum algorithms. Reporting obligations under Article 14 apply from 2026-09-11 and the regulation applies in full from 2027-12-11, so product teams are choosing cryptography now for devices that will still be supported long after those dates.

What the requirement says, and what it does not

Annex I has two parts. Part I lists essential cybersecurity requirements for the product itself, including being placed on the market without known exploitable vulnerabilities, a secure by default configuration, and the confidentiality requirement in (2)(e). Part II lists vulnerability handling requirements that run across the support period the manufacturer declares. The text is on EUR-Lex (Regulation (EU) 2024/2847) and our dated summary is on the CRA regulation page.

Three consequences follow for a product team:

• The requirement is outcome based. It names confidentiality and state-of-the-art mechanisms, not RSA, not ECDH, not ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, standardized in NIST FIPS 203).
• The reference is moving. A mechanism that is defensible at conformity assessment can stop being defensible while the product is still supported.
• Nothing in the text obliges you to ship post-quantum cryptography today. Equally, nothing rescues a design whose cryptography cannot be changed once the state of the art moves.

Harmonised standards may later detail how to meet Annex I, and conformity with a harmonised standard cited in the Official Journal gives a presumption of conformity. Until such a standard exists and is cited, its content is unknown: do not plan against assumptions about what it will say on cryptography. The legal content here is information, not legal advice.

The dates on the CRA calendar

For a device with a multi-year support period, the planning horizon is not 2027. It is the last date on which you still owe security updates for units sold just before support ends.

What state of the art can reasonably mean over a support period

The CRA does not publish an algorithm list, so the honest way to reason about state of the art is to look at what public authorities and standards bodies have actually published, with their status preserved.

Primary sources: the EU roadmap, BSI TR-02102-1, the ANSSI PQC FAQ, NIST IR 8547 ipd and NCSC migration timelines.

Our interpretation, clearly labelled as such: none of these texts makes post-quantum cryptography a CRA obligation, and no authority has stated that classical cryptography fails Annex I today. But a product whose support period extends past 2030 is being sold into a period where several authorities have already published dates for retiring classical key establishment. The defensible engineering position is therefore agility: the ability to change algorithms through a normal update, evidenced in the design file.

Crypto agility in firmware

Agility is a property of the implementation, not a sentence in a policy. Four questions decide whether a shipped device can follow the state of the art, and they are easier to answer before tape-out than after. Our deeper treatment is in the article on crypto agility.

• Negotiation, not constants. Algorithm identifiers, named groups and key sizes come from configuration or from the protocol handshake, never from a compiled constant or a fixed-size buffer. ML-KEM keys and ciphertexts are far larger than elliptic-curve values, so a struct sized for 32-byte keys is a hardware-level blocker.
• Headroom. Budget flash, RAM and handshake time for larger key material. Measure it on the target, not on a workstation.
• Library boundary. Call cryptography through a thin internal interface so the provider can be replaced. Pin the minimum version in the build: the ML-KEM TLS groups require OpenSSL 3.5 or later.
• Classical fallback. Prefer hybrid key establishment and keep a classical group behind it, so a device still connects when the far end is older.

On a test build, check what the stack can actually offer and what a device endpoint negotiates:

openssl version
# ML-KEM TLS groups require OpenSSL 3.5 or later
openssl list -tls-groups

# read-only test against a device endpoint, hybrid first, classical fallback
openssl s_client -connect device.example.com:443 -tls1_3 \
  -groups X25519MLKEM768:X25519 </dev/null

The hybrid group to prefer today is X25519MLKEM768 (IANA codepoint 0x11EC), with SecP256r1MLKEM768 or SecP384r1MLKEM1024 where a NIST curve is required; the IETF profile for post-quantum traditional hybrid key agreement in TLS 1.3 is RFC 10024 (August 2026). Pre-standard Kyber draft groups such as X25519Kyber768Draft00 are obsolete and should be removed from device firmware. Test in staging before production, and keep the classical group in the list.

Device management planes deserve the same pass. OpenSSH 9.9 added mlkem768x25519-sha256, OpenSSH 10.0 made it the default key agreement, and OpenSSH 10.1 warns when a connection negotiates a non post-quantum key agreement, per the OpenSSH release notes.

Update signing: the part you cannot patch later

Transport keys rotate every session. A root of trust burned into silicon does not. Recorded traffic is protected only by the key exchange, which is why hybrid key establishment comes first, while signatures can migrate later; but update signing is the one signature path where a late migration may be impossible, because the verifier lives in immutable boot code.

Practical measures, in order of value:

1. Provide more than one verification slot or key hierarchy, so a new signature algorithm can be introduced by an update rather than by a recall.
2. Decide now which post-quantum signature family the product could accept: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or the stateful hash-based LMS and XMSS from NIST SP 800-208, which require strict state management to avoid reusing a one-time key.
3. Keep signature verification code and parameters in an updatable stage where the security model allows it, with the immutable stage limited to verifying that updatable stage.
4. Document key rollover: who holds the keys, how a compromised or deprecated key is retired, and how a device in the field learns the new one.

CNSA 2.0 already sets end of 2030 for exclusive use of its algorithms in software and firmware signing for US National Security Systems. That is not an EU obligation, but it is a published date for the same engineering problem, and it is a reasonable input when you argue what state of the art means for a product supported past 2030.

Mapping the requirement to evidence

Next step: measure what your product shows on the wire

Before writing a single line of CRA documentation, find out what your own endpoints and update servers actually negotiate today. You can scan your domain with PQC Status for free to see the TLS versions, hybrid ML-KEM groups, cipher suites and certificate chain an external client observes. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation. Use the result as the first line of your inventory, then work inward to the firmware: key sizes in structs, library versions in the build, and the number of verification slots in your boot chain.