Cloud Security Wire
AWS Azure GCP RSS
AWSAzureGCP Hardening Guide

Post-Quantum Cryptography in Cloud: What Changes for TLS, KMS, and Certificate Management

AI-accelerated cryptanalysis just shortened the expected runway for post-quantum migration. Here's what cloud teams need to understand about quantum-safe TLS, cloud KMS hybrid key support, and the certificate pipeline changes required before NIST's selected algorithms become mandatory for government-adjacent workloads.

By Cloud Security Wire · ·
#post-quantum#PQC#TLS#KMS#certificates#ML-KEM#ML-DSA#AWS#Azure#GCP#cryptographic-agility#PKI#NIST#CNSA2

The post-quantum cryptography discussion moved from “future planning” to “active project” in August 2024 when NIST finalised its first three post-quantum standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). The conversation shifted again on 28 July 2026 when Anthropic published research showing its Claude Mythos model identified a structural flaw in HAWK — a competing post-quantum digital signature candidate — in 60 hours of computation, a finding that two years of human expert review had not surfaced.

The HAWK finding does not break anything in production. ML-KEM and ML-DSA were finalised before the finding and are unaffected. What it does is concretely demonstrate that AI-accelerated cryptanalysis can operate faster than human peer review, which changes the risk calculus for any organisation that has been treating post-quantum migration as a low-urgency multi-year project.

For cloud engineering teams, the practical question is: what specifically needs to change in your AWS, Azure, or GCP infrastructure, and in what order?

What’s Actually Changing in Cloud Provider TLS

All three major cloud providers are in active deployment of post-quantum hybrid TLS — combining classical ECDH key exchange with ML-KEM to provide protection against both classical and future quantum attacks.

AWS added support for ML-KEM hybrid key agreement in Elastic Load Balancing and CloudFront in 2025. The relevant cipher suite is TLS_AES_256_GCM_SHA384 with X25519MLKEM768 as the key agreement algorithm. It’s not enabled by default in all configurations. To check whether your ALB or CloudFront distribution is negotiating post-quantum cipher suites, query the TLS negotiation metrics:

# Check TLS cipher negotiation stats for an ALB
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name TargetTLSNegotiationErrorCount \
  --dimensions Name=LoadBalancer,Value=<your-lb-arn> \
  --start-time 2026-07-28T00:00:00Z \
  --end-time 2026-07-29T00:00:00Z \
  --period 3600 \
  --statistics Sum

For ACM certificates, post-quantum signature algorithms are not yet supported for end-entity certificates. NIST’s ML-DSA finalisation means this will change, but certificate chains in the public WebPKI are moving slower than TLS negotiation changes because they require browser and OS root store updates first.

Azure similarly added X25519MLKEM768 support to Application Gateway and Azure Front Door in 2025. The Azure TLS policy TlsPolicy-PQC-Preview enables post-quantum hybrid negotiation. It can be applied via the portal or ARM:

{
  "properties": {
    "sslPolicy": {
      "policyType": "Custom",
      "policyName": "TlsPolicy-PQC-Preview",
      "minProtocolVersion": "TLSv1_3"
    }
  }
}

GCP Cloud Load Balancing has had experimental post-quantum cipher support since late 2025 via its TLS 1.3 implementation. Check the current negotiated cipher suites in Cloud Logging:

gcloud logging read \
  'resource.type="http_load_balancer" AND 
   jsonPayload.tlsCipherSuite!="TLS_AES_256_GCM_SHA384"' \
  --limit 50 \
  --format "table(timestamp, jsonPayload.tlsCipherSuite, jsonPayload.remoteIp)"

KMS: Hybrid Key Support

Cloud key management services have a different migration path from TLS. KMS keys are used for data encryption at rest, envelope encryption for secrets, and signing operations. These are longer-lived than TLS session keys and have different requirements.

AWS KMS does not yet support ML-KEM or ML-DSA as primary key algorithms for customer-created CMKs. AWS manages post-quantum protection internally for its infrastructure but customer-facing KMS key types remain RSA, ECC, AES-256, and HMAC variants. For workloads that need post-quantum-secure key wrapping today, the practical approach is application-layer hybrid encryption: use ML-KEM for key encapsulation in application code and wrap the result with a standard AES-256 KMS key for storage.

# Conceptual: hybrid key wrapping with ML-KEM + AWS KMS
# Requires liboqs or pqcrypto Python bindings
from pqcrypto.kem.ml_kem_768 import generate_keypair, encap, decap
import boto3

kms = boto3.client('kms')

# Generate ML-KEM keypair (store public key in application config)
pk, sk = generate_keypair()

