The intersection of post-quantum cryptography and QaaS: architecting quantum-safe cloud infrastructures

1 Introduction

The architecture of modern enterprise computing has been fundamentally defined by the cloud. For over two decades, organizations have migrated their most critical workloads—ranging from global financial ledgers to proprietary pharmaceutical research—into distributed data centers. This paradigm relies absolutely on the assumption that data, both at rest and in transit, is shielded by mathematical fortresses. Classical public-key cryptography (PKC), specifically the Rivest-Shamir-Adleman (RSA) algorithm and Elliptic Curve Cryptography (ECC), has served as the bedrock of this trust. However, the commercial maturation of quantum computing, recently accelerated by the deployment of Quantum-as-a-Service (QaaS) models, is systematically dismantling the foundational premises of these cryptographic systems (Mosca, 2018).

What was once a theoretical physics exercise has rapidly transitioned into an engineering race. QaaS democratizes access to quantum processing units (QPUs), allowing enterprises and researchers to lease quantum computational time via standard cloud APIs. While this sparks unprecedented innovation in materials science, logistics optimization, and machine learning, it simultaneously arms malicious actors with the same capabilities. The timeline for the realization of a Cryptanalytically Relevant Quantum Computer (CRQC)—a machine capable of sustaining enough stable logical qubits to break 2048-bit RSA—is actively analyzed, and the consensus among cryptographers is shifting from “if” to “when” (National Institute of Standards Technology, 2022).

1.1 The mathematical vulnerability: shor's algorithm

The security of RSA is predicated on the integer factorization problem, while ECC relies on the discrete logarithm problem. Classical algorithms, such as the General Number Field Sieve (GNFS), require sub-exponential time to solve these problems. Specifically, the complexity of factoring an integer N classically scales as:

O(exp((649b)13(logb)23))(1)

where b is the number of bits in N. For a 2048-bit key, this computational effort is infeasible using the entire classical computing power currently available on Earth (Shor, 1994).

Conversely, Shor's algorithm, executing on a fault-tolerant quantum computer, solves both the integer factorization and discrete logarithm problems in polynomial time. The quantum time complexity reduces dramatically to approximately O(b³). This exponential speedup renders current public-key infrastructure essentially obsolete the moment a CRQC comes online. Table 1 illustrates the projected impact of quantum algorithms on standard cryptographic primitives.

Table 1. Impact of quantum computing on current cryptographic algorithms (Chen et al., 2016).

Bold values denote the critical post-quantum security bit levels, specifically highlighting the complete vulnerability (0 bits) of current asymmetric cryptography to Shor's algorithm.

As shown in Table 1, while symmetric algorithms like AES only suffer a halving of their effective security bit length due to Grover's algorithm (mitigated simply by doubling the key size), asymmetric algorithms are completely compromised. Because cloud architectures rely heavily on asymmetric cryptography for secure key exchange (TLS handshakes) and digital signatures (identity access management), the threat to QaaS infrastructures is acute.

1.2 The “Harvest Now, Decrypt Later” threat model

A critical misconception regarding the quantum threat is that organizations only need to upgrade their cryptography precisely when a CRQC is built. This ignores the reality of the “Harvest Now, Decrypt Later” (HNDL) strategy. Nation-state actors and sophisticated advanced persistent threats (APTs) are currently intercepting and archiving encrypted network traffic. Although they cannot decrypt this data today, their strategy relies on storing the ciphertext until quantum decryption capabilities become available.

For data with long-term confidentiality requirements—such as national security intelligence, genomic datasets, or long-term intellectual property—the threat is immediate. Michele Mosca formalized this urgency through Mosca's Theorem (Mosca, 2018), which states that a system is vulnerable if:

X+Y>Z(2)

where X is the required shelf-life of the data's security, Y is the time needed to fully migrate the IT infrastructure to quantum-safe standards, and Z is the time remaining before a CRQC is operational. If Z approaches before the data expires or the migration is complete, the data is compromised.

To visualize this operational threat landscape, Figure 1 presents a flowchart of the HNDL attack vector against current cloud environments.

1.3 Standardizing Post-Quantum Cryptography

To counteract the existential threat posed by quantum computers, the cryptographic community has spent the last decade developing Post-Quantum Cryptography (PQC). PQC refers to cryptographic algorithms that are believed to be secure against both classical and quantum computers, and critically, can be implemented on existing classical hardware.

The National Institute of Standards and Technology (NIST) initiated a global standardization process to evaluate and select the next generation of cryptographic primitives. As of 2024, NIST has finalized its primary standards (National Institute of Standards Technology, 2024):

• FIPS 203 (ML-KEM): Based on the CRYSTALS-Kyber algorithm, this is the primary mechanism for general encryption and key encapsulation. It relies on the hardness of the Module Learning With Errors (MLWE) problem over cryptographic lattices.
• FIPS 204 (ML-DSA): Based on CRYSTALS-Dilithium, this is the primary digital signature standard, also utilizing lattice-based cryptography.
• FIPS 205 (SLH-DSA): Based on SPHINCS+, a stateless hash-based signature scheme, acting as a fallback in case lattice-based assumptions are eventually broken.

While these algorithms provide mathematical safety, their integration into cloud networks introduces significant friction. PQC keys and signatures are substantially larger than their RSA or ECC counterparts. For instance, an ML-KEM-768 public key is 1,184 bytes, compared to a 32-byte X25519 public key. This payload inflation causes network overhead, TCP segmentation, and increased latency during Transport Layer Security (TLS) handshakes, which must be carefully managed in high-availability QaaS environments (Kampanakis and Fluhrer, 2022).

