Post-Quantum Cryptography Beyond TLS: Remain Quantum Safe

Mar 02, 2026

Written by

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.

Throughout our series of blog posts on post-quantum cryptography (PQC), we have focused almost exclusively on the Transport Layer Security (TLS) ecosystem in an HTTP context. Addressing the “harvest now, decrypt later” threat in the CDN context was an obvious high priority for Akamai, and we are pleased to have delivered PQC in our TLS 1.3 handshakes for both client-to-Akamai and Akamai-to-origin connections.

Over the coming weeks, these features are being rolled out everywhere as on-by-default for all Enhanced TLS customers.

Although this is in line with the rest of the industry's prioritizations, the quantum threat affects all areas of cryptography, not just TLS. In this blog post, we'll explore some of the other protocols and services that will warrant our attention when it comes to making them quantum safe.

Algorithms that are subject to quantum threats

Practically speaking, we are concerned about any software that uses the algorithms known to be subject to quantum threats; that is, any use of asymmetric key cryptography (e.g., cryptography that uses RSA or Diffie–Hellman key exchanges), as well as digital signatures (e.g., Elliptic Curve Digital Signature Algorithm [ECDSA] are of primary concern).

It's worth noting that although TLS covers the biggest surface area within the HTTP ecosystem, it is also used by many other applications, including:

The Simple Mail Transfer Protocol (SMTP) with STARTTLS or via implicit TLS submission on port 465 per RFC8314
The Internet Message Access Protocol (IMAP) or Post Office Protocol (POP) over TLS
The Lightweight Directory Access Protocol (LDAP) over TLS
TLS-based virtual private networks (VPN)
Modern network segmentation services like Akamai's Zero Trust Network Access (ZTNA)
The Extensible Messaging and Presence Protocol (XMPP) used for some instant messaging services

Since all of these services are using TLS for traffic encryption and endpoint authentication, upgrading these services to use the Post-Quantum/Traditional (PQ/T) hybrid key exchange algorithm we discussed at length in previous blog posts (i.e., X25519MLKEM768) will likewise help protect them against the quantum threat.

However, other applications and services use different protocols and will need to likewise implement PQ/T hybrid key exchange algorithms and begin to use post-quantum signature algorithms.

Secure Shell (SSH)

A primary example here is the ubiquitous SSH protocol. As you know, SSH also uses public-key cryptography to perform authentication, and as such needs to be configured to use the right key exchange algorithms to provide quantum safety.

The most widely used implementation of SSH, OpenSSH, has had support for the Streamlined NTRU Prime (SNTRUP) algorithm in a PQ/T hybrid configuration since 2021. In 2024, FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) combined with X25519 ECDH (as defined by the Internet Engineering Task Force [IETF]) was added, which became the default key exchange algorithm starting with version 9.9 — meaning that a simple upgrade across your operating systems will protect you today.

To verify whether your version of OpenSSH supports PQC, run this command:

$ ssh -Q kex | egrep "(mlkem|sntrup)"
sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com
mlkem768x25519-sha256
$

Additionally, you will notice that the latest version of the OpenSSH client (version 10.1 and above) actively warns you if you are connecting to a server that does not use post-quantum key agreement:

$ ssh -V
OpenSSH_10.2p1, LibreSSL 3.3.6
$ ssh unsafe.example.com
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
[...]

This behavior is backwards compatible, meaning that clients without support for PQC will simply use classical key exchange algorithms, so updating your SSH deployments here should be reasonably painless.

Virtual private networks (VPNs)

VPNs may use TLS to create their encrypted tunnels, and as such are able to take advantage of the common X25519MLKEM768 hybrid key exchange to make these tunnels quantum safe.

However, not all VPNs necessarily use TLS; instead, many implementations are based on Internet Protocol Security (IPsec), which uses the Internet Key Exchange (IKE). IKE is often based on a Diffie–Hellman key agreement and includes, for example, x509 client certificates for authentication. These mechanisms remain vulnerable to the quantum threat and thus require similar updates as are necessary for TLS.

RFC9370 defines the means for IKEv2 to permit multiple key exchanges (and thus create composite keys). A separate draft specifies how to use ML-KEM as such an additional key exchange. This allows for the combination of a classic key with a post-quantum key, analogous to the hybrid PQ/T key exchange we are familiar with from TLS.

Different network equipment providers support PQC in IPSec VPNs to different degrees. Check with your vendor about their current post-quantum readiness in these products.

Messages

Higher up on the application layer, one of the most widely used services — especially on mobile devices — includes text messages. This space is dominated by WhatsApp, Apple Messages, Signal, and any application or service using the Rich Communication Services (RCS) protocol, such as Google Messages.

