Quantum-Safe Cryptography for 5G/6G: NIST Standards and Migration Path

# Quantum-Safe Cryptography for 5G/6G: NIST Standards and Migration Path

The quantum computer that breaks RSA-2048 doesn't exist yet. The data it will eventually decrypt is being recorded today. That's the entire reason post-quantum cryptography (PQC) is now a live operational concern, not a research topic.

NIST finalized the first PQC standards in August 2024 as FIPS 203, 204, and 205. By April 2026 we have 18 months of implementation experience and the picture is clearer. Here's what telecom engineers actually need to know.

The Three NIST Standards

FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber) — Module-Lattice-based Key Encapsulation Mechanism. Replaces RSA and ECDH key exchange. Three parameter sets: ML-KEM-512, 768, 1024. ML-KEM-768 is the recommended default for most use cases. Public keys are around 1184 bytes, ciphertexts 1088 bytes. Fast in software, faster in hardware. FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium) — Module-Lattice Digital Signature Algorithm. Replaces RSA and ECDSA signatures. Three parameter sets: 44, 65, 87. ML-DSA-65 is the typical default. Signatures are around 3293 bytes — much larger than ECDSA. FIPS 205 (SLH-DSA, formerly SPHINCS+) — Hash-based stateless signatures. Conservative fallback if lattice cryptography is broken. Signatures are 7-49 KB depending on parameters. Slow signing, fast verification. Use it for firmware signing and root-of-trust where signature size doesn't matter.

NIST is also standardizing Falcon (FN-DSA) — smaller signatures than ML-DSA but harder to implement constant-time. Draft FIPS 206 is in progress.

Where 5G Crypto Is Actually Vulnerable

Not every cryptographic primitive in 5G is at quantum risk. Symmetric ciphers (SNOW, AES, ZUC) just need bigger keys — AES-256 is fine against Grover's algorithm. The kill zone is asymmetric crypto.

The specific 5G points that need migration:

1. SUPI/SUCI concealment. Defined in TS 33.501 Annex C. Uses ECIES with curve25519 or P-256. Quantum-vulnerable. The IMSI catcher problem returns when CRQCs (cryptographically relevant quantum computers) arrive. ETSI SAGE and 3GPP SA3 are studying ML-KEM variants.
2. Network function authentication. N32 interface between SEPPs uses TLS 1.3. Service-based architecture interfaces (Nnrf, Namf, etc.) use OAuth 2.0 with JWS — RSA or ECDSA signed. All quantum-vulnerable.
3. IPSec for backhaul. IKEv2 uses Diffie-Hellman or ECDH for key exchange. RFC 9370 defines hybrid PQC IKE — combine classical and PQC key exchanges.
4. TLS for OAM, exposure APIs, and roaming. Standard X.509 PKI throughout.
5. Subscriber credential provisioning. eSIM remote provisioning (SGP.22, SGP.32) uses ECDSA. GSMA started PQC work in 2025.
6. Certificate authorities. Root and intermediate CAs across telecom infrastructure. Long-lived certs are the highest priority.

The Harvest Now, Decrypt Later Threat

The reason this matters before quantum exists: nation-state adversaries are recording encrypted traffic today and storing it. When CRQCs arrive — most credible estimates put a Q-day for RSA-2048 between 2030 and 2040 — that recorded traffic gets decrypted retroactively.

For most application data, this isn't catastrophic. Today's WhatsApp messages won't matter in 2035. For telecom infrastructure it's worse: SUPI values, long-lived enterprise data, lawful intercept records, classified government communications carried over commercial networks. Anything with a confidentiality lifetime over 10 years is at risk now.

Migration Realities

The NIST PQC migration playbook (NIST SP 1800-38, with updates through 2025) is the reference. Real operators are already in phases 1-2:

Phase 1 — Crypto inventory. You can't migrate what you can't find. Scan every NF, every interface, every certificate. Most operators discover 30-50% more cryptographic dependencies than they expected. Vendor firmware is often a black box. Phase 2 — Hybrid deployment. Don't rip-and-replace. Run classical + PQC in parallel using hybrid key exchange (classical and PQC outputs concatenated and hashed). RFC 9370 for IKEv2, draft-ietf-tls-hybrid-design for TLS 1.3. If PQC is broken (lattice attacks have improved over 2023-2025 but no breaks yet), classical still protects you. If quantum arrives, PQC saves you. Phase 3 — Performance tuning. ML-KEM is fast. ML-DSA signatures are 30-70x larger than ECDSA. This breaks assumptions in protocols built around small signatures — DNS, certificates, OCSP, OAuth tokens. Plan for MTU issues and certificate chain bloat. Phase 4 — Decommission classical. Probably 2030-2035 for greenfield, longer for legacy.

What Operators Should Be Doing in 2026

The gap between leaders and laggards is now obvious. The leaders:

• Have completed crypto inventories and assigned each asset a PQC migration priority based on data lifetime and exposure.
• Are running hybrid TLS 1.3 (X25519 + ML-KEM-768) on internal SBA interfaces in lab and pilot environments.
• Are demanding PQC roadmaps from vendors as part of every RFP issued in 2026.
• Are tracking GSMA PQ.03 and 3GPP SA3 study items.

Laggards are still treating this as a 2030 problem. They're wrong. The 2030 problem is having migrated. The 2026 problem is starting.

Practical Implementation Notes

A few things engineers run into:

• Hardware acceleration is uneven. Most current 5G accelerator cards support ML-KEM but not ML-DSA. Signature verification on the SBA control plane will be CPU-bound for now.
• HSM support is improving. Thales, Entrust, Utimaco have FIPS 203/204 in shipping firmware as of late 2025.
• OpenSSL 3.5 ships ML-KEM and ML-DSA natively. Earlier versions required the oqs-provider plugin.
• Certificate sizes break assumptions. A composite ECDSA + ML-DSA certificate is around 5 KB. Cert chains get into territory that breaks UDP-based protocols.
• Falcon is tempting but treacherous. Smaller signatures than ML-DSA, but the floating-point operations make constant-time implementation hard. Stick with ML-DSA unless you have a specific reason.

The Q-day might be 2030 or 2040 — nobody knows. The data being recorded today is the leverage. Migration timelines are now constrained by data lifetime, not quantum timelines.

Takeaway: Treat PQC migration like Y2K with a fuzzy deadline — start the inventory now, run hybrid in 2026-2028, and make every new vendor contract demand a PQC roadmap.