Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Highlights Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration Iván Melijosa, Javier Pérez, Borja Nogales, Iván Vidal, Francisco Valera • Cloud-native orchestration automating the scalable deployment of hybrid quantum-safe network emulation. • Native support for hybrid QKD-PQC networking through standardized ETSI interfaces.

arXiv:2609.35358v1 [cs.NI] 28 Sep 2026

• Automated provisioning of virtual infrastructure across cloud virtual machines and Kubernetes clusters. • HashiCorp Vault ensures persistent, access-controlled storage of cryptographic material.

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration Iván Melijosaa,∗ , Javier Péreza , Borja Nogalesa , Iván Vidala and Francisco Valeraa a Universidad Carlos III de Madrid, Av. de la Universidad, 30, Leganés, 28911, Madrid, Spain

ARTICLE INFO

ABSTRACT

Keywords: Quantum Key Distribution; Post-Quantum Cryptography; Hybrid QKD-PQC Networks; Quantum-Safe Network Emulation; Cloud-Native Orchestration.

The ongoing transition toward quantum-safe networking has motivated the development of hybrid network architectures integrating Quantum Key Distribution (QKD) and Post-Quantum Cryptography (PQC). However, the experimental evaluation of hybrid QKD-PQC network architectures remains constrained by the high cost and limited accessibility of quantum hardware, as well as by the limited support for hybrid QKD-PQC networks in existing emulation platforms. Quditto is an open-source emulation platform originally designed for QKD networks that enables cost-effective and reproducible experimentation without requiring dedicated physical quantum infrastructure. Building on this foundation, this work presents Quditto as a hybrid QKD-PQC network emulation platform featuring automated and scalable cloud-native orchestration. The proposed platform introduces four principal contributions: a cloud-native orchestrator enabling fully automated infrastructure deployment across cloud and multi-cluster environments; an optimized provisioning workflow enabling large-scale quantum-safe network emulation; native integration of post-quantum nodes enabling unified emulation of hybrid QKD-PQC networks; and a secure key management module providing persistent and access-controlled storage of cryptographic material. Experimental validation demonstrates sublinear orchestration-time scaling with network size and successful end-to-end hybrid QKD-PQC key establishment on a representative spine-leaf deployment, thereby enabling the systematic evaluation of quantumsafe networking mechanisms in large-scale heterogeneous network environments.

1. Introduction The emergence of quantum computing represents a paradigm shift in cryptographic security, introducing unprecedented computational capabilities that challenge the foundations of existing information protection systems. In this context, quantum cryptography emerged from the pioneering work of Stephen Wiesner (Wiesner, 1983) and gained prominence with the introduction of the BB84 protocol (Bennett and Brassard, 1984), the first formally proposed Quantum Key Distribution (QKD) protocol. QKD leverages the principles of quantum mechanics to enable information-theoretically secure key distribution, ensuring that any eavesdropping attempt on the quantum channel inevitably introduces detectable disturbances (Shor and Preskill, 2000). In contrast to classical cryptography, whose security relies on computational hardness assumptions, QKD derives its security guarantees from the laws of physics, rendering it inherently resilient to advances in both classical and quantum computing. Paradoxically, the quantum mechanical principles that enable unconditionally secure key distribution also threaten the security of conventional cryptographic systems. Shor’s algorithm demonstrated that sufficiently powerful quantum computers could efficiently break widely deployed public-key cryptosystems, including RSA and Elliptic-Curve Cryptography (ECC) (Shor, 1994). Moreover, physical QKD devices remain difficult to integrate into existing communication infrastructures and are prohibitively expensive, restricting access to quantum-secured communications to a limited number of actors (Pirandola et al., 2020). These considerations have catalyzed the development of Post-Quantum Cryptography (PQC) (Bernstein et al., 2009), a field dedicated to designing cryptographic primitives resistant to classical and quantum attacks while maintaining compatibility with existing network infrastructures. The complementary properties of QKD and PQC have motivated research into hybrid QKD-PQC cryptographic architectures, which combine the information-theoretic security guarantees of QKD with the deployment flexibility ∗ Corresponding author

[email protected] (I. Melijosa); [email protected] (J. Pérez); [email protected] (B. Nogales); [email protected] (I. Vidal); [email protected] (F. Valera) ORCID (s): 0009-0007-2413-7529 (I. Melijosa); 0009-0008-3531-7696 (J. Pérez); 0000-0002-5508-5414 (B. Nogales); 0000-0001-7381-971X (I. Vidal); 0000-0001-5056-0573 (F. Valera)

: Preprint submitted to Elsevier

Page 1 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

of PQC to achieve quantum-safe communication across heterogeneous networks in which only a subset of network nodes is equipped with QKD capabilities. In this technological context, the deployment of quantum cryptographic networks remains largely inaccessible to most researchers, limiting opportunities for cost-effective and reproducible large-scale experimentation. To address these challenges, Quditto (López et al., 2025) was introduced as a Quantum Key Distribution Network (QKDN) emulation platform providing an accessible and controlled environment for studying QKD deployments without requiring dedicated physical quantum infrastructure. The platform can integrate high-fidelity simulation engines capable of reproducing the behavior of quantum devices, enabling experimentation under realistic operating conditions. In addition, Quditto supports the seamless integration and interoperation of real-world deployments and emulated network environments within a unified experimental infrastructure distributed across heterogeneous physical and virtual computing systems (Díaz-Bricio et al., 2025). However, the original Quditto platform did not support the emulation of hybrid QKD-PQC network architectures, hindering the experimental evaluation of emerging quantum-safe networking solutions. Moreover, the original design assumed the availability of pre-existing, network-accessible devices and required manual infrastructure provisioning, preventing the platform from leveraging modern cloud-native technologies (Deng et al., 2024), which enable the automated deployment, configuration, scaling, and management of containerized applications across distributed computing infrastructures through declarative orchestration frameworks, thereby providing lightweight, portable execution environments and distributed resource management. Furthermore, the original deployment workflow relied on sequential runtime software provisioning and node initialization, introducing orchestration bottlenecks that constrained the practical scalability of the emulation environment. Building upon these aspects, the present work presents Quditto as a hybrid-capable, autonomous, and scalable emulation platform with the following contributions: • Native integration of post-quantum nodes implementing IKEv2-based key establishment with ML-KEM and ML-DSA algorithms, enabling unified emulation of hybrid QKD-PQC network topologies. • A cloud-native orchestrator enabling the fully automated deployment of the underlying virtual infrastructure across cloud-hosted virtual machines and multi-cluster Kubernetes environments. • A performance-optimized deployment workflow based on prebuilt container images and parallelized provisioning and initialization operations, enabling the deployment of large-scale emulated quantum-safe networks comprising up to 200 nodes in approximately 6 minutes. • A secure cryptographic material management module providing persistent, access-controlled storage based on the secrets management service HashiCorp Vault (HashiCorp, 2025). The proposed platform enables the research community to systematically evaluate quantum-safe cryptographic mechanisms in hybrid QKD-PQC network environments at scale and under realistic, reproducible deployment conditions, helping bridge the gap between theoretical architectural design and experimental validation. Concretely, the platform enables experiments including the evaluation of QKD protocols under configurable channel conditions and eavesdropping models, compliance testing of key management interfaces against standardized API specifications, functional validation of hybrid QKD-PQC key establishment workflows across heterogeneous node configurations, and performance benchmarking of quantum-safe cryptographic mechanisms under controlled network load. These experiments can be conducted on large-scale emulated quantum-safe networks deployable on standard virtual infrastructure within practical deployment times, without requiring dedicated quantum hardware or physical testbeds. The present work is structured as follows. Section 2 reviews three research areas: hybrid QKD-PQC network architectures, existing emulation platforms, and orchestration frameworks. Sections 3 and 4 describe the design and implementation of Quditto. Section 5 presents the experimental evaluation of the platform, covering orchestration performance and functional validation. Finally, Section 6 concludes the paper and outlines future research directions.

2. State of the Art This section reviews the state of the art across three areas: hybrid QKD-PQC network architectures, quantum-safe network emulation platforms, and orchestration frameworks for automated and scalable deployment. The limitations identified in the reviewed literature motivate the design objectives of the emulation platform presented in this work.

: Preprint submitted to Elsevier

Page 2 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 1: Hybrid QKD-PQC network architecture.

