Empowering Mobile Networks Security Resilience by using Post-Quantum Cryptography

Empo wering Mobile Networks Security Resilience by using Post-Quantum Cryptography Ricardo Alves F av al 1 , Rodrigo Moreira 2 , Flávio de Oli veira Silv a 1, 3 1 Federal Univ ersity of Uberlândia (UFU), Minas Gerais, Brazil 2 Federal Univ ersity of V içosa (UFV), Minas Gerais, Brazil 3 Univ ersity of Minho (UMinho), Braga, Portugal Emails: ricardo.fa val@ufu.br , rodrigo@ufv .br , flavio@di.uminho.pt Abstract —The transition to a cloud-native 5G Service-Based Architectur e (SBA) impr oves scalability but exposes contr ol-plane signaling to emerging quantum threats, including Harv est-Now , Decrypt-Later (HNDL) attacks. While NIST has standardized post-quantum cryptography (PQC), practical, deployable inte- gration in operational 5G cores remains underexplor ed. This work experimentally integrates NIST -standardized ML-KEM- 768 and ML-DSA into an open-source 5G cor e (free5GC) using a sidecar proxy patter n that preserv es unmodified network functions (NFs). Implemented on free5GC, we compare three deployments: (i) native HTTPS/TLS, (ii) TLS sidecar , and (iii) PQC-enabled sidecar . Measurements at the HTTP/2 request– response boundary over repeated independent runs show that PQC increases end-to-end Ser vice-Based Interface (SBI) latency to ∼ 54 ms, adding a deterministic 48–49 ms overhead r elative to the classical baseline, while maintaining tightly bounded variance ( I QR ≤ 0 . 2 ms, C V < 0 . 4% ). W e also quantify the impact of Certification A uthority (CA) security levels, identifying certificate validation as a tunable contributor to overall delay . Overall, the results demonstrate that sidecar-based PQC insertion enables a non-disruptive and operationally predictable migration path for quantum-resilient 5G signaling. I . I N T RO D U C T I O N The deployment of 5th Generation Mobile Network (5G) networks represents a paradigm shift in telecommunications, supporting a massiv e ecosystem of billions of devices. Central to this e volution is the Service-Based Architecture (SBA), which replaced traditional point-to-point interfaces with a cloud-nativ e, microservices-oriented approach. While this tran- sition to Hypertext Transfer Protocol (HTTP)/2 and T ransport Layer Security (TLS) enhances scalability , it also centralizes sensitiv e cryptographic operations at critical core network functions Network Functions (NFs) [1], [2]. As research progresses to ward 6th Generation Mobile Net- work (6G) networks, the security foundations of these infras- tructures face an existential threat: the advancement of quan- tum computing. Current 5G security relies heavily on public- key cryptography , specifically Rivest–Shamir–Adleman (RSA) and Elliptic-curve cryptography (ECC), which are vulnerable to Cryptographically Relev ant Quantum Computers (CRQCs). Attacks such as Harvest No w , Decrypt Later (HNDL) [3] underscore the urgenc y , as adversaries may already be captur- ing sensitive 5G signaling to decrypt once po werful quantum machines become available. This poses a long-term risk to subscriber identities and authentication credentials stored in Unified Data Management (UDM) modules [4], [2]. T o mitigate these risks, the National Institute of Stan- dards and T echnology (NIST) finalized the first Post-Quantum Cryptography Post-Quantum Cryptography (PQC) standards in 2024, emphasizing Key Encapsulation Mechanism (KEM) and Digital Signature Algorithms (DSA). Howe ver , a significant gap remains between theoretical standardization and practical implementation in high-throughput environments like the 5G Core [5], [6]. This work addresses this gap by presenting a comprehen- siv e ev aluation of PQC inte gration into a cloud-nativ e 5G Core. W e propose a sidecar proxy architecture that enables quantum- safe communication between NFs without modifying the legac y codebase. Specifically , we integrate ML-KEM[7] and ML-DSA[8] into the free5GC platform. Our main contrib ution is a rigorous experimental comparison across three scenarios: (i) a baseline Nativ e5G Core; (ii) a TLS-based sidecar; and (iii) our PQC-enabled sidecar architecture. W e provide detailed insights into the impact of larger PQC keys on control plane latency , handshake performance, and resource consumption (Central Processing Unit (CPU) /Memory), of fering a roadmap for future quantum-resistant telecommunications infrastruc- ture. T o the best of our knowledge, this work represents one of the first fully experimental integrations of NIST -standardized PQC algorithms into a cloud-native 5G Core using a sidecar proxy pattern that preserves unmodified NF implementations. Unlike prior studies that focus on theoretical security analysis, protocol-lev el proposals, or hybrid cryptographic simulations, our approach provides a deployable migration strategy within a production-grade free5GC en vironment. Beyond reporting end-to-end latency , we experimentally isolate cryptographic processing ov erhead from wrapper- induced proxy costs, quantify deterministic control-plane be- havior under PQC, and ev aluate the impact of different Cer- tificate Authority (CA) security parameter lev els. This enables a practical characterization of performance–security trade-offs and demonstrates crypto-agility in SBA signaling without intrusiv e architectural changes. The remainder of this paper is or ganized as follo ws. Section II discusses related work on PQC and its adoption in 5G and cloud-native deployments. Section III presents the threat model and security goals. Section IV describes the proposed sidecar -based architecture for protecting SBI and extending coverage to N2 signaling. Section V details the implementation to empower Free5GC with PQC. Section VI presents the experimental methodology , including e valuation scenarios and measurement approach. Section VII reports and analyzes the results, and Section VIII concludes the paper and outlines future work. I I . R E L A T E D W O R K Mahyoub et al. [9] present a security analysis of critical interfaces in the Fifth Generation architecture, identifying in- terfaces that exchange sensitive data or are externally exposed, and mapping threats and protections across Service-Based Architecture and non-Service-Based Architecture connectivity . It discusses defenses such as T ransport Layer Security , Internet Protocol Security , and Open Authorization for Network Func- tion interactions, and highlights post-quantum considerations for key exchange and tunnel establishment. Mehic et al. [10] provide a comprehensi ve ov erview of quantum cryptography for Fifth Generation networks, cov- ering Quantum Ke y Distribution deployment options, inte- gration challenges, and standardization aspects in cellular architectures. It contrasts Quantum K ey Distribution with PQC and discusses ho w quantum-resilient key establishment can complement mechanisms such as TLS and Internet Protocol Security (IPsec) in Fifth Generation systems. Lawo et al. [11] designs and implements a Post Quan- tum Cryptography network stack on a Data Processing Unit platform, combining Falcon with K yber and Dilithium with Kyber for authentication and ke y establishment. It benchmarks performance on the NVIDIA Data Processing Unit platform, reporting latency and throughput trade-offs for PQC-protected communication. Scalise et al. [4] offer a systematic surv ey of security considerations in Fifth and Sixth Generation systems, organiz- ing challenges and trends across confidentiality , integrity , and av ailability objectiv es, and introducing a Zero T rust Architec- ture perspective. It highlights emerging directions, including Post-Quantum Cryptography for key exchange, as well as the security implications of Software-Defined Networking, Network Function V irtualization, and Multi-access Edge Com- puting deployments. Mangla et al. [12] re view Fifth Generation security vulnera- bilities in a future quantum computing environment and survey quantum-based solutions intended to mitigate these challenges, while motiv ating the transition tow ard Sixth Generation. It dis- cusses Quantum Ke y Distribution and related quantum security techniques and argues that classical public key cryptography must be complemented by quantum-resilient alternatives for next-generation industrial deployments. Dolente et al. [13] perform an experimental vulnerability assessment of open-source Fifth Generation Core Network Function implementations, focusing on externally exposed Network Functions such as the Access and Mobility Man- agement Function and the Network Repository Function with Network Exposure Function. It applies Application Program- ming Interface injection and fuzzing-style tests to Open5GS and OpenAirInterface, and reports robustness issues that can lead to denial-of-service attacks and other security risks. Pell et al. [14] study service classification of Fifth Genera- tion core netw ork traf fic using Machine Learning o ver flo w and packet metadata, motiv ated by detecting malicious signalling without Deep Packet Inspection. It compares multiple Machine Learning models and shows how accurate service-le vel infer- ence can support security monitoring for distributed Network Functions in Fifth-Generation core networks. In T able I, 5G / SB A indicates an explicit focus on the 6G and Service-Based Interface (SBI) and TLS, IPsec, and Open Authorization (O Auth) indicate whether TLS, IPsec, and OAuth are discussed or used. 5G Stack indicates use of an open-source Fifth Generation implementation or testbed; Application Programming Interface (API)/(Fuzzing or Fuzz testing) - Automated Software T esting T echnique (Fuzz) indi- cates API injection or fuzzing-style testing; and PQC indicates explicit PQC discussion or implementation. I I I . T H R E A T M O D E L A N D S E C U R I T Y G O A L S The threat model considers a passiv e adversary capa- ble of recording encrypted traffic for later decryption in a HNDL scenario, as well as an activ e adversary performing Man-in-the-Middle (MITM) attacks to intercept, replay , or modify signaling data. W e assume that the NFs and their host en vironments are trusted, while the underlying transport network is inherently insecure. While trusted NF execution is assumed, integration with T rusted Execution En vironments (TEEs) or confidential-computing mechanisms represents an important direction for mitigating endpoint compromise in future deployments. The protected assets are the confidentiality and integrity of SBI control-plane signaling exchanged between NFs (e.g., reg- istration, discov ery , and heartbeat) over potentially untrusted transport links. Consequently , the primary security objectives are to ensure long-term confidentiality , robust mutual authen- tication, and message integrity through post-quantum mech- anisms. Furthermore, the architecture must support crypto- agility , enabling an incremental migration to PQC without requiring modifications to the internal logic of the NFs. This model aligns with 3rd Generation Partnership Project (3GPP) assumptions where protection is applied at the SBA lev el; howe ver , we reinforce these interfaces against quantum- capable adversaries. Out-of-scope threats include endpoint compromise, Denial of Service (DoS) attacks, side-channel analysis, and radio-access security . By design, the sidecar introduces an additional trusted component in the NF pod, so reducing its attack surface (min- imal codebase, least-pri vilege access, and hardened container configuration) is a key operational requirement. I V . E M P O W E R I N G T H E C O R E 5 G W I T H P Q C The transition to PQC is one of the most important steps for telecommunications security , but the direct integration into the network ecosystem often entails complex modifications to legac y software, resulting in compatibility issues and increased maintenance costs. T o overcome these challenges, this work proposes a sidecar proxy pattern [15] that decouples security functions from the core business logic of the NF. Instead of modifying the NF source code, specialized proxies are deployed alongside each component to handle PQC-protected handshakes and key exchanges transparently . This modular T ABLE I: Short State of the art surve y . Paper 5GC/SB A TLS IPsec O Auth Exp. 5G Stack API/Fuzz PQC Mahyoub et al. [9] ○ ○ ○ ○    ○ Mehic et al. [10] ○ ○ ○     ○ Law o et al. [11]        ○ Scalise et al. [4] ○ ○ ○ ○    ○ Mangla et al. [12]  ○ ○     ○ Dolente et al. [13] ○ ○ ○ ○  ○ ○  Pell et al. [14] ○    ○ ○   This work ○ ○ ○ ○ ○ ○ ○ ○ layer abstracts the complexities of quantum-resistant protocols, creating a "plug-and-play" environment where algorithms can be updated without disrupting the underlying 5G infrastructure. For this implementation, the ML-KEM-768 and ML-DSA- 65 algorithms were selected due to their optimal balance between post-quantum resilience and operational efficienc y , aligning with NIST Security Level 3 standards [16]. While higher-le vel parameters (e.g., Le vel 5) offer superior security margins, they introduce prohibitiv e communication overhead and handshake latency [17] that could compromise the strict performance requirements of the 5G SB A. Furthermore, these specific parameter sets benefit from mature implementations and extensi ve optimizations in digital signature calculations and verification processes [18]. By integrating these stan- dardized algorithms via the sidecar approach, the architecture ensures robust, quantum-resistant protection while maintaining the high-performance throughput and low-latenc y response times essential for mission-critical core network operations. While the architecture supports PQC encapsulation for N2 signaling, the experimental ev aluation presented in this work focuses exclusiv ely on SBI interactions to isolate control-plane cryptographic ov erhead. V . T H E P Q C E N A B L E D F R E E 5 G C The experimental environment was built upon the free5GC platform, an open-source implementation of 3GPP 5G Core specifications designed for cloud-native deplo yments. Utilizing the free5gc-compose project, we implemented a modular post- quantum infrastructure using a sidecar proxy pattern that strictly separates cryptographic operations from the NF busi- ness logic. As illustrated in the architecture (see Figure 1), the deployment relies on a specialized cryptolib container integrating liboqs v0.15.0 and the OpenSSL Open Quantum Safe (OQS)-provider , establishing the foundation for quantum- resistant primiti ves. T o abstract these low-le vel interactions, we dev eloped wrapper -kem and wrapper-sign services that expose REpresentational State Transfer Application Program- ming Interface (RESTful) APIs for ML-KEM and ML-DSA operations. This structure (see Figure 3), orchestrated via Docker Compose, ensures that cryptographic lifecycles, includ- ing the generation of entity-specific keys and certificates by a dedicated PQC-key-generator are managed independently of the NF. The core of the PQC integration lies in the pqc-proxy instances deployed in both server and client modes. NFs pq c - prox y - a m f - to - nr f ( C lient ) A MF N F ( S C TP ) N1 1 SM F NF ( HT TP ) pq c - prox y - nr f ( S er ver ) NRF N F ( HTT P ) AMF N F :800 0 ( HT TP ) pq c - prox y - a m f ( S er ver ) pq c - pro x y - sm f - to - a m f ( C lie nt ) Po rt: 9001 P o rt: 8000 Q u a n tu m - R e si st e n t P l a i n te x t HT T P K EM / D S A P l a i n te x t HT T P P l a i n te x t HT T P pq c - prox y - pcf - to - sm f ( C lient ) PCF N F ( HTTP ) N1 5 pq c - prox y - sm f ( S er ver ) SM F NF :80 00 ( HTTP ) P o rt: 9003 P o rt: 8000 Q u a n tu m - R e si st e n t P l a i n te x t HT T P K EM / D S A P l a i n te x t HT T P N7 Po rt: 9002 HT T P P l a i n te x t K EM / D S A Q u a n tu m - R e si st e n t P o rt: 8000 pq c - prox y - nf - to - nf ( C lie nt ) NF ( HTTP ) pq c - pro x y - nf ( S er ver ) NF :80 00 ( HTTP ) Q u a n tu m - R e si st e n t P l a i n te x t HT T P K EM / D S A P l a i n te x t HTT P Pos t Q uantum Sec ure free 5GC Archit ectu re 5G C ore Dom ain (Pa r ti a l V iew ) pq c - prox y - a m f - to - nr f ( C lient ) A MF N F ( S C TP ) N1 1 SM F NF ( HT TP ) pq c - prox y - nr f ( S er ver ) NRF N F ( HTT P ) AMF N F :800 0 ( HT TP ) pq c - prox y - a m f ( S er ver ) pq c - pro x y - sm f - to - a m f ( C lie nt ) Po rt: 9001 P o rt: 8000 Q u a n tu m - R e si st e n t P l a i n te x t HT T P K EM / D S A P l a i n te x t HT T P P l a i n te x t HT T P pq c - prox y - pcf - to - sm f ( C lient ) PCF N F ( HTTP ) N1 5 pq c - prox y - sm f ( S er ver ) SM F NF :80 00 ( HTTP ) P o rt: 9003 P o rt: 8000 Q u a n tu m - R e si st e n t P l a i n te x t HT T P K EM / D S A P l a i n te x t HT T P N7 Po rt: 9002 HT T P P l a i n te x t K EM / D S A Q u a n tu m - R e si st e n t P o rt: 8000 pq c - prox y - nf - to - nf ( C lie nt ) NF ( HTTP ) pq c - pro x y - nf ( S er ver ) NF :80 00 ( HTTP ) Q u a n tu m - R e si st e n t P l a i n te x t HT T P K EM / D S A P l a i n te x t HTT P Pos t Q uantum Sec ure free 5GC Archit ectu re 5G C ore Dom ain (Pa r ti a l V iew ) Fig. 1: PQC Secure Free5GC Architecture (partial view) communicate via plain-text HTTP with local proxies within isolated Docker bridge networks (172.17.0.0/16), while inter- proxy traffic across network edges is encapsulated in ML- KEM-768 tunnels and authenticated via ML-DSA-65. A crit- ical technical challenge addressed was the protection of the N2 interface; since NGAP signaling typically relies on Stream Control T ransmission Protocol (SCTP), we deployed socat bridges to perform SCTP-to-Transmission Control Protocol (TCP) conv ersion, enabling PQC encapsulation between the pqc-proxy-gnb and pqc-proxy-amf-n2 (see Figure 2). T o ensure traf fic redirection, the free5GC configuration files (e.g., amfcfg.yaml, nrfcfg.yaml) were modified to route SBI requests through the local proxy’ s listener port. Pos t Q uantum Sec ure Archit ectu re R AN D omain (Pa r ti a l V iew ) gNB so cat - gnb - bri dge ( S C TP ) pq c - prox y - gnb ( C lie nt ) pq c - prox y - a m f - n2 ( S er ver ) so cat - a m f - bri dge ( TC P ) AMF N F ( S C TP ) Quantu m - Re si stant SCT P T CP N2 N3 ML - K E M / M L - DS A En ca p sulatio n Unecr yp te d T CP ML - K E M / M L - DS A UE E n cr yp te d NAS N1 ( NAS ) Pos t Q uantum Sec ure Archit ectu re R AN D omain (Pa r ti a l V iew ) gNB so cat - gnb - bri dge ( S C TP ) pq c - prox y - gnb ( C lie nt ) pq c - prox y - a m f - n2 ( S er ver ) so cat - a m f - bri dge ( TC P ) AMF N F ( S C TP ) Quantu m - Re si stant SCT P T CP N2 N3 ML - K E M / M L - DS A En ca p sulatio n Unecr yp te d T CP ML - K E M / M L - DS A UE E n cr yp te d NAS N1 ( NAS ) Fig. 2: PQC Radio Access Network (RAN) domain (partial view). CRYP TO - LIB ( libo q s li b r a r y ) WR AP P ER - SIGN ( HTTP :80 81 ) WR AP P ER - K EM ( HTTP :80 80 ) PQC - K ey Gen er a t o r • CA: k e m _ ca .crt / k e m _ ca.k e y • CA: d sa_ ca.crt / d sa_ ca .ke y • am f _ nf_ k e m .cr t / a m f _ nf _ d sa.ke y • • • nam e _ nf_ k e m .cr t / nam e _ nf_ d sa.ke y Sh ar e d P QC Ke y Vo l um e Fig. 3: Cryptographic infrastructure (partial view). T o e valuate the resulting cryptographic overhead and sys- tem stability , a robust monitoring frame work was integrated directly into the architecture. This stack comprises Prometheus for metrics collection, Grafana for real-time visualization, Node Exporter for hardware telemetry , and cAdvisor for container-le vel resource tracking. This integrated observ ability framew ork enables precise, high-fidelity analysis of CPU and memory consumption, as well as latency variations across the PQC mechanisms deployed within the 5G Core, providing the necessary data to v alidate the performance trade-of fs of the proposed sidecar approach (see Figure 4). Promet heu s Gr a fana ( D a s h b oa r d s ) cAdvi sor ( Co n ta i n e r M etr ic s ) Node Ex p o rt er ( Ho st Metr ics ) • KE M Op e r atio ns • DSA O p e r at io n s • P QC Hand sh ak e • CP U / M e m o ry • P o st - Quantu m Ke y S ize s P QC - Sp e cific M e tr ics Promet heu s Gr a fana ( D a s h b oa r d s ) cAdvi sor ( Co n ta i n e r M etr ic s ) Node Ex p o rt er ( Ho st Metr ics ) • KE M Op e r atio ns • DSA O p e r at io n s • P QC Hand sh ak e • CP U / M e m o ry • P o st - Quantu m Ke y S ize s P QC - Sp e cific M e tr ics Promet heu s Gr a fana ( D a s h b oa r d s ) cAdvi sor ( Co n ta i n e r M etr ic s ) Node Ex p o rt er ( Ho st Metr ics ) • KE M Op e r atio ns • DSA O p e r at io n s • P QC Hand sh ak e • CP U / M e m o ry • P o st - Quantu m Ke y S ize s P QC - Sp e cific M e tr ics Fig. 4: Monitoring infrastructure layer . V I . E X P E R I M E N T A L E V A L UAT I O N This section presents the experimental methodology adopted to assess the performance implications of integrating PQC into the free5GC using the proposed sidecar architec- ture. The e valuation is designed to ensure reproducibility , isolate cryptographic overhead from wrapper-induced pro- cessing costs, and enable a controlled comparison between Nativ e, classical TLS, and PQC-enabled deployments. The following subsections describe the workload definition, testbed configuration, experimental design, and statistical reporting framew ork. A. Evaluation Scope and W orkload T o quantify the performance impact of the sidecar ar- chitecture and PQC, the ev aluation focuses on control-plane SBI interactions between NFs and the Network Repository Function (NRF), including registration, discovery , and heart- beat procedures. By isolating the control plane from User Equipment (UE) emulation overhead, the setup enables direct comparison between the Nativ e architecture, a classical TLS sidecar proxy , and a PQC sidecar proxy integrated via liboqs. The workload consists of sequential HTTP/2 request– response exchanges per NF pair . Each experimental repetition ex ecutes 100 transactions without artificial concurrency to iso- late cryptographic overhead from scheduling or load-induced effects. A transaction is considered successful when the com- plete exchange finishes without timeout or retransmission. B. T estbed Configuration All architectures were deployed in standardized V irtual Machines (VMs) running Ubuntu 22.04 Long T erm Support (L TS), each allocated 4 CPU cores and 8 GB of Random Access Memory (RAM). The 5G Core was orchestrated using free5GC-compose v4.2.0. The PQC implementation relied on OpenSSL v3.4.0 integrated with liboqs v0.15.0, enabling ML- KEM-768 and ML-DSA through sidecar proxies. All experi- ments were conducted without hardware acceleration, isolating software-side overheads. C. Experimental Design For each architecture (Nati ve, classical TLS Proxy , and PQC Proxy), e xperiments were repeated 30 times, each repeti- tion inv olving full container lifecycle reinitialization to capture variability from virtualized resource allocation and network stack initialization. W ithin each repetition, 100 sequential SBI interactions were executed. The PQC configuration was ev aluated across three CA parameter sets (ML-DSA-44, 65, and 87), while maintaining ML-KEM-768 and ML-DSA-65 for key exchange and signatures. D. Metrics and Statistical Reporting Metrics were collected using Prometheus, cAdvisor , and Node Exporter . For statistical reporting, each repetition is treated as an independent sample. Results are expressed using median and Interquartile Range (IQR) across repetitions, and 95% confidence intervals were computed ov er per-run median latency values using the t -distribution. The monitored perfor- mance and security indicators are summarized in T able II. T ABLE II: Selected metrics for e valuation. V isual Analysis Selected Metrics Evaluation Goal Latency Dis- tribution L S B I Assess delay scaling and jitter across ar- chitectures. Resource Ef- ficiency CPU% M em M B V alidate hardware sustainability for PQC workloads. Latency Breakdown L S r v L C li Isolate sidecar ov erhead from crypto- graphic processing. SBI Matrix L S B I per NF pair Identify bottlenecks in 5G signaling (e.g., AMF, NRF). PQC Opera- tions T enc T sig T ver Correlate KEM/DSA complexity with E2E performance. V I I . R E S U L T S A N D D I S C U S S I O N W e e valuated three free5GC deployments: (i) Native , using standard Hypertext T ransfer Protocol Security (HTTPS)/TLS; (ii) TLS Pr oxy , using a sidecar model with OpenSSL certifi- cates; and (iii) PQC Pr oxy , enabling PQC through the proposed sidecar approach. Latency is measured at the HTTP/2 request–response boundary on the SBI: timestamps are captured immediately before request transmission and after complete response re- ception at the application layer . The SBI Communication met- ric therefore captures end-to-end control-plane transaction la- tency for one NF-to-NF interaction. Container Metrics capture proxy-side processing behavior , while Overall Statistics corre- spond to the per-run aggregate of all collected SBI request– response latencies across monitored NF pairs (Figure 5). Per- NF-pair heatmaps report mean latencies for individual paths (e.g., 5–6 ms in the Nativ e case), whereas Figure 5 summarizes distributional medians aggregated across interactions within each run. For statistical reporting, 95% confidence intervals were computed over per-run median latenc y values using the t - distribution across 30 independent repetitions, while error bars represent the IQR ( Q 1 – Q 3 ) around the median. Nativ e establishes the baseline, with SBI Communication and Con- tainer Metrics medians of 15.07 (Confidence Interv al (CI): [15 . 0 , 15 . 1] and [15 . 0 , 15 . 2] ) and minimal quartile deviation ( ± 0 . 05 – 0 . 1 ). Overall Statistics records 5.04 (CI: [4 . 9 , 5 . 2] ), indicating stable con ventional TLS behavior . The TLS Proxy con ver ges SBI Communication and Con- tainer Metrics at 10.20 ms (CI: [10 . 2 , 10 . 2] for both), corre- sponding to a 32.3% reduction relativ e to Nativ e and near- zero IQR. This reduction does not imply lower cryptographic complexity; it is consistent with the sidecar centralizing con- nection management and reusing pooled HTTP/2/TLS sessions across repeated SBI exchanges, thereby amortizing handshake and transport setup costs. T o ensure comparability , latency was measured at the same request–response boundary in all architectures, using identical keep-aliv e and connection-reuse settings across runs. In contrast, the PQC Proxy increases SBI Communication to 54.05 ms (CI: [53 . 9 , 54 . 1] ) while preserving tight quartile bounds ( ± 0 . 1 ), quantifying a stable o verhead of approximately 48–49 ms relativ e to classical TLS. Container Metrics remain stable at 9.46 ms (CI: [9 . 4 , 9 . 5] ), suggesting bounded resource behavior even under ML-KEM and ML-DSA processing (Fig- ure 6). From a standards perspective, the measured ∼ 54 ms end-to-end SBI latency remains well within 5G control-plane timing tolerances, which are gov erned by NAS procedure timers and are typically on the order of seconds. Therefore, the additional ∼ 48 –49 ms introduced by the PQC sidecar is operationally compatible with registration and authentica- tion signaling, while still moti vating optimization for latency- sensitiv e deployments. Quartile analysis highlights distinct distributional behav- ior across architectures. Native exhibits low-v ariance distri- butions, while TLS Proxy shows compressed quartiles for SBI and container-le vel metrics but expanded quartiles for Overall Statistics, indicating aggregation variability in the proxy pipeline. By contrast, PQC Proxy maintains narrow quartile ranges across all metrics ( I QR ≤ 0 . 2 ), demonstrating higher absolute latenc y with bounded v ariance—a key property for predictable Quality of Service (QoS). The separation is clear: PQC SBI quartiles [53 . 9 , 54 . 1] do not ov erlap with Nativ e [15 . 0 , 15 . 1] or TLS Proxy [10 . 2 , 10 . 2] , and the observ ed Native TLS Proxy PQC Proxy 0 10 20 30 40 50 Metrics V alue 15.07 [15.0 15.1] 15.07 [15.0 15.2] 5.04 [4.9 5.2] 9.29 [9.3 9.3] 9.29 [9.3 9.3] 35.76 [34.7 36.8] 54.05 [53.9 54.1] 9.46 [9.4 9.5] 48.48 [48.4 48.6] Ar chitectur e Metrics L egend Native: SBI Communication Container Metrics Overall Statistics TLS P r o xy : SBI Communication Container Metrics Overall Statistics PQC P r o xy : SBI Communication Container Metrics Overall Statistics Fig. 5: Metrics comparison across architectures Core 5G. Native HT TPS TLS Proxy PQC Proxy arch 0 10 20 30 40 50 Latency (ms) 5.56 5.56 54.05 2.52 24.71 Latency Breakdown: End-to-End vs Proxy Overhead Metric Type NF -to-NF (End-to-End) Proxy Overhead Fig. 6: Processing latency End-to-End. C V < 0 . 4% confirms stable behavior . Heatmaps further corroborate these trends. Native main- tains uniformly low SBI latencies (5.5–6.0 ms) across NF pairs (Figure 7), while TLS Proxy remains within the same order of magnitude (5.0–7.7 ms) and exhibits stable behavior consistent with optimized connection reuse (Figure 8). PQC Proxy exhibits a nearly uniform increase to 53.0–54.4 ms across all NF pairs (Figure 9), indicating deterministic over - head largely independent of the communication pattern and dominated by ML-KEM-768 encapsulation/decapsulation and ML-DSA processing. Detailed latency breakdown for representative NRF-centric exchanges (Figures 10–12) shows the same pattern: Native remains near 5–6 ms, TLS Proxy remains near 5 ms with a small proxy processing component (2.43 ms), and PQC Proxy increases to 53–54 ms. The proxy processing estimate is stable (24.71 ms) across ev aluated pairs, indicating deter- ministic ov erhead consistent with encapsulation/decapsulation dominance. The proxy processing estimate is computed inside the sidecar as ∆ t = t egress − t ingress , capturing cryptographic en- capsulation/decapsulation and certificate validation time within the proxy/wrappers, independent of NF application processing. ausf chf nrf nssf pcf smf udm udr upf dest_nf amf ausf chf nef nssf pcf smf udm udr source_nf 5.8 5.8 5.5 6.0 5.9 6.0 6.0 5.9 5.9 5.9 5.9 5.9 5.9 5.8 5.9 6.0 5.9 5.8 5.7 0.0 5.9 5.8 5.9 NF Communication Heatmap - Native HT TPS 0 1 2 3 4 5 6 Fig. 7: Mean latency in the HTTPS baseline. ausf nrf nssf pcf smf udm udr dest_nf amf ausf nssf pcf smf udm udr source_nf 5.2 5.2 6.9 5.8 5.3 5.6 7.8 5.2 5.2 5.2 5.2 5.2 5.8 5.3 5.4 5.3 5.2 5.2 NF Communication Heatmap - TLS Proxy 5.5 6.0 6.5 7.0 7.5 Fig. 8: Mean latency in the TLS Proxy . The proxy processing breakdown (Figure 13) re veals asym- metric costs for TLS Proxy (server -side 3.99 ms vs. client- side 1.00 ms), consistent with server-dominated certificate validation and priv ate-key operations. For PQC Proxy , server- side (7.03 ms) and client-side (6.56 ms) costs become near- symmetric (13.59 ms total), indicating that encapsulation and decapsulation impose comparable computational burdens and contribute directly to end-to-end latency . Overall PQC over - head comprises (i) ML-KEM encapsulation/decapsulation, (ii) ML-DSA signature generation/verification, and (iii) proxy-side certificate-chain validation. Detailed analysis indicates that higher security le vels in the CA (e.g., ML-DSA-87) directly increase server -side v alidation latency . T o quantify the impact of security margins on opera- ausf nrf nssf pcf smf udm udr dest_nf amf ausf nssf pcf smf udm udr source_nf 54.2 53.0 54.0 53.9 53.6 54.2 54.3 54.0 54.3 54.1 53.8 54.3 54.1 54.4 54.1 54.0 54.2 54.3 NF Communication Heatmap - PQC Proxy 53.2 53.4 53.6 53.8 54.0 54.2 Fig. 9: Mean latency in the PQC Proxy Native HT TPS TLS Proxy PQC Proxy Architecture 0 10 20 30 40 50 60 Latency (ms) 5.46 5.24 53.04 2.52 24.71 N/A N/A N/A L a t e n c y B r e a k d o w n : A M F N R F T otal E2E Latency Proxy Processing (Est.) Proxy Processing Fig. 10: Processing latency - AMF to NRF tional latency , we ev aluated three CA parameter lev els within the PQC Proxy configuration. As shown in T able III, increasing the CA security le vel yields a monotonic rise in server-side validation latency: the transition to ML-DSA-87 adds +1.40 ms to the median total SBI latency relativ e to ML-DSA-44. While this variation is smaller than the dominant PQC overhead, it is repeatable and measurable, confirming certificate-chain v alidation as a tunable contributor to end-to-end delay . Consequently , CA parameter selection becomes a concrete deployment lever for balancing post-quantum security margin and control-plane latency con- straints. W e assume a trusted key-generation and distribution ser- vice; operational deployments should harden this trust an- chor using Hardware Security Modules (HSMs) and audited, Native HT TPS TLS Proxy PQC Proxy Architecture 0 10 20 30 40 50 60 Latency (ms) 5.87 5.20 54.05 2.52 24.71 N/A N/A N/A L a t e n c y B r e a k d o w n : A U S F N R F T otal E2E Latency Proxy Processing (Est.) Proxy Processing Fig. 11: Processing latency - Authentication Server Function (A USF) to NRF Native HT TPS TLS Proxy PQC Proxy Architecture 0 10 20 30 40 50 60 Latency (ms) 5.90 5.33 54.00 2.52 24.71 N/A N/A N/A L a t e n c y B r e a k d o w n : U D M N R F T otal E2E Latency Proxy Processing (Est.) Proxy Processing Fig. 12: Processing latency - UDM to NRF least-privile ge key management to reduce single-point-of- compromise risk. From a deployment perspective, the results indicate that PQC-sidecar integration remains feasible for control-plane op- erations with moderate latency tolerance, while authentication- intensiv e NF interactions may require resource scaling and/or optimized certificate validation strategies. Lower CA security lev els provide measurable latency reduction, highlighting a tunable trade-off between cryptographic strength and opera- tional performance. V I I I . C O N C L U S I O N This work addressed the practical challenge of securing cloud-nativ e 5G core signaling against future quantum threats, including harvest-no w-decrypt-later and activ e MITM attacks, Native HT TPS TLS Proxy PQC Proxy Architecture Type 0 2 4 6 8 10 12 14 Processing Time (ms) Proxy Side server_latency_ms client_latency_ms 3.99 6.56 7.03 1.00 Fig. 13: PQC latency operations T ABLE III: Impact of CA security lev el on server-side v alida- tion latency (PQC Proxy). CA Algorithm Server Proxy (ms) T otal SBI Median (ms) ∆ vs ML-DSA-44 (ms) ML-DSA-44 6.48 53.72 - ML-DSA-65 7.03 54.05 +0.33 ML-DSA-87 8.21 55.12 +1.40 while preserving compatibility with existing NFs implementa- tions. T o bridge the gap between NIST PQC standardization and deployable telecommunications security , we proposed and implemented a sidecar proxy architecture that transparently provides post-quantum protection for SBI communication without modifying legacy NF codebases, enabling crypto- agility through a modular security layer . Using free5GC, we experimentally compared three sce- narios, Nativ e HTTPS, TLS Sidecar (Proxy/Wrapper), and PQC Sidecar (Proxy/Wrapper), under a controlled SBI work- load centered on NF registration, discovery , and heartbeat exchanges. The results show that the PQC sidecar increases the end-to-end SBI latency to approximately 54 ms, corre- sponding to an additional 48–49 ms compared to classical TLS. Ho we ver , the ov erhead remains deterministic and largely uniform across NF pairs, with stable distributions that support predictable capacity planning. These findings indicate that transparent PQC insertion via sidecars is operationally viable for control plane signaling with moderate latency tolerance and provides a concrete, immediately applicable migration path that preserv es operator in vestments in the current 5G infrastructure. Our ev aluation focused on control-plane traffic and isolated SBI interactions, leaving user-plane protection outside the current scope. The reliance on a trusted key generation and distribution service introduces a critical dependency that must be hardened for production deployments. Future work should therefore e xtend PQC coverage to user- plane paths, ev aluate hardware acceleration and certificate- validation optimizations for ML-KEM and ML-DSA, in ves- tigate hybrid classical and post-quantum configurations during transition periods, and validate the approach under denser operational regimes such as massiv e Internet of Things (IoT), complemented by broader security analysis of the sidecar design under varied threat models. Overall, by demonstrating a non-disruptive integration ap- proach and quantifying its deterministic performance cost, this study provides a practical foundation for quantum-resistant 5G core deployments as the ecosystem advances toward 6G. In this sense, the proposed sidecar pattern translates NIST- standardized PQC into actionable deployment guidance for operators, enabling incremental adoption of quantum-resilient SB A signaling without inv asive architectural changes. A C K N O W L E D G M E N T The authors thank F APEMIG (Grant #APQ00923-24), F APESP MCTIC/CGI Research project 2018/23097-3 - SFI2 - Slicing Future Internet Infrastructures, and Fundação para a Ciência e T ecnologia (FCT) within the R&D Unit Project Scope UID/00319/2025 - Centro ALGORITMI (ALGO- RITMI/UM) for supporting this work. R E F E R E N C E S [1] R. Zhou, H. Guo, F . E. C. T eo, and S. Bakiras, “ A survey on post-quantum cryptography for 5g/6g communications, ” in 2023 IEEE International Conference on Service Operations and Logistics, and Informatics (SOLI) , 2023, pp. 1–6. [2] S. Hoque, A. A ydeger , E. Zeydan, and M. Liyanage, “ Analysis of post- quantum cryptography in user equipment in 5g and beyond, ” in 2025 IEEE 50th Confer ence on Local Computer Networks (LCN) , 2025, pp. 1–9. [3] S. P . Sanon and H. D. Schotten, “Securing Mobile Networks in the Quantum Era: Imperative Role of Post-Quantum Cryptography, ” in 2025 Joint Eur opean Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit) , Jun. 2025, pp. 721–726, iSSN: 2575-4912. [Online]. A vailable: https://ieeexplore.ieee.or g/document/ 11037057 [4] P . Scalise, M. Boeding, M. Hempel, H. Sharif, J. Delloiacovo, and J. Reed, “ A systematic survey on 5g and 6g security considerations, challenges, trends, and research areas, ” Futur e Internet , vol. 16, no. 3, 2024. [Online]. A vailable: https://www .mdpi.com/1999- 5903/16/3/67 [5] A. Olushola and S. P . Meenakshi, “Design and implementation of an authenticated post-quantum session protocol using ml-kem (kyber), ml- dsa (dilithium), and aes-256-gcm, ” F r ontiers in Physics , vol. V olume 13 - 2025, 2026. [6] Q. D. Truong, H. Nguyen, T . T an Nguyen, and H. Lee, “Nist post- quantum cryptography standards: A comprehensiv e re view of theoretical foundations and implementations, ” IEEE Access , vol. 14, pp. 14 069– 14 097, 2026. [7] C. Zong, “The mathematical foundation of post-quantum cryptography , ” Resear ch , vol. 8, p. 0801, 2025. [Online]. A vailable: https: //spj.science.org/doi/abs/10.34133/research.0801 [8] A. Astarloa, J. Lázaro, and J. I. Gárate, “Crystals-dilithium post- quantum cyber -secure soc for wired communications in critical sys- tems, ” Internet of Things , vol. 33, p. 101656, 2025. [Online]. A vailable: https://www .sciencedirect.com/science/article/pii/S2542660525001702 [9] M. Mahyoub, A. AbdulGhaffar , E. Alalade, E. Ndubisi, and A. Ma- trawy , “Security analysis of critical 5g interfaces, ” IEEE Communica- tions Surveys & T utorials , vol. 26, no. 4, pp. 2382–2410, 2024. [10] M. Mehic, L. Michalek, E. Dervisevic, P . Burdiak, M. Plakalovic, J. Rozhon, N. Mahov ac, F . Richter, E. Kaljic, F . Lauterbach, P . Njem- cevic, A. Maric, M. Hamza, P . Fazio, and M. V oznak, “Quantum cryptography in 5g networks: A comprehensiv e overvie w , ” IEEE Com- munications Surveys & T utorials , vol. 26, no. 1, pp. 302–346, 2024. [11] D. C. Lawo, R. Frantz, A. C. Aguilera, X. A. I. Clemente, M. P . Podle ´ s, J. L. Imaña, I. T . Monroy , and J. J. V . Olmos, “Falcon/kyber and dilithium/kyber network stack on nvidia’ s data processing unit platform, ” IEEE Access , vol. 12, pp. 38 048–38 056, 2024. [12] C. Mangla, S. Rani, N. M. Faseeh Qureshi, and A. Singh, “Mitigating 5g security challenges for next-gen industry using quantum computing, ” Journal of King Saud University - Computer and Information Sciences , vol. 35, no. 6, p. 101334, 2023. [Online]. A v ailable: https://www .sciencedirect.com/science/article/pii/S1319157822002373 [13] F . Dolente, R. G. Garroppo, and M. Pagano, “ A vulnerability assessment of open-source implementations of fifth-generation core network functions, ” Future Internet , vol. 16, no. 1, 2024. [Online]. A vailable: https://www .mdpi.com/1999- 5903/16/1/1 [14] R. Pell, M. Shojafar, D. K osmanos, and S. Moschoyiannis, “Service classification of network traffic in 5g core networks using machine learning, ” in 2023 IEEE International Confer ence on Edge Computing and Communications (EDGE) , 2023, pp. 309–318. [15] S. Aldas and A. Babakian, “Cloud-Native Service Mesh Readiness for 5G and Beyond, ” IEEE Access , vol. 11, pp. 132 286–132 295, 2023. [Online]. A vailable: https://ieeexplore.ieee.or g/abstract/document/ 10327727 [16] G. Alagic, M. Bros, P . Ciadoux, D. Cooper , Q. Dang, T . Dang, J. Kelse y , J. Lichtinger, Y .-K. Liu, C. Miller et al. , Status report on the fourth r ound of the nist post-quantum cryptography standar dization pr ocess . US Department of Commerce, National Institute of Standards and T echnology , 2025. [17] J. A. Montenegro, R. Rios, and J. Bonilla, “Comparative analysis of post-quantum handshake performance in quic and tls protocols, ” Computer Networks , vol. 275, p. 111957, 2026. [Online]. A vailable: https://www .sciencedirect.com/science/article/pii/S1389128625009223 [18] I. Gorbenko, Y . Kachko, and Y . Derevianko, “Optimization of digital signature calculation and verification operations for the fips 205 standard. part 2, ” Radiotekhnika , no. 222, p. 7–21, Sep. 2025. [Online]. A vailable: http://rt.nure.ua/article/view/343463