Cryptography, PQC, QKD, and Security Migration
Security is the one quantum application where the deadline can arrive before the machine does. This chapter separates three things vendors blur together — Shor's threat, post-quantum migration, and quantum key distribution — and turns them into a sequenced plan.
The rational response to quantum risk is boring: inventory your cryptography, migrate to post-quantum standards on the schedule your asset lifetimes demand, and treat quantum key distribution as a niche infrastructure choice rather than a substitute.
This chapter gives you the working standard: plan the response by distinguishing Shor risk, PQC migration, QKD deployment, crypto agility, and enterprise timelines — then sequence the work by what your data is worth and how long it must stay secret.
Core concepts: pqc security, qkd pqc distinction, shor period finding.
Three different problems share one headline
"Quantum breaks cryptography" bundles three separate situations. First, Shor's algorithm: a large fault-tolerant quantum computer would factor integers and compute discrete logarithms efficiently, breaking the public-key systems — RSA, elliptic-curve cryptography — that secure most of the world's key exchange and signatures. That machine does not exist today, and building it is a fault-tolerance problem measured in years.
Second, post-quantum cryptography (PQC): classical algorithms, built on different mathematics, designed to resist quantum attacks and standardized for exactly this purpose. PQC runs on the computers you already have. Migrating to it is a software and inventory problem, not a physics problem.
Third, quantum key distribution (QKD): a family of quantum communication protocols that distribute keys with security tied to physical measurement, under specific assumptions and over specific links. QKD is infrastructure — fiber, trusted nodes or device trust assumptions, distance limits — and it solves key distribution only, not signatures, certificates, or the rest of the cryptographic estate. Confusing these three is the most common and most expensive error in quantum security conversations.
The math behind the threat, and a score for the plan
Shor's algorithm works by reducing factoring to period finding: given and , find such that
Classical number theory then turns the period into factors; the quantum part is estimating that period efficiently. The planning point: the threat scales with fault-tolerant machine size, not with today's small demonstrations, and no one can give you an exact arrival date.
For the response, use the decision score from this part of the book:
decision_score = claim_quality + proof_progress - risk - kill_criteria_pressure
Security work advances through proof gates, not vibes: a completed inventory, a tested migration path, interoperability evidence, and a threat model written down.
Worked example: migrate, or buy QKD?
An enterprise asks whether to purchase QKD equipment or fund a PQC migration. The strong memo starts with inventory, not products: where does cryptography live — certificates, key exchange, signing, VPNs, embedded devices, vendor systems? What data has a shelf life longer than the migration would take? What do regulators expect?
The generic answer for a broad enterprise: PQC migration planning first, because it covers the whole estate on existing infrastructure. QKD enters the discussion only for narrow, high-value links where the physical infrastructure exists and the threat model justifies dedicated hardware — and even there it complements rather than replaces conventional cryptography.
Proof gates before broad adoption either way: an asset inventory with owners, a pilot migration on a contained system, interoperability tests with partners, and an operational threat model that names what is vulnerable to harvest-now-decrypt-later and what is not.
Where security planning fails
Three failures recur. Treating QKD as a universal replacement for PQC — it addresses one problem, on links that can host it, at real cost. Waiting for a cryptographically relevant quantum computer before starting inventory — migration takes years, and data recorded today can be decrypted later, so the exposure clock started already.
And treating all cryptography as equally exposed. Symmetric encryption mostly needs longer keys. Signatures and key exchange need replacement. Certificates and archived data need different handling. A plan that says "upgrade the crypto" without distinguishing these is not a plan.
The engineering view
PQC migration is dependency management at enterprise scale. You need discovery tools, versioned rollouts, compatibility testing, key management changes, fallback behavior, and monitoring. The hard part is rarely the new algorithm — libraries exist. The hard part is finding every place cryptography is embedded, including systems nobody owns anymore.
QKD, by contrast, is a network engineering decision: link budgets, physical security of nodes, key relay architecture, maintenance. Evaluate it the way you would evaluate dedicated communications infrastructure, because that is what it is.
Build and partner opportunities
The credible near-term businesses here are unglamorous: cryptographic inventory and discovery tools, migration tooling, compliance workflows, interoperability testing, key management. These sell against a deadline that exists independently of quantum hype cycles.
For any security vendor, quantum or otherwise, the memo should require a written threat model and deployment economics, and it should refuse one move: treating fear of a future quantum computer as proof of any specific product today.
Exercise
Write the comparison memo. For one realistic organization, produce a PQC-versus-QKD recommendation.
- Baseline: the threat model, asset lifetimes, current cryptographic estate, and migration constraints.
- Evidence: separate PQC standards readiness, Shor-related future risk, and QKD deployment evidence into three labeled piles.
- Proof gates: define what a PQC migration pilot must demonstrate, and separately what a QKD deployment must demonstrate.
- Sanity check: explain, in one paragraph, how period finding connects to the factoring threat — if you cannot, that is a repair signal.
End with a label — build, partner, invest, monitor, wait, or avoid — for each of the two paths, since they need not match.
Check your understanding
Without notes: write a security recommendation that keeps PQC deployment and QKD infrastructure in separate columns, with separate assumptions and separate proof gates.
A passing answer starts from inventory and asset lifetime, states that PQC runs on existing classical infrastructure, describes QKD's link and trust constraints honestly, and names harvest-now-decrypt-later as the reason waiting is itself a decision.
Oral defense: explain to a CFO why the organization should spend on migration this year when the threatening machine may be a decade away.
If you get stuck
If your recommendation blurs PQC and QKD, or lacks a threat model and asset inventory, revisit Chapter 33 (Shor as Period Finding) for what the threat actually requires and Chapter 26 (Quantum Key Distribution) for what QKD actually provides. The confusion this chapter targets usually comes from skipping one of those two.