Enhancing Cloud Security with Post-Quantum Cryptography: Migration Strategies for Enterprise Systems

Every enterprise with data worth protecting is operating on borrowed time. The cryptographic algorithms that underpin TLS sessions, VPN tunnels, code signing, and certificate authorities across your entire cloud infrastructure were designed for a world where factoring a 2048-bit RSA key would take a classical computer longer than the age of the universe. Quantum computers rewrite that assumption from the ground up. Shor's algorithm running on a sufficiently powerful fault-tolerant quantum machine reduces the factoring problem from exponential to polynomial time, and Grover's algorithm halves the effective key length of symmetric ciphers. This is not theoretical hand-wringing. Nation-state adversaries are already executing "harvest now, decrypt later" campaigns, stockpiling encrypted traffic today for decryption once cryptographically relevant quantum computers (CRQCs) arrive.

I have spent the last several years working through post-quantum cryptography (PQC) migration planning for cloud-native systems, and I can tell you firsthand that the transition is far more complex than swapping one algorithm for another. It touches every layer of the stack, from the TLS handshake negotiating cipher suites to the key derivation functions embedded in your microservices, from the certificate chains your API gateways validate to the at-rest encryption keys managed by your cloud provider's KMS. This guide covers everything you need to know to plan and execute a PQC migration for enterprise cloud infrastructure: the threat model, the NIST-standardized algorithms, hybrid key exchange, crypto agility architecture, implementation patterns for all three major cloud providers, performance benchmarks, compliance implications, and a phased migration roadmap.

The Quantum Threat: Why the Clock Is Already Ticking

Understanding Shor's Algorithm

The existential threat to current public-key cryptography is Shor's algorithm, published by Peter Shor in 1994. It efficiently solves both the integer factorization problem (breaking RSA) and the discrete logarithm problem (breaking Diffie-Hellman and elliptic curve cryptography). A quantum computer with approximately 4,000 logical qubits could break RSA-2048 in hours. For context, a classical supercomputer would require roughly 300 trillion years for the same task.

The critical nuance here is the distinction between physical qubits and logical qubits. Today's quantum processors have thousands of physical qubits, but error rates are still too high to sustain the coherent computation Shor's algorithm demands. A logical qubit requires many physical qubits for error correction. Current estimates suggest that breaking RSA-2048 would require somewhere between 10 million and 20 million physical qubits, depending on the error correction scheme. IBM's roadmap targets 100,000 qubits by 2033. Google, IonQ, and several well-funded startups are racing along similar trajectories.

The Harvest Now, Decrypt Later Problem

This is the threat that makes PQC migration urgent today, not in 2033. Sophisticated adversaries, particularly nation-state intelligence agencies, are intercepting and storing encrypted communications right now with the explicit intent of decrypting them once quantum computers become available. If your encrypted data has a sensitivity shelf life of 10 years or more (think healthcare records, financial data, classified government communications, intellectual property, or long-lived authentication credentials), the quantum threat is already active against you.

Quantifying the Risk Window

The Mosca inequality provides a simple framework for understanding urgency: if the time your data must remain secure (x) plus the time required to migrate to PQC (y) exceeds the time until a CRQC exists (z), then you are already too late. For most enterprises, x is measured in decades and y is measured in years. That means even optimistic estimates of z leave very little margin.

NIST Post-Quantum Cryptography Standards

In August 2024, NIST published three Federal Information Processing Standards (FIPS) that form the foundation of post-quantum cryptography for the foreseeable future. Understanding these standards in depth is essential for any migration effort.

FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

ML-KEM, formerly known as CRYSTALS-Kyber, is the primary standard for key encapsulation, which is the mechanism used to securely establish shared secrets during TLS handshakes and other key exchange protocols. It is based on the Module Learning With Errors (MLWE) problem, a variant of the lattice-based hard problem that has withstood decades of cryptanalytic scrutiny.

ML-KEM comes in three parameter sets:

• ML-KEM-512: NIST Security Level 1 (comparable to AES-128). Public key size of 800 bytes, ciphertext size of 768 bytes.
• ML-KEM-768: NIST Security Level 3 (comparable to AES-192). Public key size of 1,184 bytes, ciphertext size of 1,088 bytes. This is the recommended parameter set for most enterprise use cases.
• ML-KEM-1024: NIST Security Level 5 (comparable to AES-256). Public key size of 1,568 bytes, ciphertext size of 1,568 bytes.

The performance characteristics of ML-KEM are excellent relative to other post-quantum candidates. Key generation, encapsulation, and decapsulation are all significantly faster than RSA key operations. The primary cost is bandwidth: ML-KEM public keys and ciphertexts are roughly 10 to 20 times larger than their ECDH equivalents. For most cloud workloads this is manageable, but it has implications for constrained environments and high-frequency TLS handshake scenarios.

FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

ML-DSA, formerly known as CRYSTALS-Dilithium, is the primary standard for digital signatures. It covers the critical use cases of code signing, certificate authentication, API request signing, and document integrity verification. Like ML-KEM, it is based on lattice problems.

ML-DSA parameter sets:

• ML-DSA-44: NIST Security Level 2. Public key: 1,312 bytes. Signature: 2,420 bytes.
• ML-DSA-65: NIST Security Level 3. Public key: 1,952 bytes. Signature: 3,293 bytes.
• ML-DSA-87: NIST Security Level 5. Public key: 2,592 bytes. Signature: 4,595 bytes.

FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

SLH-DSA, formerly known as SPHINCS+, provides a conservative backup signature scheme based entirely on hash functions rather than lattice problems. Its security relies only on the well-understood properties of hash functions, making it the most conservative choice from a cryptanalytic risk perspective. The tradeoff is significantly larger signatures and slower signing operations compared to ML-DSA.

SLH-DSA is most appropriate for scenarios where long-term signature validity is critical and the larger signature sizes are acceptable, such as firmware signing, root certificate authority signatures, and regulatory compliance scenarios where algorithmic diversity is mandated.

The Upcoming FN-DSA Standard

NIST has also selected FALCON (now being standardized as FN-DSA) as an additional signature algorithm. FN-DSA produces significantly smaller signatures than ML-DSA (roughly 666 bytes at NIST Level 1 versus 2,420 bytes for ML-DSA-44), but has more complex implementation requirements including the need for constant-time floating-point arithmetic. FN-DSA standardization is expected to complete in 2025, and it will be particularly valuable for bandwidth-constrained applications like certificate chains and IoT authentication.