Signal and WhatsApp both use the Signal Protocol, which introduced the Sparse Post-Quantum Ratchet (SPQR) in 2025. Cryptography experts broadly recognized it as a well-designed engineering solution.

Likewise, Apple announced their post-quantum roadmap for Apple Messages as far back as February 2024, introducing their "PQ3" post-quantum cryptographic protocol. This protocol only protects iMessages, however; messages sent using SMS or RCS (displayed on Apple devices in green, rather than blue, text bubbles) still rely on classic cryptography.

Google Messages offered (classic) end-to-end encryption as far back as 2020, but this was not standardized until the definition of the Messaging Layer Security (MLS) protocol in RFC9420. Unsurprisingly, there are now efforts under way to include ML-KEM and other post-quantum algorithms, which are included in the official specification. We expect adoption of these to slowly pick up with the coming updates.

OpenPGP

OpenPGP, defined in RFC9580, provides symmetric and asymmetric encryption and authentication via digital signatures. Despite many years of concerns and frustrations around the format itself and the usability of some of the most widely used implementations, PGP remains frequently used especially by open source projects and other software vendors to provide integrity and authenticity assurances of their software releases or security advisories.

Many organizations also use OpenPGP for encrypted communications over email. For example, Akamai allows security researchers to communicate with our security team using our public PGP key published on our Akamai Vulnerability Reporting page.

As such, the OpenPGP standard is necessarily subject to the quantum threat and in need of updates to allow for the use of PQC algorithms. Within the IETF’s OpenPGP Working Group, a new draft is being developed, which "defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme.”

This draft has already seen some adoption, but as with many of the other cryptographic tools and libraries, you will need to closely track the official releases of the software you use to enable you to adopt and integrate new versions when they are published. It will likely still be a little while before we see widespread adoption of PQC in use for, say, software package signatures.

DNSSEC

Finally, we'll need to talk about the elephant in the room. Yes, it's DNS. (It's always DNS, isn't it?) Or, to be more specific, DNSSEC.

The Domain Name System Security Extensions (DNSSEC) provide cryptographic signatures on DNS resource records (RRs), primarily using (again) RSA and ECDSA as the signature algorithms. This, of course, means that these signatures are subject to the quantum threat, and any systems that rely on DNSSEC for integrity and authenticity assurance will need to adopt post-quantum cryptographic algorithms.

However, as we discussed previously, there is a significant increase in the signing and verification performance, as well as in signature size, when moving from classic to PQC algorithms. The fact that DNS is primarily used over UDP exacerbates this problem compared with the HTTPS use case, as the larger signatures will no longer fit into a single UDP response packet.

This could lead to TCP fallback, packet fragmentation, slowed response times, and many other possible complications — not to mention the long, complex process of algorithm rollover that will have to be coordinated starting with the root zone's Key Signing Key (KSK) and the possible need for multiple signatures across all signed zones during the transition period.

While the industry has not yet fully agreed on the right approach forward, a few proposals and strategic drafts that are gaining traction involve the use of FN-DSA (i.e., what will become FIPS 206) or, alternatively, FIPS 205 Stateless Hash-Based DSA (SLH-DSA) signatures in Merkle tree ladder (MTL) mode.

This approach would reduce the cost of signatures by avoiding the need to sign and verify each individual record in favor of signed Merkle “tree ladders," a concept similar to Merkle tree certificates that are intended to help address the analogous concerns around multiple signatures in the TLS ecosystem.

Within the context of DNSSEC, the urgency of adopting PQC algorithms may not seem as immediate as in the case of protecting HTTPS traffic against the "harvest now, decrypt later" threat because the authenticity and integrity assurance of DNS traffic are not subject to a post-facto attack. However, the complexity of performing a root KSK algorithm rollover means that we need to plan for a prolonged timeline before all the DNS have been switched over.

Combined with the fact that, as noted above, we have not even agreed on what the final solution will look like, even a time horizon of a cryptographically relevant quantum computer and within the expected compliance requirements from different jurisdictions means that we can't afford to delay that work.

Conclusion

Although Akamai is at the forefront of PQC adoption within the HTTPS ecosystem, having enabled PQ/T hybrid key exchange for TLS 1.3, there is still a lot of work left to make all other systems and services quantum safe. The migration will be easier for some of the services we discussed above (e.g., SSH) but significantly more complicated for others (e.g., DNSSEC).

Systems that build on top of or use TLS make a migration easier, as most libraries and toolkits support PQ/T algorithms by now, and vendors have begun to offer these protections. However, the costs of keeping your cryptographic inventory up to date, identifying which components are ready for an update, and tracking the latest software releases remains significant.

For the other protocols, we recommend that you closely track the latest developments in the industry and to participate in the IETF and other standards discussions. As we continue to bring PQC to more of our own services, we will likewise continue to keep you updated in this blog series.