Nine Layers, One Migration: Securing Cloud Infrastructure Against the Quantum Threat

The nine-layer analysis by Baseri, Hafid, and Lashkari structures the quantum migration problem across three temporal phases. In the pre-transition phase, organizations run classical cryptography. Shor's algorithm threatens all asymmetric operations: RSA key exchange, ECDH ephemeral sessions, ECDSA-signed certificates. Grover's algorithm halves the effective security of symmetric keys, weakening AES-128 to approximately AES-64-equivalent strength against a quantum adversary. The risk is one-sided: classical defenses are already compromised in theory, and the "harvest now, decrypt later" attack is already in operation.

In the hybrid phase, organizations run classical and post-quantum algorithms in parallel — the recommended migration approach. The risks here are migration-specific: protocol downgrade paths, where a quantum-capable adversary forces negotiation back to classical algorithms; dual-certificate complexity, where certificate chains carry both classical and PQC credentials and intermediate systems may accept one but not the other; and system heterogeneity, where incompletely migrated infrastructure creates security boundary discontinuities.

In the post-transition phase, classical algorithms have been replaced. The new risk profile is PQC-specific: side-channel attacks on NTT implementations, fault injection against masked decapsulation, and the buffer-overflow and injection vectors created by the larger artifact sizes. This phase is what most migration planning fails to address. The assumption that completing the migration ends the security problem is incorrect.

At the application layer, the risks are familiar: web applications that embed hardcoded RSA keys, APIs with hardcoded certificate pins, and session-management libraries that assume fixed-size key material. The PQC-specific addition is that larger public keys and signatures may exceed the maximum message size of existing protocol implementations.

At the data and runtime layers, encryption-at-rest and in-transit both require algorithm migration. Middleware and ORM layers that abstract cryptographic operations create hidden dependencies: a framework update that installs a PQC library may not also update the database encryption driver. At the OS and virtualization layers, kernel crypto APIs, TLS stacks in container runtimes, and hypervisor-level key management all carry classical algorithm assumptions that require explicit updates.

At the network layer — the layer most studied for quantum impact — TLS, IPsec, SSH, and PGP all require migration. A 2024 paper by Baseri, Chouhan, and Hafid analyzing network protocol quantum exposure notes that TLS 1.3's hybrid key exchange extension provides the most straightforward migration path, but protocol-level negotiation failures in intermediate devices (load balancers, deep-packet inspection appliances, CDN edge nodes) are a frequent and underappreciated migration risk.

The size increase from classical to PQC artifacts is not a mere overhead concern. Baseri, Chouhan, and Ghorbani (2026) document that PQC key and ciphertext sizes are 11 to 72 times larger than their classical equivalents, and flag this as an active security vector. Systems that did not validate input sizes against fixed-size buffers because "a key is at most 512 bytes" are exposed to stack and heap overflows when a 1,184-byte ML-KEM-768 public key arrives. Polymorphic and fileless malware payloads can be embedded in the padding required to meet minimum message sizes in protocols that were sized for ECDSA credentials.

The implication is that post-migration security audits must specifically test for buffer handling at every point where cryptographic objects transit the system: TLS handshake parsing, certificate chain validation, key management APIs, and storage serialization formats.

All three major cloud providers have published roadmaps for quantum-safe migration and are actively adding hybrid PQC to key services. AWS began offering hybrid ML-KEM key exchange in its TLS implementation and has added PQC support to the AWS Key Management Service. Azure is integrating hybrid PQC into its certificate issuance infrastructure and into the Azure VPN gateway. GCP has published guidance on migrating customer-managed encryption keys. However, the survey notes that CSP-level migration addresses platform infrastructure, not tenant workloads. Organization-specific applications, databases, and middleware deployed on cloud infrastructure require independent migration assessment.

The STRIDE-based threat taxonomy in the survey also identifies cloud-specific risks that CSP migration does not address: shared-tenancy side-channel attacks on co-located virtual machines, PQC implementation weaknesses in managed runtimes where the JVM or CLR may introduce timing vulnerabilities, and quantum-amplified denial-of-service attacks that exploit the additional computation cost of PQC operations.

Treat the migration as three separate projects, not one. Pre-transition, hybrid, and post-transition phases have different risk profiles and require different controls. A migration plan that only addresses algorithm replacement misses the hybrid-phase and post-transition risks.

Audit buffer sizes before PQC artifacts flow through systems. Identify every location where cryptographic objects are parsed, stored, or transmitted — TLS handshakes, certificate validators, key management APIs — and verify that buffer allocations accommodate ML-KEM and ML-DSA artifact sizes before migration, not after a parsing failure.

Design for cryptographic agility from the start. The ability to swap algorithms without rebuilding systems is not a luxury feature; it is the operational hedge against future cryptanalytic developments. Abstract cryptographic operations behind stable interfaces, and test that interface with multiple algorithm implementations.

Do not assume CSP quantum-safe upgrades cover your workloads. Cloud provider infrastructure migration and tenant workload migration are separate efforts. Maintain an inventory of cryptographic dependencies in your own code and configuration.