Begin with the service you need
Quantum key infrastructure connects key-generation technology to the applications that consume keys. For a QKD proposal, start with the data flow: which sites communicate, how long the information must remain confidential, who operates the endpoints, and what happens when the link is unavailable?
Write a requirement that can be tested. “Protect traffic between these two data centers with documented endpoint trust and a defined outage policy” is useful. “Make the network quantum-safe” leaves the system boundary, adversary and acceptance criteria undefined.
The quantum cryptography explanation introduces the science. Here the question is whether a proposed infrastructure can deliver an authenticated, supportable service within the organization’s constraints.
Draw the complete trust map
| Component | Responsibility | Evidence to request |
|---|---|---|
| Quantum link and endpoints | Prepare and measure signals under a documented security model. | Measured operating conditions, source/detector assumptions and final secret-key rate. |
| Classical channel | Carry authenticated protocol messages. | How initial authentication is established, renewed and recovered. |
| Key-management interface | Deliver the intended keys to authorized consumers. | API authentication, key identifiers, lifetimes, synchronization and access logs. |
| Encryption appliance or application | Use keys according to an approved encryption protocol. | Algorithm/mode, key consumption, rekeying and integrity verification. |
| Intermediate trusted nodes | Handle secrets where the architecture requires trust. | Physical protection, administration, monitoring and consequences of compromise. |
| Operations and recovery | Maintain service and respond to faults. | Outage policy, failover tests, patching, spares and incident ownership. |
On a narrow screen, scroll the table sideways. Keyboard users can focus the table and use the arrow keys.
Treat a trusted relay as an explicit part of the security boundary. Ask which secrets exist at the relay and which compromise scenarios the design covers. Some architectures have different trust properties; verify the one actually being offered.
ETSI’s QKD standardization work includes interfaces and component/security concerns. An interface standard can support integration, while assurance still depends on the product, configuration and operational evidence.
Compare key supply with key demand
Request the final secret-key rate under the proposed distance, loss, environment and availability conditions. Raw detection rate and sifted-key rate precede processing that can reduce usable output. Also ask whether quoted figures are sustained measurements or favorable laboratory results.
A capacity plan should state the actual rekey policy, number of directions, burst demand, key buffers and behavior during replenishment gaps. Treat the arithmetic above as an illustration, not a suggested security policy.
Keep authentication and availability visible
QKD needs authenticated communication and protected endpoints. The NSA’s QKD technical limitations also discuss special-purpose equipment, implementation assurance, trusted relays and denial of service. Its National Security Systems recommendation has that scope; use the engineering questions to examine the complete proposal.
Specify what happens if the quantum link is cut, a key pool empties or an endpoint is replaced. A service might stop, use a defined reserve or move to an approved alternate cryptographic path. Each behavior should be explicit in policy, observable to operators and tested.
Require alerts that identify the affected service and the action an operator should take. A dashboard saying “secure” is less useful than a record showing which protection path is active, why it changed and who reviewed the event.
Compare with PKI and post-quantum migration
PKI manages certificate-based bindings between identities and public keys. A post-quantum migration can update supported key-establishment and signature mechanisms within classical systems. QKD introduces a physical key-distribution service. The technologies can intersect, but they are different projects with different dependencies.
NIST’s migration project emphasizes discovery and interoperability work. Inventory the current cryptography and applications before deciding which infrastructure changes are necessary. Request vendor evidence for the exact protocol and product versions being considered.
Compare options against the same requirements: site reach, endpoint trust, long-term confidentiality, availability, interoperability, staffing and lifecycle costs. Separate supported capabilities from roadmap promises and schedule a limited pilot with success and failure criteria.
- Record the target service, threat model and current protection.
- Obtain an architecture diagram and evidence for every trusted component.
- Measure key supply and application demand under representative conditions.
- Rehearse endpoint replacement, authentication renewal, link loss and recovery.
- Document unresolved dependencies, support ownership and the decision to proceed, revise or defer.
Keep a usable review record
Download the quantum infrastructure evaluation worksheet (plain text). Save a copy, fill it out in a text editor, and keep it with your approved project records.