2.1. Hybrid QKD-PQC Network Architectures Hybrid network architectures integrating QKD and PQC have been proposed to address the inherent limitations of each technology when considered in isolation (Campagna et al., 2015). QKD offers information-theoretic security guarantees; however, its practical deployment faces significant scalability challenges and typically requires dedicated optical infrastructure (Mehic et al., 2020). In contrast, PQC supports large-scale deployment over existing communication networks, although its security relies on the assumed computational hardness of specific mathematical problems rather than physical principles, rendering it potentially vulnerable to future algorithmic advances (Bernstein and Lange, 2017). The complementary security and deployment properties of QKD and PQC have motivated the development of hybrid QKD-PQC network architectures that integrate both technologies to achieve quantum-safe communication while preserving deployment flexibility. As illustrated in Fig. 1, these architectures typically comprise multiple QKDN segments integrated within a broader classical communication infrastructure and interconnected through PQC nodes. QKD is generally reserved for high-value core network segments requiring unconditional security guarantees and relying on trusted relay nodes, which decrypt and re-encrypt cryptographic keys at each hop and therefore must operate within physically secure environments, whereas PQC nodes extend quantum-safe cryptographic protection across intersegment connections and toward heterogeneous edge devices over existing communication infrastructure (Spooren et al., 2026; Comin, 2025), particularly where QKD deployment is either unavailable or economically impractical. The importance of hybrid QKD-PQC cryptographic architectures has been further reinforced by recent standardization progress. The National Institute of Standards and Technology (NIST) published its first PQC standards, FIPS 203 and FIPS 204, defining the Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) (National Institute of Standards and Technology, 2024b) and the Module-Lattice-Based Digital Signature Algorithm (MLDSA) (National Institute of Standards and Technology, 2024a) as the primary mechanisms for post-quantum key establishment and digital signature, respectively. In parallel, regulatory bodies have established migration roadmaps to guide the transition to PQC to ensure long-term cryptographic security (European Commission, 2025), catalyzing coordinated efforts to incorporate post-quantum cryptographic mechanisms into existing communication protocols. In this context, the Internet Engineering Task Force (IETF) has proposed extensions to the Internet Key Exchange version 2 (IKEv2) protocol (Harkins and Carrel, 2014) supporting hybrid and multiple key-establishment mechanisms (Kivinen et al., 2023), while additional post-quantum extensions remain under active development within IETF working groups (Internet Engineering Task Force (IETF), 2023). The European Telecommunications Standards Institute (ETSI) has standardized architectural frameworks for QKDNs through specifications such as ETSI GS QKD 004 (European : Preprint submitted to Elsevier

Page 3 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Telecommunications Standards Institute, 2020), which defines the internal interface between a Key Management Entity (KME) and its associated QKD module, and ETSI GS QKD 014 (European Telecommunications Standards Institute, 2019), which specifies the application-facing REST interface through which Secure Application Entities (SAEs) request key material. Within this architecture, KMEs coordinate and distribute quantum-generated key material, while SAEs consume these keys at the application layer. Furthermore, ETSI has published specifications addressing the integration of hybrid quantum-safe key establishment mechanisms within quantum-safe communication infrastructures (ETSI TC CYBER QSC, 2025, 2024), enabling recent research on adaptive hybrid frameworks for heterogeneous QKD-PQC environments (Sanz et al., 2025). Despite these advances, several challenges remain unresolved. At the architectural level, the reliance on trusted relay nodes, stemming from the limited transmission range of current QKD systems and the absence of practical quantum repeaters, and the complexity of managing unified keying material across heterogeneous network segments represent only some of the major engineering challenges facing hybrid quantum-safe networks. More critically, the surveyed proposals above predominantly address architectural design and limited-scope proof-of-concept validation, leaving open the challenge of systematic experimental evaluation of hybrid QKD-PQC networks at scale. In practice, validation is typically performed through small-scale physical testbeds, which are costly, difficult to reproduce, and largely inaccessible to the broader research community. This highlights the need for dedicated emulation infrastructures capable of reproducing hybrid QKD-PQC network behavior under realistic operating conditions.

2.2. Emulation Platforms for Quantum-Safe Networks The high cost and complexity of deploying physical QKD infrastructure have motivated the development of a broad range of simulation and emulation tools for QKDNs, operating at different levels of abstraction. While simulation approaches rely on abstract models to study network behavior, emulation approaches execute network components in controlled environments that reproduce real deployment conditions more closely. At the device level, NetSquid (NetSquid Developers, 2026) provides a discrete-event simulation engine capable of modeling individual quantum hardware components with high physical fidelity, including realistic noise and decoherence effects. While this level of detail makes NetSquid well-suited for prototyping new QKD protocols and studying device behavior under realistic physical conditions, its scope remains limited to individual device interactions and channel physics, and it does not natively support distributed network topologies or standardized key-delivery interfaces. At the network layer, platforms such as SimQN (Chen et al., 2023), SeQUeNCe (Wu et al., 2021), and QuNetSim (Diadamo et al., 2021) abstract away low-level quantum dynamics to enable the study of routing strategies, key management policies, and protocol behavior at scale. Similarly, QKDNetSim (Mehic et al., 2017) and its enhanced successor QKDNetSim+ (Blanco-Romero et al., 2024) extend the widely used NS-3 network simulator (Henderson et al., 2008) with a dedicated QKD module implementing ETSI-compliant key management functionality, enabling network-level experiments with configurable QKD topologies. More recently, work by Mehic et al. (Mehic et al., 2025) has pushed this line of research toward emulation, presenting an extended QKDNetSim-based ecosystem for the virtual deployment of a national QKDN, bridging the gap between simulation and real-world operation. Collectively, these platforms offer complementary perspectives on QKDN behavior, yet all are fundamentally limited for many different reasons: none of them provide mechanisms for modeling post-quantum cryptographic components or the interactions that arise in hybrid QKD-PQC network configurations; none are capable of creating distributed nodes on a real network, only working with local operations; and more importantly, they are not capable of working collectively with real quantum or post-quantum hardware. On the post-quantum side, simulation efforts have focused primarily on protocol-level evaluation and performance benchmarking of PQC algorithms in isolated settings rather than on the emulation of distributed PQC network infrastructures (Marchiori et al., 2025). Physical testbeds such as the Berlin OpenQKD deployment (Geitz et al., 2023) have demonstrated the feasibility of integrating QKD hardware with PQC-based key management systems in real-world environments. However, these deployments are costly, difficult to reproduce, and inherently limited in scale, making them unsuitable as general-purpose experimental platforms for the systematic evaluation of hybrid QKD-PQC network behavior. Consequently, none of the existing simulation, emulation, or physical testbed approaches natively support the integration of post-quantum components with real quantum hardware at scale, preventing researchers from conducting controlled and reproducible experimentation on hybrid network behavior. Collectively, these limitations constitute the primary gap addressed by this work: the absence of a scalable emulation platform for the systematic evaluation of architectural designs, key management strategies, and protocol interactions in hybrid QKD-PQC network environments. : Preprint submitted to Elsevier

Page 4 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

2.3. Orchestration Frameworks for Emulation Platforms Network deployment automation has evolved substantially with the widespread adoption of containerization technologies and Infrastructure as Code practices. By packaging applications together with their software dependencies into lightweight, portable execution environments, containerization has simplified the deployment of distributed systems across heterogeneous computing infrastructures. As deployments increased in complexity and scale, container orchestration platforms, particularly Kubernetes (The Kubernetes Authors, 2025b), have become the default standard for automating the deployment and management of containerized applications, providing native support for automated scaling, declarative configuration whereby application requirements are expressed as target system states rather than procedural instructions, and resource management across heterogeneous compute environments. Complementary infrastructure provisioning tools, such as Terraform (HashiCorp, 2026), address the provisioning layer of the deployment lifecycle by enabling the reproducible creation of virtual infrastructure across cloud environments through Virtual Infrastructure Managers (VIMs) such as OpenStack (OpenInfra Foundation, 2026). Configuration management and software deployment can subsequently be automated using dedicated tools, such as Ansible (Ansible Community, 2026), which automates software installation and service initialization across target nodes, or through Kubernetesnative mechanisms. Together, these technologies have established a well-integrated automation stack that supports reproducible infrastructure deployment across diverse research and production environments. Extensions to this automation stack have emerged to address specific requirements in heterogeneous deployments. KubeVirt (KubeVirt Project, 2026) bridges the boundary between virtualization and containerization by allowing virtual machines, which emulate complete operating systems, to coexist and be managed alongside lightweight containerized applications within the same Kubernetes cluster. Both execution environments are orchestrated through the Kubernetes control plane, the centralized management component responsible for scheduling and coordinating workloads across the cluster, thereby providing a unified orchestration interface for mixed infrastructure environments. Similarly, cross-cluster networking solutions such as Submariner (The Submariner Project Authors, 2026) extend Kubernetes networking across independent cluster boundaries, enabling direct pod-to-pod communication by providing pod-level IP reachability and service discovery across multi-cluster deployments. Despite this breadth of tooling, existing orchestration frameworks exhibit critical limitations when applied to the specific requirements of quantum-safe network experimentation. Although solutions such as KubeVirt provide unified orchestration for virtual machines and containerized applications, they lack declarative mechanisms for describing heterogeneous network topologies spanning both execution environments within a single deployment configuration. Furthermore, as evidenced by the platforms surveyed in Section 2.2, no existing framework provides integrated support for quantum channel simulation combined with post-quantum cryptographic protocol deployment within a unified experimental environment. Consequently, these gaps collectively constrain the ability to systematically design, deploy, and evaluate quantum-safe network architectures across heterogeneous infrastructure configurations without requiring access to dedicated quantum hardware or specialized infrastructure expertise, while nonetheless allowing the creation of mixed virtual-physical testbeds whenever such resources are available.

