Why “plug-and-play PQC upgrades” won’t happen – and why CISOs should put QKD on critical links
We all agree on the starting point: quantum-safe is no longer optional.
Regulators and national cybersecurity agencies are pushing organizations to migrate away from RSA/ECC toward post-quantum cryptography (PQC), because a cryptographically relevant quantum computer would break much of today’s public-key infrastructure – and because “harvest now, decrypt later” is already a rational threat model for long-lived secrets. (cisa.gov)
NIST has now approved the first PQC standards as Federal Information Processing Standards (FIPS 203/204/205), which means the industry has a concrete starting line – not a science project. (csrc.nist.gov)
So far, so good.
Now comes the part I’m going to say out loud: crypto agility—specifically as it’s being “sold” to CISOs as future plug-and-play – is a myth.
Not because the intent is malicious. But because the implication is operational fantasy.
Context: PQC migration is the big project. “Crypto agility” is the promise attached to it.
Let’s define terms the way the guidance does.
The PQC migration is the massive, regulator-driven program: inventory, vendor engagement, protocol upgrades, new crypto libraries, testing, rollout, and eventually deprecation of classical existing public-key algorithms.
Crypto agility, in this context, is the guidance telling you: “Implement PQC in a way that makes future cryptographic transitions easier—so you can swap algorithms without disrupting operations.” NIST’s crypto-agility white paper is explicit that agility is about replacing/adapting algorithms across protocols, software, hardware, firmware, and infrastructure while preserving ongoing operations. (NIST Publications)
And here’s where the myth creeps in – usually not from the standards text itself, but from how it gets translated into executive reassurance and vendor decks:
“Yes, this first PQC migration is hard. But if we do it ‘crypto-agile,’ the next one will be easy.”
As a CISO, you’re being led to believe the next upgrade will be closer to “swap the module” than “re-platform critical security plumbing.” That’s the myth.
Why the “next PQC upgrade will be easy” story is dangerous
NIST’s own paper acknowledges the lived reality: algorithm transitions are historically costly, time-consuming, and operationally disruptive – and then it describes why agility is needed in the first place. (NIST Publications)
So what makes people think the next PQC transition will be easy?
Because we’re mixing up two very different things:
- Decoupling cryptography in code (good and necessary), versus
- Changing cryptography in a running production ecosystem (never “plug-and-play”).
Even if you do the decoupling well, the next transition still collides with harsh systems reality:
1) Protocol reality: crypto is negotiated, not “dropped in”
PQC isn’t just a library choice. It’s negotiated in protocols, embedded in appliances, and constrained by interoperability. Algorithm swaps can require new identifiers, new negotiation logic, and cross-vendor coordination – especially when hybrid modes are needed during migration windows. (NIST Publications)
2) Size reality: PQC changes the physical shape of your traffic
Key and signature sizes aren’t a detail; they are an engineering constraint. NIST explicitly notes that larger sizes can stress or break assumptions in existing protocols and systems. (NIST Publications)
Meaning: the “swap” you planned becomes a cascade: MTU issues, handshake fragmentation, latency regressions, memory pressure, device constraints, throughput cliffs.
3) PKI reality: certificates are the blast radius
When algorithms change, certificate formats, chain validation, enrollment flows, OCSP/CRL behaviors, HSM integrations, and device trust stores all get pulled into the upgrade. That’s not agility. That’s a multi-stakeholder migration with brittle dependencies.
4) Compliance reality: regulated environments don’t move at GitHub speed
“Minor cryptographic change” can still force recertification, audit updates, control testing, and policy exceptions. The calendar becomes your dependency.
5) Risk reality: upgrades are where outages (and vulnerabilities) are born
Crypto sits on the critical path: identity, authentication, secure update, secure transport. Touching it creates the highest-leverage failure modes.
Crypto agility reduces coupling. It does not repeal operational risk.
The punchline: crypto agility can make the next transition less terrible – but not “easy”
If you implement agility correctly, you’ll improve survivability:
- Fewer hard-coded suites
- Cleaner interfaces
- Better inventory and governance
- More controlled rollouts
- Better ability to run mixed modes
That matters. It’s worth doing. But if your board thinks agility means “future PQC swaps will be painless,” you are accumulating a very specific kind of risk: future-upgrade complacency.
And complacency is exactly how CISOs end up with their pants down: a new cryptanalytic result, a deprecation cycle, a vendor scramble, and suddenly your “agile design” still requires a high-risk fleet-wide change under time pressure.
Security-in-depth: why CISOs should seriously consider QKD on critical links
This is where security leaders need to stop thinking in slogans and start thinking in failure modes.
PQC is software-defined cryptography. Its security rests on mathematical hardness assumptions and on the ecosystem’s ability to execute transitions when assumptions shift.
QKD is different: it uses quantum properties to generate and distribute key material with security rooted in physics rather than computational hardness assumptions. (tsapps.nist.gov)
That makes QKD strategically compelling for critical links – the ones you cannot afford to rebuild under duress—because it moves part of the key-establishment problem out of the application stack and into an out-of-band key service.
This is not “PQC vs QKD.” It’s PQC + QKD in a security-in-depth architecture:
- PQC broadly across the enterprise (because you must migrate) (csrc.nist.gov)
- QKD selectively on crown-jewel links where you want maximum assurance and minimum exposure to future in-band crypto churn
Think: backbone links, data center interconnects, HSM-to-HSM replication, key-management backplanes, cloud on-ramps, and other high-value paths where downtime and rushed upgrades are unacceptable.
QKD gives you an additional, physics-based key supply for the links that matter most.
The CISO logic is simple:
- If you believe PQC will be “set and forget,” you’ll build one giant migration and declare victory.
- If you accept reality – that crypto transitions (especially early-days PQC) recur and are painful – then you will want an insurance layer on the most critical links that reduces your dependence on “the next software upgrade going perfectly.”
That insurance layer is exactly where QKD belongs.
A CISO’s checklist: questions to ask before you bet on “agility”
If your program is leaning on crypto agility as a promise of future simplicity, ask these now:
- When we “swap algorithms,” what exactly changes in protocols, certificates, HSMs, and appliances?
- What breaks when message sizes grow, latencies shift, or devices can’t update? (NIST explicitly warns size can stress protocol limits) (NIST Publications)
- How do we test and roll back across the estate under real SLA constraints?
- What portion of the environment is truly upgradeable – and what is “forever legacy”?
- Which links are too critical to rely solely on in-band cryptographic churn – and should be protected with QKD as defense-in-depth? (tsapps.nist.gov)
Closing
Quantum-safe is a necessity. PQC migration is urgent and real. (cisa.gov)
But the idea that “crypto agility” will make the next PQC transition easy – plug-and-play, low risk, minimal disruption – is a myth.
Good engineering can make the next transition less catastrophic. It won’t make it painless.
And that is exactly why CISOs should treat QKD on critical links as a serious security-in-depth option: not as ideology, but as sober risk management against the day you learn – again – that software upgrades are never as agile as the guidance makes them sound.