For a while now, I’ve been making the same (slightly unpopular) point to CISOs and CTOs:
If you wait for a full, system-wide PQC migration before you materially improve your quantum posture, you’ll spend years “planning” while your highest-value data keeps moving over the same high-value pipes. We’ve even detailed this approach in a blog post “Start at the Pipes: Why QKD‑First Is the Level-headed, Safer On‑Ramp to Quantum‑Safe”
It’s encouraging to see this idea start showing up in mainstream executive guidance. In a recent Citi Institute report, Citi explicitly recommends using “quantum-safe shields / network overlays” as a bridge while the broader PQC program runs in parallel. (They call out the premise on page 9.) (Citi)
So let’s double-click: what does a “network overlay” actually mean in practice, why is it such a sensible bridge, and why is QKD the best way to do it?
Executive summary
- Full PQC migration is a multi-year program (inventory, vendor dependencies, protocol upgrades, crypto agility). The UK NCSC frames PQC migration as a long, multi-year staged journey. (Deloitte Insights)
- A network overlay is a pragmatic way to protect the highest-blast-radius links early — without waiting for every application, vendor product, and endpoint to be PQC-ready. (Citi)
- Overlays can be built using PQC or QKD. Both can raise your security floor now.
- QKD is the better overlay for the critical pipes because it improves key establishment out-of-band and therefore doesn’t require putting new cryptographic logic into the payload data path.
- One sentence on “safer”: QKD’s core security promise is based on physics rather than computational hardness assumptions, giving it a higher assurance ceiling than purely algorithmic approaches (including PQC). (IBM)
Why this “overlay bridge” matters
The “standard” roadmap you hear from regulators and consultancies is broadly:
- Inventory cryptographic usage
- Upgrade systems to PQC
- Build crypto agility
That is directionally right — and also slow. It’s why guidance exists specifically around crypto agility in the first place. (NIST)
Citi’s overlay recommendation is basically an executive translation of a simple operational truth:
The migration takes years. You still need a way to reduce exposure now, especially since HNDL (harvest now, decrypt later) attacks are already happening now.
That’s the bridge. (Citi)
The cloud reality: your data is constantly in motion
Today, most large organizations are hybrid by default: cloud + SaaS + on-prem + partners.
Which means your crown-jewel data isn’t “resting.” It’s moving:
- DC ↔ DC (replication, DR, backup/restore, analytics pipelines)
- DC ↔ cloud entry points
- HQ/branches ↔ cloud
- SaaS ↔ identity and management planes
CISOs have been right to invest heavily in cloud security stacks. But there’s a trap:
It’s easy to focus on securing what’s inside the cloud and miss the equally critical problem: securing the pipes to and from the cloud, and everything else in your stack not in the cloud.
That is exactly the surface an overlay targets.
What is a “network overlay”?
A network overlay (in the sense Citi is using it) is not “rewrite your apps.”
It’s:
- Deploying a security layer at a small number of strategic ingress/egress points
- So that all traffic traversing those links gets protected
- While your longer PQC migration program continues in parallel
A key point: overlays are attractive precisely because they let you protect a large chunk of risk by touching a small number of links (the “big pipes”).
Two overlay paths: PQC overlay vs QKD overlay
A) PQC overlay
A PQC overlay typically means deploying new cryptography in production gateways / encryptors / routers / firewalls (software and often hardware) so that traffic over chosen links is wrapped with PQC-capable mechanisms.
This can work — but it also means you’re touching the critical links with new software and likely new hardware that sits in the production environment, actively manipulates the data moving in the pipes and must interoperate cleanly at scale.
Whether the risk comes from cryptography, packet handling, interoperability, or operational complexity doesn’t really matter to the business outcome:
You’re introducing new, unproven change into the most critical pipes.
B) QKD overlay
A QKD overlay takes a different approach: it upgrades how keys are created and delivered by adding a quantum key distribution layer that feeds key material to the encryption systems protecting the link.
QKD is inherently “higher assurance” than PQC in its key-distribution premise, because it does not rely on computational hardness assumptions but on the laws of physics. (IBM)
And the most important operational distinction for overlays, QKD does not sit on the payload data path. It’s an out-of-band key establishment layer. That means it cannot reduce throughput SLA or introduce packet-level bugs by virtue of QKD itself, because it is not processing the payload traffic.
(You still have data-plane encryption on the link — but QKD isn’t “in the packets”. Encryption is done by your existing, production-proven systems).
The right mental model: “overlay for coverage,” not “temporary hardware”
When we say “network overlay,” it’s easy to accidentally trigger a bad association: a short-term patch you’ll rip out later. That’s not what’s being proposed here.
A QKD overlay is best understood as a foundational security layer on your most critical pipes — the links that carry your highest-value data in motion: data center interconnects, HQ↔DC, DC↔cloud entry points, and core backbone segments.
Yes, an overlay helps you buy time against the reality that full cryptographic modernization across thousands of applications and vendors is slow. But that doesn’t make QKD “temporary”. It simply means it creates immediate coverage while broader migrations continue in parallel.
More importantly: even after the rest of the stack evolves, those crown-jewel links still deserve a higher-assurance layer. That’s exactly where QKD fits long-term: on the few links where (a) the blast radius is enormous, and (b) the business impact of compromise is existential.
So the right framing is:
- Overlay = fastest path to reduce risk now, without boiling the ocean.
- QKD on critical links = a permanent “high-assurance backbone” layer, because those pipes will always be the pipes you can’t afford to lose.
In other words: you’re not installing “bridge hardware.” You’re installing core infrastructure — and you happen to get the bridge benefit for free.
Financial frameworks
Let’s not pretend we can calculate a precise breach probability. That’s not how large institutions make security investment decisions anyway. They budget against tail outcomes — severe but plausible events — and they prioritize controls that meaningfully reduce exposure without introducing unacceptable operational risk.
So here are the two comparisons that matter.
A) Network overlay bridge + PQC overhaul vs. PQC overhaul only
Large banks don’t spend “a few million” on cybersecurity. Deloitte’s benchmarking for banking/capital markets cites cybersecurity budgets around 0.54% of revenue (2023). On a $50B revenue institution, that implies roughly $270M per year in cyber spend. (deloitte.wsj.com)
Now compare that to a typical overlay bridge program:
- Overlay cost (order of magnitude): ~$3M–$5M for a large institution
- That’s ~1.1%–1.9% of a $270M annual cyber budget
Then ask what it buys you.
The whole overlay thesis is that you protect the big pipes first — the handful of links where most sensitive traffic concentrates (DCI, DC↔cloud entry, backbone). In many enterprises, those pipes represent the overwhelming majority of meaningful data-in-motion exposure — call it ~85–90% as a practical planning assumption.
Now pair that with the scale of tail events. IBM’s 2024 Cost of a Data Breach report shows “mega breaches” with costs reaching $173M and $375M depending on scale. (cdn.table.media)
So the executive sanity check becomes:
Is it rational to spend ~1–2% of your annual cyber budget on a (one-time) overlay project that materially improves your posture across ~90% of your data-in-motion crown-jewel exposure — during the 3–4 years it takes the full PQC overhaul to land?
For most large regulated institutions, that’s not a controversial question. It’s the same logic that drives every other resilience investment: spend a small amount to reduce exposure to an outsized downside while the long program is underway.
And as you scale down to smaller institutions, all sides of the equation shrink — but the ratios typically remain directionally similar.
B) QKD overlay bridge vs. PQC overlay bridge (the outage-risk lens)
Here the comparison is not “does PQC work.” It’s about operational risk.
Assume both overlay approaches are in the same ballpark, but PQC is a bit more cost effective on your upfront bridge CAPEX spend:
- PQC overlay: maybe ~$2M–$3M for a large institution.
- QKD overlay: maybe ~$3M–$5M for the same.
So the delta is often on the order of $1–$2M.
Now add one practical difference that your board will understand immediately:
- A PQC overlay typically introduces new software (and most likely new hardware) into the production traffic environment on critical links. Whether it’s gateways, encryptors, routers, or firewalls — you are making in-path changes on the pipes you cannot afford to break.
- A QKD overlay is different by design: QKD itself is out-of-band. It does not sit in the payload data path. That means QKD cannot reduce throughput SLAs or introduce packet-level regressions by virtue of QKD itself — because it isn’t processing the payload.
So if we’re doing this honestly, the PQC overlay must carry an explicit “introduced outage risk” premium.
You don’t need hypotheticals to see the scale of outage consequences in banking:
- TSB disclosed £330.2m of post-migration costs tied to its 2018 IT disruption (customer remediation, resourcing, fraud, lost income, etc.). (tsb.co.uk)
- MAS required DBS to hold an additional S$930m in regulatory capital following a month of two major outage events. (straitstimes.com)
Now apply the simple board logic:
If the downside of a serious disruption can be “hundreds of millions,” then even a modest chance of triggering one during a major in-path rollout can dominate the cost comparison — easily overwhelming a $1–$2M CapEx delta.
That’s the practical argument for QKD as the better overlay bridge: not just stronger assurances on keys, but a cleaner deployment risk profile because it upgrades key establishment out-of-band rather than inserting new cryptographic processing into the data plane.
So what should a CISO do on Monday morning?
- Identify the handful of links that carry the crown jewels:
- DC ↔ DC
- DC ↔ cloud entry
- HQ ↔ DC / cloud
- backbone aggregation segments
- Treat the overlay as the near-term coverage layer:
- Protect the pipes first, then expand outward.
- Run the full PQC program in parallel:
- You still need PQC everywhere. The overlay doesn’t replace that.
- Choose QKD for the overlay when:
- You want the highest-assurance key-distribution premise, and
- You want to minimize the probability that your bridge itself becomes an outage headline.
Closing
Citi’s overlay recommendation is important because it normalizes what many CISOs already feel: the multi-year migration is unavoidable, but waiting for it to finish before reducing exposure is not.
If you accept the overlay premise, then the decision becomes about engineering reality:
- PQC overlays can reduce quantum exposure, but they typically require introducing new software/hardware changes into critical traffic environments.
- QKD overlays upgrade key establishment out-of-band and can therefore deliver bridge coverage with a smaller “production traffic” change surface — while also becoming the long-term high-assurance layer on the links that matter most. (IBM)
That’s the bridge strategy that doesn’t feel like a bridge. It feels like good infrastructure.
Author: Nir Bar Lev, CEO, HEQA Security