AWS Post-Quantum Support 2026: What Actually Works Today

AWS has been quietly shipping post-quantum TLS support across its services since 2022. As of 2026, multiple services support hybrid post-quantum key exchange (ML-KEM combined with ECDH) for API connections. This is not a preview or beta, it is production-available and opt-in via SDK configuration.

This guide covers which services support PQ TLS today, how to enable it, and what the performance impact is.

Services with PQ TLS support (confirmed, production)

Service	PQ TLS Support	Algorithm	How to enable
AWS KMS	✅ GA	ECDH + ML-KEM (hybrid)	SDK parameter
AWS ACM	✅ GA	ECDH + ML-KEM (hybrid)	SDK parameter
AWS Secrets Manager	✅ GA	ECDH + ML-KEM (hybrid)	SDK parameter
Amazon S3	✅ GA	ECDH + ML-KEM (hybrid)	Client configuration
AWS Payment Cryptography	✅ GA	ECDH + ML-KEM (hybrid)	SDK parameter

Note: PQ TLS is opt-in. If you do not explicitly enable it, your AWS API calls use classical TLS (which is still secure against today’s computers but vulnerable to future quantum decryption of stored traffic).

How to enable PQ TLS

The mechanism is the same across services: configure the AWS SDK HTTP client to prefer the hybrid post-quantum cipher suite.

Java SDK (AWS SDK for Java 2.x)

import software.amazon.awssdk.http.crt.AwsCrtAsyncHttpClient;
import software.amazon.awssdk.services.kms.KmsAsyncClient;

KmsAsyncClient kmsClient = KmsAsyncClient.builder()
    .httpClientBuilder(AwsCrtAsyncHttpClient.builder()
        .postQuantumTlsEnabled(true))
    .build();

The postQuantumTlsEnabled(true) method tells the AWS Common Runtime (CRT) HTTP client to prefer the hybrid post-quantum cipher suite (ECDH with ML-KEM) during TLS negotiation.

Python SDK (boto3)

For Python, the AWS CRT-based HTTP client must be used instead of the default urllib3 client:

import boto3
from botocore.config import Config

# Use the CRT transfer acceleration client with PQ TLS
session = boto3.Session()
client = session.client(
    'kms',
    config=Config(
        request_min_compression_size_bytes=10240
    )
)
# PQ TLS is enabled automatically when using the CRT client in newer SDK versions

Note: The exact Python SDK configuration for PQ TLS has evolved across boto3 versions. Check the AWS KMS PQ TLS documentation for the current recommended approach.

For S3 specifically

# S3 requires configuring the transfer client for PQ TLS
# See: docs.aws.amazon.com/AmazonS3/latest/userguide/pqtls-how-to.html

S3’s PQ TLS configuration is slightly different because S3 uses its own transfer acceleration path. The documentation provides language-specific examples.

What PQ TLS protects on AWS

When you enable PQ TLS for an AWS API call, the key exchange between your application and the AWS service endpoint uses hybrid ECDH + ML-KEM. This means:

Protected: The TLS session key is established using both classical (ECDH) and post-quantum (ML-KEM) algorithms. An adversary would need to break both to decrypt recorded traffic later.

Not protected: Data at rest in AWS (encrypted with AES-256, which is already quantum-safe for symmetric encryption). PQ TLS protects data in transit to and from AWS services, not stored data.

Performance impact

AWS states that hybrid PQ TLS has a performance impact on latency and throughput compared to classical TLS. In practice:

Latency: Expect a small increase (low single-digit milliseconds) per TLS handshake due to the larger ML-KEM key exchange
Throughput: Minimal impact on sustained data transfer (the TLS handshake is a one-time cost per connection, data transfer uses symmetric AES which is unchanged)
Bandwidth: The initial TLS handshake is roughly 1-2 KB larger

For most API-based workloads (KMS encrypt/decrypt, Secrets Manager retrieval, S3 operations), the impact is negligible. For extremely latency-sensitive applications doing thousands of short-lived TLS connections per second, benchmark before production deployment.

AWS’s broader PQ strategy

AWS published a PQ migration plan (December 2024) stating:

They are migrating their own internal infrastructure to PQ
They provide PQ TLS as an option for customer API connections
s2n-tls (AWS’s TLS implementation) includes ML-KEM support
The approach is hybrid-first (classical + PQ together, never PQ-only at this stage)

AWS has not published specific deadlines for when PQ TLS will become the default (non-opt-in) for all services. The current posture is: available for customers who want it, optional for those who do not yet need it.

Services without PQ TLS (as of mid-2026)

The following AWS services do not currently document PQ TLS support:

CloudFront (CDN, handles TLS for web traffic, not yet PQ-enabled for customer traffic)
ALB/NLB (load balancers, use AWS-managed TLS policies that do not yet include PQ cipher suites)
API Gateway (uses its own TLS termination, no documented PQ option)
RDS/Aurora (database connections, no documented PQ TLS option for client connections)

For these services, your traffic to/from AWS uses classical TLS. If harvest-now-decrypt-later is a concern for this traffic, consider:

Using a VPN with PQ support (Cloudflare WARP, Mullvad) between your infrastructure and AWS endpoints
Encrypting sensitive data at the application layer before sending it over classical TLS
Monitoring AWS announcements for PQ support additions

How to verify PQ TLS is working

After enabling PQ TLS in your SDK configuration, verify the handshake:

# Capture the TLS handshake to an AWS endpoint
openssl s_client -connect kms.us-east-1.amazonaws.com:443 -groups X25519MLKEM768

# If the connection succeeds with X25519MLKEM768, the endpoint supports PQ
# If it falls back to X25519 or P-256, PQ is not available for that endpoint

You can also enable TLS debug logging in the AWS SDK to see the negotiated cipher suite in your application logs.

FAQ

Is AWS KMS data already quantum-safe?

KMS uses AES-256 for data encryption (which is quantum-safe). PQ TLS protects the API connection to KMS (the key material in transit). Both together provide full quantum safety: the key material is protected in transit (PQ TLS) and the encrypted data is protected at rest (AES-256).

Do I need to change my encryption keys?

No. Your KMS keys (AES-256, HMAC) are symmetric and already quantum-safe. What PQ TLS protects is the TLS connection used to send/receive those keys and the plaintext data you encrypt/decrypt through KMS.

Is there an extra cost for PQ TLS on AWS?

No. PQ TLS is included in standard AWS service pricing. There is no additional charge for opting into hybrid post-quantum key exchange.

Should I enable PQ TLS for all my AWS API calls?

If your application handles data that will remain sensitive for 10+ years, yes. The performance impact is minimal and the protection against harvest attacks is immediate. For ephemeral data (session tokens, temporary credentials), the urgency is lower.

When will AWS make PQ TLS the default?

Not announced. AWS’s current stance is opt-in. Given that Google has set a 2029 internal deadline and NSA CNSA 2.0 requires PQ by 2030 for national security systems, expect AWS to move toward default-on within 2-3 years.