1.4 The hybrid transition architecture

Due to the relative novelty of PQC algorithms, deploying them in isolation presents a systemic risk; an unforeseen mathematical flaw in ML-KEM could leave systems entirely exposed. Therefore, regulatory bodies and security architects advocate for a “hybrid” deployment strategy (Stebila and Mosca, 2019a). A hybrid key exchange combines a classical algorithm (like ECDHE) with a post-quantum algorithm (like ML-KEM). To compromise the session, an adversary would need to simultaneously break the discrete logarithm problem and the lattice-based MLWE problem.

Algorithm 1 details the procedural logic of a hybrid TLS 1.3 handshake utilized within our proposed secure cloud architecture.

Algorithm 1 Hybrid post-quantum TLS 1.3 handshake for QaaS data-in-transit. Text-based diagram outlining a hybrid quantum-safe key exchange protocol between a client and a QaaS server, listing steps for key generation, key encapsulation, session key derivation, and secure channel establishment with emphasis on classical and post-quantum cryptography.

This hybrid approach, while robust, necessitates a complete re-engineering of cloud load balancers, edge nodes, and hardware security modules (HSMs). Cloud service providers must embrace “crypto-agility”—the ability to rapidly swap cryptographic primitives via a centralized control plane without disrupting the underlying service architecture.

1.5 Structure and contributions of the paper

This paper presents a dual contribution to the field of cloud cryptography: first, we formalize the 4-layer Post-Quantum Architecture (PQA-4) as a conceptual framework for QaaS security; second, we provide a systems-level empirical benchmark of hybrid TLS 1.3 network overhead. Addressing the intersection of QaaS and post-quantum security requires a multidisciplinary approach encompassing theoretical cryptography, network engineering, and cloud topology. To provide a rigorous, reproducible blueprint for this transition, the remainder of this paper is structured as follows.

1.6 Structure of the paper

Addressing the intersection of QaaS and post-quantum security requires a multidisciplinary approach encompassing theoretical cryptography, network engineering, and cloud topology. The remainder of this paper is structured as follows: Section 2 analyzes the specific threat landscape facing QaaS platforms, detailing attack vectors on hypervisors and tenant isolation boundaries. Section 3 introduces our proposed 4-layer Post-Quantum Architecture (PQA-4). Section 4 presents the empirical implementation of PQC for data-in-transit, including latency emulations, packet fragmentation analysis, and overhead metrics. Finally, Section 5 concludes the paper by providing our structured transition roadmap and strategic recommendations.

2 The threat landscape for QaaS platforms

The migration from classical infrastructure-as-a-service (IaaS) to Quantum-as-a-Service (QaaS) fundamentally alters the threat model of the cloud environment. Traditional cloud computing security relies heavily on the logical separation of physical resources managed by a hypervisor. In a QaaS architecture, the introduction of a Quantum Processing Unit (QPU) and its associated classical-quantum control bridge creates an unprecedented attack surface. Because QPUs require massive classical computational overhead for circuit compilation, error correction, and microwave pulse generation, the boundary between classical tenant space and quantum hardware execution becomes inherently porous (Kiktenko et al., 2020). This section dissects the specific vulnerabilities unique to QaaS platforms, focusing heavily on hypervisor exploitation, the breakdown of tenant isolation, and the mechanisms of cross-VM data leakage.

To rigorously analyze these vulnerabilities, we define the following formal threat model for our QaaS architecture:

• Assets: Proprietary quantum algorithms (OpenQASM circuits), execution telemetry, and tenant data-in-transit.
• Adversaries: Malicious co-tenants aiming for cross-VM extraction, and external advanced persistent threats (APTs) employing HNDL strategies.
• Trust boundaries: The classical hypervisor, the classical-quantum (CQ) control bridge, and the east-west internal service mesh.

It is critical to distinguish between known cloud vulnerabilities (e.g., hypervisor escapes) and the QaaS-specific physical attacks detailed in this section (e.g., QPU cross-talk and calibration exhaustion). The latter remain largely hypothesized attack vectors that require further physical validation on production quantum hardware.

2.1 Architectural vulnerabilities at the classical-quantum bridge

