Post-Quantum Cryptography in the Cloud: What Changes in 2026

Google Cloud has confirmed it will begin enabling post-quantum key exchange by default in October 2026 for its load balancers — global and regional external Application Load Balancers, internal Application Load Balancers, and external proxy Network Load Balancers. Anyone who wants to hold off has until October 2027 by explicitly setting their SSL policy to defer it; after that, it is no longer optional.

AWS is already ahead of that switch. Its public service endpoints have started preferring hybrid post-quantum key exchange automatically whenever a connecting client supports it, and support for the older, pre-standard Kyber algorithm is being phased out across AWS endpoints this year in favor of the finalized ML-KEM standard. Neither of these is a future roadmap item. Both are changes rolling out to production traffic in 2026.

No cryptographically relevant quantum computer exists yet, and credible estimates still put one years away. The reason cloud providers are moving now anyway is a threat called harvest-now, decrypt-later: an adversary intercepts and stores encrypted traffic today, and simply waits until a quantum computer can break today’s key exchange to read it. For data that needs to stay confidential for years — health records, financial data, source code, long-lived contracts, anything protected by IP — that risk is live the moment the traffic is captured, not the moment a quantum computer arrives.

NIST finalized its post-quantum standards (ML-KEM for key exchange, ML-DSA for digital signatures) in 2024, which is what unlocked this wave of default rollouts. Both Google and AWS are using a hybrid approach — combining a classical algorithm like X25519 with the new post-quantum ML-KEM — so a connection stays protected by conventional cryptography even if an unexpected flaw is found in the new algorithm during its early years of real-world use.

For teams that sell into government or defense-adjacent buyers, two dates matter alongside the cloud provider rollouts. On September 21, 2026, all remaining FIPS 140-2 module certifications move to “historical” status, meaning they can no longer be cited to justify new federal procurement. On January 1, 2027, new acquisitions for U.S. national security systems must support CNSA 2.0 algorithms outright. Neither deadline forces a typical SaaS product to act by law — but they are the reason the cloud providers are moving on this timeline, and any vendor selling upstream of a government buyer will feel it as a procurement question well before it becomes their own compliance obligation.

None of this requires an emergency migration. It does require knowing where you stand before the setting flips under you:

1. Inventory every TLS termination point.
   Load balancers, API gateways, and CDNs each have their own SSL policy. Know which ones will pick up post-quantum key exchange automatically and which need an explicit policy change.
2. Test legacy and embedded clients against the new handshake.
   Hybrid key exchange adds a larger handshake payload. Most modern clients handle it transparently, but older TLS stacks, some embedded devices, and IoT firmware that has not been updated in years are worth testing explicitly rather than assuming.
3. Confirm your crypto libraries are current.
   Post-quantum TLS support typically requires a recent TLS library version — for example, AWS’s SDK guidance calls out OpenSSL 3.5 or later for Python clients. Older pinned dependencies may silently fall back to classical-only key exchange.
4. Build crypto-agility into how you manage keys and certs.
   The specific algorithm in use today will not be the last one. Infrastructure that treats the cipher suite and key exchange method as configuration, not a hardcoded assumption, is what makes the next transition routine instead of a project.
5. Flag whether the compliance clock applies to you.
   If any customer, prime contractor, or partner in your chain sells to the federal government, the September 2026 and January 2027 dates above are worth raising with them now, before it shows up as a blocked deal.

It is easy to file post-quantum cryptography under “something defense contractors deal with” and move on. That misses the point of harvest-now, decrypt-later: any product handling data with a long confidentiality shelf life is exposed the moment that data is captured in transit, regardless of who the customer is. A healthcare platform, a fintech API, or a SaaS product holding customer source code all have the same exposure window as a defense supplier — they just do not have a procurement deadline forcing the conversation. The cloud providers moving first, on their own timeline, is what makes this a 2026 story instead of a someday one.

Innvente’s cloud solutions team reviews load balancer and TLS configuration across AWS, Google Cloud, and Alibaba Cloud as part of every infrastructure engagement, and works alongside our DevOps and platform engineering team to roll changes like this out through CI/CD rather than a manual console change. If you are not sure which of your services will pick up post-quantum defaults automatically or where an outdated TLS dependency is hiding, start with a free software project audit — we will map your infrastructure’s actual exposure before October 2026 makes the decision for you.

• Inventory every load balancer, gateway, and CDN SSL policy.
• Test legacy and embedded clients against hybrid handshakes.
• Update TLS libraries pinned below current PQC support.
• Treat cipher suite and key exchange as configuration, not a constant.
• Check whether a customer or partner’s federal deadline applies to you.

For the broader contract and portability questions that come with any cloud infrastructure change, see our cloud vendor lock-in checklist.