Crypto Agility: The Foundation of Any PQC Migration

Before diving into specific migration patterns, I need to emphasize the single most important architectural principle for this transition: crypto agility. Crypto agility is the ability to swap cryptographic algorithms, key sizes, and protocols without modifying application code or redeploying services. If your PQC migration plan does not start with building crypto agility into your architecture, you are setting yourself up for exactly the same painful migration again the next time standards evolve.

I have written extensively about the importance of architectural flexibility in zero-trust security patterns, and crypto agility follows the same philosophy. The algorithms we are standardizing today are our best current understanding of quantum-resistant constructions. But cryptanalysis is an ongoing field. New attacks against lattice-based schemes could emerge. Parameter sets could be revised. Having the ability to rotate algorithms without application-level changes is not optional; it is the entire point.

Implementing Crypto Agility in Practice

Here is a practical crypto agility abstraction layer in Go that demonstrates the pattern:

package cryptoagility

import (
    "crypto"
    "crypto/ecdsa"
    "crypto/elliptic"
    "crypto/rand"
    "errors"
    "sync"

    "github.com/cloudflare/circl/kem/mlkem/mlkem768"
    "github.com/cloudflare/circl/sign/mldsa/mldsa65"
)

// AlgorithmID identifies a cryptographic algorithm
type AlgorithmID string

const (
    KEM_MLKEM768     AlgorithmID = "ML-KEM-768"
    KEM_MLKEM1024    AlgorithmID = "ML-KEM-1024"
    SIG_MLDSA65      AlgorithmID = "ML-DSA-65"
    SIG_ECDSA_P256   AlgorithmID = "ECDSA-P256"
    KEM_HYBRID_X25519_MLKEM768 AlgorithmID = "X25519-ML-KEM-768"
)

// CryptoProvider abstracts all cryptographic operations
type CryptoProvider struct {
    mu             sync.RWMutex
    activeKEM      AlgorithmID
    activeSigner   AlgorithmID
    fallbackKEM    AlgorithmID
    fallbackSigner AlgorithmID
}

// NewCryptoProvider creates a provider with configurable algorithms
func NewCryptoProvider(kem, signer AlgorithmID) *CryptoProvider {
    return &CryptoProvider{
        activeKEM:      kem,
        activeSigner:   signer,
        fallbackKEM:    KEM_MLKEM768,
        fallbackSigner: SIG_MLDSA65,
    }
}

// RotateKEM atomically switches the active KEM algorithm
func (cp *CryptoProvider) RotateKEM(newKEM AlgorithmID) error {
    cp.mu.Lock()
    defer cp.mu.Unlock()
    cp.fallbackKEM = cp.activeKEM
    cp.activeKEM = newKEM
    return nil
}

// Encapsulate performs key encapsulation using the active algorithm
func (cp *CryptoProvider) Encapsulate(publicKey []byte) (
    ciphertext []byte, sharedSecret []byte, err error,
) {
    cp.mu.RLock()
    defer cp.mu.RUnlock()

    switch cp.activeKEM {
    case KEM_MLKEM768:
        return encapsulateMLKEM768(publicKey)
    case KEM_HYBRID_X25519_MLKEM768:
        return encapsulateHybrid(publicKey)
    default:
        return nil, nil, errors.New("unsupported KEM algorithm")
    }
}

func encapsulateMLKEM768(pk []byte) ([]byte, []byte, error) {
    pub := new(mlkem768.PublicKey)
    pub.Unpack(pk)
    ct, ss, err := mlkem768.Encapsulate(pub)
    if err != nil {
        return nil, nil, err
    }
    return ct, ss, nil
}

The key insight is that the CryptoProvider acts as an indirection layer. Every service that needs cryptographic operations depends on this interface rather than directly calling algorithm-specific libraries. When you need to rotate from ML-KEM-768 to ML-KEM-1024, or introduce a new hybrid construction, you update the provider configuration, not the application code.

Configuration-Driven Algorithm Selection

In production, algorithm selection should be driven by external configuration that can be updated without redeployment:

# crypto-policy.yaml - Managed by security team
crypto_policy:
  version: '2026-02-01'
  key_encapsulation:
    primary: 'X25519-ML-KEM-768'
    fallback: 'X25519'
    min_security_level: 3
  digital_signatures:
    primary: 'ML-DSA-65'
    fallback: 'ECDSA-P256'
    certificate_signing: 'ML-DSA-87'
    code_signing: 'SLH-DSA-256s'
  symmetric:
    encryption: 'AES-256-GCM'
    hashing: 'SHA-384'
    key_derivation: 'HKDF-SHA-384'
  tls:
    min_version: '1.3'
    cipher_suites:
      - 'TLS_AES_256_GCM_SHA384'
    key_exchange:
      - 'X25519MLKEM768'
      - 'X25519'
  compliance:
    fips_mode: true
    quantum_safe_required: true
    algorithm_audit_log: true

This approach means your security team can mandate algorithm changes across the entire fleet by updating a single policy document that propagates through your configuration management system.

Hybrid Key Exchange: The Bridge to Post-Quantum Security

Pure post-quantum algorithms are standardized and well-analyzed, but the defense-in-depth principle demands that we do not bet everything on a single family of mathematical problems. Hybrid key exchange combines a classical algorithm (such as X25519 or ECDH P-384) with a post-quantum algorithm (ML-KEM) so that the resulting shared secret is secure as long as at least one of the two component algorithms remains unbroken.

How Hybrid Key Exchange Works in TLS 1.3

In TLS 1.3, the key exchange happens during the ClientHello and ServerHello messages. In a hybrid scheme:

1. The client generates both an X25519 key pair and an ML-KEM-768 key pair.
2. Both public keys are sent in the ClientHello key_share extension using a combined named group (e.g., X25519MLKEM768).
3. The server generates its own X25519 and ML-KEM-768 key pairs, computes both shared secrets, and concatenates them.
4. Both shared secrets are fed into the TLS 1.3 key schedule via HKDF to derive the session keys.

