Post-Quantum Cryptography: What’s Next for Edge Security

• While ML-DSA remains the primary general-purpose standard, newer post-quantum signatures like FN-DSA (Falcon) offer smaller footprints but introduce complex floating-point implementation challenges.

• Major industry players are accelerating transition timelines to 2029, a shift Akamai is matching by preparing to offer post-quantum cryptography (PQC) certificates by that same year.

• Prominent cryptographers agree that symmetric encryption remains highly secure, meaning quantum computers do not threaten AES-128 or require a transition to 256-bit keys.

• The newly chartered PLANTS working group at the Internet Engineering Task Force (IETF) is solving the PQC scale problem by developing Merkle Tree Certificates to minimize the packet size overhead in TLS handshakes.

This blog post wraps up our series on post-quantum cryptography (PQC) with an overview of some newer algorithms and other work going on in the field.

In a previous post, we talked about the ML-DSA post-quantum signature algorithm, which is the most general-purpose signature algorithm and seems to be the first choice for use on the web. But there are many other options to consider, and we’ll look at a few of them here.

A composite signature is a single signature made up of two parts: a traditional algorithm and a post-quantum algorithm. Unlike hybrid key exchange, however, in a composite signature the two keys are treated as a single “composite” key, and the signature is a single set of bytes. This makes it easier for application code to accommodate, as they simply recognize the identifier and call the cryptography library. 

This naturally leads to a combinatorial increase in identifiers: 18 for messages and 15 proposed for TLS. This could lead to interoperability concerns, as it requires both sides to support the same mechanisms. For hybrid key exchange, the de facto standard is X25519MLKEM768. 

While key exchange protects against a “harvest now, decrypt later” (HNDL) threat, the concern about a quantum computer being able to break authentication is not as universal; many people in the IETF are not convinced it’s needed. Furthermore, those who maintain several prominent implementations have stated that they have no interest in it.

A forthcoming National Institute of Standards and Technology (NIST) standard, FN-DSA, is based on the “Falcon” algorithm. Its keys and signatures are much smaller than the standards that use ML-DSA, but NIST warns that it is difficult to implement. For one thing, it uses floating-point arithmetic, which may limit its deployment. Timing issues with floating-point math are also a concern, as such libraries have historically focused on correctness rather than on performing operations in constant time.

Noted cryptographer Sophie Schmieg starts her advice with “the best approach to using FN-DSA is to not,” but then goes on to give a number of useful implementation tips anyway. For security architects, this illustrates the broader deployment challenge of PQC: How you manage implementation can be just as important as which algorithms you select.

NIST has also published a draft on additional parameter sets for the hash-based signature algorithm SLH-DSA. As NIST says, "[T]hese variants are specifically tailored for use cases that require fast verification and reduced signature sizes, such as the signing of software, firmware, and digital certificates." 

Two recent papers suggest that a cryptographically relevant quantum computer (CRQC) could appear sooner than expected.

The first, a cryptocurrency paper from Google, explained that it may take fewer qubits than predicted to break web use. This claim was presented in the form of a zero-knowledge proof (ZKP), a cryptographic method that allows one party to prove the truth of a specific statement without disclosing any sensitive information.

Prompted by this, respected cryptographer Bas Westerbaan posted on LinkedIn that we may be reaching the end of open, public sharing of PQ advances.

However, someone replicated Google’s results and the author posted that while he “enjoyed publishing some cheeky ZKPs,” he acknowledged that “The benefits are negligible, and the costs are many. We should just publish openly.”

The second paper significantly lowered the number of atomic qubits needed to implement Shor’s algorithm. This algorithm was one of the first to show that a quantum computer could do integer factorization and discrete logarithms — fundamental to current cryptographic algorithms — much more efficiently than a conventional computer. The paper claims that instead of millions of qubits, Shor’s algorithm could be implemented in closer to 10,000.

In response to these accelerating threats, Google has advanced its quantum-safe timetable from 2035 to 2029. At Akamai, we are evaluating our global roadmap to match this reality, including offering PQC certificates by 2029.

While the impact of a CRQC on traditional algorithms like RSA and elliptic curve cryptography is clear, there is still some misunderstanding regarding its impact on symmetric encryption algorithms like AES or digests like SHA-256.

Filippo Valsorda, a respected cryptography engineer who maintains the Go programming cryptographic library, argued that there is no need to move from AES-128 to AES-256. His position can be summed up in the title of his blog post Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys. After showing some math, he points to NIST and other standards as proof points.

ML-DSA signatures are big. The IETF just started a new working group to work on PKI, Logs, And Tree Signatures, abbreviated to the acronym PLANTS. The goal is to reduce the total size and number of signatures when using a certificate in TLS.

A typical example includes the website’s certificate, the signing certificate authority (CA), and at least two signatures from certificate transparency (CT) logs, which increases the size of an initial server TLS message by anywhere from 20 KB to 40 KB. That causes particular problems for UDP-based protocols such as DNS and HTTP version 3 (which uses QUIC).

The key technology behind the PLANTS group is the Merkle Tree: a cryptographic data structure that summarizes large datasets into a single root hash. Each time a new piece of data is added, it alters the hash, or digital fingerprint, of that section.

By pairing and recalculating hashes all the way to the top, you create a new digital fingerprint, or root value. You can then apply a cryptographic signature to the new root value. If you include the certificate, CAs, and CT logs in the tree, you only need to send one signature.

The user can then make “inclusion proofs” to easily ensure that all necessary pieces are included in the tree. To distinguish these from standard ML-DSA certificates, we call them Merkle Tree Certificates (MTC).

As you can see, there’s a lot of math and proofs involved. To lighten things up, there are several  plant-related puns in the mailing list archives, such as talk of “sprouting new text” and people greeting each other as “buds.” Many in the industry have committed to support the PLANTS specification, even though it’s still early days (the group has only had three meetings by the publication date of this post).

We’re involved and eagerly participating in the development of this new technology. PLANTS is an example of the ecosystem adapting to make PQC operationally viable at internet scale.

We actively participate in and are at the front edge of many of these standards development groups. At the same time, we also listen closely to our customers’ needs to help you prepare for the next phase of PQC.

We are working on the timeline but still need to work out many details; we anticipate that we will be supporting pure ML-DSA certificates in certain contexts, while aiming for goals such as MTC for the web PKI.

If you missed any of the previous posts in this series, you can check them out now.

• Post-Quantum Cryptography Beyond TLS: Remain Quantum Safe (published March 2, 2026)

• Digital Signatures: Traditional Vs. Post-Quantum Cryptographic Mechanisms (December 3, 2025)

• A Guide to International Post-Quantum Cryptography Standards (October 8, 2025)

• Akamai Enables Post-Quantum Cryptography on the Edge (September 3, 2025)

• Post-Quantum Cryptography Implementation Considerations in TLS (August 6, 2025)

• Building a Quantum-Safe Internet: the IETF’s Plan for TLS (June 18, 2025)

• Taking Steps to Prepare for Quantum Advantage (August 12, 2024)

• Akamai and the Adoption of Post-Quantum Cryptography (April 27, 2023)