- ✓The quantum threat is not only a future problem. Long-lived encrypted traffic captured today can be stored and decrypted later once a capable quantum computer exists — the "harvest now, decrypt later" problem — so data with a multi-year confidentiality requirement is already exposed.
- ✓NIST finalized its principal post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. They are ready to deploy now.
- ✓The migration is not a drop-in swap. Post-quantum keys and signatures are substantially larger than today's elliptic-curve equivalents, which changes handshake size, packet overhead, and tunnel-setup behavior — exactly the places a high-scale IPsec deployment already feels pressure.
- ✓The real deliverable is crypto-agility: the ability to change algorithms without re-architecting. Most networks can't currently answer "where is every use of RSA/ECC in our stack?" — and that inventory is step one.
- ✓NIST's transition timeline (IR 8547) deprecates quantum-vulnerable algorithms by 2035, with high-risk systems moving much earlier. The work to get there takes years, which is why "start now" is the actual recommendation, not a slogan.
Most quantum-computing coverage answers the wrong question. It asks when a quantum computer will break RSA, treats it as a distant "someday," and stops there. For a network operator, the useful questions are different: which of my traffic is already at risk, what specifically changes when I move to post-quantum algorithms, and what can I do this year that isn't wasted effort? This post answers those questions.
"Someday" Is the Wrong Frame: Harvest Now, Decrypt Later
The headline risk everyone knows — a large quantum computer running Shor's algorithm could break the public-key cryptography (RSA, Diffie-Hellman, elliptic-curve) that protects key exchange and signatures today — is real but incomplete. Stating it and stopping is the shallow version.
The part that actually changes an operator's timeline is when the exposure begins. Public-key crypto is mostly used to establish session keys; an attacker who records encrypted traffic today can store it and decrypt it the day a cryptographically relevant quantum computer (CRQC) arrives. That is the "harvest now, decrypt later" model, and it moves the deadline forward from "whenever a CRQC exists" to "today, for any data that must stay confidential past that date."
This reframing is what makes the timeline concrete. NIST notes that some experts predict a device capable of breaking current encryption could appear within a decade.[2] If a subset of your traffic — subscriber identity data, lawful-intercept material, inter-site signaling, anything with a 10-year secrecy requirement — needs to stay private beyond that horizon, the harvest risk already applies to it. The correct first move is therefore not "watch the quantum-computing news"; it's to identify which of your data has a confidentiality lifetime long enough to be in scope.
What Actually Changed in 2024: The Standards Are Done
The reason "start now" became actionable in 2024 is that the algorithms stopped being research candidates and became finalized standards. After an eight-year process that assessed 82 submissions from 25 countries, NIST published its first three post-quantum Federal Information Processing Standards on August 13, 2024:[1][2]
- ◆FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber): the primary standard for general encryption / key establishment. This is the one that matters most for securing transport, because it replaces the Diffie-Hellman/ECDH step where session keys are agreed.
- ◆FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, from CRYSTALS-Dilithium): the primary standard for digital signatures and authentication.
- ◆FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, from SPHINCS+): a signature standard built on a different mathematical foundation, intended as a backup in case the lattice-based approach is later weakened.
The practical significance of "two different math families" (lattice-based and hash-based) is diversification: if lattice problems turn out to be more breakable than believed, hash-based signatures don't fall with them. NIST has continued adding to the set — it selected the HQC algorithm as an additional key-encapsulation mechanism in March 2025 — but its guidance is explicit that ML-KEM, ML-DSA, and SLH-DSA can and should be put into use now rather than waiting for backups.[1]
The telecom industry is already organizing around this transition, not waiting for it. The GSMA's Post-Quantum Telco Network work assesses the dependencies and timelines for a quantum-safe migration across the whole ecosystem — operators, network and IT vendors, integrators, and regulators — and centers crypto-agility as the guiding principle for the 5G architecture.[8] In other words, the standards are ready and the industry's own body has mapped the migration; what's left is execution inside each network.
The Cost Networks Feel First: Bigger Keys and Signatures
Here is where a telecom-specific view diverges from the generic "swap your algorithms" advice. Post-quantum algorithms are not free drop-in replacements at the packet level: their keys, ciphertexts, and signatures are materially larger than the elliptic-curve values networks use today. A single handshake carries more bytes, and a network that establishes and re-keys tunnels constantly will feel that.
For a distributed access network terminating large numbers of IPsec tunnels, this lands in three concrete places:
- ✓Handshake size. IKEv2 negotiation that once fit a compact ECDH exchange now carries larger key-establishment and signature payloads, which can push messages toward fragmentation and add round-trip cost.
- ✓Tunnel-setup rate. If every tunnel's establishment is heavier, the gateway's tunnel-setup and re-key throughput — already a scaling constraint at thousands of nodes — is stressed further, not less.
- ✓Compute per session. The cost profile of the cipher work shifts, so a platform sized for classical crypto isn't automatically sized for the post-quantum equivalent under the same load.
None of this is a reason to delay — it's a reason to plan capacity and test under realistic load rather than assume parity. It also connects directly to why the security gateway (SecGW) is a natural control point for the migration: it's where key exchange and tunnel authentication are actually enforced, so it's where post-quantum key establishment gets adopted for transport. If your gateway hides its cryptographic behavior behind fixed firmware, you can't migrate it; if it's built for algorithm change, you can.
Concretely, at NIST security level 3 (the general-use tier), the payload growth is large. These are the sourced figures:
For the highest-assurance contexts, NSA's CNSA 2.0 requires the larger ML-KEM-1024 for key establishment and ML-DSA-87 for signatures in U.S. national-security systems.[6]
For IPsec specifically, this isn't hypothetical: IETF RFC 9370 standardizes multiple key exchanges in IKEv2, letting a gateway run ML-KEM alongside a classical Diffie-Hellman group in the same negotiation[7] — the hybrid approach that delivers harvest-now-decrypt-later protection today while staying interoperable with peers that haven't migrated. The cost lands exactly where a high-scale gateway already feels pressure: larger IKE payloads (risking fragmentation), heavier per-tunnel setup, and more work at every re-key across thousands of tunnels.
The Real Work Is Crypto-Agility, Not a One-Time Swap
The deepest point, and the one most migration coverage misses: the goal is not to replace RSA with ML-KEM once. It's to reach a state where you can change cryptographic algorithms again — because the post-quantum set will itself evolve (SLH-DSA exists precisely because ML-DSA might need replacing). That property is crypto-agility, and most production networks don't have it today.
The failure mode crypto-agility prevents is the one operators already know from every hard-coded dependency: an algorithm baked into firmware, a certificate profile, or a device that can't be updated in the field becomes a forced hardware refresh instead of a config change. During a transition that will run for years and involve more than one algorithm swap, the difference between "update policy" and "replace the box" is the entire cost of the program.
This is also why the honest first step is unglamorous. Before any algorithm changes, you need a cryptographic inventory — where every instance of RSA, ECDH, and ECDSA lives across the RAN transport, core signaling, management plane, PKI, and device fleet, and what the confidentiality lifetime of the data on each path is. Most teams cannot produce that inventory on demand, and you cannot prioritize a migration you can't see.
What Telecom Operators Should Do Now
Concrete, non-wasted actions available today — none of which require waiting for a quantum computer or for further standards:
- 1 Build the cryptographic inventory. Map every use of quantum-vulnerable public-key crypto across transport, core, management, and PKI, tagged with the data's confidentiality lifetime. This is the artifact everything else depends on.
- 2 Prioritize by data lifetime, not by system. Traffic and keys that must stay secret past the ~10-year horizon are the harvest-now-decrypt-later targets; migrate those first, regardless of which subsystem they sit in.
- 3 Demand crypto-agility in procurement. For any new gateway, core element, or PKI, require documented support for algorithm change and a stated post-quantum roadmap — not a fixed cipher set. Treat "can this be migrated without a hardware swap?" as a gating question.
- 4 Test post-quantum key exchange under realistic load. Validate ML-KEM in IKEv2 (including hybrid classical-plus-PQC modes designed for exactly this transition) against your real tunnel counts, packet sizes, and re-key rates — not a single lab handshake.
- 5 Map your program to the published timelines. NIST IR 8547 deprecates quantum-vulnerable algorithms by 2035, with high-risk systems earlier.[3] For a sharper, transport-specific anchor, NSA's CNSA 2.0 timeline requires national-security systems to support and prefer post-quantum algorithms in traditional networking equipment such as VPNs and routers by 2026, and to use them exclusively by 2030 — with the overall NSS transition complete by 2035.[9] Even if you aren't bound by NSS rules, that schedule signals where vendor support and procurement expectations are heading; back-plan from it, accounting for the multi-year reality that full integration takes time.
If your current gateway shows several of the constraints in 7 signs your network has outgrown its security gateway, a platform that also has no post-quantum path is compounding two problems into one refresh — worth factoring into the timing of any upgrade.
Where This Fits With Zero Trust
Post-quantum readiness and zero trust reinforce each other. Zero trust already assumes no connection is implicitly trusted and every session is authenticated on its own terms; PQC is what keeps that authentication and the resulting key exchange sound against a future quantum adversary. Neither replaces the other — a quantum-safe tunnel to an unauthenticated peer is still a problem, and a well-authenticated tunnel using quantum-vulnerable key exchange is a harvest-now target. The two are layers of the same defensible boundary, which is why the transport security layer is the practical place to invest in both.
Plan Your Migration on Infrastructure That Can Move
Quantum-ready encryption is less about any one algorithm and more about whether your network can change algorithms at all. Talk to Nybsys about evaluating your transport-security layer for crypto-agility as you plan the transition.
Talk to NybsysFrequently Asked Questions
Is the quantum threat real yet, or is this hype?+
Both a real risk and often overhyped on timing. No public quantum computer can break RSA today. But "harvest now, decrypt later" means data captured today can be decrypted once such a machine exists, so any information with a long confidentiality lifetime is already exposed. The practical response is to start migrating long-lived-secret traffic now, not to panic about today.
What are FIPS 203, 204, and 205?+
They are NIST's finalized post-quantum cryptography standards, published in August 2024. FIPS 203 (ML-KEM) handles key establishment; FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) handle digital signatures, using two different mathematical foundations for diversity. NIST says they are ready for use now.
Why can't we just swap the algorithms when a quantum computer appears?+
Because a migration across a large network takes years, and much of the at-risk data has a confidentiality lifetime longer than that. Waiting also assumes your systems are agile enough to swap on demand — most aren't. The value is in achieving crypto-agility before you're forced to use it.
Does post-quantum encryption slow the network down?+
It changes the cost profile. Post-quantum keys and signatures are larger than elliptic-curve equivalents, so handshakes carry more bytes and tunnel setup is heavier. Whether that's noticeable depends on your tunnel counts, re-key rates, and gateway capacity — which is why it should be tested under realistic load rather than assumed.
What is the single most useful first step?+
A cryptographic inventory: knowing where every use of quantum-vulnerable public-key crypto lives and how long the data it protects must stay secret. You can't prioritize or plan a migration you can't see.
References
- NIST — Post-Quantum Cryptography project (FIPS 203/204/205) — csrc.nist.gov/projects/post-quantum-cryptography
- NIST — "NIST Releases First 3 Finalized Post-Quantum Encryption Standards" (Aug 13, 2024) — nist.gov
- NIST IR 8547 — Transition to Post-Quantum Cryptography Standards — csrc.nist.gov/pubs/ir/8547/ipd
- NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM) — doi.org/10.6028/NIST.FIPS.203
- NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA) — doi.org/10.6028/NIST.FIPS.204
- NSA — Commercial National Security Algorithm Suite 2.0 (ML-KEM-1024 + ML-DSA-87 for NSS), per the NSA-authored IETF profile "CNSA Suite Profile for S/MIME" (Becker & Jenkins, NSA, 2025) — ietf.org
- IETF RFC 9370 — Multiple Key Exchanges in IKEv2 (2023) — rfc-editor.org/rfc/rfc9370
- GSMA — "PQ.1 Post-Quantum Telco Network: Impact Assessment" whitepaper (Feb 2023) — gsma.com
- NSA — "Announcing the Commercial National Security Algorithm Suite 2.0" (Cybersecurity Advisory PP-22-1338, Sept 2022); transition timeline, p.6 — media.defense.gov