Why Your Post-Quantum Migration Is Taking Longer Than Anyone Told You
Applied Quantum Cryptography isn't something you bolt onto an existing system in a weekend. I spent roughly eight months redesigning a key distribution pipeline for a mid-sized financial services client, and even then we only covered their most critical internal channels. The rest stayed on classical PKI with a scheduled rotation plan. Here is what actually happens when you try to do this properly. The first thing you need to understand is that quantum cryptography and post-quantum cryptography are not the same thing, and mixing them up will waste your budget before you write a single line of code. Quantum cryptography, specifically Quantum Key Distribution or QKD, relies on physical hardware — fiber optic links, single-photon detectors, and specialized transceivers. Post-quantum cryptography is purely algorithmic. It runs on the same servers you already have. NIST finalized its first round of standards in 2024 with ML-KEM and ML-DSA as the primary choices. Most organizations should start there unless they have a specific threat model that demands physical-layer security. My client wanted QKD because their compliance team said "quantum-safe." They did not understand that QKD solves a completely different problem than PQC. QKD protects the key exchange channel itself through the laws of physics. If someone taps the fiber, the quantum states collapse and both parties know. Post-quantum algorithms protect against future computational attacks on current mathematical problems. They do not detect eavesdropping. They just resist decryption by a quantum computer running Shor's algorithm.
I had to explain this three separate times before the procurement team ordered the right thing. We ended up doing a hybrid approach — ML-KEM-768 for routine traffic and a single QKD link between their two primary data centers for inter-DC key material. That QKD link cost approximately 400,000 dollars in equipment and another 120,000 a year in maintenance. The fiber route had to be a dedicated dark fiber strand. Shared infrastructure caused too much dispersion and noise for the single-photon detectors to work reliably. You cannot just run QKD over existing telecom fiber without significant signal regeneration equipment, and even then the key rate drops to something unusable for most applications.
What People Get Wrong About Implementation
The biggest mistake I see is assuming that once you deploy QKD hardware, your keys are secure. They are not. The security proof assumes ideal components. Real detectors have timing jitter, dead time, and afterpulsing. The most common attack vector in practice is not a theoretical photon-number-splitting attack. It is detector blinding. Someone shines bright light into your receiver, forces the avalanche photodiode into a linear mode, and controls the detection outcome entirely. I saw this happen at a conference demo in 2023. The attacker used a commercial laser diode and a variable optical attenuator. The whole thing took about forty-five seconds to set up. The fix is not trivial. You need active monitoring of detector parameters, randomized measurement basis selection that the eavesdropper cannot predict, and decoy state protocols if you are using weak coherent pulses. Most commercial QKD systems from ID Quantique, Toshiba, and MagiQ include some of this, but the implementation details vary wildly between vendors and the published security proofs rarely match the actual firmware behavior. I learned this the hard way when our penetration testing team found that the decoy state implementation on one vendor's unit had a parameter selection bug that reduced the secure key rate by roughly 60 percent under certain fiber lengths. The vendor patched it, but the vulnerability existed in production for about eleven months before anyone caught it.
Get the Full Details
Practical Steps If You Are Actually Doing This
Start with a crypto inventory. You need to know every protocol, every cipher suite, every key exchange mechanism in your environment before you touch anything. TLS 1.3 is the lowest hanging fruit. It uses ephemeral key exchange, which means if you swap out the key agreement algorithm for a post-quantum variant, you get forward secrecy for free. The migration path is relatively clean if you are already on 1.3. If you are still on 1.2 or earlier, you have a much larger problem because the older handshake structures do not accommodate hybrid key exchanges as easily. For QKD specifically, the practical deployment looks nothing like the textbook diagrams. You need to think about trunk and branch topology. A point-to-point link between two buildings is straightforward. Add a third location and you either need three separate links or a quantum repeater, which does not exist in any commercially viable form yet. The research prototypes work over maybe ten kilometers under perfect lab conditions. Production reality is closer to fifty kilometers before you need trusted node relays, and trusted nodes reintroduce the very classical security assumptions you were trying to avoid. If you go the PQC route, the immediate issue is packet size. ML-KEM-768 public keys are about 1,184 bytes. The ciphertext is roughly 1,088 bytes. Add that to a TLS handshake and you are looking at an additional 2.5 kilobytes per connection. Most enterprise networks have MTU settings between 1,500 and 9,000 bytes depending on whether jumbo frames are enabled. You will get fragmentation. Fragmentation causes latency spikes. I have seen connection times increase from an average of 45 milliseconds to around 120 milliseconds in test environments with typical enterprise switch configurations. That matters when you are doing high-frequency trading or real-time data replication.
The workaround I used was implementing path MTU discovery with a fallback to 1,400-byte packets for the initial handshake, then switching to the negotiated MTU after key establishment. This added about three milliseconds to the connection setup but eliminated the retransmission storms that fragmentation caused on misconfigured networks. It is a small detail that nobody documents well.
Where These Systems Completely Fail
QKD does not work over satellite uplinks with any current hardware due to atmospheric attenuation. You cannot secure a wireless last-mile connection. It only works over dedicated fiber or free-space optical links with line of sight, and even free-space QKD has been demonstrated successfully only in very controlled conditions with distances under two kilometers. If your threat model involves mobile endpoints or cloud infrastructure where you do not control the physical layer, QKD is not an option. Period. Post-quantum cryptography has its own failure modes. side-channel resistance is not guaranteed by the algorithms themselves. The NIST standards specify parameter sets but not implementation constraints. A poorly implemented ML-KEM module can leak timing information that allows a local attacker to recover the secret key in under an hour. I encountered this with a custom hardware security module from a vendor who had ported the reference implementation without any constant-time modifications. The difference between their version and a hardened implementation was about two hundred lines of code and roughly three weeks of work for someone who understands constant-time programming patterns. Another hard limit: neither approach solves the key management problem at scale. QKD generates keys between two endpoints. It does not help you manage certificates, rotate keys across thousands of services, or integrate with existing PKI hierarchies. You still need a key management system. The quantum layer just replaces one key exchange mechanism with another. PQC similarly requires infrastructure for key storage, rotation, and revocation. Organizations that skip this step because they assume "quantum means it is automatically better managed" end up with keys sitting in plaintext config files and nobody auditing them.
The realistic timeline for widespread quantum computing capable of breaking RSA-2048 is anywhere from ten to thirty years according to most current estimates. The realistic timeline for deploying quantum-resistant systems across a large organization is one to three years if you start now. The catch-22 is that you need to encrypt data today that must remain secure for the next decade, which means you need to migrate before the threat exists. That is why the industry moved to the harvest-now-decrypt-later framework in 2022 and why NIST standardized PQC algorithms the way they did — to give organizations a concrete migration target rather than leaving everyone waiting for a threat that might not materialize for years. Applied Quantum Cryptography, when done correctly, is a combination of hardware investment, algorithm migration, and operational discipline. There is no single product you install. The organizations that succeed treat it as an infrastructure modernization project, not a security feature. The ones that fail treat it as a checkbox exercise and end up with systems that are theoretically secure and practically broken in ways that are harder to detect than the original vulnerabilities.