# Encapsulate: generates shared secret and ciphertext
ciphertext, shared_secret = encap(pk)

# Wrap the ML-KEM ciphertext with KMS for storage
wrapped = kms.encrypt(
    KeyId='alias/my-app-key',
    Plaintext=ciphertext
)

# shared_secret is now your quantum-safe symmetric key material
# Use it with AES-GCM for data encryption

Azure Key Vault is in a similar position — RSA and EC keys for wrapping, no ML-DSA signing support yet. The Azure team has published a PQC roadmap indicating hybrid RSA+ML-KEM wrapping support is targeted for general availability in late 2026.

GCP Cloud KMS added Cloud HSM support for hybrid post-quantum operations in preview in early 2026. The GOOGLE_SYMMETRIC_ENCRYPTION and RSA_DECRYPT_OAEP_* key versions remain the production recommendation; the hybrid PQ variants are still in preview with restrictions on HSM locations.

Certificate Pipeline Changes

Certificate management is where most organisations have the most work to do. A typical cloud environment has certificates in several places with different update paths:

  • ACM/Azure Certificate Manager/GCP Certificate Manager: Load balancer and CDN certs — automated renewal, but algorithm selection is provider-controlled
  • Internal PKI (ACM Private CA, Azure Managed HSM, GCP Certificate Authority Service): Where you control the signature algorithm
  • Code signing certificates: For Lambda deployment packages, container images, IaC modules — these touch security-sensitive supply chain paths
  • Client certificates for mTLS between microservices

For internal PKI, you can begin issuing ML-DSA certificates today for internal services. This requires:

  1. Creating a new CA hierarchy with ML-DSA as the signing algorithm
  2. Updating TLS libraries in applications to accept and validate ML-DSA signature chains
  3. Running the new PKI in parallel with your existing ECDSA hierarchy (hybrid operation)

The parallel operation phase is operationally important because not all clients and services will support post-quantum certificates at the same time. Services that talk to external parties need to maintain ECDSA compatibility; services that only talk to internal infrastructure that you control can be migrated to ML-DSA more aggressively.

ACM Private CA with ML-DSA (preview):

aws acm-pca create-certificate-authority \
  --certificate-authority-configuration \
    'KeyAlgorithm=ML-DSA-65,
     SigningAlgorithm=SHA512WITHML-DSA,
     Subject={CN=Internal PQ Root CA}' \
  --certificate-authority-type ROOT \
  --region us-east-1

Crypto Agility: The Foundational Requirement

Regardless of which specific algorithms you migrate to and when, the most important architectural requirement is crypto agility — the ability to swap cryptographic algorithms without application code changes.

The patterns that work:

  • Algorithm identifiers are configuration, not constants. Store key_algorithm: "ML-KEM-768" in config, read it in code.
  • Key material is wrapped, not embedded. No hard-coded key bytes in application code or container images.
  • Certificate and key rotation is automated and tested. Manual rotation that takes weeks is too slow if a vulnerability is found in a deployed algorithm.
  • Monitoring exists for algorithm negotiation. You should know within an hour if a service is negotiating a downgraded cipher.

The HAWK finding is a demonstration that cryptographic algorithms can fail faster than the industry expects. An ML-KEM or ML-DSA vulnerability discovered by an AI system in 2027 or 2028 is not a hypothetical scenario anymore. The speed of cryptographic agility in your infrastructure determines how quickly you can respond.

Prioritisation for Cloud Teams

High priority, start now:

  • Audit TLS cipher suite negotiation across your load balancers and CDN configurations. Enable post-quantum hybrid where provider support is available and confirmed stable.
  • Identify services using long-lived encrypted data (backups, audit logs, regulated records). These are at highest risk from harvest-now-decrypt-later attacks. Plan for re-encryption as part of PQC migration.
  • Inventory all certificate authorities in use, including self-managed PKI. Establish which ones can issue ML-DSA certs today.

Medium priority:

  • Begin running a parallel ML-DSA PKI for internal service-to-service mTLS in non-production environments.
  • Update TLS library pinning in microservices to allow ML-KEM cipher suites without requiring code changes.
  • Establish crypto agility as an architectural standard in your security review process for new services.

Track, not urgent yet:

  • KMS algorithm migration: providers are not yet offering production ML-DSA signing keys for customer CMKs. Track provider roadmaps but do not block other work on this.
  • Public-facing certificate migration: requires browser/OS root store changes that are provider- and standards-body-driven. Participate in relevant working groups if you have the capacity; otherwise monitor and wait for provider-driven rollout.
← All Analysis Subscribe via RSS