Post-quantum TLS on AWS, Google Cloud and Azure: 2026 status

If your company runs on AWS, Google Cloud or Azure, some of its traffic is already protected by post-quantum encryption, and some is not, and the difference usually comes down to a setting nobody has changed yet. As of November 2026, all three providers and Cloudflare support hybrid key exchange (a classical algorithm combined with ML-KEM, the NIST standard published as FIPS 203) on at least part of their edge. Only some of it is on by default, and almost all of it stops at the edge.

AWS states the split plainly. Its migration plan says “we will deliver PQC as part of our shared responsibility model,” and its post-quantum hub adds that “updating resource configuration to a PQ-enabled TLS policy is on the customers’ side.” This article lists what each provider does for you, what you have to switch on, and how to check.

Which cloud traffic is already post-quantum by default?

The table sums up the main services as documented by each provider. “Client must offer it” means the server is ready, but the handshake only goes post-quantum if your SDK, library or browser also proposes ML-KEM.

AWS: post-quantum is ready, but often opt-in

CloudFront is the easy win. On September 5, 2025 AWS announced that “PQC support is available on all existing security policies by default, requiring no customer configuration” for connections from viewers. Connections from CloudFront to your origin are listed on AWS’s readiness page as “coming soon.” On October 30, 2026 AWS added a CloudFront-Viewer-TLS-Details header that lets you measure how many of your users actually connect with post-quantum key exchange.

Load balancers are where most teams fall behind. AWS’s November 21, 2025 announcement says “you must explicitly update your existing ALB HTTPS listeners or NLB TLS listeners to use a PQ-TLS security policy.” The documentation recommends ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 (and a FIPS variant), and notes a trap: a new listener created in the console gets a post-quantum policy, but one created with the CLI, CloudFormation or CDK gets ELBSecurityPolicy-2016-08, which is not post-quantum. If your infrastructure is defined as code, check the templates. API Gateway REST APIs work the same way, with policies such as SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09.

AWS service endpoints are ready on the server side. KMS, ACM and Secrets Manager added hybrid ML-KEM in April 2025, and AWS’s readiness page now lists FIPS and non-FIPS endpoints with the note “Transparent. Customers must update clients.” Regional S3 endpoints followed on November 19, 2025. Whether your calls use it depends on the SDK. According to AWS’s April 2026 security blog, the Rust, Go and Node.js SDKs (and Kotlin on Linux) do it by default in recent versions, Python “requires OpenSSL 3.5 or later to be present on the host system,” and Java needs the CRT HTTP client with post-quantum TLS turned on. For Secrets Manager you can confirm it in CloudTrail, where tlsDetails shows X25519MLKEM768.

Two more points. AWS said in April 2025 that the pre-standard Kyber option “will be removed across all AWS service endpoints in 2026 in favor of ML-KEM,” so clients pinned to old builds should be updated. And AWS’s plan gives no end date for the rest of its services, only “over the coming years.”

Google Cloud: on by default for Google, scheduled for your load balancers

Google is furthest along on its own endpoints. Its Cloud roadmap of August 11, 2026 says that google.com and *.googleapis.com “have implemented NIST-standardized ML-KEM (FIPS 203) in hybrid mode,” and that Google targets full post-quantum readiness by 2029. A test we ran on November 8, 2026 against storage.googleapis.com with a current OpenSSL client negotiated X25519MLKEM768.

Your own load balancers follow a published schedule. Google’s documentation describes three steps: “Disabled by default, enabled only when set to ENABLED,” then “Enabled by default, disabled when set to DEFERRED” after October 2026, then “Enabled always” after October 2027. It applies to seven load balancer types and covers only “connections between the client and the load balancer,” not the hop to your backends. When we checked in November 2026 the page still described the first step as current, so set the policy to ENABLED explicitly rather than assume the switch has happened.

For keys, Google announced on July 28, 2026 the general availability of quantum-safe signatures (ML-DSA and SLH-DSA) and ML-KEM key encapsulation in Cloud KMS.

Microsoft Azure: Front Door now, the rest later

Microsoft’s company-wide target moved forward this year. On June 30, 2026 it wrote that “the goal is to transition products and services to PQC by 2029.”

