In late March of 2026, Google announced a 2029 timeline for their post-quantum cryptography (PQC) migration.  That announcement also mentions a change in priorities.  PQC implementation work has largely been focused on key exchanges, which mitigates Harvest-Now-Decrypt-Later (HNDL) attacks.  The goal has been to get ML-KEM used during session negotiations (ex. get TLS to use X25519MLKEM768). Google is now prioritizing PQC in authentication services, which means getting one of the PQC Digital Signature Algorithms used (ex. ML-DSA or SLH-DSA).  Both key exchange and digital signature algorithm migrations need to happen for a full PQC migration. 

This timeline and change in priorities was driven in part by advances in quantum computers and a reduction in estimates of the resources needed by quantum computers to break asymmetric cryptography.  For a number of years, the capability gap to Q-Day has been squeezed from both sides. Q-Day is the day when a quantum computer becomes powerful enough to break the standard encryption used to secure most of today’s digital communication.

This article will discuss the timeline of PQC relevant events, and provide a number of PQC relevant statistics that we see across our customers.  This builds on our previous post Preparing for Post-Quantum Cryptography.

Timeline

The following are some highlights of PQC relevant events:

As you can see from that timeline, during the past 50-year history of the asymmetric encryption we use today, the development of quantum computers and post-quantum cryptography has been progressing in parallel, but without as much attention from the broader world.  A tipping point is now being reached, where the risks of quantum computers feel too close for comfort, but luckily the standards and implementation of post-quantum cryptography have recently become available.

State of the PQC Implementations

Key Exchange

The original focus for PQC efforts was on key exchange to use ML-KEM in order to mitigate the Harvest-Now-Decrypt-Later (HNDL) threat.  Session negotiation key exchange for both TLS and SSH is a "solved problem" in that it has been implemented broadly now and just needs software to be updated, or, in a few remaining cases, implementation of well-tested standards.  Current browsers, and many TLS termination servers, support TLSv1.3 with X25519MLKEM768.  Similarly many SSH servers and clients support mlkem768x25519-sha256.  

Although the ecosystem of software broadly supports PQC key-exchange when using the latest versions, there is action that needs to be performed for it to be used.  This generally means finding and updating the things that are still using slightly out-of-date software and configurations.  For example, TLS 1.3, which was released in 2018 and is a prerequisite for PQC, is still not as broadly adopted as you would hope, as this report will show later.  

Digital Signing

NIST has approved 2 of 3 planned Digital Signing Algorithms (DSAs).  ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) have been approved since late 2024. As of May 2026, we are still waiting on FN-DSA (FIPS 206) to be approved.  All of these have the same purpose, but different trade-offs.  NIST has consistently recommended ML-DSA as the "primary algorithm", meaning it should be the most commonly used option and the others will only be used in special situations, so don't wait on FN-DSA to be approved. 

The following table shows the trade-offs of some of the options.  This is not an exhaustive table of the key size options, and speed of the operations can vary depending on hardware, but this is meant to show the relative differences between the options.  The performance data comes from Commey et al.’s 2025 study on Post-Quantum Cryptography performance. Smaller numbers are better for all columns.  Sizes are in bytes and the sign and verify operations are the milliseconds to operate on a 1 kilobyte message as measured in that paper.

Even though FN-DSA looks attractive from the data in that table, I want to reiterate that ML-DSA is the preferred migration target.  

OpenSSL has had support for ML-DSA and SLH-DSA since version 3.5.0, released in April 2025.  AWS supports ML-DSA keys and signing via KMS, but not CloudHSM. GCP Cloud KMS offers support for both ML-DSA-65 and SLH-DSA-SHA2-128S.   

Additional upstream support is still needed for these though.  For example, OpenSSH does not currently support PQC for authentication. VPN support for PQC DSA is not common, and there is almost no support in the browser ecosystem (browsers, TLS termination solutions, and Certificate Authorities).  The core issue for the browser ecosystem is that the chain of trust from a Certificate Authority down to the certificate of an individual server would end up being very large in a quantum-resistant model. You can see from the table the large size differences for signatures for ML-DSA-44 vs the non-PQC algorithms.  To mitigate this, browsers will be migrating from the classic X.509 certificate chains (where every public key and signature in the chain is included) to Merkle Tree Certificates (MTCs).  MTCs allow for a compact proof of inclusion, instead of requiring the full chain to be downloaded.