3. Design Building upon the foundational principles of the original platform, Quditto preserves its core design objectives: distributed emulation capabilities, adherence to standardized key-delivery interfaces, flexibility to support realistic modeling of quantum networks across heterogeneous technologies and protocols, and accessibility to users regardless of programming background. Beyond these inherited principles, the proposed platform introduces two additional capabilities to address the aspects identified in Section 2. First, it provides native support for the definition and operation of hybrid network configurations integrating QKD and PQC components. Second, it enables the automated and scalable deployment of the underlying virtual infrastructure on which network emulation environments are dynamically instantiated to reproduce diverse hybrid network scenarios. These capabilities remain largely absent from existing emulation platforms, which typically neither support the specification and execution of hybrid QKD-PQC network topologies nor provide automated mechanisms for provisioning and managing the virtual computing resources required for large-scale network emulation. Collectively, they establish a unified, scalable, and reproducible platform for emulating hybrid quantum-safe networks under realistic deployment conditions. The proposed Quditto platform is organized into four hierarchical layers coordinated by the orchestrator, as illustrated in Fig. 2. The orchestrator operates as a cross-cutting management plane that coordinates provisioning and deployment operations across all architectural layers from a user-provided configuration. The first layer comprises the : Preprint submitted to Elsevier

Page 5 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 2: Quditto architectural design.

underlying physical infrastructure, including the physical machines and network equipment over which the platform is deployed and to which the orchestrator maintains connectivity. The second layer corresponds to the underlying virtual infrastructure, where virtual machines and containerized environments are provisioned and managed by the orchestrator on top of the underlying physical infrastructure. The third layer encompasses the quantum and postquantum modules, comprising Quditto nodes supporting QKD or PQC functionality and the Quditto modeling engine, all instantiated as independent virtualized components within the underlying virtual infrastructure. Each node exposes a standardized key-delivery interface and incorporates a secure key management component for the protected storage of cryptographic material, whereas the modeling engine comprises a modeling core and a message-queue handler for quantum channel simulation. Finally, the fourth layer represents the hybrid emulated network, an abstract topology of interconnected sites defining the logical network structure over which quantum-safe cryptographic operations are performed. The platform additionally supports transparent integration with physical QKD devices through a dedicated interface, bridging emulated and real-world quantum network deployments and enabling progressive migration toward physical quantum infrastructure. The following subsections provide a detailed description of each architectural layer of the platform.

3.1. Quditto Orchestrator The Quditto orchestrator supports the automated deployment of both the underlying virtual infrastructure and the network emulation environment directly from a user-provided declarative configuration, without requiring pre-existing virtual resources. In this context, the underlying virtual infrastructure comprises the virtual computing, storage, and networking resources required to host and execute Quditto, instantiated as virtual machines in cloud environments or as container-based clusters in cloud-native deployments. On top of this infrastructure, the network emulation environment comprises the virtual network components representing the communication elements of the emulated network. : Preprint submitted to Elsevier

Page 6 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

At the architectural level, the orchestrator enforces a clear separation between infrastructure provisioning and network emulation orchestration, while enabling their unified management through a common interface. Once the virtual infrastructure has been provisioned, the orchestrator instantiates the distributed Quditto platform, creating the network emulation environment corresponding to the user-defined network topology. This two-stage deployment process, comprising infrastructure and emulation environment instantiation, results in a fully operational distributed network deployment. Beyond the initial specification of the infrastructure configuration and the target network topology, the orchestration workflow requires no further manual intervention. The orchestrator supports both fully automated end-to-end deployment and integration with user-managed infrastructure, allowing flexible operation across diverse execution environments while ensuring the accessibility and reproducibility of experimental results. To support large-scale network emulation, the orchestrator is designed to operate across multi-cluster environments, enabling distributed resource provisioning and management, as discussed in Section 3.2.

3.2. Underlying Infrastructure The underlying infrastructure supporting Quditto comprises two layers: a physical infrastructure and a virtual infrastructure built on top of it to host the platform components. The physical infrastructure constitutes the pre-existing physical substrate on which the platform is deployed and comprises computing and networking resources, including servers, networking equipment, and the connectivity required by the orchestrator. On top of this layer, the orchestrator instantiates and manages the underlying virtual infrastructure, which abstracts the available computing resources into virtualized deployment environments suitable for network emulation. The platform supports three deployment configurations within this virtual infrastructure: a virtual machine-based environment, where the platform is deployed across multiple virtual machines; a heterogeneous environment combining virtual machines with a container-based cluster; and a distributed multi-cluster container environment spanning multiple independent container clusters. This abstraction enables the same orchestration workflow to operate across different infrastructure configurations while providing a common execution environment for the upper architectural layers. To overcome the scalability limitations observed in the original platform, Quditto supports container-based cluster orchestration as a deployment configuration for large-scale network emulation environments. The original platform relied on a virtual machine-based infrastructure, which limited efficient deployment due to the resource overhead associated with provisioning and managing independent virtual machine instances. Containerization provides several advantages over traditional virtual machine-based deployments in the context of large-scale network emulation. First, containers have a significantly reduced resource footprint, since they share the host operating system kernel rather than requiring dedicated operating system instances, enabling higher deployment densities and allowing a single physical host to support a larger number of virtual instances. Second, containers provide faster instantiation times of software components, typically on the order of seconds rather than minutes, thus reducing the latency associated with network deployment operations. Third, containerization improves environment portability across heterogeneous infrastructure by encapsulating software dependencies within standardized container images that can be deployed consistently across different host systems. Finally, container orchestration frameworks provide mechanisms for declarative configuration, automated deployment, scaling, and distributed resource management, thereby simplifying the provisioning and operation of large-scale emulation environments. Consequently, the adoption of container-based clusters establishes the architectural foundation for the scalability evaluation presented in Section 5, enabling Quditto to support large-scale hybrid QKD-PQC network emulation scenarios under realistic deployment conditions.

3.3. Network Emulation Environment The network emulation environment comprises the virtual components required to reproduce the communication elements of the emulated network, including Quditto nodes and the Quditto modeling engine. The Quditto nodes are digital representations of physical network devices responsible for handling cryptographic material requests from client applications and external entities, including KMEs and SAEs, through a standardized key-delivery API. The Quditto modeling engine is responsible for reproducing the behavior of quantum communication processes through highfidelity simulations of quantum channels and QKD protocols, comprising a message-broker handler for asynchronously managing simulation tasks and results, and a modeling core for executing the underlying quantum communication models. Each Quditto node operates either in QKD mode or in PQC mode, according to the cryptographic functionality it provides. Consequently, every node is associated with one of two distinct and logically separated cryptographic network planes, corresponding to QKD and PQC, respectively. In this context, a site denotes a logical location that : Preprint submitted to Elsevier

Page 7 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 3: Architectural node-based overview of the Quditto QKD-PQC hybrid network architecture.

hosts one QKD node, one PQC node, or both simultaneously, in which case it is referred to as a hybrid site, whereas a node refers to the individual cryptographic-plane component itself. Together, these planes define the logical topology of the hybrid emulated network comprising abstract QKD-only, PQC-only, and hybrid sites, as illustrated in Fig. 3. Prior to deployment, the topology of each plane is independently defined, providing flexibility in configuring node placement, interconnections, and link characteristics. Once deployed, each plane operates autonomously; however, both planes can be instantiated simultaneously to enable a hybrid key establishment environment that preserves strict logical separation between the two cryptographic mechanisms within the overall network architecture. This separation ensures that each key establishment mechanism operates independently while still supporting coordinated key distribution workflows when required. The Quditto QKD plane comprises a virtualized network of Quditto nodes capable of processing requests for quantum cryptographic key material. These nodes handle requests for the generation and storage of quantum cryptographic keys with neighboring nodes, as well as requests for the retrieval of previously generated keys, using unique key identifiers to ensure unambiguous association between the generated key material and the corresponding key generation session. Key material is generated by the Quditto modeling engine through high-fidelity simulation of QKD protocols and quantum channels, reproducing the statistical properties and operational behavior of real-world quantum communication systems, including channel error rates and key generation dynamics. The generated key material is then asynchronously delivered to the nodes through a message-broker-based communication interface. The Quditto PQC plane comprises distributed Quditto nodes emulating post-quantum network devices capable of establishing quantum-safe shared secrets through a pairwise, mutually authenticated key negotiation framework. Each key establishment session follows an initiator-responder model in which mutual authentication is achieved through a post-quantum digital signature scheme, assuming that the public key of each node is certified by a trusted Certificate Authority (CA), thereby establishing a PKI-based trust model. The key establishment mechanism is based on the IKEv2 protocol, conventionally used to negotiate Security Associations (SAs) and establish cryptographic keying material for IPsec communications. In the proposed architecture, IKEv2 is adapted as a standalone key establishment service, decoupling its cryptographic key derivation procedures from IPsec tunnel configuration and data-plane functions, and extended to incorporate post-quantum algorithms. As a result, IKEv2 operates as an ondemand mechanism for generating quantum-safe shared secrets while preserving its original security properties, including mutual authentication, key freshness, and resistance to replay attacks. IKEv2 was selected over alternative key establishment protocols, such as TLS 1.3 (Rescorla, 2018), because its peer-to-peer key establishment model closely : Preprint submitted to Elsevier

Page 8 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

