The threat: harvest now, decrypt later
Quantum-safe networking is driven by a threat that is already active — adversaries capturing encrypted traffic today to decrypt once a quantum computer exists.+
If a message’s confidentiality lifetime outlasts Q-Day, it is already at risk. The deadline is not when quantum computers arrive — it is how long today’s data must stay secret.
The exposure is asymmetric in time. Shor’s algorithm solves integer factorisation and discrete logarithms in polynomial time, collapsing RSA and elliptic-curve schemes (ECDH, ECDSA) — the asymmetric primitives that establish and authenticate keys. Symmetric ciphers are only weakly affected: Grover’s algorithm gives at most a quadratic speed-up on brute-force search, so AES-256 keeps roughly 128-bit effective strength and stays sound. The break is in key establishment, not bulk encryption — which is why a quantum-safe strategy centres on how symmetric keys are agreed and delivered, and lets AES-256-GCM keep protecting the data plane.
Estimates for a cryptographically relevant quantum computer vary widely — breaking RSA-2048 is put at the order of a few thousand logical, error-corrected qubits, far beyond today’s noisy hardware — but the real deadline is set by data confidentiality lifetime + migration time measured against that arrival. For records that must stay secret for a decade or more, the safety margin may already be negative.
Driver 1 — The standards will keep changing
FIPS 203, 204 and 205 are final, but the landscape is still moving: HQC was selected in 2025 (not yet final), FIPS 206 is in draft, and cryptanalysis continues.
Crypto-agility — swapping algorithms by configuration, not hardware refresh — is the only strategy that survives a standards landscape guaranteed to keep changing.
The finalised standards rest on deliberately different mathematics. ML-KEM (FIPS 203) and ML-DSA (FIPS 204) derive security from Module-Learning-With-Errors over structured lattices; SLH-DSA (FIPS 205) is stateless hash-based, resting only on hash preimage and collision resistance — slower and larger, but highly conservative. HQC, selected in 2025 as a backup KEM, is code-based, so a break in lattice assumptions would not fell it alongside ML-KEM.
Migration is not a drop-in. ML-KEM public keys and ciphertexts are ~1–1.5 kB (versus ~32 bytes for X25519); ML-DSA signatures run to a few kilobytes and SLH-DSA to tens of kilobytes — inflating handshakes, certificate chains and packets on constrained links. With confidence in these young schemes still maturing, the prevailing posture is hybrid: run a classical and a post-quantum primitive together so the channel holds unless both fail. In TLS 1.3 this is the X25519MLKEM768 named group, whose shared secret concatenates the X25519 and ML-KEM-768 secrets — now default in mainstream stacks; IKEv2 gains the same property through RFC 9370 (multiple key exchanges) and RFC 8784 (post-quantum pre-shared keys). Crypto-agility is precisely what lets an operator move hybrid → pure-PQC, swap ML-KEM for HQC, or adopt a sovereign variant as a policy change rather than a forklift upgrade.
Driver 2 — There is no single right algorithm
Four quantum-safe approaches sit on a spectrum from physics-based to purely mathematical. None dominates; each fits a different threat model and constraint.
QKD’s security rests on physics but is distance-limited and relay-dependent; PQC deploys in software today but is not guaranteed forever. They will coexist for a long time.
QKD’s guarantee is physical. Protocols such as decoy-state BB84 encode key bits in single-photon states; any interception disturbs them and raises the quantum bit error rate (QBER), which the endpoints monitor to bound an eavesdropper’s information before privacy amplification distils the final secret. This is information-theoretic security for the key — independent of the attacker’s compute — but only under real assumptions: an authenticated classical channel (itself bootstrapped with symmetric or PQC authentication), implementations free of exploitable side channels, and a hard distance ceiling.
Fibre photon loss is exponential, so secret-key rate falls steeply with distance and repeaterless links top out around a few hundred kilometres; going further today means trusted-node relays (which see the key) or advanced protocols — measurement-device-independent QKD, which closes detector side channels, and twin-field QKD, which extends range — still largely confined to field trials.
PQC has the mirror-image profile: it runs in software on existing hardware and scales to the whole internet, but rests on computational assumptions that cryptanalysis can erode — as the SIKE isogeny scheme was, abruptly, in 2022. Sovereign PQC and BYOA are governance choices layered on that same computational model, letting a nation or organisation mandate or supply its own vetted algorithm. Because each option fails in a different way, mature designs keep more than one on hand.
Driver 3 — The multi-OEM reality
Real networks mix vendors, each with its own siloed key management and upgrade cycle. Solving quantum safety box-by-box reproduces the fragmentation it is meant to fix.
With no common control plane, a single un-upgraded segment breaks the promise of end-to-end quantum safety.
The friction bites at the key-management layer. Each vendor’s encryptor expects keys from its own manager over a proprietary interface; none can consume another’s key material or present a shared policy, rotation schedule or audit surface. Retrofitting quantum-safe keys per platform therefore becomes N independent integration projects, each gated on that vendor’s roadmap and each carrying its own assurance evidence — and end-to-end safety is only as strong as the weakest hop, since a single classical key-agreement anywhere in the path reintroduces harvest-now exposure for every flow that crosses it.
The approach: a Hybrid QKDN overlay
Instead of embedding quantum-safe crypto into every vendor’s box, build a vendor-neutral overlay that delivers quantum-safe keys to every box — sourced from whichever technology fits.
Encryptors request a key and receive one; they neither know nor care whether it came from QKD, PQC, a sovereign variant, or a custom algorithm. That turns an irreversible bet into a per-link setting.
The overlay decouples key generation from key consumption. In each site a Key Management Entity (KME) pools key material from whatever sources attach — QKD modules, a PQC key-agreement service, a sovereign or custom engine — and serves it to encryptors (Secure Application Entities, SAEs) over the standardised ETSI GS QKD 014 REST interface on mutually-authenticated HTTPS. An encryptor calls GET_KEY and receives symmetric key material plus a key_ID; its peer calls GET_KEY_WITH_KEY_IDS with that identifier and obtains the identical key. Both encryptors keep running AES-256-GCM on the data plane — only the source of the symmetric key changes. Because the interface is source-agnostic, moving a link from PQC to QKD, or adding a sovereign algorithm, is a configuration action behind the same API. The one control plane onboards nodes, distributes configuration, rotates keys and exposes FCAPS telemetry across every OEM.
A standards-based layered model
The overlay productises the ITU-T QKDN reference model — four layers, with interworking between providers defined in Y.3810 (2024).
The model separates fragile physics from stable service. The quantum layer runs the QKD protocol between QKD Entities (QKDEs) and outputs raw key; the key-management layer (KMS / KME) buffers it, relays across trusted nodes, and serves it via the 014 and 004 APIs; the control layer handles routing, sessions and resource allocation (increasingly SDN-driven per Y.3805); the management layer runs FCAPS. Clean boundaries are what let a PQC or satellite source slot in beneath an unchanged key-supply interface — and let one provider’s network hand keys to another’s under the Y.3810 interworking framework, via gateway and interworking functions, without exposing internal topology.
Heterogeneous by design
One fabric federates terrestrial fibre, software-based ‘Digital QKD’, and free-space / satellite links under central management.
In the conventional trusted-relay model, intermediate nodes see the key in the clear and must be secured — a known limitation and active area of standards work.
Terrestrial fibre QKD suits metro and regional spans inside the loss budget; between distant sites, trusted-node relays chain links at the price of trusting each relay’s physical security. “Digital QKD” substitutes a software PQC key-agreement service where optics are impractical, delivering keys through the same KME/SAE interface so consumers cannot tell the difference. Free-space and satellite QKD bridge spans no fibre can reach — a satellite acting as a trusted relay between far-apart ground stations. Federating all three under one manager lets an operator match method to segment — physics where it pays, algorithms where it scales — and re-route as conditions change.
Where to integrate
Keys can be injected wherever the operator already encrypts — at Layer 1, 2 or 3 — rather than forcing a single insertion point.
At Layer 1, keys feed optical-transport encryption for line-rate bulk protection at minimal latency. At Layer 2 they key MACsec (IEEE 802.1AE) for Ethernet and data-centre interconnect. At Layer 3 they enter IPsec/IKEv2 — through RFC 8784 post-quantum pre-shared keys or RFC 9370 additional key exchanges — for routed traffic and site-to-site VPNs. Feeding keys through the 014 interface at whichever layer already terminates encryption leaves the encryptor’s cryptographic core and the forwarding path untouched; only the key feed changes.
Migration: three steps, no rip-and-replace
Adoption is incremental and rides on standardised key-delivery interfaces, so nothing has to be torn out.
Assess is a cryptographic inventory: enumerate every terminating cipher and key-exchange across L1–L3, map key-management and certificate/PKI dependencies, and rank segments by data lifetime and harvest exposure. Integrate deploys KMEs beside existing encryptors and wires them over the 014 API behind mutual TLS, with nothing in the forwarding path replaced. Operate moves to automated generation, delivery and rotation from one consol, with FCAPS telemetry and per-segment key-rate and QBER monitoring feeding assurance.
An honest word on limits
The takeaway
The likely future is not a single winning technology but a long period of coexistence. A vendor-neutral key-distribution overlay turns shifting standards, competing algorithms, and vendor fragmentation into a managed, incremental migration — and the networks that come through intact will be the ones built to change.
Standards referenced
Glossary
- AES-256-GCM — 256-bit symmetric cipher with authenticated encryption; protects the data plane.
- BB84 — The original QKD protocol; decoy-state variants are the practical standard.
- BYOA — Bring Your Own Algorithm: customer- or mission-specific cryptography.
- Crypto-agility — Changing algorithms by configuration rather than hardware refresh.
- FCAPS — Fault, Configuration, Accounting, Performance and Security management.
- Harvest-now, decrypt-later — Capturing ciphertext today to decrypt once quantum-capable.
- HQC — Code-based backup KEM selected by NIST in 2025 (standard in development).
- IPsec / IKEv2 — Layer-3 VPN encryption and its key-exchange protocol.
- KEM — Key-Encapsulation Mechanism: establishes a shared symmetric key.
- KME — Key Management Entity (ETSI QKD): pools and serves key material to apps.
- MACsec — IEEE 802.1AE Layer-2 (Ethernet) link encryption.
- MDI-QKD — Measurement-Device-Independent QKD; removes detector side channels.
- ML-DSA — FIPS 204 lattice-based digital signature (formerly Dilithium).
- ML-KEM — FIPS 203 lattice-based key encapsulation (formerly Kyber).
- PQC — Post-Quantum Cryptography: quantum-resistant mathematical algorithms.
- QBER — Quantum Bit Error Rate; rises under eavesdropping and bounds leakage.
- QKD — Quantum Key Distribution: physics-based key generation.
- QKDE — QKD Entity: endpoint running the QKD protocol.
- QKDN — Quantum Key Distribution Network (ITU-T Y.3800 series).
- QRNG — Quantum Random Number Generator: hardware entropy source.
- SAE — Secure Application Entity (ETSI QKD): the encryptor/app requesting keys.
- SLH-DSA — FIPS 205 stateless hash-based signature (formerly SPHINCS+).
- TF-QKD — Twin-Field QKD; extends achievable point-to-point distance.
- Trusted node — Relay that sees keys in the clear and must be physically secured.