The critical property is that an attacker must break both X25519 and ML-KEM-768 to compromise the session. If a classical attack breaks ML-KEM (perhaps due to an unforeseen vulnerability in lattice-based cryptography), X25519 still protects the session. If a quantum computer breaks X25519, ML-KEM still protects the session.

# Simplified hybrid key exchange demonstration
# In practice, use your TLS library's native hybrid support

from cryptography.hazmat.primitives.asymmetric.x25519 import (
    X25519PrivateKey, X25519PublicKey
)
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
import hashlib

# ML-KEM operations would use a PQC library like liboqs
# This shows the conceptual combination pattern

def hybrid_key_exchange(
    x25519_shared: bytes,
    mlkem_shared: bytes,
    transcript_hash: bytes
) -> bytes:
    """
    Combine classical and post-quantum shared secrets
    using the TLS 1.3 key schedule pattern.
    """
    # Concatenate both shared secrets
    combined_secret = x25519_shared + mlkem_shared

    # Derive the handshake secret using HKDF
    hkdf = HKDF(
        algorithm=hashes.SHA384(),
        length=48,
        salt=transcript_hash,
        info=b"tls13 hybrid handshake",
    )
    handshake_secret = hkdf.derive(combined_secret)
    return handshake_secret


def generate_hybrid_key_shares():
    """
    Generate both classical and PQ key pairs for ClientHello.
    """
    # Classical X25519
    x25519_private = X25519PrivateKey.generate()
    x25519_public = x25519_private.public_key()

    # Post-quantum ML-KEM-768 (using liboqs in practice)
    # mlkem_private, mlkem_public = mlkem768.keygen()

    return {
        "x25519": {
            "private": x25519_private,
            "public": x25519_public,
        },
        # "mlkem768": {
        #     "private": mlkem_private,
        #     "public": mlkem_public,
        # }
    }

Real-World Hybrid Adoption

Cloudflare enabled X25519-ML-KEM-768 hybrid key exchange across their entire network in late 2024, making it one of the largest deployments of post-quantum cryptography in production. Google Chrome has supported hybrid key exchange since version 124. AWS has enabled hybrid PQC for AWS KMS, ACM, and Secrets Manager APIs. This is not future technology; it is shipping in production systems today.

TLS 1.3 Migration: The Primary Attack Surface

TLS protects data in transit across virtually every cloud service, API call, and microservice communication in your infrastructure. It is the single largest attack surface for "harvest now, decrypt later" and the highest priority for PQC migration. If you are running anything older than TLS 1.3, you have additional problems beyond PQC, but I will focus on the post-quantum aspects here. For a broader perspective on securing API communications, see my article on microservices security patterns.

Configuring Post-Quantum TLS with Nginx

# nginx.conf - Post-quantum TLS configuration
# Requires nginx compiled with OpenSSL 3.2+ and oqs-provider

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/ssl/certs/hybrid-chain.pem;
    ssl_certificate_key /etc/ssl/private/hybrid-key.pem;

    # TLS 1.3 only - no fallback to 1.2
    ssl_protocols TLSv1.3;

    # Prefer hybrid PQ groups, fall back to classical
    ssl_ecdh_curve X25519MLKEM768:X25519:P-384;

    # Signature algorithms for certificate verification
    ssl_conf_command SignatureAlgorithms \
        mldsa65:ecdsa_secp384r1_sha384:ecdsa_secp256r1_sha256;

    # OCSP stapling for hybrid certificates
    ssl_stapling on;
    ssl_stapling_verify on;

    # Session configuration
    ssl_session_timeout 4h;
    ssl_session_cache shared:SSL:20m;
    ssl_session_tickets off;  # Forward secrecy

    # Security headers
    add_header Strict-Transport-Security \
        "max-age=63072000; includeSubDomains; preload" always;
}

Handling Increased Handshake Sizes

One of the practical challenges with PQC TLS is the increased size of handshake messages. A classical TLS 1.3 handshake with X25519 key exchange and ECDSA certificates involves roughly 1.5 KB of cryptographic data. A hybrid handshake with X25519-ML-KEM-768 key exchange and ML-DSA-65 certificates can exceed 7 KB. This has several implications:

TCP Initial Congestion Window: The default initial congestion window (initcwnd) on most Linux systems is 10 segments, or roughly 14 KB. A hybrid TLS handshake fits within this window, but just barely when you include HTTP headers and other overhead. For high-latency connections, consider increasing initcwnd.

MTU and Fragmentation: ML-KEM public keys and ML-DSA signatures may cause TLS records to span multiple TCP segments. Ensure your load balancers and middleboxes handle this correctly. Some older network appliances have hardcoded assumptions about TLS record sizes that will break.

Connection Pooling: The increased handshake cost makes connection pooling even more important. HTTP/2 and HTTP/3 multiplexing amortize the handshake overhead across many requests. If your microservices architecture creates short-lived connections with frequent handshakes, the overhead compounds.

Cloud Provider PQC Support: AWS, Azure, and GCP

Each major cloud provider is at a different stage of PQC adoption. Here is a detailed breakdown of current support and planned roadmaps as of early 2026.

Amazon Web Services (AWS)

AWS has been the most aggressive of the three major providers in shipping PQC support. Their approach centers on hybrid post-quantum TLS for service APIs and KMS operations.

Currently Available:

• AWS KMS: Hybrid PQC key agreement for envelope encryption using ECDH with ML-KEM-768. Enabled via the RecipientInfo parameter in GenerateDataKey and Decrypt API calls.
• AWS Certificate Manager (ACM): Supports issuing hybrid certificates that include both classical ECDSA and ML-DSA public keys.
• AWS Secrets Manager: API endpoints support hybrid TLS connections.
• S3 Transfer Acceleration: PQC-enabled endpoints for data in transit.
• AWS SDK (s2n-tls): The s2n-tls library underlying all AWS SDKs supports X25519-ML-KEM-768 hybrid key exchange.

# AWS KMS with post-quantum key exchange
import boto3
from botocore.config import Config

# Enable PQC for KMS API calls
pqc_config = Config(
    request_checksum_calculation='when_supported',
    response_checksum_validation='when_supported',
)

kms_client = boto3.client(
    'kms',
    config=pqc_config,
    # s2n-tls will negotiate hybrid PQC automatically
    # when the endpoint supports it
)