The visible change for Azure customers is recent. On November 6, 2026 Microsoft announced that on Azure Front Door “TLS 1.3 hybrid PQC is enabled by default; no customer action is required,” using the X25519MLKEM768 and SecP256r1MLKEM768 groups. It protects the client to Front Door segment; the hop from Front Door to your origin is not covered yet.

On your own Windows servers the support exists but is off. Microsoft’s July 14, 2026 post says hybrid TLS with ML-KEM “is now generally available (GA) in Windows 11 and Windows Server 2025” but that “the PQC groups are not enabled by default.” The post shows how to enable them with PowerShell: Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0.

Azure’s management and service APIs are behind. In a scan published on May 28, 2026, Wiz wrote: “we were not able to find any Azure API servers that support this, while all GCP API servers do.” The same report found post-quantum key exchange on only 13% of AWS API servers at that date, before part of AWS’s 2026 rollout. Our own November 8 check of management.azure.com still negotiated a classical elliptic-curve group.

Cloudflare: the furthest along, including origins

Cloudflare reported on June 23, 2026 that “over two-thirds of browser traffic to Cloudflare’s network is protected with post-quantum encryption.” Since July 21, 2026 its automatic key exchange to origins is “on for all existing zones and on by default for new zones,” and prefers X25519MLKEM768 when the origin supports it. The limit is your servers: Cloudflare wrote on September 8, 2026 that the share of origins supporting post-quantum key exchange “grew from 0.5% to 12.8%.”

Why your own clients and servers decide the outcome

A hybrid handshake happens only when both ends propose it, so the libraries in your stack matter as much as the cloud.

• OpenSSL 3.5, released on April 8, 2025, added ML-KEM, ML-DSA and SLH-DSA and changed the default TLS keyshares “to offer X25519MLKEM768 and X25519.” Servers and runtimes, such as Python, linked to older OpenSSL versions stay classical.
• Go 1.24 turned on hybrid ML-KEM by default “when Config.CurvePreferences is nil.”
• Java gets hybrid key exchange for TLS 1.3 through JEP 527, delivered in JDK 27 in September 2026. Applications on older JDKs do not have it in the standard library.
• Windows has it in SChannel but disabled by default, as above.

In a typical Latin American estate, with Java services on older JDKs, Windows servers and on-premises appliances behind the cloud edge, this is where most connections remain classical.

How do you check whether a connection is post-quantum?

Four checks cover most cases:

1. OpenSSL 3.5 or later. Run openssl s_client -connect example.com:443 -servername example.com -tls1_3 -groups X25519MLKEM768. If the output includes Negotiated TLS1.3 group: X25519MLKEM768, the server supports hybrid key exchange.
2. Browser. In Chrome or Edge, open Developer Tools and the Security panel, which describes the connection and its key exchange.
3. Provider logs. CloudTrail tlsDetails for AWS API calls, ALB connection logs and the CloudFront viewer header for your own endpoints.
4. Your inventory. Record the result per endpoint, so the next audit starts from data rather than guesses.

What to do this quarter

1. List every internet-facing entry point (CDN, load balancers, API gateways) and its TLS policy.
2. Move AWS load balancers and API Gateway to PQ policies, set Google Cloud SSL policies to ENABLED, and confirm the Front Door and CloudFront defaults apply to you.
3. Fix infrastructure-as-code defaults so new listeners are not created with ELBSecurityPolicy-2016-08.
4. Upgrade clients: OpenSSL 3.5 or later on hosts, current AWS SDKs, Go 1.24 or later, and a plan for Java and Windows services.
5. Map what sits behind the edge: origins, service-to-service calls, databases, VPNs and partner links such as payment gateways and open finance APIs. Those carry the data that harvest now, decrypt later puts at risk.
6. Ask your SaaS and payment providers when their endpoints will offer hybrid key exchange.

This is the first, cheapest layer of a migration. Certificates and signatures come next and take longer, as our post-quantum cryptography explainer describes, and the endpoint list you build here is the start of a cryptographic inventory. If you want an outside view of where your cloud and on-premises traffic stands, a quantum readiness assessment covers it, and a post-quantum cryptography migration takes it from settings to signatures. Banks and fintechs with open finance APIs should also read our page on banking and finance.