In contemporary QaaS deployments, users do not directly interface with the QPU. Instead, user-submitted workloads (typically in the form of OpenQASM or Q# code) are ingested by a classical cloud gateway, provisioned into a virtual machine (VM) or container, and subsequently compiled into hardware-specific microwave control pulses. These pulses are sent via digital-to-analog converters (DACs) into the dilution refrigerator housing the physical qubits.

This multi-stage pipeline introduces the “Classical-Quantum (CQ) Bridge” as a primary target for adversaries. Figure 2 delineates this complex threat taxonomy. While traditional cloud architectures treat the CPU and memory as the primary boundaries of trust, QaaS architectures extend this boundary down to the control electronics. If an attacker can compromise the classical control node, they gain the ability to manipulate the pulse-level execution of co-located tenants, potentially injecting cross-talk errors or exfiltrating proprietary quantum algorithms.

The latency requirements for quantum error correction (QEC) exacerbate this vulnerability. QEC algorithms must run in microsecond loops to measure syndromes and apply corrections before qubit decoherence occurs (Preskill, 2018). Consequently, hypervisors managing these workloads cannot utilize standard CPU context switching, as the scheduling jitter would destroy the quantum state. QaaS providers are therefore forced to implement custom, thin hypervisors or rely on bare-metal provisioning for the control nodes. These customized virtualization layers often lack the decades of hardening present in mainstream solutions like KVM or VMware ESXi, providing fertile ground for zero-day exploits.

2.2 Hypervisor attack vectors in QaaS

The hypervisor, or Virtual Machine Monitor (VMM), is the linchpin of cloud security, responsible for enforcing memory and CPU isolation between untrusted tenants. In a QaaS paradigm, the hypervisor must also broker access to the QPU job queue. Attackers targeting the QaaS hypervisor generally employ three distinct methodologies: resource exhaustion, control-plane manipulation, and hypercall abuse.

Table 2 contrasts traditional hypervisor vulnerabilities with those specifically engineered for quantum cloud environments.

Table 2. Comparative analysis of classical vs. QaaS hypervisor vulnerabilities.

A critical threat unique to QaaS is the Calibration Exhaustion Attack. QPUs require frequent calibration to maintain fidelity, a process managed by the hypervisor. A malicious tenant can submit highly specific, noise-inducing circuits designed to trigger continuous recalibration routines. This not only denies service to other tenants but can physically heat the dilution refrigerator, causing thermal fluctuations that degrade the fidelity of all active computations (Das and Chakrabarti, 2021). By exploiting the hypervisor's fair-share scheduling algorithms, an attacker manipulates the classical control plane to achieve a physical disruption at the quantum level.

2.3 Tenant isolation boundaries and cross-VM data leakage

The economic viability of QaaS relies on multi-tenancy. However, ensuring strict tenant isolation is profoundly difficult when multiple users are submitting circuits to the same physical QPU. Even if the hypervisor perfectly isolates the classical VMs, the shared nature of the QPU and its control electronics provides a novel conduit for cross-VM data leakage.

Modern processors use microarchitectural features like the Translation Lookaside Buffer (TLB) and shared Last-Level Caches (LLC) to accelerate memory accesses. When a classical VM compiles a quantum circuit (translating OpenQASM to instruction sets), the specific memory access patterns are highly correlated with the structural properties of the quantum algorithm (Ge et al., 2018). A malicious co-tenant can utilize a Prime+Probe cache side-channel attack on the classical node to steal the intellectual property of a victim's quantum circuit before it even reaches the QPU.

Furthermore, once the circuits hit the QPU, physical side-channels emerge. Quantum hardware is susceptible to cross-talk, where applying a gate to one qubit inadvertently affects the state of adjacent qubits. In a spatial multi-programming scenario—where the QPU is partitioned to run multiple tenants' circuits simultaneously—an attacker can intentionally execute high-energy pulse sequences on their allocated qubits to induce deterministic cross-talk on the victim's partition (Murali et al., 2019).

To formalize the threat of classical-quantum side channels, we present Algorithm 2, which demonstrates how an attacker might infer the composition of a victim's quantum circuit by monitoring the classical compiler's cache footprint during the QaaS ingestion phase.

Algorithm 2 Microarchitectural extraction of QaaS circuit topologies. Algorithm pseudocode in a code block describes steps for an attacker virtual machine to infer a victim quantum circuit using shared cache monitoring and a Hidden Markov Model to filter noise, ultimately returning a partially reconstructed quantum circuit.

As demonstrated in Algorithm 2, the isolation boundary is circumvented entirely on the classical side of the QaaS infrastructure. The attacker does not need to compromise the QPU; they merely exploit the deterministic behavior of the classical compiler preparing the quantum workload.

It is important to note that while these microarchitectural and cross-talk vulnerabilities represent highly plausible attack paths, they are currently hypothesized within this framework. Future empirical validation is required to quantify the exact signal-to-noise ratio an attacker could achieve in a production QaaS scheduler.

2.4 The HNDL threat in multi-tenant environments

The “Harvest Now, Decrypt Later” (HNDL) strategy is traditionally viewed as an external network threat, wherein nation-state actors passively tap fiber optic backbones. However, within the context of a multi-tenant QaaS environment, HNDL becomes a potent internal threat vector. East-west traffic—the communication between VMs, microservices, and storage nodes within the cloud provider's data center—often relies on older, less secure cryptographic implementations for performance reasons, operating under the assumption that the internal network is a trusted zone.

If an attacker achieves a hypervisor escape or breaches the tenant isolation boundary, their primary objective shifts from immediate disruption to passive harvesting. By compromising a virtual switch or a QaaS job routing node, the adversary can intercept API calls containing proprietary datasets or cryptographic key exchanges generated by co-tenants. Because these internal communications frequently utilize standard ECC or RSA-2048 for ephemeral session keys, the harvested data is highly susceptible to future cryptanalysis via Shor's algorithm.

Figure 3 illustrates the mechanics of an internal HNDL campaign. Unlike external harvesting, which is noisy and requires tapping physical infrastructure, internal harvesting via a compromised QaaS hypervisor allows the attacker to silently mirror ports on virtual switches. This grants them access to high-value quantum simulation results, pharmaceutical molecular models, and financial optimization algorithms before they are heavily encrypted for egress to the public internet.

2.5 Redefining the security perimeter

The findings detailed in this section necessitate a paradigm shift in how cloud providers architect their systems. The traditional demarcation between hardware, virtualization, and application layers is insufficient for QaaS. Mitigating these threats requires the implementation of hardware-enforced trusted execution environments (TEEs) that extend from the classical ingestion nodes down directly to the digital-to-analog converters of the QPU. Furthermore, post-quantum cryptographic standards must be applied not merely at the edge of the cloud (north-south traffic) but universally across all internal microservice communications (east-west traffic) to neutralize the internal HNDL threat vector.

Without mathematically rigorous isolation boundaries that account for both microarchitectural classical side-channels and physical quantum cross-talk, QaaS platforms will remain highly volatile environments unsuited for the processing of critical enterprise or state secrets.

3 Architecting quantum-safe cloud infrastructures: the PQA-4 framework

The transition from classical cryptographic primitives to quantum-resilient paradigms cannot be executed as a monolithic patch; it requires a systemic, defense-in-depth overhaul of the entire network stack. Quantum-as-a-Service (QaaS) platforms, which inherently process high-value intellectual property and execute proprietary quantum algorithms, represent the most critical apex of this vulnerability curve. To secure these environments against both immediate “Harvest Now, Decrypt Later” (HNDL) data exfiltration and future active quantum cryptanalysis, we propose the 4-layer Post-Quantum Architecture (PQA-4).

The PQA-4 framework Abandons the perimeter-based security model in favor of a structurally integrated quantum-resilient mesh. It is divided into four interdependent layers: Transport Layer Quantum Protection, Quantum Key Distribution (QKD) Integration, Post-Quantum Identity and Access Management (IAM), and the Crypto-Agility Orchestration Plane.

3.1 Layer 1: transport layer quantum protection

The foremost priority in securing QaaS architectures is protecting data-in-transit across the public internet and within the provider's internal wide-area network (WAN). Currently, Transport Layer Security (TLS) version 1.3 relies overwhelmingly on Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) for session key agreement. Because Shor's algorithm solves the Elliptic Curve Discrete Logarithm Problem (ECDLP) in polynomial time, any data encrypted under keys derived from ECDHE is fundamentally compromised by a cryptanalytically relevant quantum computer (CRQC) (Shor, 1994).

To address this, Layer 1 mandates the implementation of Hybrid Key Exchange (HKE) mechanisms within the TLS 1.3 handshake. Rather than abruptly abandoning battle-tested classical algorithms, HKE combines a classical key encapsulation mechanism (KEM), such as X25519, with a NIST-standardized Post-Quantum KEM, specifically ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, formerly CRYSTALS-Kyber) (National Institute of Standards Technology, 2024).

