What are ECCG agreed cryptographic mechanisms post-quantum?

The ECCG Agreed Cryptographic Mechanisms document is the EU’s reference list of cryptographic algorithms and parameters that count as state of the art for security certification. The European Cybersecurity Certification Group (ECCG) maintains it and ENISA publishes it. Since version 2, it also says which post-quantum mechanisms are accepted and how to combine them with classical cryptography.

If you run OT or critical infrastructure, this list matters well beyond product certification. It is the clearest official statement in Europe of which key exchange is acceptable for links between sites, cloud environments and remote users that have to stay confidential for years. This article explains what the document says, how it connects to the EUCC and the Cyber Resilience Act, and how to use it when you buy VPN or encryption gateways.

What is the ECCG Agreed Cryptographic Mechanisms document?

It is a guidelines document under the EUCC (the Common Criteria-based European certification scheme), written by the ECCG’s Sub-group on Cryptography. It sorts algorithms into “recommended” and “legacy” and adds notes on implementation and parameters.

The EUCC was created under Regulation (EU) 2019/881 (Cybersecurity Act) by Implementing Regulation (EU) 2024/482. ENISA’s guidelines describe the cryptography document as a guidelines document supporting Commission Implementing Regulation (EU) 2024/482, and say it may be updated whenever needed to reflect the developments and best practices in the field of Agreed Cryptographic Mechanisms. Under that regulation, state-of-the-art documents which have been endorsed by the European Cybersecurity Certification Group shall be published by ENISA.

The document defines two categories. Recommended mechanisms are regarded to represent the current state of the art in cryptographic security engineering. Legacy mechanisms are older algorithms that are still widely used:

The document is also intended for people outside certification. Its authors say it could also help developers, decision makers and users of cryptography to decide which cryptographic mechanisms are state-of-the-art and could cover their need for cryptographic protection, e.g., confidentiality, integrity, data origin authentication and authentication.

Which post-quantum key exchange mechanisms does the EU accept?

ML-KEM (FIPS 203) is the main agreed post-quantum key encapsulation mechanism. FrodoKEM appears next to it as a more conservative lattice-based option. Both are agreed only for use in a hybrid construction.

Version 2, published in April 2025, is the first edition that introduces several asymmetric post-quantum mechanisms as agreed. For key establishment it lists ML-KEM as recommended. For signatures it adds ML-DSA (FIPS 204), SLH-DSA (FIPS 205) and the stateful hash-based schemes. ENISA’s April 2026 report on hybridisation maps standards against version 2. It lists ML-KEM-768, ML-KEM-1024, FrodoKEM-976 and FrodoKEM-1344 under agreed key agreement schemes, although ENISA says the report does not establish a recommendation from ENISA and the ECCG subgroup on cryptography.

A draft revision dated May 2026 on ENISA’s certification portal makes this explicit. It marks ML-KEM [FIPS203] R and FrodoKEM as recommended and adds a parameter note: It is recommended to use the highest possible standardised parameter size, either ML-KEM-1024 or ML-KEM-768.

The hybrid rule

The rule with the most practical effect is about how these KEMs are used. Version 2 states that LWE or MLWE based cryptographic mechanisms shouldn’t be used in a standalone way to provide the intended security functionality, but should be combined with a well established classical cryptomechanism. The ECCG Sub-group on Cryptography explains that a hybrid construction is only broken if all combined pre or post-quantum cryptographic mechanisms need to be broken simultaneously for the hybrid mode to be broken.

The rule also works the other way. For classical asymmetric mechanisms, the document says that in contexts where resistance against attacks leveraging quantum computers is required, these cryptographic mechanisms shall not be used without being combined with a quantum resistant mechanism. In plain terms, neither half is enough on its own for confidentiality that has to last.

The document also says how the two halves are joined. A key combiner works in such a way that establishment of the resulting key is secure as long as at least one of the key establishment mechanisms is robust. Version 2 lists two ETSI constructions as recommended combiners: CatKDF and CasKDF.

Does EUCC certification require hybrid post-quantum key exchange?

The EUCC does not require every product to have post-quantum key exchange. But if a product claims quantum resistance through a lattice-based KEM, the agreed mechanisms expect that KEM to be combined with a classical one, and evaluators check against that list.

The wording in the EUCC guidelines is deliberately careful. Developers should consider using the agreed cryptographic mechanisms as defined in ECCG Agreed Cryptographic Mechanisms version 2, and evaluators should check that products preferably rely on agreed cryptographic mechanisms as defined in ACM v2. That is guidance, not an absolute ban. In practice, though, a product that departs from the list has to justify it during evaluation.

