A Guide to International Post-Quantum Cryptography Standards

Jan Schaumann

Oct 08, 2025

Jan Schaumann

Jan Schaumann

Written by

Jan Schaumann

Jan Schaumann, Chief Information Security Architect at Akamai, has more than 20 years of experience building and securing high-availability services at internet scale. At Akamai, he launched our bug bounty program, works with the Architecture Group on a range of company-wide initiatives, represents InfoSec in the Open Source Working Group, and leads the internal Cryptography Group, among other initiatives. His research interests cover the overall health of the internet, as well as the safety and privacy of its users.

Share

Executive summary

  • The United States National Institute of Standards and Technology (NIST) has approved certain standard algorithms for post-quantum cryptography (PQC). These standards set the baseline for encryption and authentication in the age of quantum computers.

  • Although NIST has not officially approved any hybrid algorithms, hybrids are widely used in the industry and can be compliant in the context of Federal Information Processing Standard (FIPS) 140 validation.

  • Most countries agree that organizations should aim for full quantum resistance by 2035.

  • While most countries agree on the overall approach for PQC, they disagree on recommended or required algorithms and the use of combination post-quantum/traditional (PQ/T) algorithms.

  • Most governments, including the U.S. and U.K. governments, recommend against using quantum key distribution, and instead favor the use of post-quantum cryptography.

The adoption of post-quantum cryptography (PQC) has become a critical mandate for organizations of all sizes. The United States National Institute of Standards and Technology (NIST) released the first three PQC standards — including the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), the Module-Lattice-Based Digital Signature (ML-DSA), and the Stateless Hash-Based Digital Signature (SLH-DSA). And across the industry, this release has effectively set the baseline and direction of adoption of these new technologies.

The quantum computing revolution and its implied threats to your encrypted data and cybersecurity don’t respect borders. The solutions and defenses that we develop in the larger internet community protect users everywhere.

In this blog post, we'll explore how different governments and standards bodies define PQC compliance to help you understand adoption timelines and considerations for quantum-resistant cryptography.

Other competitions and algorithms

While the NIST Post-Quantum Cryptography Standardization program saw submissions from the international cryptography community and researchers across the globe, it can't escape the impression of being a U.S.-driven initiative, and some nations have launched independent efforts to identify new quantum-resistent encryption algorithms.

Two of these initiatives come from China's Institute of Commercial Cryptography Standards (ICCS) and the Korean Post-Quantum Cryptography (KpqC) research group. Both are independently seeking proposals for public key cryptography algorithms, cryptographic hash algorithms, and block cipher algorithms.

As of September 2025, China has yet to announce any selection of cryptographic algorithms. Korea, on the other hand, has selected HAETAE and AIMer for digital signatures, as well as SMAUG-T and NTRU+ as key encapsulation mechanisms (KEMs).

Korea's algorithms suggest industry consensus regarding module lattice-based key encapsulation and signature algorithms. In case weaknesses are found in the lattice-based ML-KEM, NIST selected an error-correcting code-based algorithm — Hamming Quasi-Cyclic (HQC) — as a backup. This is expected to  be standardized in 2027.

Some submissions that are not accepted by NIST for standardization are accepted or recommended by other government bodies. These include:

  • FrodoKEM, a KEM-based on the learning with errors (LWE) mathematical problem using generic, unstructured lattices

It remains to be seen whether the industry — and especially client software providers — will adopt any of these algorithms in addition to (or — in certain markets — in place of) the NIST-selected standards.

Hybrid algorithms

Much of the industry focus today is on the adoption of hybrid key exchange algorithms, primarily in the context of Transport Layer Security (TLS). It is worth distinguishing this from the pure PQC algorithms, since no hybrid algorithm has seen a formal standardization by NIST (or any other standards body). 

Still, the industry has settled on the use of ML-KEM as the underlying de facto ѕtandard as defined in this draft from the Internet Engineering Task Force (IETF), which describes the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 combinations.

In practice, virtually all implementations focus on X25519MLKEM768 only, as the industry still debates the best methods to efficiently select a preferred hybrid algorithm. There are also ongoing debates on the benefits and drawbacks of adopting hybrid algorithms over pure algorithms, and under what circumstances organizations may (or must) choose one over the other. 