The mathematical security of this layer relies on the hardness of the Module Learning with Errors (MLWE) problem. In a hybrid setup, the shared secret (SS_*master*) is derived using a cryptographic hash function that concatenates the classical shared secret and the post-quantum shared secret:

SSmaster=HKDF(SSX25519∥SSML-KEM)(3)

An adversary would need to simultaneously break both the classical elliptic curve and the lattice-based cryptosystem to compromise the session keys (Stebila and Mosca, 2019a).

However, integrating ML-KEM introduces nontrivial network overhead. While an X25519 public key requires merely 32 bytes, an ML-KEM-768 public key payload is 1,184 bytes, and the resulting ciphertext is 1,088 bytes. In high-throughput QaaS environments, this payload expansion forces excessive TCP segmentation or, if the path MTU is circumvented, IP fragmentation at the network layer. Figure 4 illustrates the modified packet structure and flow of the PQA-4 hybrid handshake.

To mitigate fragmentation latency, PQA-4 strictly enforces TCP Initial Window (IW) tuning on all cloud load balancers, increasing the IW from the standard 10 segments to 30 segments. This ensures the entire hybrid key exchange can be transmitted in a single round trip, maintaining the ultra-low latency required for cloud-native applications.

3.2 Layer 2: quantum key distribution integration

While Layer 1 provides computational security based on the presumed hardness of mathematical problems, Layer 2 provides unconditional, information-theoretic security governed by the laws of quantum mechanics. Quantum Key Distribution (QKD) is deployed specifically for Data Center Interconnects (DCIs)—the high-capacity fiber optic backbones connecting geographically distributed QaaS availability zones.

PQA-4 utilizes a Measurement-Device-Independent QKD (MDI-QKD) topology (Lo et al., 2012). Traditional QKD setups, such as those relying on the Decoy-State BB84 protocol, are vulnerable to side-channel attacks on the single-photon detectors (e.g., blinding attacks). MDI-QKD eliminates detector vulnerabilities by having both communication endpoints (Alice and Bob) send their photonic states to an untrusted central relay (Charlie), which performs a Bell-State Measurement (BSM) and broadcasts the results. Alice and Bob then use this classical broadcast to reconcile a shared cryptographic key, without Charlie ever gaining access to the key material.

Table 3 provides a comparative analysis of the cryptographic properties between the PQC implementation in Layer 1 and the physical QKD implementation in Layer 2.

Table 3. Comparative analysis of cryptographic strategies within the PQA-4 framework.

While MDI-QKD provides information-theoretic security over the fiber link, it is not a panacea. Operationally, QKD does not mitigate endpoint compromise, hardware side-channel attacks, or classic Denial-of-Service (DoS) vectors against the quantum channel. Furthermore, the deployment of a full QKD mesh is constrained by high capital expenditures, hardware availability, and fiber attenuation. Consequently, within the PQA-4 transition roadmap, PQC migration is treated as a mandatory, immediate baseline, whereas QKD deployment is reserved as an optional, high-security overlay for specific critical Data Center Interconnects.

