PQC Validator: Closing 5G Core's Silent Crypto Gap

Last updated: June 2025

Key Takeaways

• A 5G Network Function can advertise ML-KEM-768, negotiate a hybrid KEM, and still authenticate with classical ECDSA-P256 — all without triggering a single alert in existing scanners like testssl.sh, sslyze, or Qualys.
• PQC Validator (arXiv:2605.01454) introduces a five-layer framework — PQ Crypto Engine (L1) through PQ Overhead Meter (L4) plus an eBPF Attestation Plane — that extracts wire-level ground truth and classifies every endpoint as classical, hybrid-pq, or full-pq.
• Organizations deploying PQ cryptography in 5G Core today without wire-level attestation are accepting a compliance posture they cannot verify — and a quantum-vulnerable attack surface they cannot see.

[IMAGE: Macro shot of a 5G radio access node circuit board with entangled cyan light beams representing ML-KEM key exchange, dark background with deep blacks, cinematic lighting revealing cryptographic algorithm labels etched into silicon traces, 8K quality, no human faces or UI elements]

The Problem: PQ Deployment Is Not PQ Security

Your 5G Core vendor’s release notes confirm ML-KEM-768 support. Your procurement checklist shows NIST FIPS 203 compliance. Your architecture diagram shows hybrid KEM on every Service-Based Interface. On paper, your control plane is post-quantum ready.

On the wire, it may not be.

A Network Function (NF) operating inside a cloud-native 5G Core can simultaneously advertise ML-KEM-768 support, complete a hybrid KEM handshake, and then authenticate the session using ECDSA-P256 — a classical elliptic curve algorithm that a sufficiently powerful quantum computer breaks with Shor’s algorithm. That same NF might present an ML-DSA leaf certificate anchored to a classical certificate chain, or skip mutual TLS entirely on the N4 reference point between the SMF and UPF.

None of these failures generate an error. None appear in logs. None are detectable by any scanner currently in production use.

This is the core finding of “PQC Validator: Validating Post-Quantum Readiness in Cloud-Native 5G Core Networks”, published on arXiv (paper ID: 2605.01454v1). The research identifies a structural gap between PQ algorithm deployment and PQ security assurance — and proposes a concrete framework to close it.

Why 5G Core Is the Highest-Risk Surface Right Now

Cloud-native 5G Core networks run on Kubernetes, expose hundreds of NF endpoints over HTTP/2-based Service-Based Interfaces, and interconnect via IPsec-protected N2, N3, and N4 reference points. The 3GPP security specification — TS 33.501 — governs the cryptographic requirements for these interfaces, and IETF drafts are actively extending it to cover PQ-TLS 1.3 and PQ-IPsec.

Operators and vendors are already advertising PQ-TLS 1.3, PQ-IPsec, and hybrid KEM support across these interfaces. The migration is underway. The problem is that the tooling ecosystem has not kept pace.

“Deploying PQ primitives does not guarantee PQ security. A Network Function may advertise ML-KEM-768 and silently fall back to X25519; negotiate a hybrid KEM but authenticate with ECDSA-P256; present an ML-DSA leaf on a classical chain; or skip mutual TLS altogether. These failures are silent on the wire.” — PQC Validator research paper, arXiv:2605.01454v1

Existing tools operate at the wrong layer. testssl.sh, sslyze, and Qualys were built to audit classical TLS deployments. They parse certificate chains, check cipher suite ordering, and flag deprecated algorithms — but they have no awareness of ML-KEM key encapsulation, ML-DSA signature verification, or the hybrid KEM constructions that combine X25519 with ML-KEM-768. They are, in the paper’s framing, “PQ-unaware and telecom-blind.”

Existing 5G-specific fuzzers share the same blind spot. They test protocol conformance against 3GPP specifications but do not validate whether the cryptographic algorithms actually negotiated on the wire match what the NF advertised in its NRF OpenAPI registration.

The attack surface this creates is not theoretical. A harvest-now-decrypt-later adversary intercepting 5G control-plane traffic today — subscriber authentication vectors, session management signaling, policy enforcement messages — needs only the eventual availability of a cryptographically relevant quantum computer to retroactively decrypt it. If your NFs are silently falling back to X25519, that traffic is already harvested and already vulnerable.

Technical Deep-Dive: How PQC Validator Works

The Five-Layer Architecture

PQC Validator is a layered framework comprising five components that together cover the full control-plane cryptographic surface of a cloud-native 5G Core.

