- A five-node international testbed fuses Classical Cryptography, Quantum Key Distribution, and Post-Quantum Cryptography inside a single DMVPN fabric, proving multi-vendor quantum-safe IPsec is deployable now.
- The architecture reconciles three mutually incompatible key-delivery interfaces — ETSI004, ETSI014, and Cisco SKIP — using Software-Defined Networking as the orchestration plane.
- Banks that wait for IPsec standards to absorb PQC will ship harvest-now-decrypt-later risk into every new certificate and tunnel they provision this year.
The Quantum Clock Is Already Ticking for Interbank Traffic
A mid-tier European bank rotates its site-to-site IPsec tunnels on 90-day cycles. Every tunnel negotiated today uses RSA, Diffie-Hellman, or ECC for key agreement. Every packet crossing those tunnels — SWIFT payloads, settlement instructions, KYC records — can be captured today, stored, and decrypted the moment a Cryptographically Relevant Quantum Computer arrives.
That is the harvest-now-decrypt-later problem, and it is not hypothetical for banking. Financial data carries a regulatory retention horizon measured in decades. A payment authorization recorded in 2026 must remain confidential in 2040. If the asymmetric primitive protecting it breaks in 2032, the breach was effectively committed six years earlier — at the moment of capture.
Researchers publishing on arXiv put the threat model plainly:
“The emergence of Cryptographically Relevant Quantum Computers (CRQCs) presents a critical threat to classical cryptographic systems, particularly widely adopted protocols such as RSA, Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC).” — arXiv:2604.12985
The attack surface is not a single algorithm. It is every IPsec tunnel, every IKE exchange, and every VPN concentrator across a bank’s branch network, treasury backbone, and cloud interconnects.
[IMAGE: Quantum processor lattice with entangled light beams converging on a glowing IPsec tunnel suspended over a darkened bank vault]
Why Pure-PQC IPsec Is Not Yet an Option
A CISO reading NIST’s PQC announcements might assume the migration path is straightforward: swap the key-encapsulation mechanism, rotate the tunnels, done. It is not. PQC algorithms have not yet been incorporated into finalized IPsec standards. IKEv2 extensions for hybrid key exchange remain drafts. Vendor implementations are fragmented. Interoperability across multi-vendor estates — the norm in banking — is unproven at the protocol layer.
This leaves security architects with three imperfect options:
- Wait for standardized PQC-IPsec and accept harvest-now-decrypt-later exposure on every tunnel provisioned in the interim.
- Deploy single-vendor PQC-only tunnels and accept lock-in plus the risk that the chosen algorithm fails cryptanalysis.
- Layer defenses by combining classical, quantum, and post-quantum key material so that no single primitive failure compromises confidentiality.
The third option is the one the arXiv framework operationalizes — and the only one that survives a realistic threat model against a 20-year data retention requirement.
Inside the Hybrid CC+QKD+PQC Architecture
The proposed architecture runs a full-mesh Dynamic Multipoint VPN across a five-node testbed: three physical nodes on a Madrid campus network, plus two private-cloud nodes in northern Spain and Mexico. Each site-to-site tunnel derives its session key from three independent sources combined through a Software-Defined Networking key-distribution controller.
The controller is the load-bearing element. Without it, the architecture is a pile of incompatible key-delivery APIs. With it, those APIs become interchangeable inputs into a unified key-combiner feeding IPsec.
The Three Key-Material Streams
- Classical Cryptography (CC): Conventional IKEv2 with ECDH or RSA, preserved as a fallback so that a bug in QKD hardware or an undiscovered weakness in a PQC candidate does not collapse confidentiality.
- Quantum Key Distribution (QKD): Both Discrete Variable (DV-QKD) and Continuous Variable (CV-QKD) implementations, delivering information-theoretically secure key material over dedicated fiber.
- Post-Quantum Cryptography (PQC): Lattice-based or code-based key encapsulation running in software, providing protection on routes where QKD fiber is unavailable — notably the transatlantic link to Mexico.
[IMAGE: Three parallel key streams — classical, quantum, and post-quantum — braiding into a single encrypted tunnel silhouetted against a dark fiber backbone]
Reconciling Three Incompatible Interfaces
The hardest engineering problem is not cryptographic. It is plumbing. QKD and PQC vendors ship mutually incompatible key-delivery interfaces:
| Interface | Origin | Key Source | Transport | Role in Architecture |
|---|---|---|---|---|
| ETSI GS QKD 004 | ETSI standard | QKD devices | Application-layer API | Stateful key streaming to IPsec endpoints |
| ETSI GS QKD 014 | ETSI standard | QKD devices | REST-over-TLS | Stateless key retrieval for heterogeneous clients |
| Cisco SKIP | Cisco proprietary | QKD devices | Vendor-specific | Native integration with Cisco routing platforms |
A Madrid node sourcing keys from an ETSI014-speaking QKD appliance cannot hand those keys directly to a Mexico-facing Cisco router expecting SKIP. The SDN controller normalizes these interfaces into a single internal key representation, then re-serializes them for the target IPsec endpoint.
“The deployment uses a heterogeneous mix of physical and virtual devices from diverse technology providers, integrating DV-QKD and CV-QKD implementations across mutually incompatible key-delivery interfaces.” — arXiv:2604.12985
That sentence is the whole thesis. Banking estates are heterogeneous by regulation, procurement cycle, and geography. Any migration path that demands vendor homogeneity is dead on arrival. This architecture accepts heterogeneity as a design constraint rather than an obstacle.
The Regulatory and Market Context Banks Cannot Ignore
NIST finalized its initial PQC standards in August 2024. The EU’s Digital Operational Resilience Act (DORA) took effect in January 2025, requiring financial entities to manage ICT risks across their full lifecycle — a standard that cryptographic obsolescence will fail. The U.S. National Security Memorandum 10 directs federal agencies toward PQC migration by 2035, and banking supervisors typically lag federal mandates by 18 to 36 months before issuing equivalent guidance.
The practical consequence: a bank procuring network equipment today on a seven-year refresh cycle is locking in cryptographic agility — or the lack of it — through 2033. Equipment that cannot accept PQC key material via a standardized interface will require early retirement or expensive middleboxing.
Market adoption is already bifurcating. Tier-1 banks with sovereign-scale security budgets are running QKD pilots on metropolitan fiber. Regional banks are waiting for vendor integration. The gap between these two groups is where regulatory enforcement will eventually fall.
The BeQuantum Perspective: Orchestration Over Algorithms
The temptation in PQC discussions is to fixate on algorithm selection — ML-KEM versus HQC, lattice versus code-based. That debate matters, but it is not where most banks will fail their migration. They will fail at orchestration: the unglamorous work of making a QKD appliance, a PQC software module, and a legacy IPsec concentrator agree on a session key.
This is the same architectural pattern BeQuantum’s PQC Layer addresses for enterprise customers. The Digital Notary anchors cryptographic lifecycle events — key rotations, algorithm migrations, certificate replacements — to a verifiable blockchain record, so that a bank auditing its 2026 tunnel configuration in 2034 can prove which key material protected which flows. The IceCase hardware module exposes a unified key-delivery interface that abstracts over ETSI004, ETSI014, and vendor-specific APIs, eliminating the integration overhead the arXiv testbed had to solve bespoke.
The lesson from the Madrid-to-Mexico testbed is not that QKD works over transatlantic distances — it does not, which is why PQC fills that link. The lesson is that crypto-agility at the orchestration layer is what makes any of the underlying primitives deployable at bank scale.
What Your Security Team Should Do in the Next 90 Days
- Inventory every IPsec tunnel terminating on internet-facing infrastructure. Record the IKE version, DH group, and certificate algorithm for each. This is the baseline against which harvest-now-decrypt-later exposure is measured.
- Engage VPN and firewall vendors on their PQC-IPsec and hybrid key-exchange roadmap. Ask for specific interface support — ETSI014 at minimum — and committed delivery dates. Vague answers are a procurement signal.
- Pilot a hybrid tunnel on a non-production path. A single site-to-site tunnel combining classical ECDH with a PQC KEM via IKEv2 hybrid extension proves out operational readiness before regulatory pressure forces the timeline.
FAQ
Q: Why combine QKD and PQC instead of choosing one? A: They fail differently. QKD is information-theoretically secure but requires dedicated fiber and trusted hardware, making it unusable for transoceanic or satellite links. PQC runs anywhere software runs but rests on mathematical assumptions that could, in principle, be broken by future cryptanalysis. Combining both — plus classical as a fallback — means no single failure mode breaks confidentiality.
Q: Does this architecture work across multiple vendors? A: Yes, and that is its central contribution. The five-node testbed integrates physical and virtual devices from diverse providers using DV-QKD, CV-QKD, and three incompatible key-delivery interfaces. The SDN controller normalizes them. Any bank running a homogeneous single-vendor estate is an outlier; this design targets the real world.
Q: What is the biggest risk if we wait for standards to mature? A: Every tunnel provisioned today with pure classical cryptography contributes captured ciphertext to the harvest-now-decrypt-later corpus. For data with a 10-to-30-year retention requirement — which covers most banking records — waiting is not a neutral choice. It is an active decision to accept future compromise.
Last updated: April 2026. Primary source: arXiv:2604.12985.