We will provide more insights into these topics in future blog posts.

Finally, it is important to note that NIST explicitly allows the combination post-quantum/traditional (PQ/T) algorithm within the context of FIPS 140 validation and considers an implementation to be compliant so long as either one of the combined algorithms is FIPS approved. In other words: X25519MLKEM768 as used by Akamai for all PQC connections allows for FIPS 140 compliance.

PQC requirements by country

The timelines for the adoption of post-quantum cryptography are broadly agreed upon and organizations should: 

  • Aim for full quantum resistance by 2035 

  • Phase out any systems unable to support PQC by the end of 2030

Outside of the United States, many countries have issued their own requirements and recommendations (Table).

 

Country/Guidance

PQC algorithms approved

Hybrid algorithms

United States / NIST

Key encapsulation

  • ML-KEM

  • HQC-KEM (to be finalized)


Signature algorithms

  • ML-DSA

  • SLH-DSA

  • FN-DSA

  • LMS/HSS

  • XMSS/XMSSMT

Neutral

United States / CNSA 2.0

Key encapsulation

  • ML-KEM-1024*


Signature algorithms

  • ML-DSA-87

  • LMS

  • XMSS

Allowed in some cases, but not recommended

Australia / ACSC

Key encapsulation

  • ML-KEM-768 (until 2030 only)

  • ML-KEM-1024


Signature algorithms

  • ML-DSA-65 (until 2030 only)

  • ML-DSA-87

Not recommended

Canada / CCCS

Key encapsulation

  • ML-KEM


Signature algorithms

  • ML-DSA

  • SLH-DSA

  • LMS/HSS

  • XMSS/XMSSMT

Neutral

Czech Republic / NUKIB

Key encapsulation (pure)

  • ML-KEM-1024


Key encapsulation (hybrid)

  • ML-KEM-768

  • Classic McEliece

  • FrodoKEM-976

  • FrodoKEM-1344


Signature algorithms

  • ML-DSA-87

  • ML-DSA-65 in hybrid only

  • SLH-DSA

  • LMS

  • XMSS

Neutral

Germany / BSI

Key encapsulation

  • ML-KEM-768

  • ML-KEM-1024

  • FrodoKEM-976

  • FrodoKEM-1344

  • mceliece460896

  • mceliece6688128

  • mceliece8192128


Signature algorithms

  • ML-DSA-65

  • ML-DSA-87

  • SLH-DSA

  • LMS/HSS

  • XMSS/XMSSMT

Recommended

The Netherlands / AIVD

Recommended key encapsulation

  • ML-KEM-1024


Accepted key encapsulation

  • ML-KEM-768

  • Classic McEliece

  • FrodoKEM


Recommended signature algorithms

  • ML-DSA-87

  • SLH-DSA-192

  • SLH-DSA-256

  • LMS/HSS

  • XMSS


Accepted signature algorithms

  • ML-DSA-65

  • SLH-DSA-128

  • FN-DSA

Recommended

United Kingdom / NSCS

Key encapsulation

  • ML-KEM-768


Signature algorithms

  • ML-DSA-65

  • SLH-DSA

  • LMS

  • XMSS

Interim only

*In some cases, only specific strengths (e.g., ML-KEM-1024) are allowed. Where no strength is indicated, all are approved, conditional on the required security category. 

†The guidance provided by Germany's Bundesamt für Sicherheit in der Informationstechnik (BSI) largely reflects the most up-to-date guidance for most members of the European Union.

Table: Post-quantum cryptography requirements by country

As you can see, while there is significant alignment on the recommended approach, the subtle differences in the recommended or required algorithms and the use of PQ/T hybrid algorithms reflects the rapidly evolving field.

For example, as noted above, X25519MLKEM768 is the de facto industry standard for PQC key exchange in browsers. The Internet Assigned Numbers Authority (IANA) has assigned code points for certain pure PQC and hybrid key groups using ML-KEM-1024 (i.e., SecP384r1MLKEM1024), but many browsers and TLS libraries have yet to implement those, making compliance with guidelines that mandate their use impossible — at this time, at least.