matches the ETSI QKD architecture, where KMEs establish secure associations independently of application traffic. Furthermore, IKEv2 provides a mature and extensible framework for post-quantum integration through ongoing IETF standardization efforts, facilitating interoperability while preserving compatibility with existing security architectures. Upon successful key establishment, the initiator generates a random key identifier and transmits it to the responder, enabling both endpoints to unambiguously associate the derived keying material with a common reference identifier. This mechanism mirrors the identifier-based key management model of the QKD plane, in which both endpoints independently possess identical cryptographic material bound to a common identifier. By adopting a consistent identifier scheme across both planes, the system enables a unified key management model in which client applications retrieve key material through the same API, regardless of the underlying cryptographic mechanism. At runtime, client applications submit key requests to nodes in either plane via the standardized ETSI GS QKD 014 API. Each node internally routes the request to the appropriate cryptographic plane and handles it according to the configured key establishment mechanism. The platform natively supports multiple protocols and can be extended through custom implementations, enabling the integration of additional mechanisms while ensuring consistent handling across heterogeneous hybrid infrastructure. To provide persistent and secure management of cryptographic material, each Quditto node integrates a dedicated secure key management component responsible for its storage, protection, and retrieval. The original platform relied on in-memory storage for cryptographic material, which provided neither persistence across node restarts nor protection of key material at rest without mechanisms for access traceability. The proposed architecture addresses these limitations by introducing a secure key management layer that provides persistent, integrity-protected, and auditable management of cryptographic material throughout its entire lifecycle. The secure key management component supports the storage and retrieval of cryptographic keys generated by both the QKD and PQC planes. In addition to cryptographic key material, it stores the SA state associated with post-quantum key establishment sessions, enabling efficient stateful rekeying. All stored material is protected at rest and is accessible exclusively through authenticated interfaces subject to fine-grained access control policies, ensuring that access is restricted to authorized entities. This unified storage layer abstracts the differences between the two cryptographic planes, exposing a consistent retrieval interface to client applications regardless of the underlying key generation mechanism. By enforcing fine-grained access control at the node level, the proposed design reduces the attack surface of the platform while ensuring that cryptographic material remains accessible only to authorized entities through auditable and traceable operations. These properties establish secure key management as a core security component of the platform, enabling consistent and secure end-to-end management of cryptographic material across heterogeneous cryptographic planes.

4. Implementation Quditto is implemented as a Python-based open-source platform with dedicated packages for its three core components: the nodes, the modeling engine, and the orchestrator. The implementation details of these packages are described in the following subsections.

4.1. Quditto Node Package The Quditto node package implements two principal components: a quantum component for emulating quantum network nodes and a post-quantum component for emulating post-quantum network nodes. Additionally, each node runs a local HashiCorp Vault instance for the secure and unified management of cryptographic material across both QKD and PQC planes. The complete key establishment workflow, including Vault-based key storage and retrieval, is illustrated in Fig. 4. Upon a client-issued get_key request (1), the KME forwards an ETSI GS QKD 014 get_key request to the HTTP receptor of Quditto Node A, which triggers the Key Establishment Component (KEC) to initiate either a QKD- or PQCbased key establishment procedure with the peer node. The resulting cryptographic key and its associated identifier are securely stored in the local Vault instance at both endpoints before being returned to the client through the standardized interface. For subsequent get_key_with_ID requests (2), the HTTP receptor retrieves the corresponding key from the local Vault instance using the provided identifier. Both request types are accessible through multiple interfaces, including the standardized ETSI GS QKD 004 and 014, as well as proprietary interfaces. The quantum component emulates a QKDN node through two concurrent processes. The first process is responsible for communication with the Quditto modeling engine through a RabbitMQ-based (VMware Tanzu, 2026) message : Preprint submitted to Elsevier

Page 9 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 4: Key establishment sequence diagram for Quditto nodes, illustrating the interaction between the Key Establishment Component (KEC), which can correspond to either a QKD or PQC component, and the HTTP receptor responsible for processing key establishment requests from KMEs.

broker, which relays key generation requests and returns the resulting quantum cryptographic material. The second process hosts an HTTP server exposing the ETSI GS QKD 014-compliant API, enabling client applications to request cryptographic material using standardized primitives according to their role in the key establishment procedure: get_key for the initiating endpoint and get_key_with_ID for the responding endpoint, which retrieves the previously established key using its identifier. If a request containing a key identifier is received, the node searches for the corresponding entry in its local key store. If found, the associated key material is returned directly without interacting with the modeling engine. Keys are subject to a configurable time-to-live (TTL), with a default value of 10 minutes, consistent with the operation of commercial QKD devices. The post-quantum component emulates a post-quantum network node. Compared with the quantum component, the communication architecture is simplified. Since no interaction with the modeling engine is required, the RabbitMQbased message broker is omitted and replaced by a direct socket-based client-server communication model. As with the quantum component, the HTTP server exposing the ETSI GS QKD 014-compliant API handles requests for postquantum cryptographic material. In the post-quantum case, the key size parameter is not applicable, since ML-KEM produces fixed-length shared secrets. At the cryptographic level, post-quantum nodes implement key establishment using the IKEv2 protocol. IKEv2 packet construction and processing are implemented using the Scapy Python library (Scapy Project), which was selected for its flexibility in constructing, parsing, and extending protocol packets. Classical cryptographic operations, including ECC key generation, HKDF-based key derivation, hashing, and AES-GCM encryption, are implemented using the Python Cryptography library (Python Cryptographic Authority). Post-quantum cryptographic primitives are implemented using the reference implementations of ML-KEM (Pope, b) and ML-DSA (Pope, a), with minor modifications to ensure compliance with FIPS 203 and FIPS 204, respectively. Building on this cryptographic foundation, the protocol-level implementation extends the standard IKEv2 protocol within the unified request-driven model through post-quantum mechanisms based on two IETF Internet-Drafts. The first defines hybrid key exchange by combining classical Diffie-Hellman with ML-KEM (Fluhrer et al., 2024), while the second integrates ML-DSA into the IKEv2 authentication framework (Hoffman et al., 2024). The complete post-quantum key establishment sequence is illustrated in Fig. 5. The initial key establishment between client and server proceeds through three sequential phases. During IKE_SA_INIT, both parties perform an ephemeral Elliptic Curve Diffie-Hellman (ECDH) key exchange, deriving a shared secret used to generate the initial IKEv2 keying material. During IKE_INTERMEDIATE, ML-KEM key encapsulation is performed. The client provides its encapsulation key, and the server returns the resulting ciphertext. Both : Preprint submitted to Elsevier

Page 10 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 5: Post-quantum key establishment sequence diagram between Quditto PQC nodes.

parties then derive the corresponding shared secret and use it to update the IKEv2 keying material, thereby injecting the post-quantum contribution into the IKEv2 key derivation session. During IKE_AUTH, mutual authentication is performed using ML-DSA. Each party signs the session transcript with its private key and verifies the signature received from its peer, thereby authenticating both endpoints and completing the key establishment procedure. Upon completion, the SAs are established to maintain the session state across subsequent key establishment operations, and : Preprint submitted to Elsevier

Page 11 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

the final shared key is derived from the accumulated IKEv2 keying material. The client then generates a UUID, which is transmitted to the server to establish a shared key identifier for the resulting cryptographic material. For subsequent key refresh operations, a single CREATE_CHILD_SA exchange performs ML-KEM-based rekeying, deriving a new shared secret and identifier from the existing SA without repeating the full authentication procedure. HashiCorp Vault serves as a secure persistence layer for cryptographic material, rather than merely a key storage mechanism, and was selected for its encrypted persistent storage, fine-grained access control, and native auditing capabilities within a self-contained deployment model that is independent of the underlying infrastructure. Each node runs a dedicated Vault instance configured with file-based storage to ensure that cryptographic material persists across node restarts. The instance is bound exclusively to the local loopback interface, restricting access to processes running on the same node. Upon initialization, the Vault instance is configured with Shamir’s Secret Sharing (Shamir, 1979), using a threshold of three out of five key shares. To support autonomous node initialization, the resulting unseal keys and root token are persisted with restricted file system permissions, and the instance remains sealed until explicitly unsealed by the internal components of the node. Secrets are managed using the Key-Value version 2 engine, which maintains a version history for all stored secrets. As illustrated in Fig. 4, the key material and its associated identifier are stored in the local Vault instance immediately after each key establishment, indexed by the peer address, and subsequently retrieved in response to identifier-based client requests without requiring a new key establishment. For post-quantum nodes, Vault additionally stores the IKE SA information established during the initial IKEv2 handshake, preserving the negotiated session state required to support efficient rekeying during subsequent key exchange operations. Access to the stored cryptographic material and session state is restricted to the local cryptographic components and HTTP receptor of each node, ensuring that sensitive cryptographic assets remain protected at rest and are accessible only to the internal components of the node through local authenticated interfaces.