State of PQC on the Cloud Service Providers

Support for PQC key exchanges is very different across the cloud providers.  The API servers of the different cloud providers use HTTPS, and ideally should all support ML-KEM hybrid key exchange.  However, we were not able to find any Azure API servers that support this, while all GCP API servers do.  AWS supports it on only 13% of their API servers, based on specific services such as KMS which does support it.

As an example, an AWS request to create an IAM user access key (which is not recommended) goes to https://iam.amazonaws.com. You can see in our tool https://www.wiz.io/pqc-tester that the API server for that service does not support PQC key exchanges, which means that under the assumed HNDL threat, that access key could potentially be at risk one day.  Similarly on Azure, the API server management.azure.com is commonly used and does not support PQC key exchanges.

 But just because PQC key exchange is supported, is it actually used by the users?  On AWS, CloudTrail logs provide some information about the TLS connection requests made to AWS APIs in an environment.  GCP and Azure do not log this.  We see 84% of all API requests to AWS use TLS 1.3, which is a prerequisite for PQC key exchanges. AWS only supports TLS 1.2 or 1.3 for their APIs.

Some services have higher percentage usage of TLS 1.3.  For example, we see 97% of the requests for the encryption services KMS and ACM use TLS 1.3.  However, log events for some services (such as SSM) have very little TLS 1.3 usage. 

Although Secrets Manager and KMS support PQC key exchanges, our visibility into CloudTrail data shows that clients are making requests with PQC key exchanges for these services in only 10% of requests.  The cryptography used by an application when accessing AWS is based on the default cryptography library of the application.  The AWS SDK for Python, known as botocore, uses OpenSSL, and the AWS SDK for Golang uses the Go standard library crypto/tls. OpenSSL and crypto/tls each obtained support for X25519MLKEM768 by mid 2025.  Getting applications to use this modern key exchange should simply be a matter of updating the underlying SDK and TLS libraries.

When it comes to the services offered by the cloud providers, we analyzed 42 cloud services across the cloud providers that are relevant to PQC assessments. This includes encryption keys, certificates, and networking services (load balancers, CDNs, API gateways). We found 81% of these cloud services with cryptographic configurations do not currently offer a PQC-compliant configuration option.

State of PQC on company servers

OpenSSH version 10.0, which was released in April 2025, is the first version of OpenSSH to default to the PQC key exchange mlkem768x25519-sha256.  OpenSSH 9.0 (released in April 2022), used a PQC key exchange called sntrup761x25519-sha512, but that was not leveraging the NIST standards. 4.4% of OpenSSH instances are using a version greater than or equal to 10.0.

Less than 15% of instances of OpenSSL that we see throughout all company environments are using OpenSSL that supports PQC.  You must use OpenSSL version 3.5.0 or greater, which was released in April of 2025, in order to use PQC with it.  This helps explain the previous CloudTrail data about why connections to Secrets Manager and KMS still have low usage of PQC key exchange. 

Even if all OpenSSL versions were upgraded, some are configured in such a way that they will not use PQC.  Approximately 4% of companies have at least one instance of OpenSSL configured in a way that does not allow for PQC key exchange.  One way this can be misconfigured is if they have selected specific key exchange groups to be used and did not include the key exchanges that use ML-KEM.  

The Go language has supported X25519MLKEM768 by default in crypto/tls since 1.24, and we see 60% of Go installs use at least that version.

We see less than 1% of companies are using AWS KMS keys for ML-DSA signing.  

From our runtime sensor we have visibility into incoming TLS connections to hosts that are doing their own TLS termination such as on EC2 instances or kubernetes nodes running nginx.   From this we can see that while 78% of inbound TLS to them uses TLS 1.3, 22% uses TLS 1.2, and a small but non-zero amount of TLS 1.1 and 1.0 is observed.  Among the TLS 1.3, only 15% of connections are using PQC compliant key exchange.

Conclusion

Everywhere we look there is still a lot of work to be done for post-quantum cryptography migrations. The implementations and deployments of PQC Digital Signature Algorithms, where focus has recently shifted, need the most improvement.  Wiz can help identify, inventory, and prioritize where these improvements and migrations need to be made.  For more information about our product capabilities see our recent post From Cryptographic Blind Spots to Post-Quantum Agility: Introducing Wiz for PQC Readiness.