Because QKD links suffer from exponential signal decay over optical fiber, PQA-4 limits QKD deployment to sub-200 km regional links. The quantum-derived keys are then fed into AES-256 hardware encryptors using the ETSI GS QKD 014 REST API standard. This creates an impenetrable DCI backbone, ensuring that if an adversary taps the physical fiber between two QaaS data centers, the wave-function collapse inherent in quantum observation will immediately alert the network orchestrator to the intrusion (Pirandola et al., 2020).

3.3 Layer 3: identity and access management and digital signatures

Authentication in cloud environments relies heavily on Public Key Infrastructure (PKI) and digital signatures, formalized via X.509 certificates. QaaS platforms require continuous authentication across microservices, serverless functions, and user API invocations. The transition to post-quantum signatures is arguably the most complex component of PQA-4 due to the sheer size of the resulting signatures.

Layer 3 replaces classical RSA and ECDSA signatures with ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium) for general-purpose authentication, and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+) as a highly secure, albeit slower, fallback for root Certificate Authorities (CAs) (National Institute of Standards Technology, 2024).

An ML-DSA-65 signature is approximately 3,309 bytes. When validating an X.509 certificate chain comprising a Root CA, an Intermediate CA, and an End-Entity certificate, the cumulative signature payload exceeds 10 kilobytes. This severely degrades connection establishment times and can crash legacy ASN.1 parsers within older IoT or edge devices (Bindel et al., 2017).

To enforce Post-Quantum IAM without breaking the cloud ecosystem, PQA-4 utilizes a Composite Certificate Architecture. Algorithm 3 details the internal routing mechanism of the PQA-4 IAM gateway when validating incoming authentication tokens.

Algorithm 3 PQA-4 composite IAM signature validation. Require: Incoming API Request containing X.509 Composite Certificate Cert_*comp* and Signature payload Sig_*payload*. Ensure: Binary Access Decision (GRANT or DENY). 1: Extract Cert_*comp* attributes. 2: Identify algorithm Object Identifiers (OIDs). Let OID_*class* be the classical OID (e.g., ECDSA) and OID_*pq* be the post-quantum OID (e.g., ML-DSA). 3: Split Sig_*payload* into Sig_*class* and Sig_*pq*. 4: if Client Context denotes legacy system (No PQC support) then 5: Warning: Connection downgraded to classical security. 6: Validate Sig_*class* against classical public key. 7: return Result 8: else 9: Execute Thread A: Validate Sig_*class* using Elliptic Curve verification libraries. 10: Execute Thread B: Validate Sig_*pq* using Lattice-based signature verification libraries. 11: Join Threads. 12: if Thread A is VALID and Thread B is VALID then 13: Extract User Role and map to QaaS Role-Based Access Control (RBAC) matrix. 14: Issue short-lived, symmetric bearer token. 15: return GRANT 16: else 17: Log potential cryptanalytic attack or data corruption vector. 18: return DENY 19: end if 20: end if

This composite approach ensures that the IAM infrastructure is quantum-resilient while maintaining strict backward compatibility. For Root CA operations where signature size is irrelevant but long-term mathematical security is paramount, SLH-DSA is strictly enforced. Because SLH-DSA relies solely on the security of established hash functions (like SHA-256) rather than complex algebraic structures, it acts as the ultimate failsafe against unforeseen breakthroughs in lattice cryptanalysis.

3.4 Layer 4: crypto-agility orchestration plane

The final layer of the PQA-4 framework is the operational nervous system: the Crypto-Agility Orchestration Plane. The history of cryptography demonstrates that algorithms frequently fall to novel cryptanalytic techniques (e.g., the deprecation of MD5 and SHA-1, or the breaking of SIKE during the NIST PQC rounds). Therefore, hardcoding ML-KEM or ML-DSA into the QaaS application logic is an anti-pattern (Mosca, 2018).

Crypto-agility is the capability to seamlessly rotate, deprecate, or update cryptographic primitives across a distributed system without requiring application downtime or extensive code refactoring. In the PQA-4 model, crypto-agility is achieved by abstracting all cryptographic operations away from the application layer and pushing them down into a dedicated Service Mesh (e.g., Envoy or Istio sidecars).

As depicted in Figure 5, when a tenant application initiates a network call, the local sidecar proxy intercepts the traffic. The proxy, governed by policies pushed from the Centralized Control Plane, handles the complex hybrid TLS handshakes and post-quantum certificate validation. If a vulnerability is discovered in ML-KEM, the security team updates the policy in the Control Plane. The Control Plane instantly pushes a configuration update to all sidecar proxies across the QaaS fleet, gracefully draining existing connections and rotating the entire infrastructure to a fallback algorithm (e.g., the NIST-selected HQC or Classic McEliece) in milliseconds.

This orchestration plane also includes advanced cryptographic telemetry. It monitors connection timeout rates, TCP segmentation anomalies, and cipher-suite negotiation failures in real-time. By continuously analyzing this data, the PQA-4 framework allows cloud architects to fine-tune network parameters, ensuring that the heavy computational demands of post-quantum cryptography do not degrade the fundamental performance of the QaaS platform.

Through the integration of quantum-safe transport tunnels, physics-based key distribution, composite digital identities, and a deeply agile orchestration mesh, the PQA-4 framework provides a comprehensive, scalable blueprint for securing the next generation of computational infrastructure.

4 Empirical implementation of PQC for data-in-transit