For some product types the list is mandatory. The EUCC state-of-the-art document for qualified signature and seal creation devices says that the usage of cryptographic mechanisms (including related relevant parameters) that are classified neither as ‘recommended’ nor as ‘legacy’ in [EUCC_CR] is not allowed. Expect protection profiles for network encryption devices to move the same way as they are updated.

Certification under the Cybersecurity Act is voluntary unless EU or national law makes it mandatory. For an OT operator, the more useful question is whether a gateway’s key exchange matches what the list describes, whether or not the vendor holds a certificate.

How do the ECCG agreed mechanisms affect buying VPN and encryption gateways?

They turn “quantum-safe” from a marketing word into something you can check. Ask which KEM and parameter set the gateway uses, how the classical and post-quantum secrets are combined, and how the algorithms can be replaced later.

This is most urgent for OT. Recordings of control traffic, engineering files and remote maintenance sessions can stay sensitive for as long as the plant runs, so data captured today could be decrypted once quantum computers are capable enough. The EU timeline reflects this:

• All Member States should start transitioning to PQC by the end of 2026. (European Commission, Coordinated Implementation Roadmap, June 2025)
• The protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030. (European Commission, June 2025)
• The roadmap expects as many systems as possible to be migrated by 2035. (European Commission Joint Research Centre, 2025)

Henna Virkkunen, Executive Vice-President of the European Commission, put it this way when the roadmap was released: “post-quantum cryptography is essential to ensure a high level of cybersecurity, fortifying our systems against future threats.”

A procurement checklist based on the list

Two more points matter in OT procurement. The first is protection against downgrade. IETF work on ML-KEM in IKEv2 warns that an on-path attacker might force peers back to traditional-only key exchange if both still support it. So ask how a gateway stops a session from being negotiated without the post-quantum part. The second is crypto agility. The ECCG list has changed once in about a year and a new draft is already out, so a gateway whose algorithms cannot be updated in the field will fall behind the list during its service life.

Where gateways sit in an OT network

In many OT networks the practical answer is a dedicated encryption layer that leaves existing firewalls and routers in place. Quantum Network’s QPN is one example of this pattern. It is a Layer 3 gateway placed at each end of a site-to-site, edge-to-cloud or remote-access connection. It combines a classical and an ML-KEM post-quantum part into one session key, and it sits in front of the existing firewall when that firewall still needs to inspect traffic. Whatever product you look at, check the same items in the table above against the vendor’s own documentation.

How does the ECCG list relate to the Cyber Resilience Act’s essential requirements?

Regulation (EU) 2024/2847 (Cyber Resilience Act) requires manufacturers to protect data with state-of-the-art means but does not name algorithms. The ECCG list is the most authoritative EU description of what “state of the art” means for cryptography.

The essential requirements in Annex I include obligations to protect the confidentiality and integrity of data stored, transmitted or processed, and the legal text refers to encryption of data at rest or in transit by state-of-the-art mechanisms. The CRA leaves the choice of algorithm to harmonised standards, certification schemes and technical practice. That is where the ECCG document comes in, because it explicitly presents itself as a tool for deciding which mechanisms are state of the art.

The timing lines up with the PQC roadmap. The CRA entered into force on 10 December 2024. The main obligations introduced by the Act will apply from 11 December 2027, with reporting obligations to apply as of 11 September 2026. A European Commission presentation hosted by ENISA describes a strong hook to the Cyber Resilience Act in the Roadmap, and the roadmap targets quantum-safe software and firmware upgrades are enabled by default by 2030.

The CRA also links to the Cybersecurity Act through Article 27. That article allows European cybersecurity certification schemes, such as the EUCC, to be used to show conformity with the essential requirements. This is the route by which the ECCG list could gain more legal weight over time.

What this means for operators rather than manufacturers

CRA obligations fall on manufacturers, importers and distributors of products with digital elements. As an operator of critical infrastructure, you are mainly a buyer. Even so, the CRA’s state-of-the-art requirement and the ECCG list give you a defensible basis for procurement requirements. Writing “hybrid key establishment using agreed mechanisms per the current ECCG Agreed Cryptographic Mechanisms” into a tender is concrete, checkable and in line with Commission Recommendation (EU) 2024/1101, which foresees PQC in critical infrastructures via hybrid schemes that may combine Post-Quantum Cryptography with existing cryptographic approaches.

Two caveats. First, the ECCG list is a moving target: version 2 is current, a draft successor exists, and your requirement should refer to “the current version” rather than a fixed edition. Second, an algorithm on the list is not a guarantee of security. The list itself contains implementation notes because most real-world failures come from how cryptography is built and configured, not from the choice of algorithm.