PQC uses new cryptographic algorithms designed to resist attack by quantum computers, while QKD uses quantum physics to distribute encryption keys. PQC is software and protocol based, so it is easier to deploy at scale. QKD needs specialised hardware and links, so practitioners usually plan migration around PQC for most systems.
Why PQC and QKD solve different problems
PQC and QKD both address the quantum-era threat, but they do so at different layers. PQC changes the cryptographic algorithms themselves so they remain practical on ordinary systems, while QKD changes how keys are shared by using quantum effects. That means the operational trade-off is not just security strength, but deployment model, compatibility, and how much infrastructure you must change.
For most teams, the key question is whether the control must fit existing software, network, and lifecycle processes or whether it can justify a specialised communications channel. PQC is usually easier to integrate into standard application, identity, and transport stacks, while QKD is usually a dedicated design choice for narrow, high-value links. For a practical migration view, see Post-Quantum Readiness for Identity and PKI.
QKD is often misunderstood as a general replacement for encryption, but it is mainly a key-distribution mechanism. It does not remove the need for authenticated endpoints, key management, or secure system integration. PQC, by contrast, can be used across broader cryptographic functions and is the more scalable option for modern enterprise systems, especially where software updates and protocol changes are realistic.
Where PQC fits better than QKD in real deployments
PQC is generally the better fit when the goal is to protect data, sessions, signatures, and trust relationships across many systems without adding specialised hardware. That matters because most organisations need a cryptographic transition that can be rolled out through software, firmware, and protocol upgrades rather than through new physical links. The broad deployment path makes PQC the default planning choice for large estates.
QKD can be compelling where the environment already justifies dedicated fibre, trusted nodes, or tightly controlled point-to-point links. Even then, it is best understood as a niche control for specific channels, not a universal enterprise strategy. The practical difference is that PQC can travel with the application or service, while QKD tends to stay bound to the link and the equipment that implements it.
That distinction also affects governance and inventory. pqc migration is usually about discovering where cryptography exists, what algorithms are in use, and where protocol upgrades are needed. QKD planning is usually about link topology, hardware dependencies, operational maintenance, and whether the cost of specialised deployment is justified by the protection target. The broader transition challenge is captured well in Machine Identity, PKI and Certificate Lifecycle Guide.
How to think about the security trade-offs and operational limits
PQC and QKD are not interchangeable controls, because they fail in different ways. PQC depends on correct algorithm implementation, protocol integration, and migration discipline. QKD depends on specialised hardware, secure channels, and the assumption that the key exchange path itself is deployed and operated correctly. In other words, PQC shifts the challenge toward software agility, while QKD shifts it toward physical and operational complexity.
That difference matters when you are deciding what to protect first. If you need broad coverage, compatibility, and manageable rollout, PQC usually gives the better risk reduction per unit of effort. If you need a very specific high-assurance link and can support the infrastructure, QKD may be useful as a narrow compensating design. Most organisations should assume PQC first, then evaluate whether any link-specific QKD use case is still worth the extra complexity.
Current guidance across the crypto-migration community points in the same direction: plan for algorithm transition, inventory cryptographic use, and avoid waiting for a hardware-led solution to solve a software-scale problem. That is especially important where long-lived trust relationships and certificate lifecycles are already part of the environment, because quantum risk is really a migration problem as much as a cryptography problem. A useful reference point is NIST SP 800-57 Key Management.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | PT1 — Recommendation for Key Management, Part 1 | PQC and QKD both hinge on key lifecycle and algorithm transition decisions. |
| Recommendation — Define cryptoperiods and migration rules for quantum-safe key management. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Quantum-safe transition affects credential and key handling across systems. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | QKD and PQC affect machine and service trust paths that authenticate across systems. | |
| Recommendation — Update authenticator lifecycle controls to support quantum-safe cryptography. Use cryptographic transitions that preserve service-to-service authentication integrity. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The question is fundamentally about choosing cryptographic protection methods. |
| Recommendation — Specify cryptographic controls that can be migrated to quantum-safe algorithms. | ||
| CIS Controls v8 | CIS-3 — Data Protection | PQC and QKD are both data-protection choices for protecting confidentiality in transit. |
| Recommendation — Prioritise quantum-safe protection for sensitive data flows and key exchange. | ||
Practitioner Guidance
What to prioritise: Treat PQC as the default migration path for most systems and reserve QKD for narrow cases where the link value, distance, and infrastructure justify specialised deployment. If a system can be updated through software and protocol changes, it is usually a PQC candidate first.
What to verify: Check where your current cryptography lives in software, firmware, certificates, APIs, and transport layers, then separate broad migration needs from link-specific exceptions. If the architecture needs new hardware or dedicated circuits to make the control work, you are moving into QKD territory.
Common mistake: Do not treat QKD as a universal replacement for post-quantum migration. It solves a different part of the problem, and it does not eliminate the need to plan for algorithm agility, key lifecycle management, and authenticated system integration.
Practitioner takeaway: For most environments, the right decision is not “PQC or QKD” as equals, but “PQC everywhere possible, QKD only where a narrow link use case justifies the infrastructure.”
Related resources from NHI Mgmt Group
- What is the difference between a separate PQC CA hierarchy and hybrid certificates?
- What is the difference between cryptographic inventory and cryptographic context in PQC migration?
- What is the difference between hybrid PQC certificates and pure post-quantum certificates?
- What is the difference between cryptographic inventory and algorithm agility in a PQC migration?