4.2. Quditto Modeling Engine Package The Quditto modeling engine is the core component responsible for simulating quantum-level behavior of cryptographic key exchange systems and executing key generation protocols with realistic temporal characteristics. It comprises two main functional components: a message-broker handler that manages communication with Quditto nodes via RabbitMQ, and a quantum-behavior modeling core built on top of the NetSquid quantum simulator. The engine operates as an asynchronous event-driven service, processing key generation requests for different QKD links in parallel while enforcing link-level serialization. This ensures that concurrent requests on different links proceed independently, improving overall throughput, yet maintains strict temporal ordering for multiple requests on the same link, accurately reflecting physical QKD system behavior where link resources cannot be simultaneously shared. Upon receiving a "modeling request" message through the RabbitMQ broker, the engine validates the request by verifying that both nodes exist in the network and are neighbors on the same QKD link. If valid, the request is forwarded to the modeling core for protocol execution. By default, the engine features two QKD protocol implementations based on the BB84 scheme: BB84 with Eve for eavesdropping scenarios, and Extended BB84 with user-configurable parameters to model realistic quantum hardware imperfections. Additional protocol implementations can be integrated as custom scripts based on NetSquid or any other quantum simulation platform, provided they produce cryptographic material and report realistic execution durations. When processing a key request, the modeling engine executes the protocol implementation script repeatedly until sufficient cryptographic material is collected. Critically, the engine itself tracks how many bits remain to satisfy each request, eliminating the need for individual protocol implementations to accept key-length parameters. This separation of concerns simplifies protocol integration and allows developers to adopt flexible key generation strategies, such as maintaining internal buffers or computing bits on demand. Once all required key material is gathered, the engine calculates and enforces the latency that would have been incurred by actual physical QKD hardware, based on protocol-specific parameters and link characteristics. The "modeling result" message, containing the generated key material and its unique identifier, is then published under the routing keys of both participating nodes after the calculated delay has elapsed. Throughout this process, the modeling engine continuously records detailed logs capturing protocol interactions, timing events, and Quantum Bit Error Rate metrics. These logs are made available to users for post-execution analysis and debugging, enabling in-depth inspection of protocol behavior, performance measurement, and anomaly detection. In the cloud-native deployment, the modeling engine is instantiated as an independent Kubernetes pod with NetSquid and RabbitMQ installed by the orchestrator during initialization. : Preprint submitted to Elsevier

Page 12 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

4.3. Quditto Orchestrator Package The Quditto orchestrator package is responsible for the end-to-end deployment and configuration of the platform, from the provisioning of the underlying virtual infrastructure across cloud-hosted virtual machine and cloudnative Kubernetes environments to the initialization of all services comprising the network emulation environment. Provisioning performance has been further improved through the parallelization of Ansible playbook execution, substantially reducing the overall network instantiation and initialization time. The following subsections describe the resource provisioning capabilities and the end-to-end deployment workflow of the platform.

4.3.1. Resource Provisioning and Execution Environment Preparation The orchestrator extends beyond the configuration of Quditto components on pre-existing resources. In addition to deploying Quditto on reachable physical or virtual machines, it provisions the virtual infrastructure required to host the platform in cloud-based environments. This functionality is built upon Terraform, an infrastructure-as-code tool used to define and provision virtual machines across different cloud platforms. The Terraform workflow is programmatically executed through a Python library using a declarative YAML-based description of the resources to be provisioned. This description specifies the required infrastructure parameters, including machine specifications, network interfaces, images, and access credentials, enabling automated virtual machine provisioning on cloud platforms such as OpenStack. The provisioned resources support two execution models. In the first model, components are configured and executed directly on physical or virtual machines, following the original machine-based deployment model of Quditto. In the second, the orchestrator introduces a cloud-native execution model in which components are deployed as containerized services on Kubernetes. To enable this execution model, the main Quditto components have been packaged as Kubernetes artifacts through dedicated Helm Charts (Helm Authors, 2026), which provide templated and versioned packages of Kubernetes resource definitions for the emulated node services and the modeling engine. These charts define the required Kubernetes resources and expose configurable parameters for component placement, service exposure, and container image selection. The container image parameter allows the orchestrator to instantiate components either from prebuilt images or from base images that are configured during the initialization of the network emulation environment. To support the cloud-native deployment model, the orchestrator package incorporates the capability to bootstrap Kubernetes clusters on physical or virtual machines through KubeOne (Kubermatic, 2025), a Kubernetes lifecycle management tool that automates cluster provisioning, upgrade, maintenance, and teardown while relying on kubeadm (The Kubernetes Authors, 2025a), the Kubernetes-native cluster bootstrapping utility, for the underlying cluster initialization and configuration. KubeOne operations are programmatically managed through Python-based logic, following the same integration approach used for Terraform-based virtual infrastructure provisioning. The package also includes functions to install the software dependencies required before cluster bootstrap, ensuring that this step is integrated into the orchestrated preparation of the execution environment rather than performed as a separate manual operation. Both the Kubernetes bootstrap process and the Quditto deployment follow a declarative YAML-based configuration approach. The cluster description provides the information required by KubeOne to bootstrap the cluster, including the machines comprising the cluster, their roles, and connectivity parameters. The Quditto deployment description specifies the components to be deployed, their placement, configuration parameters, and exposed services. The orchestrator maps this description to the corresponding Helm chart values and deploys the appropriate Helm charts on the target cluster. Additionally, the Quditto deployment description includes placement parameters that allow components to be assigned to different Kubernetes clusters, enabling multi-cluster emulation scenarios. This execution model assumes only the availability of network connectivity between pods and services deployed across clusters, without imposing any specific multi-cluster networking solution. To provide this connectivity when required, the orchestrator package can dynamically install and configure multi-cluster networking plugins as part of the Kubernetes deployment workflow. The corresponding configuration parameters are specified in the YAML-based cluster description and mapped to the corresponding Helm chart values of the selected networking plugin. For instance, Submariner can be used to provide transparent inter-cluster connectivity, allowing services running in different clusters to communicate without requiring modifications to the application-level logic of either the modeling engine or the emulated node services. 4.3.2. Deployment Workflow of the Quditto Network Emulation Environment Prior to the definition and instantiation of the emulated network, users may follow one of two workflows depending on the availability of existing infrastructure: either relying on pre-existing, user-managed machines with network : Preprint submitted to Elsevier

Page 13 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 6: Automated deployment workflow of the Quditto platform.

connectivity or delegating the provisioning of the virtual infrastructure and the network emulation environment to the orchestrator. In the latter case, to fully exploit the advantages of the automated deployment process, the orchestrator implements parallelization across all deployment stages. The provisioning of the underlying virtual infrastructure, the deployment of Quditto components as pods within Kubernetes clusters, and the subsequent dependency installation and service initialization procedures are all executed concurrently across the target nodes. Combined with the lightweight nature of containerized deployments, this parallelization strategy substantially reduces orchestration time and enables the platform to scale to networks comprising hundreds of nodes while maintaining acceptable deployment latency. The complete automated deployment workflow is illustrated in Fig. 6. Starting from a Python-capable client terminal, the Quditto orchestrator package is installed via PyPI (stage 1). The orchestrator then provisions the required virtual machines for cloud environments such as OpenStack according to the corresponding infrastructure YAML specification (stage 2). Once the virtual machines are available, the orchestrator bootstraps a Kubernetes cluster across them, configuring the control-plane and worker nodes according to the cluster specification YAML file (stage 3). The provisioning process is configured through three declarative YAML files. The vm-deployment file specifies the parameters required to provision virtual machines, including machine specifications, network interfaces, and access credentials. The k8s-deployment file defines the configuration required to bootstrap the Kubernetes cluster, including node roles, network parameters, and cluster connectivity settings. The qd2-deployment file specifies the parameters required to deploy Quditto pods within the cluster, including per-module Helm chart configuration and the Kubernetes NodePort services used to expose the ETSI GS QKD 014-compliant API port of each emulated network node on every cluster node, enabling external access to the key management interfaces. Notably, a virtual machine provisioned as part of the underlying virtual infrastructure may simultaneously host a Quditto network node within the network emulation environment. Once the cluster is operational, Quditto pods are deployed within it (stage 4.1), including QKD nodes, PQC nodes, and the modeling engine, each instantiated as an independent Kubernetes pod forming part of the network emulation environment. Pod readiness is verified iteratively (stage 4.2). Once all pods are ready, their IP addresses are retrieved and injected into the configuration YAML file. Quditto supports two deployment strategies for pod instantiation. The recommended approach uses prebuilt Docker images, one for each Quditto component, available in the associated Docker Hub repository with all required dependencies preinstalled. Alternatively, when such images are unavailable, an automated dependency installation pipeline prepares the execution environment at deployment time, resulting in

: Preprint submitted to Elsevier

Page 14 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

a fully operational system while preserving the same functional behavior under standard operating conditions. The deployment strategy is selected through the version field of the Helm chart entries in the qd2-deployment file. Once the deployment strategy has been selected, the user defines the network to be emulated following the original Quditto approach. The structure of the inventory file remains unchanged, providing the credentials used by Ansible to connect to the devices comprising the network emulation environment. The configuration file describing the network topology supports two types of nodes: quantum nodes, characterized by link lengths and the potential presence of eavesdroppers, and post-quantum nodes, defined by parameters such as the security level of the post-quantum digital signature algorithm. During the emulated network initialization (stage 5), the orchestrator executes three substages via Ansible across all pods. When prebuilt Docker images are unavailable, the dependency installation pipeline is executed first (stage 5.1). The required Python dependencies are installed across all pods. Additionally, the HashiCorp Vault client libraries are installed on node pods, whereas NetSquid and RabbitMQ are installed on the modeling engine pod. Once all dependencies have been installed, the orchestrator distributes the required Python scripts to each component (stage 5.2). These scripts implement the quantum or post-quantum key establishment logic according to the specified topology, together with an HTTP receptor for processing client requests and a Vault server instance for secure key management. Finally, the orchestrator starts all required services (stage 5.3), rendering the distributed system fully operational according to the user-provided network configuration. Once initialized, the emulated network enables clients to submit on-demand requests for quantum-safe cryptographic material through the ETSI GS QKD 014 specification.

