AWS Post-Quantum Support 2026: What Actually Works Today

AWS supports several distinct post-quantum workflows: hybrid ML-KEM TLS on documented service endpoints, GA ML-DSA signing in AWS KMS, GA ML-DSA private PKI in AWS Private CA, and Preview ML-DSA operations in AWS CloudHSM. These capabilities have different activation models and service statuses.

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
Amazon CloudFront	✅ GA	Hybrid ML-KEM	Enabled across existing TLS policies
Application Load Balancer	✅ GA	Hybrid ML-KEM	Opt-in PQ-TLS listener policy
Network Load Balancer	✅ GA	Hybrid ML-KEM	Opt-in PQ-TLS listener policy

Note: Activation depends on the endpoint and client. CloudFront enables PQ key establishment across its existing security policies. ALB and NLB require a PQ-TLS listener policy. Public service endpoints also require a compatible client runtime or SDK; several current SDKs prefer PQ TLS by default.

Managed signatures, HSMs, and private PKI

AWS KMS supports GA ML-DSA signing with ML_DSA_44, ML_DSA_65, and ML_DSA_87. AWS states that the keys and signing operations are protected by FIPS 140-3 Security Level 3 validated HSMs. This is a digital-signature capability, not an ML-KEM KEM-key workflow.

AWS Private CA supports ML-DSA CA keys and certificate signatures for private PKI. IAM Roles Anywhere can use ML-DSA certificate authorities as trust anchors. AWS CloudHSM separately offers ML-DSA key generation and signing in Preview. Do not collapse KMS GA and CloudHSM Preview into one AWS-wide status.

AWS does not document a customer-facing ML-KEM key and decapsulation workflow in KMS that is equivalent to Google Cloud KMS KEM keys. It also does not document an HPKE-based quantum-safe import transport equivalent to Google Cloud’s Preview feature. See the AWS, Azure, and Google Cloud PQC comparison for the workflow-level differences.

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)

Current Boto3 uses the TLS library linked by Python. PQ TLS requires a build and system policy that enable the hybrid group, normally OpenSSL 3.5 or later:

import ssl
print(ssl.OPENSSL_VERSION)

# After confirming OpenSSL 3.5+ and the operating-system policy,
# use the normal Boto3 service client.
import boto3
kms = boto3.client("kms")

Note: OpenSSL 3.5 is necessary but may not be sufficient on Linux because the distribution crypto policy must also enable PQ groups. Check the AWS SDK PQ TLS documentation for platform-specific requirements.

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 documented PQ TLS

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

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, while hybrid PQ TLS can protect key establishment for the API connection. That does not make the full workload quantum-safe. Authentication, application signatures, unsupported endpoints, dependencies, and other key-management paths must be assessed separately.

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?

AWS has not announced one default-on date for every service. Activation already varies: CloudFront enables PQ key establishment across existing policies, ALB and NLB use opt-in policies, and SDK behavior depends on language, runtime, and version.

Sources

AWS Security Blog: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager — GA announcement (April 2025)
AWS Docs: Configure hybrid post-quantum TLS for KMS — SDK configuration guide
AWS Docs: Using hybrid post-quantum TLS with Amazon S3 — S3 PQ TLS documentation
AWS Docs: Hybrid post-quantum TLS for Secrets Manager — Secrets Manager PQ TLS guide
AWS Docs: Enabling hybrid post-quantum TLS (SDK reference) — Cross-service SDK PQ TLS configuration
AWS Security Blog: AWS post-quantum cryptography migration plan — Multi-phase PQ migration strategy (December 2024)
AWS Security Blog: AWS-LC FIPS 3.0 — First cryptographic library to include ML-KEM in FIPS 140-3 validation — FIPS-validated PQ library (December 2024)
AWS: Amazon S3 now supports post-quantum TLS key exchange on S3 endpoints — S3 PQ TLS announcement (November 2025)
AWS: Post-Quantum Cryptography overview — AWS PQ strategy page
AWS KMS: ML-DSA keys — ML-DSA key specifications, HSM protection, and signing behavior
AWS Private CA supported algorithms — ML-DSA CA and certificate algorithms
AWS: CloudFront post-quantum TLS — Default support across CloudFront TLS policies
AWS: ALB and NLB post-quantum TLS — Opt-in PQ-TLS policies and regional availability