Make the traffic you carry unreadable to whoever collects it in bulk.
Post-quantum TLS across core, backhaul and interconnect without re-platforming, CNSA 2.0 on the federal circuits you carry, and a quantum-safe service you can sell.
Q-day is uncertain. The requirements for telecom are not.
Nobody knows when a cryptographically relevant quantum computer will arrive (Q-day), but your cryptography requirements do not depend on that date. Four reasons to start now:
AI is already finding weaknesses in algorithms
Anthropic’s Claude Mythos preview found serious weaknesses in candidate algorithms without a quantum computer. Cryptography can fail before Q-day arrives.
Adversaries are harvesting encrypted data now
They are collecting subscriber identity and session data which are collected in bulk, to decrypt when Q-day arrives: harvest now, decrypt later.
Regulators already require PQC migration
For a carrier that means the strong TLS, modern cryptography and visibility CISA’s communications-infrastructure hardening guidance asks for, the post-quantum playbook GSMA PQ.03 and PQ.07 set out for core, RAN and SIM authentication, and CNSA 2.0 on any federal circuit carried.
Estimates for Q-day keep shrinking
Google has set 2029 as the target for its own migration. If yours is not finished in time, the foundation of core, backhaul and interconnect security is at risk.
Google’s 2029 target and resource estimates: QuSecure, April 2026. NIST IR 8547, initial public draft, November 2024. Anthropic, Claude Mythos preview, 2026.
Why use QuProtect?
Cryptography belongs in a layer you control and configure, not in application code.
No rewrite, no rip-and-replace
QuProtect moves critical and legacy systems to PQC in a fraction of the time and cost.
Discovery and remediation in one platform
Many PQC solutions stop at discovery and leave the fix to you.
Built for large, complex organizations with highly sensitive traffic
Developed with the U.S. Army and U.S. Air Force.
Nothing is re-coded
A carrier cannot take the core down to re-code it, so QuProtect does not ask for it.
The next migration is a configuration change
It is made from an Orchestrator you control, not run as another program.
Proven in production
Banco Sabadell validated post-quantum TLS in four months.
Use case in action
Your network, from the cryptography it runs today to the policy change that keeps it current. Move through the five steps, or click a number on the drawing.
-
RAN and edge
- gNodeB sites cannot be upgraded
- Backhaul cannot be upgraded
- Subscriber CPE cannot be upgraded
-
Core
- Packet core
- Subscriber data and HSS
- OSS and BSS
-
Interconnect (not yours to change)
- Roaming and IPX partners
- Federal and defense circuits
- Enterprise customers
Legacy cryptography, and what Q-day does to it
gNodeB sites, backhaul and subscriber CPE reach the packet core on the TLS they were built with, and the core reaches roaming partners, federal circuits and enterprise customers on TLS 1.2 with RSA key exchange. Traffic recorded today can be stored until a quantum computer running Shor’s algorithm recovers those keys, and a carrier’s traffic is collected in bulk.
Sensors find the legacy negotiations and rank the violations
Reconnaissance sensors read what is on the wire across core, RAN, backhaul and interconnect and record the cipher suites, protocols, certificates and keys in use, without touching a network function. Each policy violation is ranked by severity: the RAN and edge hops first, RSA key exchange on the interconnect links next.
Encryptors remediate at the network layer
Gateway encryptors at the site and the interconnect edge and sidecars beside the packet core, subscriber data and OSS and BSS carry each hop over TLS 1.3 with NIST post-quantum key exchange, X25519MLKEM768. No re-platforming, and each circuit carries its own policy: CNSA 2.0 on the federal circuit, hybrid post-quantum TLS elsewhere.
Data in transit is secured, and the CBOM proves it
Subscriber traffic recorded from now on is not readable by a future quantum computer. The CBOM lists each connection’s protocol, algorithm and certificate with no open violations, reported per circuit, which is also the quantum-safe service a carrier has to sell.
Crypto-agility: the next algorithm is a policy change
When a standard moves, the Orchestrator pushes the new policy to each encryptor and the connections renegotiate, here from ML-KEM-768 to ML-KEM-1024, while traffic keeps flowing. The program does not start again.
Other use cases
Estate-wide cryptographic inventory
A CBOM across core, RAN, backhaul and interconnect, the visibility CISA’s hardening guidance asks for.
Interconnect and roaming gateways
Partner links carry post-quantum TLS to the carrier’s edge with per-partner identities, and end to end where the partner negotiates it.
Subscriber CPE fleets
Edge equipment that cannot be re-platformed sits behind gateway encryptors.
A quantum-safe service to sell
Quantum-safe slices and connectivity tiers built on the same overlay.
Backhaul and RAN-to-core protection
Gateway encryptors at the site carry backhaul over post-quantum mutual TLS without re-platforming.
CNSA 2.0 on federal circuits
Federal and defense circuits carry their own policy from the same Orchestrator, ahead of the acquisition gate.
Certificates at carrier scale
Automated provisioning and rotation across the estate.
Algorithm change by policy
The next standard is a policy push across the estate, not another program.
Telecom case study
Post-quantum TLS across existing infrastructure.
A Tier-1 operator deployed post-quantum TLS across existing infrastructure without rewriting legacy applications, against years of cryptographic debt.