5. Validation To validate the capabilities of the proposed platform, this section presents a comprehensive evaluation structured along two complementary dimensions: orchestration performance and functional correctness. The evaluation of orchestration performance is motivated by the scalability constraints identified in the original Quditto platform. In particular, as the size and complexity of the emulated networks increased, the time required to instantiate and configure the network components became a significant bottleneck, hindering the scalability of the platform for large-scale deployments. These limitations motivated the proposed orchestrator to reduce deployment overhead and enable the efficient management of larger hybrid network scenarios. Therefore, this evaluation focuses on characterizing the efficiency and scalability of the automated deployment workflow across networks of varying sizes, assessing its performance in terms of deployment time and underlying computational infrastructure characteristics. The functional dimension assesses the ability of the platform to faithfully emulate the behavior of realistic hybrid quantum networks across diverse configurations and scenarios. All experiments were conducted on virtual machines hosted at the NEXTONIC laboratory (NEXTONIC), ensuring a controlled and reproducible execution environment.

5.1. Orchestration Performance This evaluation investigates the orchestration performance of Quditto as a function of network size, characterizing how the time required to deploy and initialize emulated hybrid networks scales with the number of nodes. The analysis identifies which stages of the orchestration process introduce overheads proportional to network growth and which remain invariant with respect to scale, delineating the practical scalability limits of the orchestration workflow. The results validate a core contribution of Quditto: its capability to support the automated and scalable deployment of distributed hybrid network emulation environments without requiring pre-existing infrastructure. For the experimental evaluation, the virtual infrastructure is automatically provisioned using the deployment workflow proposed in this work. The provisioning process operates on four pre-configured virtual machines deployed in a private OpenStack cloud environment. Although these virtual machines can also be provisioned by Quditto, they are treated as part of the initial conditions of the experimental setup to isolate the evaluation of network-scale orchestration from the variability associated with environment-dependent infrastructure provisioning. By contrast, the Kubernetes cluster initialization constitutes a fixed one-time overhead that is independent of network scale and is therefore reported separately. Consequently, the provisioning process creates a minimal Kubernetes cluster configuration consisting of one control-plane node and two worker nodes, each deployed on a separate virtual machine. Across 20 repeated measurements, the cluster initialization time ranged from 162 s to 342 s, with a mean of approximately 230 s, reflecting the variability of Kubernetes cluster initialization in cloud environments. Once provisioned, this virtual infrastructure can support the deployment of multiple independent instances of the network emulation environment, thereby decoupling infrastructure provisioning from network scale. In this evaluation, each worker node hosts up to 100 : Preprint submitted to Elsevier

Page 15 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

350

Deployment time Initialization time

Time (s)

300 250 200 150 100 50 0

2

4

10

25 50 75 Number of nodes

100

150

200

Figure 7: Quditto orchestration time breakdown as a function of network size. Results correspond to 20 deployments per configuration, with error bars representing the 95% confidence interval. Note that the horizontal axis is not linearly scaled.

Kubernetes pods, each emulating a quantum network node. Accordingly, network configurations of up to 100 nodes are deployed on a single worker node, whereas larger configurations are distributed across both worker nodes to maintain a balanced resource utilization. All measurements reported in this section were obtained using the Quditto prebuilt Docker images, which substantially reduce initialization overhead while ensuring consistent and reproducible execution across environments. This configuration also avoids the additional setup time associated with dependency installation, particularly for Vault-related components. Consequently, this choice isolates orchestration performance from dependency management overhead, ensuring that the reported measurements accurately reflect the scalability of the system under the recommended deployment mode. The orchestration measurements were obtained using virtual machines with the following computational resources: the orchestrator node was allocated 48 vCPUs, 80 GB of RAM, and 50 GB of storage, while each cluster node was provisioned with 24 vCPUs, 32 GB of RAM, and 50 GB of storage. Fig. 7 presents the time breakdown of the orchestration process as a function of the number of emulated quantum network nodes, decomposed into its two variable-duration stages. The overall orchestration time increases with network size, confirming that the orchestration workload primarily scales with node-related operations. The network emulation environment deployment stage constitutes the dominant contributor to total orchestration time, particularly for larger network configurations. The observed scaling behavior is consistent with sublinear growth, with the total deployment time increasing from 7.6 s for a 2-node network to 298.8 s for a 200-node network, corresponding to a 39-fold increase in deployment time for a 100-fold increase in network size. This sublinear trend reflects the high degree of parallelization achieved through concurrent pod instantiation. However, the growth rate increases progressively for larger configurations, as Kubernetes scheduling latency and resource allocation pressure accumulate with the number of managed pods, despite Ansible executing operations concurrently in batches. In contrast, the node initialization stage exhibits a markedly lower growth rate, increasing from 15.5 s for a 2-node network to 62.6 s for a 200-node network, consistent with the parallelization of per-node provisioning and service startup, which distributes the initialization workload across nodes concurrently. Notably, even at the largest evaluated scale of 200 nodes, the total orchestration time remains within approximately six minutes, demonstrating that Quditto supports the automated deployment of large-scale emulated networks within practical operational times. These results demonstrate a significant improvement in deployment efficiency compared to the original Quditto platform. Although an absolute comparison with the deployment times of the original platform is not possible due to the absence of documented infrastructure specifications for the previous setup, a meaningful qualitative assessment can still be drawn. As shown in Fig. 3 of the original Quditto work, node initialization did not scale efficiently with the : Preprint submitted to Elsevier

Page 16 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

number of nodes, effectively limiting practical deployments to networks of up to 20 nodes. This limitation has been addressed through two targeted optimizations: the adoption of prebuilt Docker images, which eliminates sequential per-node dependency installation, and the parallelization of the network emulation environment deployment and node initialization stages. Together, these improvements extended the practical deployment scale of the platform from small configurations of up to 20 nodes to large-scale deployments of 200 or more nodes within approximately six minutes, representing an order-of-magnitude increase in the supported network scale. To assess the robustness of the orchestration workflow under resource-constrained conditions, a complementary set of experiments was conducted on machines with significantly reduced computational resources. In this configuration, the orchestrator was allocated 2 vCPUs, 4 GB of RAM, and 50 GB of storage, while each cluster node was configured with 4 vCPUs, 8 GB of RAM, and 50 GB of storage. For an intermediate network configuration of 50 nodes, the reduced-resource setup required approximately 96 s for network emulation environment deployment and 65 s for node initialization. In comparison, under the high-resource configuration shown in Fig. 7, the same stages required approximately 87 s and 25 s, respectively. Notably, the impact of reduced computational resources is asymmetric across the two stages: the network emulation environment deployment time increases by approximately 10% (from 87 s to 96 s), whereas node initialization time increases by a factor of 2.6 (from 25 s to 65 s). This disparity suggests that the deployment stage is primarily constrained by Kubernetes scheduling overhead rather than by available computational resources, while the initialization stage, which involves dependency installation and service initialization, is more sensitive to CPU and memory availability. These results indicate that large-scale emulated hybrid network configurations can be deployed within acceptable time frames on modest infrastructure, thereby demonstrating the feasibility of operating the platform without requiring dedicated high-performance computing resources.

5.2. Functional Validation of Hybrid Networks This validation evaluates the functional performance of a key establishment protocol executed between a postquantum node and a quantum-enabled node through a hybrid network under realistic operating conditions. To this end, a hybrid QKD-PQC network is deployed following a spine-leaf topology (described in detail below), over which a key establishment is performed between an access-level post-quantum site and a spine-level quantum site while the network is subjected to background traffic, i.e., concurrent request load emulating realistic network usage. The study characterizes the impact of this background traffic on the execution of the protocol by systematically measuring the network load alongside the temporal performance of the primary key establishment process. Timestamps are collected for each relevant event, including master key generation, get_key and get_key_with_ID, master key encryption and decryption, and completion of the establishment, enabling a detailed breakdown of the whole process. The analysis identifies how concurrent traffic influences protocol efficiency, thereby establishing the robustness and timing reliability of the establishment mechanism in hybrid environments. However, prior to presenting the measurement results, the network deployment used in this validation is described. The chosen scenario is a hybrid network with a spine-leaf topology architecture. This specific architecture was selected to evaluate the performance of an evenly distributed hybrid environment with both QKD and PQC loads. As can be seen in Fig. 8, although there are more post-quantum sites per se than quantum sites, the number of quantum and post-quantum links is nearly the same, slightly favoring quantum links. A real-world justification for this deployment can be drawn from large-scale, security-critical infrastructures, where highly secure and physically protected core links employ QKD, intermediate aggregation nodes use hybrid QKD-PQC to ensure interoperability and resilience, and edge or access nodes rely on PQC to enable scalable and cost-effective connectivity. The measurements shown in Fig. 9 present the timestamps corresponding to a secure key establishment protocol between two nodes belonging to different technological planes, i.e., between a post-quantum and a quantum cryptographic node. The figure shows the creation of the master key for the exchange as the initial timestamp, as well as the encryption and decryption of this key at each node hop, together with the timestamps corresponding to the initialization and resolution of the point-to-point key establishments between neighboring sites used to generate the encryption keys that ensure secure distribution. Additionally, the figure includes the background traffic of the emulated network, measured in requests per second (shaded purple area, right axis), and is divided into three horizontal sections, each corresponding respectively to the three levels of the spine-leaf architecture shown in Fig. 8, namely the Access, Leaf, and Spine levels, plotted bottom-to-top. At the Access Level, the protocol starts at 𝑡 = 0.000 s with the generation of the master key, marked by a purple circle (∙). The PQC key-request round-trip is shown by the blue upward-pointing triangles (▴): the request is sent at 𝑡 = 0.000 s and the response is received at 𝑡 = 1.210 s. The resulting AES encryption is marked by a purple square (■) : Preprint submitted to Elsevier