Transitioning from theoretical cryptographic frameworks to empirical cloud deployments reveals a spectrum of engineering bottlenecks. While the mathematical robustness of lattice-based cryptography is well-documented, its operational integration into high-throughput Quantum-as-a-Service (QaaS) environments requires rigorous performance validation. Post-Quantum Cryptography (PQC) algorithms fundamentally alter the payload economics of the Transport Layer Security (TLS) handshake, introducing significant overhead in both computational cycles and network transmission bytes (Kampanakis and Fluhrer, 2022).

This section presents a comprehensive empirical analysis of PQC implementations for data-in-transit within an enterprise QaaS topology. By deploying a hybrid TLS 1.3 architecture across a globally distributed testbed, we evaluate latency emulations, investigate TCP segmentation dynamics at the network edge, and quantify compute overhead metrics against established classical baselines.

4.1 Testbed architecture and cloud topology

To ensure the empirical metrics accurately reflect enterprise QaaS workloads, we constructed a distributed testbed mirroring a Tier-1 cloud provider's architecture. The topology consists of three primary geographical zones: a Client Edge Network (simulating API consumers), a Regional Ingress Gateway (acting as the TLS termination point), and a Deep-Cloud QaaS Control Plane (simulating the classical-quantum interface).

The underlying infrastructure utilizes bare-metal hypervisors equipped with dual-socket Intel Xeon Platinum 8380 processors running Ubuntu 22.04 LTS (Linux Kernel 5.15). CPU frequency scaling was disabled to ensure consistent benchmarking. The network stack utilized 100 Gbps Mellanox ConnectX-6 NICs with standard TCP offload engines enabled. The modified TLS 1.3 stack was compiled using GCC 11.3 (-O3 optimization) and integrated OpenSSL version 3.0.8 with the liboqs (Open Quantum Safe) library version 0.7.2.

Figure 6 illustrates the architectural flow and the specific nodes where post-quantum telemetry was captured.

The TLS stack was modified using a custom fork of OpenSSL 3.0 integrated with the liboqs (Open Quantum Safe) library (Stebila and Mosca, 2019b). We evaluated the NIST-standardized Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM, specifically parameter sets 512, 768, and 1,024) and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA-44 and ML-DSA-65). These were benchmarked against a classical baseline utilizing ECDHE (secp256r1) and RSA-2048.

To capture a holistic view of cloud networking, traffic emulation was not limited to a single latency profile. We evaluated three distinct scenarios using the Linux tc-netem utility:

• Regional LAN (1 ms RTT, 0% loss) representing internal service-to-service API calls,
• Cross-region WAN (75 ms RTT, 0.1% loss) representing standard enterprise ingress, and
• Degraded mobile/edge (150 ms RTT, 1% packet loss).

All tests were executed over 100,000 iterations following a 5,000-connection warm-up phase to stabilize cache hits. We report not only the mean but the median (p50), 95th-percentile (p95), and standard deviation (σ) to accurately capture tail latencies and failure rates.

4.2 Latency emulations and TLS handshake overhead

In classical architectures, the cryptographic computation phase of a TLS 1.3 handshake is virtually negligible compared to network propagation delay. However, lattice-based cryptography shifts this paradigm. To quantify the user-facing impact, we measured the Time-to-First-Byte (TTFB) across 100,000 handshake iterations per cipher suite configuration, allowing for a 5,000-iteration warm-up period to stabilize cache dynamics. Rather than relying solely on mean averages, we tracked variance including median (p50), 95th-percentile (p95), and 99th-percentile (p99) latencies to capture network jitter and performance degradation under packet loss. Table 4 presents the cumulative handshake latency, statistical variance, failure rates, and the isolated cryptographic processing overhead at the Ingress Gateway across all three simulated network topologies. The implementation specifically tests a “Hybrid” mode, where ECDHE is combined with ML-KEM to comply with transitional security mandates (Bindel et al., 2019).

Table 4. Empirical TLS 1.3 handshake metrics across three network topologies (100,000 iterations per scenario).

The data in Table 4 indicates a non-linear scaling of latency that becomes severely pronounced under degraded network conditions. While the computational time increases by merely 2.3 to 3.7 milliseconds compared to the baseline, the tail latency (p99) under 1% packet loss inflates drastically—reaching 385.7 ms for the ML-KEM-1024/ML-DSA-87 combination. This discrepancy isolates the primary bottleneck of post-quantum data-in-transit: network payload inflation leading to TCP window exhaustion and packet fragmentation.

4.3 Packet fragmentation analysis at the network edge

The most critical operational challenge observed during our emulation was IP-layer fragmentation. Standard Ethernet networks utilize a Maximum Transmission Unit (MTU) of 1,500 bytes. In a classical TLS 1.3 handshake, the ServerHello, EncryptedExtensions, Certificate, and CertificateVerify messages comfortably fit within a single TCP segment.

Conversely, a post-quantum handshake utilizing ML-KEM-768 and an ML-DSA-65 certificate chain results in a server response exceeding 5,000 bytes. Because this payload surpasses the standard Maximum Segment Size (MSS) of 1,460 bytes, the TCP stack must split the data across multiple segments through TCP segmentation. If middleware appliances (e.g., legacy firewalls or deep packet inspection engines) mishandle segmented traffic or fail to support TCP Window Scaling (RFC 7323), the QaaS API gateway experiences catastrophic connection timeouts (Sikeridis et al., 2020). It is critical to distinguish this from IP fragmentation, which occurs only if the path MTU is exceeded; proper MSS clamping ensures the payload is handled sequentially at the transport layer.