L1 — PQ Crypto Engine: An independent PQ-TLS 1.3 client and server implementation. Rather than relying on the NF’s own TLS stack to report what it negotiated, L1 initiates and terminates connections using its own ML-KEM-768 and ML-DSA implementations, providing a ground-truth reference for what the NF actually supports versus what it claims.

L2 — PQ Conformance Prober: Validates that NF behavior aligns with 3GPP TS 33.501, NIST FIPS 203/204/205, and emerging IETF drafts. The compliance suite spans TLS, PQC algorithm correctness, 3GPP SBI conformance, NRF OpenAPI schema validation, and security hardening baselines. An NF that advertises ML-DSA but signs with ECDSA-P256 fails L2.

L3 — PQ Robustness Tester: A protocol fuzzer that exercises CVE-class regressions and downgrade paths. This layer specifically targets the negotiation phase — probing whether an NF that supports ML-KEM-768 can be forced into X25519 through malformed ClientHello extensions, version rollback attempts, or algorithm stripping attacks.

L4 — PQ Overhead Meter: Measures the performance cost of PQ algorithm adoption across the SBI, N2, N3, and N4 reference points. This layer provides the data security architects need to make informed decisions about where to deploy full-pq versus hybrid-pq configurations without degrading control-plane latency.

eBPF Attestation Plane: The component that makes the other four layers meaningful. Using eBPF, XDP, and TC (Traffic Control) hooks, this plane intercepts live traffic at the kernel level and extracts the actual cryptographic groups and signature algorithms negotiated on the wire — independent of what any NF reports through its management interface. This is the ground truth layer.

Endpoint Classification: The Three-State Model

Every NF endpoint assessed by PQC Validator receives one of three classifications:

The distinction between hybrid-pq and full-pq matters operationally. An NF classified as hybrid-pq provides forward secrecy against a quantum adversary for the key exchange — but if it authenticates with ECDSA-P256, a quantum attacker can forge authentication and impersonate that NF. The endpoint is not fully protected.

The Kubernetes-Native Discovery Layer

PQC Validator includes a Kubernetes-native UI that auto-discovers NFs within a 5G Core deployment. In a cloud-native environment where NF instances scale horizontally and NRF registrations change dynamically, static endpoint lists become stale within hours. Auto-discovery ensures that every NF instance — including newly spun-up replicas — is included in the attestation scope.

The eBPF Attestation Plane is the architectural innovation that separates PQC Validator from every existing scanner. By extracting wire-level cryptographic evidence at the kernel layer — independent of NF self-reporting — it closes the gap between what an operator believes is deployed and what is actually protecting traffic.

Industry Context: The Compliance Clock Is Running

NIST and 3GPP Timelines

NIST finalized three post-quantum cryptography standards in 2024:

• FIPS 203: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) — the standard covering ML-KEM-768
• FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
• FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Standard)

3GPP TS 33.501 governs 5G security architecture and is the baseline specification that PQC Validator validates against. IETF working groups are actively drafting extensions that will bring PQ-TLS 1.3 and PQ-IPsec requirements into the standards track.

The compliance burden for telecom operators is compounding: they must satisfy NIST FIPS requirements for algorithm selection, 3GPP TS 33.501 for interface-level security, and emerging IETF drafts for protocol-level PQ integration — across four reference points (SBI, N2, N3, N4) simultaneously.

Who Is Moving, Who Is Lagging

Operators and vendors are beginning to advertise PQ-TLS 1.3, PQ-IPsec, and hybrid KEM support in product roadmaps and release notes. The advertisement is ahead of the verification. No standardized assurance framework for PQ readiness in 5G Core existed before PQC Validator’s publication — meaning operators accepting vendor attestations of PQ compliance have had no independent means of verification.

The scanner ecosystem — testssl.sh, sslyze, Qualys — serves the enterprise web application security market and has no roadmap for 5G SBI or IPsec interface coverage. 5G-specific security tooling has focused on protocol fuzzing and signaling-layer attacks, not cryptographic algorithm attestation.

The Economic Case for Acting Now

The cost of PQ migration increases with delay for two reasons. First, every classical-only or hybrid-pq endpoint deployed today becomes a remediation item when regulators formalize PQ compliance mandates — and renegotiating vendor contracts for cryptographic upgrades is expensive. Second, harvest-now-decrypt-later exposure accumulates linearly with time. Control-plane traffic intercepted today remains vulnerable for as long as the underlying algorithms remain unbroken — and the timeline for cryptographically relevant quantum computers, while uncertain, is shortening.

