![QKD vs PQC: Software Wins, 2035 Deadline [2026]](https://shattered.io/wp-content/uploads/2026/11/qkd-vs-pqc-quantum-key-distribution-post-quantum-cryptography-2026-gen-1.webp)
NIST finalized its post-quantum transition roadmap on October 27, 2026, and the message for anyone weighing QKD vs PQC is blunt. The agency named 2035 as the primary target for completing federal migration to post-quantum cryptography, with earlier checkpoints of 2030 for key establishment and 2031 for digital signatures in the most sensitive federal systems. Those dates attach to algorithm standards such as ML-KEM, not to optical hardware.
Quantum key distribution (QKD) and post-quantum cryptography (PQC) both answer the same fear. A large quantum computer could break the public-key math that protects today’s key exchanges, and attackers can record encrypted traffic now to open it later. The two answers could hardly differ more. QKD uses single photons over dedicated optical links to agree on a key. PQC swaps the vulnerable algorithms for new ones that run as ordinary software on ordinary networks.
The practical verdict is lopsided. PQC is the migration path for almost every organization, QKD is a specialist add-on for a narrow set of fiber and satellite projects, and the two meet in hybrid designs. The three NIST algorithm families behind PQC have their own side-by-side look at ML-KEM, ML-DSA and SLH-DSA.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
QKD vs PQC at a Glance: 12 Differences That Matter #
Standards status, government statements and deployment facts from late 2026 separate the two approaches more sharply than any performance figure could. No independent source has published matching speed numbers for both sides, so the comparison sticks to what can be verified.
| Dimension | Quantum key distribution (QKD) | Post-quantum cryptography (PQC) |
|---|---|---|
| What it does | Agrees a shared secret key between two endpoints using quantum states of light | Replaces public-key algorithms for key establishment (ML-KEM) and signatures (ML-DSA, SLH-DSA) |
| Security basis | Physics of measuring quantum states | Hard math problems, lattices for ML-KEM and ML-DSA, hash functions for SLH-DSA |
| Standards status | No FIPS equivalent. Reporting on NSA’s position says owners of national security systems must consult the agency before adding it | FIPS 203, 204 and 205 finalized August 13, 2024 |
| Authentication | Needs a separately authenticated channel, because it only agrees keys | Signature standards (ML-DSA, SLH-DSA) cover identity and integrity |
| Hardware | Dedicated optical equipment on fiber or satellite links | Software, firmware and protocol updates on existing networks |
| Reach | Point-to-point links, with trusted relay nodes or satellites to go farther | Anywhere IP traffic already flows |
| TLS support | Not a TLS cipher suite | TLS 1.3 only, with three hybrid groups in RFC 10024 (August 2026) |
| Threat it blunts | Eavesdropping on the key agreement itself | Harvest-now-decrypt-later capture of key exchanges, plus forged identities when signatures migrate |
| Main weakness | Flawed implementations and the untouched software around the link | Younger math, which is why hybrids pair it with classical algorithms |
| Government stance | NSA does not support it for national security systems, BSI calls it a niche tool, the EU funds EuroQCI | NIST, NSA (CNSA 2.0), UK NCSC and BSI all back it |
| Price transparency | No public price list found for EuroQCI-style equipment | Standards carry no license fee, cost sits in testing and upgrades |
| Federal timeline | None set | 2030 for key establishment, 2031 for signatures, 2035 for completion |
Two rows carry most of the weight. The TLS row explains why PQC spread through browsers and cloud services in 2026 while QKD stayed in pilot networks. The authentication row explains why QKD can never stand alone, since a key agreed over a fiber link is worthless if the other end is an impostor.
The threat model sharpens the contrast. Harvest-now-decrypt-later collection costs an attacker little, since recording encrypted traffic needs only a tap and cheap storage. The payoff comes years later, if a quantum computer ever breaks the key exchange that protected the session. In the QKD vs PQC debate, that asymmetry favors the approach that can cover the most sessions quickly. A QKD link protects only the fiber it runs on. A PQC-capable client and server protect every session they negotiate, across any network, starting the day both sides enable the group.
How Quantum Key Distribution Works and What It Leaves Out #
Quantum key distribution encodes bits in properties of single photons, such as polarization. The sender transmits a stream of photons in randomly chosen bases. The receiver measures each one in a randomly chosen basis. The two sides then compare, over an ordinary channel, which bases they used and keep only the positions where the bases matched. An eavesdropper who measures a photon in transit disturbs it, and that disturbance shows up as errors when the parties compare a sample of their key. High errors mean someone is listening, so the parties discard the key and try again.
That is the elegant part. The catch is everything surrounding it. The comparison step runs over a classical channel that must be authenticated, otherwise an attacker sits in the middle and talks to both ends. The authentication typically relies on pre-shared secrets or on classical public-key signatures, which means QKD still leans on conventional cryptography for its own integrity. The output is also just a key. A symmetric cipher such as AES still encrypts the actual traffic, and the key still has to be handled by ordinary software and hardware.
Distance is the second constraint. Photons get absorbed in fiber, and unlike a normal data signal they cannot be amplified without destroying the quantum state. Operators extend reach in two ways. Trusted relay nodes decrypt and re-encrypt keys at each hop, which concentrates risk in physical sites that must be guarded. Satellites carry keys across longer spans, which is why Europe’s program couples terrestrial fiber with a space segment. Both options add cost and operational weight that a software upgrade never does.
Third, QKD secures a link, not a system. It protects the key agreement between two fixed endpoints. It does nothing for a web server talking to millions of anonymous browsers, a mobile app calling an API, or a signed software update traveling through a content network. Most modern traffic follows those patterns, and QKD has no answer for them. Readers who want the wider map of algorithms, hashes and key exchange can browse the cryptography section for background.
Fourth, the security claim is about physics, but the product is hardware. Real detectors, lasers and firmware have flaws that a perfect protocol on paper does not. A skeptical reading of the field, shared by several government agencies, is that these engineering gaps matter more than the elegance of the underlying physics.
How Post-Quantum Cryptography Works #
PQC does not change the physical layer. It replaces the mathematical problems underneath key exchange and signatures with problems that quantum computers are not known to solve quickly. NIST finalized the first three standards on August 13, 2024, and all three are software algorithms that run on existing CPUs, HSMs and cloud services.
Key establishment: ML-KEM
ML-KEM, defined in FIPS 203 and formerly known as CRYSTALS-Kyber, is a key-encapsulation mechanism. One side generates a key pair, the other uses the public key to produce a ciphertext and a shared secret, and the first side decapsulates the ciphertext to recover the same secret. FIPS 203 defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, with security rising and speed falling across that order. NIST’s October 2026 roadmap prioritizes ML-KEM migration for data exposed to harvest-now-decrypt-later collection, and NSA’s CNSA 2.0 suite specifies ML-KEM-1024 for national security systems. Anyone replacing RSA key exchange follows the same path, and the trade-offs against classical keys are laid out in this look at ML-KEM vs RSA.
NIST also selected HQC in March 2025 as a backup key-encapsulation algorithm built on different math, so a future break of lattices would not leave the world without a standard. HQC is not one of the three finalized standards, and ML-KEM vs HQC covers how the two relate.
Signatures: ML-DSA and SLH-DSA
ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) is the general-purpose lattice-based signature standard, with ML-DSA-44, ML-DSA-65 and ML-DSA-87 parameter sets. SLH-DSA (FIPS 205, formerly SPHINCS+) is a stateless hash-based alternative that rests on different assumptions. CNSA 2.0 specifies ML-DSA-87 for signatures and LMS or XMSS for software and firmware signing, alongside AES-256 and SHA-384 or SHA-512.
For developers, the change is smaller than the headlines suggest. Libraries expose ML-KEM through the same key-encapsulation interfaces they already use for key exchange, and TLS stacks negotiate hybrid groups through the existing supported-groups mechanism. The costs show up as bigger handshake messages and a bit more CPU work, plus the testing needed to confirm that old middleboxes tolerate the larger packets. Nothing in that workload resembles installing optical equipment.
Signatures matter to the QKD debate because they solve the authentication problem that QKD leaves open. A deployment that wants quantum-safe key agreement and quantum-safe identity needs both halves. PQC delivers both with the same operational model. QKD delivers only the key half and borrows the other half from classical or PQC signatures.
What NSA, NCSC, BSI and NIST Say About QKD #
Government positions carry unusual weight here, because the buyers of QKD equipment are mostly governments and state-backed operators. The picture in November 2026 is consistent: PQC first, QKD at the edges.
NIST published its final transition roadmap, IR 8547, on October 27, 2026. The report maps quantum-vulnerable algorithms to the 2024 PQC standards and sets the federal completion target at 2035 under National Security Memorandum 10. The coverage reviewed describes no QKD milestone in it. The NIST IR 8547 deadline schedule breaks down which classical algorithms lose approval and when.
NSA says it does not support QKD or quantum computing for protecting national security systems, and that it does not anticipate certifying QKD products unless stated technical limitations are overcome. NSA’s CNSA 2.0 suite, dated September 2022, specifies ML-KEM-1024 for key establishment, a post-quantum algorithm rather than a QKD system.
The UK NCSC reached the same conclusion in 2018 and still ships guidance that treats PQC as the route. Its TLS guidance, dated October 15, 2026, tells organizations to move to TLS 1.3 and to enable post-quantum key exchange alongside it. A March 2025 NCSC migration timeline reportedly calls for discovery and an initial plan by 2028, the highest-priority migrations by 2031 and completion by 2035.
BSI and ANSSI signed a January 26, 2024 joint position, together with Dutch and Swedish authorities, that gives clear priority to PQC migration, including hybrid use alongside classical algorithms, and describes QKD as suited only to niche use cases. Reporting on the French side says ANSSI requires hybrid constructions inside its certification perimeter and strongly recommends them elsewhere. A secondary report on BSI’s technical guideline TR-02102-1 (version 2026-01) says it recommends ML-KEM-768 or ML-KEM-1024 in hybrid form, alongside FrodoKEM variants.
| Agency | Position on QKD | Position on PQC | Date |
|---|---|---|---|
| NIST | Not addressed. IR 8547 maps quantum-vulnerable algorithms to the 2024 PQC standards | Federal completion target 2035 | October 27, 2026 |
| NSA | Does not support it for national security systems unless limits are overcome | CNSA 2.0 requires ML-KEM-1024 and ML-DSA-87 | September 2022 (CNSA 2.0) |
| UK NCSC | PQC mitigations judged more effective | TLS 1.3 plus post-quantum key exchange | 2018 view, TLS guidance in 2026 |
| BSI | Suited only to niche use cases | Priority migration, hybrids during transition | January 26, 2024 joint position |
The European Commission sits on the other side of the funding line, since it backs EuroQCI and has opened a consultation on activities from 2027 onward. Certification explains much of the agencies’ caution. A product that protects national security data has to pass evaluation, and evaluators need a clear specification, a testable implementation and a threat model they can bound. Software algorithms with published standards fit that process. Optical hardware with proprietary firmware and site-specific installation fits it poorly, which is the practical thrust of NSA’s stated condition that technical limitations must be overcome first. None of the security agencies argues that QKD is useless. They argue about scale, authentication, maintenance burden and where the next dollar should go. Europe’s own research calls hint at the endpoint, because an EuroHPC call on next-generation QKD systems, updated on October 15, 2026, reportedly asks for demonstrations of hybrid QKD and PQC frameworks in at least two realistic use cases. Even the QKD funders now frame the technology as something that rides alongside PQC.
Expert Voices: The Case Against Relying on QKD #
Two of the sharpest critiques predate the 2026 roadmap but have aged well, because the underlying engineering problems have not changed. In 2018, the UK’s National Cyber Security Centre (GCHQ) wrote that QKD protocols address only the problem of agreeing keys, in the exact words: “QKD protocols address only the problem of agreeing keys for encrypting data.” The same statement continued with a direct comparison: “By contrast, post-quantum public key cryptography appears to offer much more effective mitigations for real-world communications systems from the threat of future quantum computers.”
Security technologist Bruce Schneier reached a similar view long before PQC standards existed. In a 2008 essay on quantum cryptography, he wrote: “The quantum part doesn’t address the weak points of the system.” He added a point that applies to every QKD link today: “Even quantum cryptography doesn’t “solve” all of cryptography: The keys are exchanged with photons, but a conventional mathematical algorithm takes over for the actual encryption.”
In a May 2024 post, Schneier made the range point again: “The nearest we have currently at a fundamental level is “Quantum Key Distribution” and on Earth it’s really quite range limited.”
Read together, the three quotes cover the full critique. The scope is narrow (keys only), the surrounding system stays classical, and the range is limited. None of those points says the physics is wrong. They say the product answers a smaller question than the one most organizations face. Note also that two of the three statements are 8 to 18 years old, so they describe a standing design critique, not a reaction to this month’s roadmap.
Real-World Examples: Who Deploys What in 2026 #
Five PQC deployments and four QKD projects show where each technology actually runs.
- AWS KMS adds ML-KEM. AWSannounced on October 26, 2026 that AWS Key Management Service supports ML-KEM-512, ML-KEM-768 and ML-KEM-1024 through an encapsulation API that returns a shared secret. Customers use it to establish secrets for their own applications. Neither the announcement nor the other sources checked list an ML-KEM-specific price.
- Red Hat ships hybrid modes. Red Hat described hybrid post-quantum modes in RHEL 10 and OpenShift on October 29, 2026, using X25519 together with ML-KEM-768 as the working example.
- Imperva negotiates X25519MLKEM768. On October 5, 2026, Imperva said PQC-capable clients can negotiate the X25519MLKEM768 hybrid group for TLS 1.3 connections to its service, which protects those sessions against recorded-traffic attacks.
- Firefox and NSS. Mozilla’s NSS library centers its post-quantum work on ML-KEM. Firefox interoperates with any server that follows the IETF X25519MLKEM768 specification, and OpenSSL 3.5, Cloudflare’s BoringSSL-based edges and AWS-LC servers all qualify.
- OpenSSH. A secondary source reports that OpenSSH 9.9 added the mlkem768x25519-sha256 key exchange in 2024. That is not a recent release, but it shows that admin tooling got hybrid support long before many web stacks.
- EuroQCI. The European Commission describes EuroQCI as terrestrial fiber networks linking strategic national and cross-border sites plus a satellite segment. Its Joint Research Centre reported on October 30, 2026 that 12.9% of quantum-technology signals were at operational level. That figure covers quantum technology as a whole and does not mean EuroQCI itself is fully operational. The Commission has also opened a consultation on activities to support from 2027 onward.
- Eagle-1. ESA and a consortium led by SES are building the Eagle-1 satellite for in-orbit QKD validation. Reports on its launch date conflict, ranging from late 2026 or early 2027 to late 2027, so treat any date as unconfirmed. The Commission separatelycalled for a QKD microsatellite pilot mission , which confirms continuing space-segment work without proving a finished pan-European network.
- BeneluxQCI. A reported Benelux-QCI meeting in late October 2026 reviewed a planned fiber backbone linking sites in Belgium, the Netherlands and Luxembourg for QKD traffic.
The split is stark. Every PQC item is a product or protocol that a developer can switch on this quarter. Every QKD item is a government-backed infrastructure project with a multi-year horizon. For readers comparing cloud vendors on this exact point, the KMS comparison covering post-quantum support shows how far PQC has already spread across the big clouds.
Hybrid TLS: Where Both Camps Agree #
The most important 2026 development for working engineers is RFC 10024, published in August 2026 as a Proposed Standard. It specifies three hybrid key agreement mechanisms for TLS 1.3, each pairing ML-KEM with a classical elliptic-curve exchange: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. In a hybrid handshake, the session secret mixes both component secrets, so an attacker has to break both the classical exchange and ML-KEM to recover it.
That design answers the one honest objection to PQC, which is that lattice-based schemes are far younger than RSA or elliptic curves. If someone finds a flaw in ML-KEM, the classical half still holds against today’s computers. If a quantum computer breaks the classical half, ML-KEM still holds. QKD’s advocates sometimes call physics-based security a stronger hedge, but a hybrid TLS group delivers a hedge today, on every TLS 1.3 stack that supports it, at no hardware cost. A direct comparison with plain elliptic-curve exchange appears in this breakdown of ML-KEM against X25519 in TLS 1.3.
The NCSC’s guidance frames hybrids as an interim measure. It supports both hybrid and pure-PQC configurations, notes that hybrid deployment is currently more widespread, and recommends supporting a future pure-PQC option. Germany and France lean harder toward hybrids. Reporting says ANSSI requires them inside its certification scope and BSI recommends them. NSA’s position is different, since CNSA 2.0 names ML-KEM-1024 directly and reportedly permits or recommends hybrids in particular contexts such as IKEv2 rather than requiring them everywhere. This divergence between regimes is a planning problem for multinational organizations, and the trade-offs among hybrid, pure and composite rollouts deserve attention before a fleet-wide change.
Standardization continues beyond RFC 10024. An IETF draft for a standalone ML-KEM TLS mechanism (draft-ietf-tls-mlkem, version 11) remains a draft. Another draft defines MLKEM1024X448, which combines ML-KEM-1024 with X448 and targets a security level matching AES-256 and ChaCha20, though it too is not a final RFC. Drafts also exist for ML-KEM in IKEv2 and for HQC-based TLS combinations. None of these should appear in a production requirement until it becomes an RFC.
Compatibility testing deserves real attention before a hybrid group goes live. A hybrid key share is larger than a classical one, so the first handshake message grows, and some old firewalls, load balancers and inspection devices mishandle messages that no longer fit in a single packet. The failure pattern is usually silent: certain clients cannot connect, while everyone else works. Staged rollouts with per-client monitoring catch this early. Server settings should also keep a classical fallback in place during the transition, so that a client without PQC support still connects, only without the post-quantum protection.
QKD has no equivalent slot in TLS. The EuroQCI program is infrastructure, not a cipher suite, so a QKD-derived key would reach an application through a vendor-specific key-management interface rather than a handshake any browser understands. That integration gap is a large part of why hybrid QKD and PQC demonstrations are an active research goal rather than a shipping product.
Deployment Maturity Scoreboard: Four Yardsticks #
Independent speed benchmarks that compare QKD and PQC directly are scarce, partly because the two do different jobs. A key-rate figure for a fiber link says little about a TLS handshake. The more useful yardsticks in 2026 measure standardization, software support, cloud availability and operational readiness.
| Yardstick | PQC | QKD | Source |
|---|---|---|---|
| Published standard for TLS 1.3 key agreement | RFC 10024, three hybrid groups, August 2026 | None, not a TLS cipher suite | IETF RFC 10024, program descriptions |
| Mainstream client and server support | Firefox via NSS, OpenSSL 3.5, BoringSSL, AWS-LC, RHEL 10 hybrid modes | Specialist vendors and national pilots | NSS roadmap summary, Red Hat |
| Cloud service availability | AWS KMS ML-KEM, announced October 26, 2026 | No public cloud service found | AWS announcement |
| Operational readiness signal | NIST IR 8547 sets dated federal targets | JRC: 12.9% of all quantum-technology signals operational | NIST, European Commission JRC |
Four independent sources, from standards bodies, cloud vendors and the European Commission’s research arm, point the same way. PQC has published standards, shipping software and dated mandates. QKD has pilots and funded programs.
One caution on reading the table: the 12.9% figure is a measure of the wider quantum-technology sector, from quantum computers to sensors, so it flatters neither side. It shows that even the EU’s own research arm sees most quantum technology as pre-operational. The sentence to take away is that QKD may mature later, but the PQC migration has to finish first, since NIST’s earliest deadlines arrive in 2030.
Cost and Procurement: Who Pays for What #
Neither side publishes a price list that a buyer can compare line by line. The useful question is where each approach puts its costs, and the answer starts with a plain statement: no price was found for either side.
| Cost item | PQC | QKD |
|---|---|---|
| Licensing for the core technology | None. FIPS 203, 204 and 205 are government standards | None for the physics, but vendor equipment is proprietary |
| Hardware | Usually none. HSM firmware or cloud service upgrades may apply | Transmitters, receivers, detectors, fiber or satellite capacity |
| Cloud service pricing | AWS KMS ML-KEM: no ML-KEM-specific price in the sources reviewed | No public cloud tariff found |
| Program-level pricing | Not applicable | No official EuroQCI equipment or subscription prices found |
| Main cost driver | Inventory, testing, certificate and PKI changes, performance validation | Site surveys, fiber routes, trusted-node security, specialist staff |
| Ongoing cost | Library and protocol updates through normal patch cycles | Equipment maintenance, key-management integration, recalibration |
How much work lands on the customer depends on the vendor, and the Cloudflare and AWS comparison on post-quantum TLS shows two different approaches. For most budgets, the PQC bill is labor. Teams must find every place that uses RSA or elliptic-curve key exchange, test larger handshakes against middleboxes and old clients, and plan certificate changes. A cryptographic inventory is the first real expense, and it is the same step regulators ask for first. The EU roadmap, as reported, asks Member States to start with an inventory, and one industry resource notes that Article 21 of the NIS2 directive asks organizations for cryptography policies.
The QKD bill is capital. A point-to-point link needs matched equipment at both ends, a suitable fiber route or a satellite partnership, and a secure place to run trusted nodes if the span exceeds a single hop. Because the key still feeds a symmetric cipher and an authenticated channel, the organization pays for the QKD layer and the classical stack beneath it.
A last cost often gets missed. QKD hardware has no software upgrade path when requirements change. If a regulator, as NSA has said it will, declines to certify QKD for a given system class, the buyer holds hardware with no approved use. PQC buyers face the opposite risk, a parameter-set change that requires a patch, which is a much smaller bill.
Migration Deadlines You Actually Face #
Deadlines drive more budgets than technology preferences do. NIST’s final roadmap and secondary summaries of the NSA schedule set the dates that auditors will check.
| Authority | Milestone | Date | Notes |
|---|---|---|---|
| NIST IR 8547 | Federal high-value systems, key establishment | 2030 | Per roadmap summaries |
| NIST IR 8547 | Federal high-value systems, digital signatures | 2031 | Per roadmap summaries |
| NIST IR 8547 | Broader federal completion | 2035 | Stated in NIST’s announcement under NSM-10 |
| NSA CNSA 2.0 | Exclusive use for software, firmware signing and networking equipment | 2030 | Secondary source, confirm against NSA text |
| NSA CNSA 2.0 | Exclusive use for other systems | 2033 | Secondary source, confirm against NSA text |
Secondary summaries of the NIST report also describe a deprecation window of 2031 to 2035 for classical general-purpose signatures, with disallowance after December 31, 2035. Teams should read the primary report before writing policy, because deadlines vary by algorithm and system category.
None of the deadline summaries reviewed attach a QKD milestone to these dates. That absence is the strongest single signal in the comparison, because the rows where a government sets a deadline and an auditor checks for it name PQC algorithms and nothing else. A March 2025 NCSC timeline lines up with them, since it reportedly asks for an initial plan by 2028, top-priority migrations by 2031 and completion by 2035. How the final text differs from the earlier draft is covered in IR 8547 final vs draft, and it pairs well with the table above.
One more date matters for sequencing. Secondary reporting says the European Commission expects Member States to begin transitioning to PQC by the end of 2026, and that national roadmaps follow that start. Treat the exact EU milestones as reported rather than confirmed until the Commission text is in hand.
Pros and Cons #
Both approaches have real strengths. The first table covers QKD and the second covers PQC.
| QKD pros | QKD cons |
|---|---|
| Security argument rests on physics, not unproven math | Agrees keys only, authentication and encryption stay classical |
| Detects eavesdropping on the quantum channel | Needs dedicated optical hardware and fiber or satellite links |
| Funded European programs build real expertise | Range limits force trusted relays or satellites |
| Useful for fixed high-value links with decades-long secrets | No fit for web, mobile or cloud traffic |
| Pairs with PQC in hybrid research projects | NSA, BSI and the NCSC all rank it below PQC |
| PQC pros | PQC cons |
|---|---|
| Standardized in FIPS 203, 204 and 205 | Lattice math is far younger than RSA or elliptic curves |
| Runs as software on existing networks and clouds | Larger keys, ciphertexts and signatures than classical schemes |
| Hybrid groups hedge against flaws in either half | TLS 1.2 and earlier will not receive PQC upgrades |
| Backed by NIST, NSA, NCSC and BSI with dated deadlines | Signature migration waits on PKI and certificate-authority changes |
| Already shipping in Firefox, OpenSSL 3.5, AWS KMS and RHEL 10 | Standalone ML-KEM TLS and some hybrids are still drafts |
Look at the PQC cons closely, because they are about transition friction and not about the strategy failing. The signature problem is the sharpest example. The NCSC’s guidance says that moving TLS authentication to post-quantum alternatives depends on the PKI the connection relies on, and has to wait until the relevant standards are confirmed. Key exchange can move now. Certificates take longer. QKD offers no shortcut for that second half.
Use-Case Recommendations: Which One Fits Your Situation #
The right choice depends on the traffic, the secrecy lifetime and the regulator. Seven scenarios cover most real decisions.
- Public websites and APIs. Enable a hybrid TLS 1.3 group, with X25519MLKEM768 as the default, and keep classical groups as a fallback for old clients. QKD plays no role here.
- US national security systems. Follow CNSA 2.0, with ML-KEM-1024 for key establishment and ML-DSA-87 for signatures. Anyone who wants to add QKD must consult NSA first, and the published stance is against it.
- Cloud key management. Use the provider’s native ML-KEM support where it exists, as AWS KMS now does, and keep envelope encryption with AES-256 underneath.
- European government and critical-infrastructure links with decades-long secrecy. Deploy PQC across the estate first. Join a EuroQCI-related pilot only where a funded program and a specific high-value link justify it, and design that pilot to layer on top of PQC rather than replace it.
- Legacy TLS 1.2 estates. Plan the TLS 1.3 upgrade before anything else. The NCSC states that only TLS 1.3 provides protection against quantum attacks when configured correctly, and it advises that adopting TLS 1.3 and enabling post-quantum key exchange often belong in a single migration.
- Satellites and other long-lived assets. An industry resource notes that a geostationary spacecraft launched in 2027 can still be flying in 2042, so traffic recorded now falls inside its operating life. Prioritize PQC for the link and treat QKD satellite experiments, such as Eagle-1, as research with uncertain timing.
- VPNs and remote access. Look for hybrid support in IKEv2 and in modern tunnel protocols.Post-quantum WireGuard shows what the key-size trade-off looks like in a lightweight VPN.
A few of these cases carry traps. In scenario one, enabling a hybrid group on the server does nothing for clients that never offer it, so adoption tracks browser and library updates. In scenario three, native KMS support covers keys held in the service, but data protected by older client-side libraries keeps its classical exposure until those libraries change. In scenario four, a pilot link can still be wrapped in PQC tunnels, which turns a QKD vs PQC choice into a layered design where each side covers the other’s gap.
A simple rule sits behind these seven cases. If the traffic crosses the open internet or a cloud boundary, QKD cannot reach it, so PQC is the only candidate. If the traffic crosses a dedicated, physically controlled link between two government sites, QKD becomes technically possible, and the question is whether a funded program justifies the cost over PQC alone.
Migration Guide: From Classical Key Exchange to Hybrid PQC in 8 Steps #
Moving to PQC is a staged upgrade, and QKD never enters the plan. The sequence below follows the order the NCSC and NIST guidance imply.
- Inventory cryptography. List every use of RSA, Diffie-Hellman and elliptic-curve key exchange in TLS, SSH, VPNs, code signing, S/MIME, databases and internal services. Record data lifetime for each. Data that must stay secret for a decade or more comes first, because that data is what harvest-now-decrypt-later attacks target.
- Retire TLS 1.0 and 1.1, then plan TLS 1.2 exits. Those old versions are formally deprecated by the IETF in RFC 8996. The NCSC advises government systems to drop them and to move to TLS 1.3.
- Upgrade libraries and proxies. Move to stacks that support the hybrid groups, such as OpenSSL 3.5, BoringSSL-based or AWS-LC-based components, and current NSS.
- Enable a hybrid group on a test endpoint. Turn on X25519MLKEM768 first and keep classical groups available.
- Verify negotiation. A TLS 1.3 connection is not automatically quantum-resistant. It only counts if a PQC or hybrid group is actually negotiated.
- Test for middlebox and size problems. Hybrid handshakes are larger than classical ones, so check firewalls, load balancers and legacy clients before wide release.
- Roll out in rings. Start with internal traffic, then low-risk public endpoints, then the whole fleet. Watch handshake failures and latency.
- Plan signatures and certificates separately. Authentication moves on a slower clock because it depends on certificate authorities and PKI. Track ML-DSA and SLH-DSA support in your CA and HSM vendors.
Two commands help with steps 4 and 5. They assume OpenSSL 3.5 or later.
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 -brief </dev/null
openssl list -kem-algorithms
ssh -Q kex | grep -i mlkem
If the first command reports a negotiated group named X25519MLKEM768, the hybrid exchange works end to end. If it falls back to X25519, the server or an intermediate device does not support the hybrid group yet.
Mistakes to Avoid During Migration
Vendor support is not a government approval. A product that advertises ML-KEM may still fall outside a certification scope that requires specific modes. Another frequent error is assuming TLS 1.3 alone protects against quantum attacks, when only the negotiated key exchange does. A third is treating draft specifications as stable. Standalone ML-KEM TLS and MLKEM1024X448 are still drafts, so avoid hard-coding them into contracts. Last, do not delay signature planning until key exchange is finished, since certificate lead times are long.
Verdict: PQC for Nearly Everyone, QKD as a Specialist Add-On #
The evidence from the final quarter of 2026 is one-sided. NIST set 2035 as the federal completion target and named 2030 and 2031 checkpoints for the most sensitive systems. RFC 10024 standardized three hybrid TLS 1.3 groups in August 2026. AWS added ML-KEM to KMS on October 26. Red Hat, Imperva, Firefox and OpenSSL already carry hybrid support. On the other side, NSA, BSI and the NCSC rank QKD below PQC, and the large QKD programs in the sources reviewed are public infrastructure projects whose own funders now describe hybrid QKD and PQC as a research goal.
The scorecard, in plain terms: PQC wins on standards, deployment reach, cost transparency, regulatory backing and developer effort. QKD wins on the elegance of its physical security argument and on a narrow class of fixed, high-value links where a government program pays the bill. It loses badly on scope, since it agrees keys and nothing else.
Recommended action for the next 90 days: finish the cryptographic inventory, move to TLS 1.3 everywhere, enable X25519MLKEM768 on public endpoints, and test ML-KEM in your cloud key-management service. Put QKD on a watch list, not a roadmap, unless a regulator or a funded program names it in writing. Reassess when Eagle-1’s timing firms up, when the European Commission publishes its post-2027 EuroQCI plan, or when an agency such as NSA changes its position, because any one of those would be a real signal.
FAQ: QKD vs PQC #
Is quantum key distribution more secure than post-quantum cryptography?
QKD rests on physics and PQC rests on math, but “more secure” depends on the whole system. QKD agrees keys only, needs authentication from another mechanism, and depends on real hardware that can have flaws. Agencies including NSA, BSI and the NCSC rank PQC higher for practical protection.
Does NSA recommend QKD?
No. Reporting on NSA’s published position says the agency does not support QKD or quantum-cryptography systems for national security systems and does not anticipate certifying QKD products unless stated limitations are overcome. NSA’s CNSA 2.0 suite names ML-KEM-1024 and ML-DSA-87 instead.
Can QKD replace TLS or HTTPS?
No. QKD is not a TLS cipher suite, and it works on dedicated point-to-point links. Web traffic uses TLS 1.3, where RFC 10024 defines three hybrid groups that pair ML-KEM with classical elliptic-curve exchange.
What is the difference between a hybrid and a pure PQC key exchange?
A hybrid handshake combines a classical exchange, such as X25519, with ML-KEM and mixes both secrets. An attacker must break both parts. A pure PQC exchange relies on ML-KEM alone. The NCSC supports both and calls hybrids an interim step, while BSI and ANSSI lean toward hybrids.
What is EuroQCI?
EuroQCI is the European Quantum Communication Infrastructure, an EU program that combines terrestrial fiber networks with a satellite segment to carry QKD between member states. The Commission has opened a consultation on activities to support from 2027 onward. It is an infrastructure program rather than a product with a price list.
When must organizations finish migrating to PQC?
NIST’s October 27, 2026 roadmap sets 2035 as the federal completion target, with 2030 for key establishment and 2031 for signatures in high-value systems. The UK NCSC’s timeline also ends in 2035. Private companies have no single deadline but face customer and regulator pressure from the same dates.
Should my company buy QKD hardware?
Almost certainly not today. Unless a regulator or a funded government program requires it, spend the budget on cryptographic inventory, TLS 1.3 and hybrid PQC. Revisit QKD if an agency changes its stance or if Europe’s post-2027 plans create a concrete procurement path.