Page 17 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 8: Schematic of the hybrid QKD-PQC spine-leaf network deployment used for the functionality test. The network comprises 36 nodes and 35 communication links, including 19 QKD links and 16 PQC links. The nodes are distributed across three logical levels: the spine level, with 4 QKD nodes; the leaf level, with 8 QKD and 8 PQC nodes; and the access level, with 16 PQC nodes. The path followed by the key establishment protocol during the functionality test is highlighted in green.

■

at 𝑡 = 1.211 s. Moving to the Leaf Level, the PQC key-ID request round-trip is shown by the blue downward-pointing triangles (▾), sent at 𝑡 = 1.211 s and received at 𝑡 = 2.020 s, followed immediately by the PQC decryption (purple diamond, ) at 𝑡 = 2.020 s. The first QKD key-request round-trip, marked by pink right-pointing triangles (▶), is then sent at 𝑡 = 2.020 s and received at 𝑡 = 12.915 s, after which the data is re-encrypted with the QKD key (purple square) at 𝑡 = 12.916 s. At the Spine Level, the first QKD key-ID request round-trip is marked by pink left-pointing triangles (◀), sent at 𝑡 = 12.916 s and received at 𝑡 = 14.103 s; the QKD decryption of the first hop (purple diamond) and the second QKD key request (pink right-pointing triangle, sent) occur within the same millisecond, at 𝑡 = 14.103 s, and are shown stacked front-to-back in chronological order to keep them distinguishable. The second QKD key-request round-trip completes when the response is received at 𝑡 = 36.941 s (pink right-pointing triangle), followed by the second QKD encryption (purple square) at 𝑡 = 36.942 s. Finally, the second QKD key-ID request round-trip, marked by pink left-pointing triangles, is sent at 𝑡 = 36.942 s and received at 𝑡 = 38.032 s, and the protocol concludes with the final decryption (purple diamond) at 𝑡 = 38.033 s. The results of the measurement show that the average background traffic during the main establishment was 325 requests per minute. Taking into account this request load, the main key establishment took exactly Δ𝑡 = 38.033 s to complete its secure distribution from the post-quantum access node to the quantum spine node. These measurements demonstrate the viability of establishing cryptographic keying material between nodes in different logical planes of the hybrid emulated network. These results, as well as the ones obtained in the scalability performance test shown in Fig. 7, were measured on virtual machines with considerable computational resources. For the purpose of highlighting results of particular relevance, it can be noted that in the PQC key establishment, both the generation of the encryption key and its subsequent recovery, are fulfilled in Δ𝑡 = 1.210 s and Δ𝑡 = 0.820 s, respectively. However, even though the recovery of the quantum key after its generation is fulfilled in about the same amount of time (Δ𝑡1 = 1.187 s, Δ𝑡2 = 1.090 s), the generation of said key is by far the longest process in the whole establishment: the first generation with Δ𝑡 = 10.895 s and the last generation with Δ𝑡 = 22.838 s. Both the disparity of length between the post-quantum and quantum key generations as well as the difference of time between both quantum generations in the process can be explained by the same phenomenon: generating quantum cryptographic material of a specific length is highly variable, as it depends on pure probability in the quantum measurements. It is also noteworthy that for the sake of observing the full performance of the network under a considerable workload, the quantum cryptographic material used to generate the QKD encryption keys was generated on demand rather than pre-computed, in order to observe the full operational behavior of the network under a representative workload. : Preprint submitted to Elsevier

Page 18 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Figure 9: Timeline of the establishment of a 256-bit key between a post-quantum site and a quantum site in an emulated hybrid network. Vertical markers indicate key events (deltas) at the Access (PQC), Leaf (hybrid), and Spine (QKD) levels, including key generation, key request, encryption, and decryption operations. The shaded area represents the background network traffic intensity, measured in requests per second (req/s), throughout the protocol execution.

6. Conclusion This work presented Quditto as an emulation platform that addresses the automation, scalability, and hybridization challenges identified in the original platform, thereby filling a significant gap in the state of the art regarding reproducible emulation of hybrid quantum-safe network infrastructures. Four principal contributions were introduced: a cloud-native orchestrator supporting fully automated virtual infrastructure provisioning across cloud and multi-cluster Kubernetes environments; a parallelized deployment workflow enabling networks of up to 200 nodes to be deployed within a practically acceptable time frame; the integration of post-quantum nodes implementing IKEv2-based key establishment with ML-KEM and ML-DSA, enabling native emulation of hybrid QKD-PQC topologies; and a secure key management module built on HashiCorp Vault, providing auditable, integrity-protected, and persistent storage of cryptographic material. The experimental validation substantiated these contributions along two complementary dimensions. The orchestration performance evaluation demonstrated sublinear scaling of deployment time with network size, extending the practical deployment scale of the platform from the small-scale configurations supported by the original Quditto, limited to approximately 20 nodes, to large-scale deployments exceeding 200 nodes in approximately six minutes. Furthermore, the robustness assessment under resource-constrained conditions showed that this scalability does not require high-performance computing infrastructure, with the deployment stage remaining primarily constrained by Kubernetes scheduling overhead rather than by computational resource availability. The functional validation complemented these results by confirming the correct end-to-end operation of a hybrid key exchange over a representative spine-leaf topology, demonstrating reliable interoperability between the quantum and post-quantum planes under realistic background traffic conditions, and characterizing the distinct temporal behavior of QKD- and PQC-based key generation within a unified key establishment procedure. Collectively, these results confirm that the proposed platform closes a significant gap identified in the literature: the absence of emulation and orchestration frameworks capable of reproducing hybrid QKD-PQC network behavior at scale without requiring dedicated physical quantum infrastructure or manually provisioned virtual resources. By coupling automated infrastructure provisioning with a standards-based hybrid key establishment framework, Quditto provides the research community with an accessible, reproducible, and extensible testbed for evaluating quantum-safe cryptographic architectures under realistic and controllable conditions. : Preprint submitted to Elsevier

Page 19 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration

Future work will explore several directions building on this foundation. First, the evaluation of additional network topologies and larger-scale hybrid deployments would further characterize the interplay between orchestration overhead and the emulated network structure. Second, the integration of adaptive operational modes capable of switching dynamically between QKD-only, PQC-only, and hybrid configurations, as explored in recent proposals surveyed in Section 2.1, would broaden the applicability of the platform to heterogeneous and evolving network conditions. Finally, progressive integration with physical QKD devices, as envisioned in the architectural design of the platform, would enable systematic validation of emulated results against real-world quantum hardware, further bridging the gap between controlled experimentation and practical deployment.

Acknowledgements The present work has been supported by the 6G-INSPIRE project, PID2022-137329OB-C42, funded by MCIN/AEI/ 10.13039/501100011033/ and by the EU Horizon Europe project Quantum Security Networks Partnership (QSNP), under grant 101114043.