Organizations that deploy PQC Validator now establish a baseline attestation record: which endpoints are full-pq, which are hybrid-pq, and which are silently classical. That record becomes the foundation for vendor accountability conversations and regulatory audit responses.

The BeQuantum Perspective: Wire-Level Truth Over Configuration Claims

At BeQuantum, we encounter the same gap PQC Validator identifies — but across enterprise environments rather than telecom infrastructure. Organizations deploy PQ-capable libraries, update their TLS configurations, and receive vendor confirmation of ML-KEM support. Then our Digital Notary layer performs wire-level attestation and finds hybrid-pq endpoints authenticating with classical certificates, or full-pq advertised algorithms falling back under load.

The architectural principle PQC Validator establishes — that cryptographic assurance requires independent wire-level verification, not configuration inspection — is the same principle underlying BeQuantum’s PQC Layer. Configuration files can be correct while runtime behavior diverges. Certificate chains can include ML-DSA leaves while the root of trust remains classical. The only authoritative source of truth is what actually traverses the wire.

For organizations operating or procuring cloud-native 5G Core infrastructure, the eBPF Attestation Plane approach PQC Validator describes maps directly to what a mature PQ security posture requires: continuous, kernel-level cryptographic monitoring that classifies every session independently of NF self-reporting.

The three-state classification model — classical, hybrid-pq, full-pq — also provides the structured evidence format that compliance teams need. Auditors and regulators will not accept “we deployed ML-KEM-768” as evidence of PQ compliance. They will require endpoint-level attestation records showing negotiated algorithms, authentication mechanisms, and certificate chain composition. PQC Validator’s structured PQ evidence output is the format that conversation needs.

What You Should Do Next

Within 30 days: Map your 5G Core cryptographic attack surface. Enumerate every NF endpoint across your SBI, N2, N3, and N4 reference points. For each endpoint, document the advertised PQ algorithms from NRF OpenAPI registrations. This inventory is the prerequisite for any attestation exercise — and most operators discover they lack a complete, current list.

Within 90 days: Audit your TLS certificate chains for classical anchors. An ML-DSA leaf certificate on a classical root CA is a hybrid-pq configuration at best, and a compliance gap at worst. Pull the full certificate chain for every NF endpoint and verify that the root of trust is PQ-capable, not just the leaf. Pay particular attention to N4 interface certificates, where mutual TLS is most frequently skipped or misconfigured.

Within 180 days: Implement wire-level cryptographic attestation. Whether through PQC Validator, BeQuantum’s PQC Layer, or an equivalent eBPF-based monitoring approach, establish a continuous attestation pipeline that classifies endpoints by actual negotiated algorithms — not advertised capabilities. Set alerting thresholds for any endpoint that regresses from hybrid-pq to classical, and establish a remediation SLA for full-pq migration on high-priority interfaces.

Frequently Asked Questions

Q: If my 5G Core vendor confirms ML-KEM-768 support in their release notes, why do I need independent wire-level validation?

A: Vendor release notes confirm that ML-KEM-768 is implemented in the software — not that it is negotiated in every session under all network conditions. A Network Function can support ML-KEM-768 and still fall back to X25519 when a peer does not advertise PQ support, when a load balancer strips PQ extensions, or when a misconfigured policy prioritizes classical algorithms. Wire-level attestation via eBPF captures what actually happens during live sessions, not what the configuration intends.

Q: What is the difference between hybrid-pq and full-pq, and does hybrid-pq provide adequate protection today?

A: A hybrid-pq configuration combines a classical algorithm (X25519) with a PQ algorithm (ML-KEM-768) for key exchange, ensuring that a quantum attacker who breaks the classical component cannot derive the session key. However, if authentication uses ECDSA-P256, a quantum attacker can forge NF identity and execute man-in-the-middle attacks. Full-pq requires both ML-KEM-768 key exchange and ML-DSA authentication throughout. Hybrid-pq is an acceptable transitional posture for key exchange, but classical authentication in a hybrid-pq deployment remains a material vulnerability.

Q: Do existing enterprise security scanners cover 5G Core PQ validation?

A: No. testssl.sh, sslyze, and Qualys were designed for classical TLS in web application contexts. They have no awareness of ML-KEM key encapsulation mechanisms, ML-DSA signature verification, or the 3GPP SBI and IPsec interface structures that 5G Core uses. They cannot parse NRF OpenAPI registrations, do not cover N2/N3/N4 reference points, and cannot detect the silent fallback scenarios that PQC Validator was specifically designed to identify.