Figure 7 delineates the failure domains introduced by large PQC payloads and the requisite packet reassembly mechanisms.

To mitigate fragmentation-induced latency and packet loss, we developed and deployed a dynamic Initial Window (IW) tuning and MSS negotiation algorithm on the QaaS edge load balancers. Standard TCP initializes the congestion window (cwnd) to 10 segments. For PQC handshakes, this often requires an additional Round-Trip Time (RTT) just to transmit the certificates.

Algorithm 4 outlines our implemented mitigation strategy, which dynamically scales the TCP window boundaries based on the negotiated cryptographic suite during the initial ClientHello phase.

Algorithm 4 Dynamic TCP window scaling for PQC payloads. Require: Incoming TCP SYN from Client, Gateway configured with MTU M_*edge*. Ensure: Optimized Transmission of PQC TLS Records without extraneous RTTs. 1: Phase 1: TCP Handshake & MSS Discovery 2: Intercept Client SYN packet. 3: Extract Client MSS (MSS_*client*) from TCP Options. 4: Set Negotiated MSS: MSS_*neg* = min(MSS_*client*, M_*edge*−40). 5: Complete TCP 3-way handshake. 6: Phase 2: TLS ClientHello Inspection 7: Parse ClientHellosupported_groups and signature_algorithms extensions. 8: if Client prefers ML-KEM AND ML-DSA then 9: Calculate estimated server payload size P_*server* (e.g., 5200 bytes for ML-KEM-768 + ML-DSA-65). 10: Calculate required segments: S_*req* = ⌈P_*server*/MSS_*neg*⌉ 11: if S_*req*>Current TCP Initial Window (IW) then 12: Dynamically adjust socket buffer: setsockopt(TCP_INIT_CWND, S_*req*+2). 13: Note: The +2 provides buffer for network headers and potential retransmissions. 14: end if 15: end if 16: Generate and transmit hybrid PQC ServerHello and Certificate chain. 17: Phase 3: Connection Integrity Monitoring 18: if TCP Duplicate ACKs detected (indicating middleware segmentation drop) then 19: Trigger strict downgrade prevention policy: DO NOT fallback to classical ECDHE. 20: Terminate connection (Fail-Closed) and log anomaly to the IAM Control Plane. 21: Initiate alternate routing path using secondary PQC parameters if tenant policy permits. 22: end if

To deploy this algorithm without modifying the core tenant application logic, we implemented Algorithm 4 via custom eBPF (Extended Berkeley Packet Filter) hooks at the Ingress Gateway, which allows dynamic overriding of the standard Linux kernel socket buffer limitations per connection.

The empirical validation of this approach demonstrated substantial improvements in tail latency. In our baseline Cross-Region WAN scenario utilizing the default Linux TCP IW of 10 segments, the p99 latency for an ML-KEM-768/ML-DSA-65 handshake was 123.1 ms due to the mandatory extra round-trip required to transmit the certificate chain. After enforcing dynamic IW scaling via eBPF, the payload was successfully transmitted within the initial flight, dropping the p99 latency to 105.6 ms. This represents a 14.2% reduction in tail latency, effectively neutralizing the RTT penalty caused by TCP slow-start mechanics struggling with large cryptographic assets.

4.4 Throughput and compute overhead metrics

Beyond network latency, the integration of PQC into QaaS infrastructure dictates a re-evaluation of compute resource allocation. Edge nodes and API gateways must maintain high connections-per-second (CPS) rates to handle concurrent tenant workloads (Paquin et al., 2020).

During our stress-testing phase, we bombarded the Ingress Gateway with varying rates of concurrent TLS handshakes to determine the maximum throughput before CPU exhaustion. Table 5 contrasts the processing capacity of the testbed under classical and post-quantum loads.

Table 5. Gateway throughput and compute saturation metrics (100,000 concurrent sessions).

The empirical data demonstrates a 33.6% degradation in maximum connections per second when transitioning from classical elliptic curve cryptography to ML-KEM-768. Furthermore, the memory footprint scales aggressively. Because ML-KEM relies on polynomial matrix multiplications over polynomial rings, the algorithms demand significantly larger data structures to be held in active memory during the encapsulation and decapsulation phases. This results in a marked increase in the L3 Cache Miss Rate (from 4.2% to 11.5%), as the processor is forced to frequently fetch the large public key matrices from main memory.

For cloud providers, these metrics dictate that deploying a quantum-safe infrastructure is not merely a software patch; it requires a physical provisioning upgrade. QaaS load balancers will require approximately 1.5x the CPU cores and 3x the active RAM to maintain the identical throughput profiles they currently achieve with classical algorithms. Offloading these lattice-based operations to specialized hardware accelerators (e.g., FPGA-based SmartNICs) will be a mandatory evolution in cloud data center design to preserve compute resources for actual quantum workload compilation.

4.5 Limitations of the empirical study

While the empirical results demonstrate the localized network impact of PQC integration, this study operates under several acknowledged boundaries. First, the latency emulations assume TLS over TCP; the performance dynamics of QUIC-based transport (HTTP/3), which inherently mitigates some TCP head-of-line blocking, were not evaluated. Second, the testbed utilized self-signed composite certificate chains; production environments utilizing full Web PKI hierarchies may experience further payload bloat. Finally, the QaaS-specific vulnerabilities discussed in Section 2 were simulated strictly at the classical hypervisor boundary; validation against active cross-talk on physical, multi-tenant QPU hardware remains a critical area for future research.