A note on quantum key distribution

Quantum key distribution (QKD) allows for the use of quantum mechanical properties, such as superpositions and entanglement, to implement cryptographic key exchange mechanisms distinct from classical systems and which may allow for detection of an observer in the middle.

Although this may seem like a natural fit for PQC, QKD requires the existence of an already authenticated channel. Because of this, along with the complexity and cost of QKD, most governments (including the U.S., the U.K., and 18 EU member states) recommend against its use.

Akamai doesn’t have any plans to adopt or implement QKD at this time. Rather, we’ll continue to focus on adopting and improving PQC.

Akamai’s phased approach: A progress update

Akamai’s approach to securing end-to-end delivery transport includes three phases:

  • Phase one: Akamai-to-origin (Akamai-to-website)

  • Phase two: Client-to-Akamai (browser-to-Akamai)

  • Phase three: Akamai-to-Akamai

Phase one: Akamai-to-origin

PQC to origin servers using the X25519MLKEM768 hybrid key share is currently an opt-in limited availability feature. Starting January 31, 2026, it will become a default feature for all customers.

In the meantime, we encourage you to enable PQC to your origins. Keep in mind that the feature is backward compatible, allowing you to enable it even if your current origin infrastructure doesn’t support PQC yet.

Phase two: Client-to-Akamai

On September 1, 2025, we launched PQC support for client browser-to-Akamai connections as a limited availability opt-in feature.

This setting isn’t tied to the enablement of PQC from Akamai-to-origin, so even if your origin doesn’t yet support PQC, you can still enable PQC on the client-to-Akamai connection.

This feature will become the default in Q1 2026 (February), but since most client browsers today already support PQC, we encourage you to enable PQC for all clients as soon as possible.

Phase three: Akamai-to-Akamai

We’re on track to complete the PQC update for mid-tier connections across all of Akamai’s networks in Q1 2026 (March). With this change, all Akamai-to-Akamai connections will be quantum safe. Customers who have enabled client-to-Akamai and Akamai-to-origin PQC will enjoy full end-to-end quantum-resistant traffic protection against the active “harvest now, decrypt later” (HNDL) threat.

The future of post-quantum cryptography

There are many moving parts in the world of post-quantum cryptography. As information technology continues to evolve, so will cryptographic systems and encryption methods — introducing the need for new algorithms and more sophisticated network security. 

If your organization doesn’t yet have a roadmap for ensuring crypto security, you may want to consider taking that step. In future posts, we’ll explore the challenges of efficiently supporting multiple PQC key groups and whether to migrate to pure PQC instead of PQ/T hybrid algorithms.

In the meantime, we hope to see more customers opt in to our PQC offerings, and we invite you to reach out with any questions. We're looking forward to helping you and your clients on your post-quantum journey.

Jan Schaumann

Oct 08, 2025

Jan Schaumann

Jan Schaumann

Written by

Jan Schaumann

Jan Schaumann, Chief Information Security Architect at Akamai, has more than 20 years of experience building and securing high-availability services at internet scale. At Akamai, he launched our bug bounty program, works with the Architecture Group on a range of company-wide initiatives, represents InfoSec in the Open Source Working Group, and leads the internal Cryptography Group, among other initiatives. His research interests cover the overall health of the internet, as well as the safety and privacy of its users.

Tags

Share

Related Blog Posts

Security
Akamai Named a Gartner Peer Insights Customers’ Choice for WAAP Six Years in a Row
October 08, 2025
Akamai was recognized as a Gartner Peer Insights Customers’ Choice for WAAP for the sixth time. Discover why.
Security
Akamai Is the 2025 Customers' Choice in Online Fraud Detection
September 22, 2025
Learn why Akamai was recognized as the only 2025 Gartner Peer Insights™ Customers' Choice for Online Fraud Detection.
Security
The 8 Most Common Causes of Data Breaches
April 19, 2024
Discover the primary causes of data breaches — and how to protect your organization from these pervasive threats.