cyber.hendryadrian.com
Security Report · wiz.io

Wiz Finds Post-Quantum Cryptography Adoption Still Lagging Across Cloud and Company Systems

· Original article ↗

Summary

Wiz’s analysis finds limited post-quantum cryptography adoption across cloud services and company systems, with key exchange support more advanced than digital-signature migration.

Key points

  • Google’s announced 2029 PQC migration timeline reflects a shift toward authentication and digital signatures, in addition to key exchange protections against harvest-now-decrypt-later attacks.
  • Wiz found that 81% of 42 assessed cloud services with cryptographic configurations lack a PQC-compliant option; it found no Azure API servers and only 13% of AWS API servers supporting PQC key exchange.
  • Although 84% of observed AWS API requests used TLS 1.3, only 10% of requests to Secrets Manager and KMS used PQC key exchanges.
  • Only 4.4% of observed OpenSSH instances ran version 10.0 or later, and fewer than 15% of observed OpenSSL instances used a version supporting PQC.
  • Among inbound TLS 1.3 connections to monitored hosts, 15% used PQC-compliant key exchange; Wiz also observed some TLS 1.0 and 1.1 traffic.
  • PQC digital-signature support remains limited: OpenSSH lacks PQC authentication support, and fewer than 1% of companies used AWS KMS keys for ML-DSA signing.

Article Details

Publisher
Wiz IO
Scope
PQC readiness and implementation across cloud providers and company environments, including cloud services, API traffic, server software, and incoming TLS connections.
Sample Size
42 cloud services across cloud providers; other analyzed populations are not quantified in the article.
Key Statistics
  • AWS API servers support PQC key exchange on 13% of servers; the article reports that all GCP API servers support it and that no Azure API servers were found to support it.
  • 84% of observed AWS API requests use TLS 1.3; KMS and ACM requests use TLS 1.3 at 97%.
  • Clients use PQC key exchanges in 10% of requests to Secrets Manager and KMS, based on the authors' visibility into CloudTrail data.
  • 81% of 42 assessed cloud services with cryptographic configurations do not offer a PQC-compliant configuration option.
  • Among inbound TLS 1.3 connections observed by Wiz's runtime sensor, 15% use PQC-compliant key exchange.
Recommendations
  • Prioritize ML-DSA as the digital-signature migration target, consistent with the article's account of NIST's recommendation.
  • Update software and configurations that prevent use of PQC key exchange, including OpenSSL and underlying SDK or TLS libraries.
  • Inventory and prioritize where PQC improvements and migrations are needed.

Vendors

Amazon Web ServicesOpenSSL 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 andAzureHTTPS, 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 APIGCPversion 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.   GoogleIn 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 onNISTNIST 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.Wizkey (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

Products

ACMpercentage 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. AWS SDK for Golanglibrary 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 forAWS SDK for Pythonwhen 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 librarybotocoreAWS 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 andCloud KMS3.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.   CloudHSMsince 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.   CloudTrail 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 Azurecrypto/tlsfor 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 toGoapplication.  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.IAMAs 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 serviceKMSML-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.   Merkle Tree CertificatesX.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 beOpenSSHAdditional 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 browserOpenSSLOpenSSL 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 andSecrets ManagerAlthough 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 cryptographySSMfor 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. X.509for 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

Tools

Wiz PQC tester

Related Articles