5 Strategic transition roadmap and conclusion

The timeline for the cryptographic apocalypse, colloquially termed Q-Day, remains a highly debated moving target among physicists. However, the operational mandate for cloud service providers (CSPs) is already fixed. As demonstrated throughout this paper, the convergence of Quantum-as-a-Service (QaaS) democratization and the immediate threat of “Harvest Now, Decrypt Later” (HNDL) data exfiltration leaves no room for latency in strategic planning (Cybersecurity Infrastructure Security Agency, 2022). Adopting the PQA-4 framework is not merely an exercise in compliance; it is an existential requirement for preserving the foundational trust model of cloud computing.

Transitioning a globally distributed cloud infrastructure from classical to post-quantum cryptography (PQC) without causing catastrophic downtime is an engineering challenge on par with the original deployment of the internet backbone. To navigate this, we present a structured transition roadmap and a consolidated set of strategic recommendations.

5.1 The three-phase migration blueprint

Migrating to a quantum-safe posture cannot be achieved via a single software patch. It requires a deliberate, phased rollout that accounts for legacy system compatibility, hardware procurement cycles, and evolving standardization bodies. We propose a Three-Phase Migration Blueprint, illustrated in Figure 8.

Phase I focuses entirely on visibility. Because modern microservices heavily utilize hardcoded cryptographic libraries, a blind deployment of PQC will fracture internal API routing. Phase II introduces the hybrid algorithms detailed in the PQA-4 framework, wrapping legacy traffic in quantum-safe tunnels at the network perimeter while leaving internal legacy systems temporarily intact.

Phase III

• Deprecate pure classical endpoints.
• Enforce pure ML-KEM intra-cloud.
• Pilot optional MDI-QKD overlays on highly-classified, sub-200 km Data Center Interconnect (DCI) fiber links.
• SLA guarantees for Quantum Safety.

5.2 Cryptographic asset discovery

The most pervasive bottleneck encountered by early PQC adopters is the inability to locate where legacy cryptography is actively executing within their environments. Cloud providers must automate the discovery of asymmetric keys, hardcoded protocol versions, and outdated Hardware Security Modules (HSMs) (Campagna and Ott, 2020).

Algorithm 5 outlines a procedural logic flow for a continuous cryptographic discovery daemon that QaaS providers should integrate directly into their hypervisor or service mesh.

Algorithm 5 Continuous cryptographic asset discovery & risk scoring. Require: Cloud telemetry stream, API Gateway Logs, internal DNS queries. Ensure: A real-time matrix of HNDL vulnerabilities across tenant workloads. 1: while QaaS Infrastructure is active do 2: Intercept connection initialization (e.g., TLS ClientHello). 3: Extract CipherSuite and TLS_Version. 4: if TLS_Version < 1.3 or CipherSuite relies solely on RSA/ECC then 5: Flag connection as CLASSICAL. 6: Inspect payload metadata (via deep packet inspection, if unencrypted internally). 7: if Payload contains long-term IP, PII, or credentials then 8: Assign Risk Score: R_*HNDL* = CRITICAL 9: Alert Orchestration Plane to dynamically inject a Hybrid PQC Sidecar Proxy. 10: else 11: Assign Risk Score: R_*HNDL* = MODERATE 12: Log asset for Phase II deprecation schedule. 13: end if 14: else if CipherSuite utilizes approved Hybrid PQC (e.g., X25519 + ML-KEM) then 15: Flag connection as QUANTUM-SAFE. 16: Update Tenant Compliance Dashboard. 17: end if 18: end while

By utilizing automated discovery algorithms like Algorithm 5, cloud architects can prioritize their migration efforts, focusing immediately on API routes that handle high-value data susceptible to immediate interception.

5.3 Strategic recommendations for QaaS providers

Drawing upon the empirical performance data and threat modeling analyzed in the preceding sections, we provide a consolidated set of strategic mandates for cloud providers operating QaaS platforms. Table 6 summarizes these directives across hardware, software, and policy domains.

Table 6. Core strategic recommendations for post-quantum QaaS integration.

The recommendations in Table 6 highlight that achieving quantum resilience is a cross-disciplinary effort. It is not sufficient to merely update cryptographic libraries; the underlying network physics (TCP windows) and compute infrastructure (SmartNICs) must be co-optimized to handle the unique profiles of lattice algorithms.

5.4 Final remarks

The advent of Quantum-as-a-Service represents one of the most profound technological leaps of the 21st century, promising breakthroughs in fields ranging from molecular dynamics to financial modeling. However, this same technology presents a critical vulnerability to the current cryptographic protocols that secure the digital economy.

Cloud environments, characterized by dense multi-tenancy and continuous data transmission, are the ground zero for this cryptographic paradigm shift. The implementation of the PQA-4 framework—integrating Hybrid TLS 1.3, MDI-QKD backbones, composite identity management, and an agile orchestration plane—provides a comprehensive blueprint for survival. By executing the structured roadmap outlined in this section, cloud service providers can proactively dismantle the “Harvest Now, Decrypt Later” threat vector, ensuring that the cloud remains a bastion of data security well into the post-quantum era.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher's note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Shahzad Ashraf, Gachon University, Republic of Korea

Reviewed by: Ankit Gupta, University of North Texas, United States

Shilpi Mittal, University of North Texas, United States