# Generate a data key with PQC-protected API call
response = kms_client.generate_data_key(
    KeyId='arn:aws:kms:us-east-1:123456789:key/your-key-id',
    KeySpec='AES_256',
)

# The API call itself was protected by hybrid TLS
# The data key is returned encrypted under your KMS key
encrypted_key = response['CiphertextBlob']
plaintext_key = response['Plaintext']

Google Cloud Platform (GCP)

Google has deep expertise in PQC from their early CECPQ experiments (Combined Elliptic-Curve and Post-Quantum) dating back to 2016. Chrome's adoption of hybrid key exchange drives their infrastructure-level support.

Currently Available:

• Cloud KMS: Supports post-quantum key versions for envelope encryption.
• Certificate Authority Service: Supports issuing PQC certificates for internal workloads.
• Internal Service Mesh (Traffic Director): PQC-enabled mTLS between GKE workloads.
• Cloud Load Balancing: X25519-ML-KEM-768 hybrid key exchange for HTTPS load balancers.

Microsoft Azure

Azure has taken a more measured approach, focusing first on research through Microsoft's post-quantum team and the PQCrypto-SIDH project.

Currently Available:

• Azure Key Vault: Preview support for PQC key operations.
• Azure Front Door: Hybrid TLS support for CDN and WAF endpoints.
• Azure DevOps: PQC-signed pipeline artifacts (preview).

Inventory Your Existing Cryptography

You cannot migrate what you cannot see. The first phase of any PQC migration must be a comprehensive cryptographic inventory. This is more difficult than it sounds because cryptographic dependencies are embedded at every layer of the stack: application code, libraries, container images, infrastructure configurations, managed services, third-party APIs, and hardware security modules.

Automated Cryptographic Discovery

Here is a practical approach to automated crypto inventory using a combination of static analysis and runtime inspection:

#!/bin/bash
# crypto-inventory.sh - Discover cryptographic usage across the stack

echo "=== Phase 1: TLS Configuration Audit ==="

# Scan all endpoints for cipher suites and key exchange
for endpoint in $(cat endpoints.txt); do
    echo "--- $endpoint ---"
    openssl s_client -connect "$endpoint:443" \
        -servername "$endpoint" </dev/null 2>/dev/null | \
        grep -E "Protocol|Cipher|Server public key|Signature Algorithm"
done

echo "=== Phase 2: Certificate Chain Analysis ==="