References Ansible Community, 2026. Ansible Community Documentation. https://docs.ansible.com. Accessed: 2026-05-08. Bennett, C.H., Brassard, G., 1984. Quantum cryptography: Public key distribution and coin tossing, in: Proceedings of the IEEE International Conference on Computers, Systems and Signal Processing (ICCSSP), IEEE, Bangalore, India. pp. 175–179. Bernstein, D.J., Buchmann, J., Dahmen, E. (Eds.), 2009. Post-Quantum Cryptography. Springer. Bernstein, D.J., Lange, T., 2017. Post-quantum cryptography. Nature 549, 188–194. Blanco-Romero, J., García, P.O., Sobral-Blanco, D., Mendoza, F.A., Fernández Vilas, A., Fernández-Veiga, M., 2024. QKDNetSim+: Improvement of the quantum network simulator for NS-3. SoftwareX 26, 101685. Campagna, M., et al., 2015. Quantum Safe Cryptography and Security: An Introduction, Benefits, Enablers and Challenges. Technical Report. ETSI. URL: https://www.etsi.org/images/files/ETSIWhitepapers/QuantumSafeWhitepaper.pdf. ETSI White Paper. Chen, L., Xue, K., Li, J., Yu, N., Li, R., Sun, Q., Lu, J., 2023. SimQN: A network-layer simulator for the quantum network investigation. IEEE/ACM Transactions on Networking . Comin, A., 2025. Hybrid quantum security: Integrating QKD and PQC in brownfield optical networks. Quantum Information doi:10.13052/ qi2795-0492.116. Deng, S., Zhao, H., Huang, B., Zhang, C., Chen, F., Deng, Y., Yin, J., Dustdar, S., Zomaya, A.Y., 2024. Cloud-native computing: A survey from the perspective of services. ACM Computing Surveys doi:10.1145/3610228. Diadamo, S., Nötzel, J., Zanger, B., Beşe, M.M., 2021. QuNetSim: A software framework for quantum networks, in: Proceedings of the 2021 IEEE International Conference on Quantum Computing and Engineering (QCE). Díaz-Bricio, A., López, B., Pérez, J., Vidal, I., Valera, F., 2025. A Research Testbed for Multi-Domain QKD and PQC Network Applications and Services. Technical Report. IMDEA Networks Institute. URL: https://phantomsfoundation.com/QUANTUM/2025/Abstracts/2025_ Diaz-Bricio_Angela_151.pdf. technical report presented at the Phantoms Foundation Quantum Workshop 2025. ETSI TC CYBER QSC, 2024. Deployment Considerations for Hybrid Schemes. Technical Report ETSI TR 103 966 V1.1.1. European Telecommunications Standards Institute (ETSI). URL: https://www.etsi.org/deliver/etsi_tr/103900_103999/103966/01.01. 01_60/tr_103966v010101p.pdf. ETSI TC CYBER QSC, 2025. Quantum-Safe Hybrid Key Establishment. Technical Report ETSI TS 103 744 V1.2.1. European Telecommunications Standards Institute (ETSI). URL: https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.02.01_60/ts_ 103744v010201p.pdf. European Commission, 2025. A coordinated implementation roadmap for the transition to post-quantum cryptography. https:// digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography. Accessed: 2025-12-02. European Telecommunications Standards Institute, 2019. Quantum Key Distribution (QKD); Application Interface. Technical Report ETSI GS QKD 014 V1.1.1. ETSI. URL: https://www.etsi.org/deliver/etsi_gs/QKD/001_099/014/01.01.01_60/gs_qkd014v010101p.pdf. ETSI Group Specification. European Telecommunications Standards Institute, 2020. Quantum Key Distribution (QKD); Components and Internal Interfaces. Technical Report ETSI GS QKD 004 V2.1.1. ETSI. URL: https://www.etsi.org/deliver/etsi_gs/QKD/001_099/004/02.01.01_60/gs_ qkd004v020101p.pdf. ETSI Group Specification. Fluhrer, S., Stebila, D., Mosca, M., 2024. Post-quantum hybrid key exchange with ML-KEM in the internet key exchange protocol version 2 (IKEv2). IETF Internet-Draft, https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-mlkem. Accessed: 2025-12-15. Geitz, M., Döring, R., Braun, R.P., 2023. Hybrid QKD & PQC protocols implemented in the Berlin OpenQKD testbed, in: 8th International Conference on Frontiers of Signal Processing (ICFSP), pp. 69–74. Harkins, D., Carrel, D., 2014. Internet Key Exchange Protocol Version 2 (IKEv2). Technical Report RFC 7296. Internet Engineering Task Force. URL: https://datatracker.ietf.org/doc/html/rfc7296. IETF Request for Comments. HashiCorp, 2025. Vault documentation: Secrets management and encryption as a service. URL: https://developer.hashicorp.com/vault. accessed: 2025-12-04. HashiCorp, 2026. Terraform. https://www.terraform.io. Accessed: 2026-05-08.

: Preprint submitted to Elsevier

Page 20 of 21

Hybrid QKD-PQC Network Emulation through Automated and Scalable Cloud-Native Orchestration Helm Authors, 2026. Helm Charts. https://helm.sh. Accessed: 2026-05-08. Henderson, T.R., Lacage, M., Riley, G.F., Dowell, C., Kopena, J., 2008. Network simulations with the ns-3 simulator, in: Proceedings of the SIGCOMM 2008 Demonstration Conference, ACM, Seattle, WA, USA. Hoffman, P.E., Kivinen, T., Smyslov, V., 2024. IKEv2 support of ML-DSA. IETF Internet-Draft, https://datatracker.ietf.org/doc/html/ draft-sfluhrer-ipsecme-ikev2-mldsa-01. Accessed: 2025-12-15. Internet Engineering Task Force (IETF), 2023. Post-quantum use in protocols (pquip) working group charter. https://datatracker.ietf. org/doc/charter-ietf-pquip/. IETF Working Group Charter. Kivinen, T., Smyslov, V., Nir, Y., 2023. Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2). Technical Report RFC 9370. Internet Engineering Task Force. URL: https://www.rfc-editor.org/rfc/rfc9370.html. IETF Request for Comments. Kubermatic, 2025. Kubeone: Cluster lifecycle management. URL: https://docs.kubermatic.com/kubeone/. accessed: 2025-12-04. KubeVirt Project, 2026. KubeVirt: Running virtual machines on Kubernetes. https://kubevirt.io. Accessed: 2026-05-08. López, B., Díaz-Bricio, A., Pérez, J., Vidal, I., Valera, F., 2025. Quditto: Emulating and orchestrating distributed QKD network deployments. URL: https://arxiv.org/abs/2512.15408, arXiv:2512.15408. Marchiori, F., et al., 2025. PQ-CAN: A framework for simulating post-quantum cryptography in embedded systems. arXiv preprint arXiv:2504.10730 . Mehic, M., Dervisevic, E., Burdiak, P., Lipovac, V., Fazio, P., Voznak, M., 2025. Emulation of quantum key distribution networks. IEEE Network 39, 116–123. Mehic, M., Maurhart, O., Rass, S., Voznak, M., 2017. Implementation of quantum key distribution network simulation module in the network simulator NS-3. Quantum Information Processing 16, 253. Mehic, M., Niemiec, M., Rass, S., Ma, J., Peev, M., Aguado, A., Martin, V., Schauer, S., Pacher, C., Hirota, O., Voznak, M., 2020. Quantum key distribution: A networking perspective. ACM Computing Surveys 53, 1–41. National Institute of Standards and Technology, 2024a. Module-Lattice-Based Digital Signature Algorithm (ML-DSA). Technical Report FIPS 204. NIST. URL: https://csrc.nist.gov/pubs/fips/204/final. Federal Information Processing Standards Publication. National Institute of Standards and Technology, 2024b. Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Technical Report FIPS 203. NIST. URL: https://csrc.nist.gov/pubs/fips/203/final. Federal Information Processing Standards Publication. NetSquid Developers, 2026. NetSquid: A Discrete-Event Simulator for Quantum Networks. https://netsquid.org. Accessed: 2026-05-08. NEXTONIC, . An open research and innovation laboratory focusing on next generation mobile networks. https://www.nextonic.org/. Accessed: 2026-04-07. OpenInfra Foundation, 2026. OpenStack. https://www.openstack.org. Accessed: 2026-05-08. Pirandola, S., Andersen, U.L., Banchi, L., Berta, M., Bunandar, D., Colbeck, R., Englund, D., Gehring, T., Lupo, C., Ottaviani, C., et al., 2020. Advances in quantum cryptography. Advances in Optics and Photonics 12, 1012–1236. Pope, G., a. dilithium-py: Python implementation of the dilithium post-quantum digital signature algorithm. https://github.com/ GiacomoPope/dilithium-py. Accessed: 2025-12-02. Pope, G., b. kyber-py: Python implementation of the kyber post-quantum key encapsulation mechanism. https://github.com/GiacomoPope/ kyber-py. Accessed: 2025-12-02. Python Cryptographic Authority, . Cryptography: Cryptographic recipes and primitives for Python. https://pypi.org/project/ cryptography/. Accessed: 2025-12-02. Rescorla, E., 2018. The transport layer security (tls) protocol version 1.3. URL: https://www.rfc-editor.org/info/rfc8446, doi:10. 17487/RFC8446. Sanz, A., et al., 2025. Extending quantum-safe communications to real-world networks: An adaptive security framework. arXiv preprint arXiv:2511.22416. URL: https://arxiv.org/abs/2511.22416. accessed: 2025-12-15. Scapy Project, . Scapy: Packet manipulation library for Python. https://scapy.net/. Accessed: 2025-12-02. Shamir, A., 1979. How to share a secret. Communications of the ACM 22, 612–613. doi:10.1145/359168.359176. Shor, P.W., 1994. Algorithms for quantum computation: Discrete logarithms and factoring, in: Proceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), IEEE Computer Society, Santa Fe, NM, USA. pp. 124–134. Shor, P.W., Preskill, J., 2000. Simple proof of security of the BB84 quantum key distribution protocol. Physical Review Letters 85, 441–444. doi:10.1103/PhysRevLett.85.441. Spooren, P., Neuhold, A., Ramacher, S., Hühn, T., 2026. PQC-enhanced QKD networks: A layered approach, in: Proceedings of the 2026 IEEE International Conference on Quantum Communications, Networking, and Computing (QCNC), Kobe, Japan. doi:10.1109/QCNC69040.2026. 00060. The Kubernetes Authors, 2025a. kubeadm. https://kubernetes.io/docs/reference/setup-tools/kubeadm/. Accessed: 2026-08-03. The Kubernetes Authors, 2025b. Kubernetes. https://kubernetes.io/. Accessed: 2026-06-29. The Submariner Project Authors, 2026. Submariner. https://submariner.io. Accessed: 2026-05-08. VMware Tanzu, 2026. RabbitMQ: Open Source Message Broker. https://www.rabbitmq.com. Accessed: 2026-05-08. Wiesner, S., 1983. Conjugate coding. SIGACT News 15, 78–88. Wu, X., Kolar, A., Chung, J., Jin, D., Zhong, T., Suchara, M., Kettimuthu, R., 2021. SeQUeNCe: A customizable discrete-event simulator of quantum networks, in: Proceedings of the 2021 IEEE International Conference on Quantum Computing and Engineering (QCE).

: Preprint submitted to Elsevier

Page 21 of 21