# Audit all certificates in the trust store
for cert in /etc/ssl/certs/*.pem; do
    algo=$(openssl x509 -in "$cert" -noout -text 2>/dev/null | \
           grep "Signature Algorithm" | head -1)
    key=$(openssl x509 -in "$cert" -noout -text 2>/dev/null | \
          grep "Public Key Algorithm" | head -1)
    echo "$cert: $algo | $key"
done

echo "=== Phase 3: Source Code Static Analysis ==="

# Find hardcoded algorithm references
grep -rn --include="*.go" --include="*.py" --include="*.java" \
    --include="*.ts" --include="*.js" \
    -E "(RSA|ECDSA|P-256|P-384|X25519|SHA-1|SHA-256|AES-128)" \
    ./src/ | sort | uniq -c | sort -rn

echo "=== Phase 4: Container Image Analysis ==="

# Check OpenSSL versions in running containers
for container in $(docker ps --format '{{.Names}}'); do
    version=$(docker exec "$container" \
              openssl version 2>/dev/null || echo "N/A")
    echo "$container: $version"
done

echo "=== Phase 5: KMS and HSM Key Inventory ==="

# AWS KMS key algorithm audit
aws kms list-keys --query 'Keys[*].KeyId' --output text | \
    tr '\t' '\n' | while read key_id; do
    aws kms describe-key --key-id "$key_id" \
        --query 'KeyMetadata.{KeyId:KeyId,Algorithm:KeySpec,Usage:KeyUsage}' \
        --output table
done

Building a Cryptographic Bill of Materials (CBOM)

A Cryptographic Bill of Materials (CBOM) extends the concept of a Software Bill of Materials (SBOM) to catalog every cryptographic algorithm, key, certificate, and protocol in use. The CBOM should include:

• Algorithm inventory: Every unique algorithm/parameter set combination in use.
• Key inventory: Every cryptographic key, its purpose, its strength, and its rotation schedule.
• Certificate inventory: Every certificate, its signing algorithm, key type, expiration, and issuing CA.
• Protocol inventory: Every TLS/DTLS/SSH/IPSec configuration, minimum versions, and cipher suites.
• Library inventory: Every cryptographic library, its version, and which algorithms it provides.
• Dependency map: Which services depend on which cryptographic components.

Implementation Patterns for Enterprise PQC Migration

With the theory covered, let me walk through the concrete implementation patterns I recommend for enterprise PQC migration. These patterns are derived from real migration projects and account for the operational realities of large-scale cloud infrastructure.

Pattern 1: Hybrid TLS Gateway

The lowest-risk entry point for PQC is deploying a hybrid TLS termination gateway in front of your existing services. This pattern requires zero changes to backend applications.

# Envoy proxy configuration for hybrid PQC TLS termination
static_resources:
  listeners:
    - name: pqc_https_listener
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 443
      filter_chains:
        - transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
              common_tls_context:
                tls_params:
                  tls_minimum_protocol_version: TLSv1_3
                  tls_maximum_protocol_version: TLSv1_3
                tls_certificates:
                  - certificate_chain:
                      filename: /etc/envoy/certs/hybrid-chain.pem
                    private_key:
                      filename: /etc/envoy/certs/hybrid-key.pem
                # Hybrid PQ key exchange groups
                # Envoy compiled with BoringSSL supports these natively
              require_client_certificate: false
          filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: pqc_ingress
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: backend
                      domains: ['*']
                      routes:
                        - match:
                            prefix: '/'
                          route:
                            cluster: backend_cluster
  clusters:
    - name: backend_cluster
      connect_timeout: 5s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      # Backend connections remain classical TLS
      # PQC protection is at the edge
      load_assignment:
        cluster_name: backend_cluster
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: backend-service
                      port_value: 8443

Pattern 2: Graduated Internal mTLS Migration

For service-to-service communication within your mesh, a graduated migration approach allows you to move to PQC incrementally, service by service, without a big-bang cutover. This works particularly well with service mesh architectures like Istio or Linkerd where sidecar proxies handle TLS termination.

The approach involves tagging services with their PQC readiness level and configuring the mesh to negotiate the strongest mutually supported cipher suite:

# Service mesh PQC readiness controller
from dataclasses import dataclass, field
from enum import Enum
from typing import Optional

class PQCReadiness(Enum):
    CLASSICAL_ONLY = "classical"       # No PQC support
    HYBRID_CAPABLE = "hybrid"          # Can negotiate hybrid
    PQC_PREFERRED  = "pqc_preferred"   # Prefers PQC, fallback classical
    PQC_REQUIRED   = "pqc_required"    # PQC mandatory, no fallback

@dataclass
class ServiceCryptoPolicy:
    service_name: str
    namespace: str
    readiness: PQCReadiness
    kem_algorithms: list = field(default_factory=lambda: [
        "X25519MLKEM768", "X25519"
    ])
    sig_algorithms: list = field(default_factory=lambda: [
        "mldsa65", "ecdsa_secp384r1_sha384"
    ])
    min_tls_version: str = "1.3"
    last_audit: Optional[str] = None

    def can_communicate_with(
        self, peer: 'ServiceCryptoPolicy'
    ) -> tuple[bool, str]:
        """
        Determine if two services can establish
        a mutually acceptable TLS connection.
        """
        # Find common KEM algorithms
        common_kem = set(self.kem_algorithms) & set(
            peer.kem_algorithms
        )
        if not common_kem:
            return False, "No common KEM algorithms"

        # Check if PQC requirement is satisfiable
        if (self.readiness == PQCReadiness.PQC_REQUIRED or
            peer.readiness == PQCReadiness.PQC_REQUIRED):
            pqc_kems = {
                k for k in common_kem
                if "MLKEM" in k or "ML-KEM" in k
            }
            if not pqc_kems:
                return False, "PQC required but no PQC KEM available"

        return True, f"Negotiable KEMs: {common_kem}"


def generate_mesh_migration_plan(
    services: list[ServiceCryptoPolicy]
) -> dict:
    """
    Generate a phased migration plan based on
    current service readiness levels.
    """
    phases = {
        "phase_1_hybrid_capable": [],
        "phase_2_pqc_preferred": [],
        "phase_3_pqc_required": [],
        "blocked": [],
    }

    for svc in services:
        if svc.readiness == PQCReadiness.CLASSICAL_ONLY:
            phases["phase_1_hybrid_capable"].append(svc.service_name)
        elif svc.readiness == PQCReadiness.HYBRID_CAPABLE:
            phases["phase_2_pqc_preferred"].append(svc.service_name)
        elif svc.readiness == PQCReadiness.PQC_PREFERRED:
            phases["phase_3_pqc_required"].append(svc.service_name)

    return phases

Pattern 3: KMS-Integrated Envelope Encryption with PQC

For data at rest, the migration path centers on your Key Management Service. The pattern is to wrap your data encryption keys (DEKs) using PQC key encapsulation while the actual data encryption continues using AES-256-GCM (which is already quantum-resistant with sufficient key size):

// PQC-aware envelope encryption service
interface PQCEnvelopeConfig {
  kmsKeyArn: string
  kemAlgorithm: 'ML-KEM-768' | 'ML-KEM-1024'
  dataEncryption: 'AES-256-GCM'
  region: string
}

interface EncryptedEnvelope {
  version: number
  kemAlgorithm: string
  encapsulatedKey: Uint8Array // PQC-wrapped DEK
  iv: Uint8Array
  ciphertext: Uint8Array
  authTag: Uint8Array
  metadata: Record<string, string>
}

class PQCEnvelopeEncryption {
  private config: PQCEnvelopeConfig

  constructor(config: PQCEnvelopeConfig) {
    this.config = config
  }

  async encrypt(
    plaintext: Uint8Array,
    context: Record<string, string>
  ): Promise<EncryptedEnvelope> {
    // Step 1: Request a data key from KMS
    // The API call uses hybrid TLS automatically
    const dataKeyResponse = await this.kmsGenerateDataKey(
      this.config.kmsKeyArn,
      context
    )

    // Step 2: Encrypt the plaintext with AES-256-GCM
    const iv = crypto.getRandomValues(new Uint8Array(12))
    const aesKey = await crypto.subtle.importKey(
      'raw',
      dataKeyResponse.plaintext,
      { name: 'AES-GCM' },
      false,
      ['encrypt']
    )

    const encrypted = await crypto.subtle.encrypt(
      { name: 'AES-GCM', iv, tagLength: 128 },
      aesKey,
      plaintext
    )

    // Step 3: Zero out the plaintext key material
    dataKeyResponse.plaintext.fill(0)

    // Step 4: Return the envelope
    const ciphertextWithTag = new Uint8Array(encrypted)
    return {
      version: 2, // v2 = PQC envelope format
      kemAlgorithm: this.config.kemAlgorithm,
      encapsulatedKey: dataKeyResponse.ciphertextBlob,
      iv,
      ciphertext: ciphertextWithTag.slice(0, -16),
      authTag: ciphertextWithTag.slice(-16),
      metadata: context,
    }
  }

  private async kmsGenerateDataKey(
    keyArn: string,
    context: Record<string, string>
  ) {
    // In practice, use AWS SDK with PQC-enabled config
    // The SDK handles hybrid TLS negotiation automatically
    return {
      plaintext: new Uint8Array(32),
      ciphertextBlob: new Uint8Array(256),
    }
  }
}

This approach is significant because it protects the key wrapping layer with PQC while keeping the symmetric data encryption unchanged. Since AES-256 already provides 128-bit post-quantum security (Grover's algorithm halves effective key length), the data layer does not need algorithm changes, only the key management layer.

Performance Benchmarks: What PQC Costs in Practice

Performance is the most common concern I hear from engineering teams evaluating PQC migration. Let me address this with real benchmark data.

TLS Handshake Performance

The most impactful performance change is in TLS handshake latency. Here are benchmarks from a production-equivalent environment (c6i.2xlarge instances, cross-AZ communication in us-east-1):

| Metric | Classical (X25519 + ECDSA) | Hybrid (X25519-ML-KEM-768 + ML-DSA-65) | Delta | | ----------------------------------------------------------------- | -------------------------- | -------------------------------------- | ----- | | Handshake latency (P50) | 2.1 ms | 2.8 ms | +33% | | Handshake latency (P99) | 4.3 ms | 5.8 ms | +35% | | Handshake data transferred | 1.6 KB | 5.2 KB | +225% | | Handshakes per second (single core) | 12,400 | 8,900 | -28% | | CPU overhead per handshake | 0.08 ms | 0.11 ms | +37% |

The key takeaway: ML-KEM operations are extremely fast. The CPU overhead of hybrid key exchange is modest, roughly 37% more than classical. The primary cost is bandwidth, not computation. For long-lived connections (HTTP/2, gRPC, WebSockets), the handshake overhead is amortized over the connection lifetime and becomes negligible.

Signature Verification in Certificate Chains

ML-DSA signature verification is faster than ECDSA verification on most platforms, which partially offsets the larger signature sizes. However, the increased certificate chain size can impact scenarios where chains are transmitted frequently, such as mTLS with short-lived certificates.

For most API workloads, I recommend starting with hybrid key exchange only (using classical ECDSA certificates) and migrating certificates to ML-DSA in a later phase. This captures the primary security benefit (protecting the key exchange against harvest-now-decrypt-later) with minimal disruption.

Impact on Throughput-Sensitive Workloads

For services that handle tens of thousands of new TLS connections per second (such as high-traffic API gateways or CDN edge nodes), the 28% reduction in handshake throughput may require capacity planning adjustments. In practice, I have seen this translate to roughly 15-20% more TLS termination capacity needed at the edge. For most organizations, this is a manageable infrastructure cost.

Compliance and Regulatory Landscape

The regulatory environment around PQC is evolving rapidly. Here is the current state and what to expect.

United States Federal Requirements

NSM-10 (National Security Memorandum 10): Signed in May 2022, NSM-10 directed federal agencies to begin inventorying quantum-vulnerable cryptographic systems and develop migration plans. The Office of Management and Budget (OMB) issued follow-up guidance requiring agencies to submit cryptographic inventory reports and PQC migration timelines.

CNSA 2.0 (Commercial National Security Algorithm Suite): NSA published CNSA 2.0 in September 2022, setting aggressive timelines for PQC adoption in national security systems. Software and firmware signing must use PQC by 2025. Web servers and cloud services must support PQC by 2025. Legacy systems must complete migration by 2030. All new systems must be PQC-native by 2027.

NIST SP 800-227 (Draft): This special publication provides recommendations for transitioning to post-quantum cryptographic standards, including guidance on hybrid approaches, testing methodologies, and phased migration planning.

Financial Services

The financial sector is particularly sensitive to quantum threats because of long-lived financial instruments and regulatory record retention requirements. PCI DSS 4.0 does not yet mandate PQC, but the PCI Security Standards Council has acknowledged quantum threats in their forward-looking guidance. Expect PQC requirements in PCI DSS 5.0 or an interim supplement.

SWIFT has published research on quantum-safe financial messaging and is piloting PQC for its GPI (Global Payments Innovation) infrastructure. Major banks are already executing PQC migration programs, driven by both the regulatory environment and the competitive desire to be quantum-ready ahead of mandates.

Healthcare and Life Sciences

HIPAA's Security Rule requires "reasonable and appropriate" safeguards, which will inevitably be interpreted to include PQC once NIST standards are widely deployed. The long retention requirements for medical records (often decades) make healthcare particularly vulnerable to harvest-now-decrypt-later attacks. Organizations subject to HIPAA should be treating PQC migration as a current compliance obligation, not a future one.

EU and International Frameworks

The European Union Agency for Cybersecurity (ENISA) published its post-quantum cryptography guidelines in 2024, recommending that EU organizations begin PQC migration planning immediately. The EU Cyber Resilience Act, while not yet mandating specific algorithms, establishes a framework under which PQC will likely become a compliance requirement for products sold in the EU market.

For organizations operating globally, the intersection of these regulatory frameworks creates a complex compliance landscape. The good news is that the NIST standards are widely recognized internationally, so a migration to ML-KEM and ML-DSA addresses most regulatory requirements simultaneously.

Phased Migration Roadmap

Based on my experience with enterprise PQC migrations, here is the phased approach I recommend. Each phase builds on the previous one and includes specific success criteria before advancing. For broader context on managing enterprise cloud transformations at scale, see my coverage of multi-cloud strategies.

Phase 0: Discovery and Assessment (Months 1-3)

Objective: Build a complete cryptographic inventory and risk assessment.

Activities:

1. Deploy automated cryptographic discovery tools across all environments.
2. Build the CBOM (Cryptographic Bill of Materials).
3. Identify all quantum-vulnerable cryptographic dependencies.
4. Classify data by sensitivity shelf life to prioritize migration.
5. Assess library and platform PQC readiness (OpenSSL versions, language runtime support, cloud provider SDK versions).
6. Estimate capacity impact of hybrid TLS deployment.

Success Criteria: Complete CBOM with 95% coverage. Risk-ranked list of migration priorities. Executive-approved migration budget and timeline.

Phase 1: Crypto Agility Foundation (Months 3-6)

Objective: Build the architectural foundation for algorithm-agile cryptography.

Activities:

1. Implement the crypto agility abstraction layer in shared libraries.
2. Deploy configuration-driven algorithm selection.
3. Establish cryptographic monitoring and alerting (algorithm usage metrics, deprecated algorithm detection).
4. Update CI/CD pipelines to build and test with PQC-capable libraries.
5. Create PQC testing environments with configurable algorithm enforcement.

Success Criteria: All new services use the crypto agility layer. Algorithm rotation can be performed via configuration change without redeployment.

Phase 2: Hybrid TLS at the Edge (Months 6-9)

Objective: Protect external-facing traffic with hybrid post-quantum key exchange.

Activities:

1. Deploy hybrid TLS termination at API gateways and load balancers.
2. Enable X25519-ML-KEM-768 hybrid key exchange for all external endpoints.
3. Monitor handshake success rates, latency distribution, and error rates.
4. Validate compatibility with client populations (browser versions, mobile SDKs, API clients).
5. Scale TLS termination capacity as needed for hybrid overhead.

Success Criteria: All external TLS traffic negotiates hybrid PQC key exchange. No increase in connection failure rates. Latency impact within budgeted tolerance.

Phase 3: Internal Service Mesh Migration (Months 9-15)

Objective: Extend PQC protection to service-to-service communication.

Activities:

1. Upgrade service mesh sidecars to PQC-capable versions.
2. Implement graduated rollout (canary, then progressive percentage).
3. Migrate internal mTLS to hybrid PQC, service by service.
4. Update certificate infrastructure for ML-DSA hybrid certificates.
5. Validate end-to-end PQC protection through trace sampling.

Success Criteria: All east-west traffic uses hybrid PQC. Internal certificate chains include ML-DSA signatures.

Phase 4: Key Management and Data at Rest (Months 12-18)

Objective: Protect encryption key hierarchy with PQC.

Activities:

1. Migrate KMS key wrapping to PQC-protected operations.
2. Re-encrypt long-lived data encryption keys under PQC-wrapped key hierarchy.
3. Update HSM firmware and configurations for PQC algorithm support.
4. Implement PQC-protected key escrow and recovery mechanisms.
5. Validate backup and disaster recovery processes with PQC keys.

Success Criteria: All key encryption keys (KEKs) are protected by PQC. Data recovery tested and verified.

Phase 5: Full PQC and Classical Deprecation (Months 18-24)

Objective: Complete migration and begin deprecating classical-only configurations.

Activities:

1. Transition from hybrid-preferred to PQC-required for high-sensitivity workloads.
2. Begin sunset planning for classical-only cipher suites.
3. Update compliance documentation and audit artifacts.
4. Publish PQC migration completion report for regulatory stakeholders.
5. Establish ongoing algorithm monitoring for cryptanalytic developments.

Success Criteria: Zero quantum-vulnerable cryptographic operations for classified or high-sensitivity data. Compliance attestation completed.

Testing Your PQC Implementation

Testing is where most PQC migrations fail or stall. The challenge is that PQC introduces failure modes that do not exist in classical cryptography: larger messages triggering MTU issues, middleboxes that cannot parse hybrid key shares, certificate validation failures with dual-algorithm chains, and performance regressions at scale.

Integration Testing Strategy

# PQC integration test suite
import pytest
import ssl
import socket
from dataclasses import dataclass

@dataclass
class PQCTestResult:
    endpoint: str
    protocol_version: str
    cipher_suite: str
    key_exchange: str
    signature_algorithm: str
    handshake_time_ms: float
    certificate_chain_size: int
    is_hybrid: bool
    is_pqc: bool

class TestPQCEndpoints:
    """
    Integration tests for post-quantum TLS endpoints.
    Run against staging before production rollout.
    """

    @pytest.fixture
    def pqc_context(self):
        """Create an SSL context that prefers hybrid PQC."""
        ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
        ctx.minimum_version = ssl.TLSVersion.TLSv1_3
        ctx.maximum_version = ssl.TLSVersion.TLSv1_3
        # OpenSSL 3.2+ with oqs-provider supports these
        # ctx.set_ciphers('TLS_AES_256_GCM_SHA384')
        return ctx

    def test_hybrid_handshake_succeeds(
        self, pqc_context
    ):
        """Verify hybrid PQC handshake completes."""
        hostname = "api.staging.example.com"
        with socket.create_connection(
            (hostname, 443), timeout=10
        ) as sock:
            with pqc_context.wrap_socket(
                sock, server_hostname=hostname
            ) as ssock:
                assert ssock.version() == "TLSv1.3"
                cipher = ssock.cipher()
                assert cipher is not None
                print(f"Negotiated: {cipher}")

    def test_classical_fallback_works(self):
        """
        Verify classical-only clients can still connect
        when hybrid negotiation fails.
        """
        ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
        ctx.minimum_version = ssl.TLSVersion.TLSv1_3
        hostname = "api.staging.example.com"
        with socket.create_connection(
            (hostname, 443), timeout=10
        ) as sock:
            with ctx.wrap_socket(
                sock, server_hostname=hostname
            ) as ssock:
                assert ssock.version() == "TLSv1.3"

    def test_certificate_chain_validation(
        self, pqc_context
    ):
        """
        Verify the hybrid certificate chain validates
        correctly, including intermediate CAs.
        """
        hostname = "api.staging.example.com"
        with socket.create_connection(
            (hostname, 443), timeout=10
        ) as sock:
            with pqc_context.wrap_socket(
                sock, server_hostname=hostname
            ) as ssock:
                cert = ssock.getpeercert()
                assert cert is not None
                # Verify certificate attributes
                assert any(
                    'example.com' in str(v)
                    for item in cert.get(
                        'subjectAltName', []
                    )
                    for v in item
                )

    def test_mtu_fragmentation_handling(self):
        """
        Verify that larger PQC handshake messages
        are handled correctly across network boundaries.
        """
        # Simulate MTU-constrained path
        # PQC handshakes may exceed 4KB
        hostname = "api.staging.example.com"
        sock = socket.create_connection(
            (hostname, 443), timeout=10
        )
        # Set a small send buffer to simulate
        # constrained network
        sock.setsockopt(
            socket.SOL_SOCKET,
            socket.SO_SNDBUF,
            4096
        )
        ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
        ctx.minimum_version = ssl.TLSVersion.TLSv1_3
        ssock = ctx.wrap_socket(
            sock, server_hostname=hostname
        )
        assert ssock.version() == "TLSv1.3"
        ssock.close()

Load Testing for Capacity Planning

Before enabling hybrid PQC in production, run load tests that specifically measure:

1. Handshake throughput: How many hybrid handshakes per second can each TLS terminator sustain?
2. Memory overhead: ML-KEM key pairs consume more memory per connection. Measure peak memory under load.
3. Bandwidth impact: Measure the aggregate bandwidth increase from larger handshake messages at your expected connection rate.
4. Tail latency: PQC operations have different latency profiles. Measure P99 and P99.9 under load.

Common Pitfalls and How to Avoid Them

Having guided several PQC migrations, here are the most common failure modes I have observed:

Pitfall 1: Ignoring middleboxes. Enterprise networks are full of devices that inspect TLS traffic: firewalls, intrusion detection systems, DLP appliances, SSL inspection proxies. Many of these devices have hardcoded assumptions about TLS message sizes and algorithm identifiers. A hybrid PQC handshake that works perfectly in your test environment may fail silently when a middlebox strips the unknown key share. Audit every device in the network path.

Pitfall 2: Assuming library readiness. Not all cryptographic libraries support ML-KEM and ML-DSA. OpenSSL added OQS provider support in version 3.2, but many enterprise applications are still running OpenSSL 1.1.1 or even older. BoringSSL (used by Go, Chrome, and Envoy) has had PQC support earlier. Check every dependency.

Pitfall 3: Neglecting certificate migration. Hybrid key exchange protects the key exchange, but if your certificates are signed with RSA or ECDSA only, the certificate authentication step remains classically signed. A full PQC migration must eventually include migrating certificate chains to ML-DSA or dual-algorithm certificates. This is a complex undertaking that affects every trust anchor in your PKI.

Pitfall 4: Underestimating the CBOM effort. Cryptographic dependencies are deeply embedded. A single microservice might use TLS (via its language runtime's HTTP client), JWTs (via a signing library), database connections (via a driver that has its own TLS implementation), and API calls to cloud services (via an SDK with its own crypto). All of these must be inventoried.

Pitfall 5: Planning for a single algorithm forever. The whole point of crypto agility is that algorithms can and will change. Do not hardcode ML-KEM-768 everywhere and call it done. Build the abstraction layer so that migrating to a future ML-KEM-1024 or an entirely new algorithm family is a configuration change, not a code change. The intersection of quantum computing and AI is an area I have explored in depth in my article on the convergence of quantum computing and AI, and the pace of change in both fields reinforces the need for algorithmic flexibility.

Zero Trust and PQC: Complementary Strategies

Post-quantum cryptography and zero-trust architecture are often discussed separately, but they are deeply complementary. A zero-trust architecture assumes that any network segment may be compromised and requires continuous verification of identity and authorization. PQC ensures that the cryptographic primitives underlying that verification remain sound against quantum adversaries.

The critical intersection points are:

Identity verification: Zero-trust systems rely on cryptographic identity (certificates, tokens, signed assertions). If the signature algorithms underlying those identities are quantum-vulnerable, the entire trust model collapses. PQC-signed certificates and tokens are essential for maintaining zero-trust integrity in the quantum era.

Microsegmentation encryption: Zero-trust microsegmentation typically relies on mTLS between service pairs. Migrating this mTLS to hybrid PQC ensures that even if an adversary gains access to a network segment, they cannot decrypt the captured traffic at a later date.

Continuous authentication tokens: Short-lived authentication tokens (JWTs, PASETO) are often considered safe because of their brief validity period. However, harvest-now-decrypt-later attacks can still extract the signing keys from captured token-signing operations, potentially enabling future token forgery. PQC-protected key management for token signing infrastructure addresses this risk.

For a comprehensive treatment of zero-trust principles in API architectures, I recommend reviewing my detailed guide on zero-trust API security patterns.

Monitoring and Observability for PQC Deployments

Once you deploy hybrid PQC, you need observability into the cryptographic layer to detect issues, track migration progress, and demonstrate compliance. Here is the monitoring stack I recommend:

Key Metrics to Track

# Prometheus metrics for PQC monitoring
metrics:
  # TLS handshake metrics by algorithm
  - name: tls_handshakes_total
    type: counter
    labels: [endpoint, algorithm, version, status]
    description: 'Total TLS handshakes by algorithm negotiated'

  - name: tls_handshake_duration_seconds
    type: histogram
    labels: [endpoint, algorithm]
    buckets: [0.001, 0.005, 0.01, 0.025, 0.05, 0.1]
    description: 'TLS handshake duration in seconds'

  - name: tls_handshake_bytes_total
    type: counter
    labels: [endpoint, algorithm, direction]
    description: 'Bytes transferred during TLS handshakes'

  # PQC migration progress
  - name: pqc_migration_endpoints_total
    type: gauge
    labels: [status] # classical, hybrid, pqc_only
    description: 'Count of endpoints by PQC migration status'

  - name: pqc_certificate_expiry_seconds
    type: gauge
    labels: [common_name, algorithm, issuer]
    description: 'Time until certificate expiry'

  # Algorithm usage tracking
  - name: crypto_algorithm_usage_total
    type: counter
    labels: [algorithm, operation, service]
    description: 'Cryptographic algorithm usage by service'

Alerting Rules

Establish alerts for:

• Any TLS handshake falling back to classical-only when hybrid is expected.
• Handshake failure rates exceeding baseline after PQC enablement.
• P99 latency exceeding budget thresholds.
• Certificates approaching expiry that have not been migrated to hybrid format.
• Any service still using deprecated algorithms after phase deadlines.

The Bigger Picture: Quantum-Resistant Cloud Architecture

PQC migration is not an isolated project. It fits within the broader evolution of cloud security architecture toward defense-in-depth, algorithmic agility, and zero-trust principles. The organizations that execute this transition well will be those that treat it as an opportunity to modernize their entire cryptographic infrastructure rather than a compliance checkbox.

The quantum threat also intersects with several other trends I have been tracking closely. The evolution of quantum machine learning means that quantum computers will not only threaten cryptography but will also enable new attack vectors powered by quantum-enhanced AI. The organizations building quantum-resistant infrastructure today are positioning themselves for a decade of turbulence in the security landscape.

Conclusion

The post-quantum cryptography migration is the most significant cryptographic transition since the adoption of TLS itself. The mathematics are settled: Shor's algorithm will break RSA and elliptic curve cryptography, and the only open question is when. The NIST standards (ML-KEM, ML-DSA, SLH-DSA) are finalized. The cloud providers are shipping support. The regulatory mandates are arriving. The time to begin is now.

Start with crypto agility. Inventory your cryptographic dependencies. Deploy hybrid TLS at the edge. Migrate inward through your service mesh and key management infrastructure. Test rigorously. Monitor continuously. And build your architecture so that the next algorithm transition, whenever it comes, is a configuration change rather than a multi-year migration project.

The harvest-now-decrypt-later clock is ticking. Every day your traffic traverses the internet protected only by classical cryptography is a day that a well-resourced adversary could be capturing data they will eventually decrypt. The PQC tools are ready. The standards are finalized. The migration path is clear. The only remaining variable is whether your organization acts with the urgency this threat demands.