September 4, 2026
QNu Labs Editorial

What to Ask a Quantum Security Vendor Before You Sign: Ten Questions That Separate Deployed Technology from a Promising Prototype

The quantum security market in 2026 contains vendors at every stage of maturity: research institutions with impressive papers and no production deployments, startups with early-stage pilots in controlled conditions, and companies with years of production deployment across demanding real-world environments. Procurement teams and CISOs evaluating vendors in this market face a specific challenge: the technology vocabulary is common across all of them. QKD, PQC, QRNG, Crypto Agility, information-theoretic security. These terms appear in every pitch deck regardless of whether the underlying product has ever left a laboratory.

The questions below are designed to cut through that ambiguity. They are not trick questions. A vendor with production-grade technology will answer them directly, with specifics. A vendor whose technology is not yet production-ready will answer them with qualifications, deferrals, or terms that sound like answers but are not. The pattern of responses to these ten questions is more informative than any product demonstration.

The quantum security market is young enough that buyers have significant leverage. The questions you ask in a procurement process shape the standards the market is held to. Organisations that ask rigorous questions, and evaluate answers rigorously, advance the quality of quantum security deployment across the entire sector.

The Ten Questions

Question 1: Is this technology commercially deployed in production, or is it a prototype?

This is the first and most important question. A production deployment means the technology is operating continuously in a live environment where real data depends on it. A prototype means the technology has been demonstrated, possibly in a controlled environment, and may work as described under those conditions.

A strong answer names specific deployments with customer categories (not necessarily customer names, which may be confidential), states the duration of deployment, and describes the operational environment. A weak answer discusses pilots, proof-of-concept deployments, or demonstrations without stating that those have transitioned to production.

Why it matters: quantum security systems face operational conditions in production environments that controlled demonstrations do not replicate: vibration, temperature variation, electromagnetic interference, concurrent traffic loads, and operational maintenance constraints. A system that performs well in a demonstration environment may not perform reliably under these conditions.

Question 2: What independent validation do you have, from whom, and what exactly did they test?

Independent validation means a third party with no commercial stake in the outcome tested the system against documented criteria and published the results. It is distinct from internal testing, which every vendor has, and from reference deployments, which speak to customer acceptance but not to technical specification verification.

A strong answer names the validator, describes the test methodology, specifies the performance parameters tested (key generation rate, QBER, range, error correction rate), and provides access to the validation report. A weak answer cites a customer reference, a conference presentation, or a research paper authored by the vendor's own team.

Question 3: What fibre distances and network topologies have you deployed in production?

QKD systems operate under physical constraints that vary significantly by network topology. A point-to-point deployment at 50 km is technically simpler than a hub-and-spoke deployment at 150 km or a meshed QKDN at 500 km. The vendor's production deployment portfolio is a direct indicator of the engineering challenges they have actually solved.

A strong answer specifies distances, topologies (point-to-point, hub-and-spoke, QKDN, free-space, satellite), and the infrastructure conditions under which those deployments operate (standard telecom fibre vs. specialised quantum fibre, urban vs. inter-city, indoor vs. outdoor). A weak answer quotes theoretical maximum range from a laboratory result or a protocol specification without a corresponding production deployment.

Why it matters: standard telecom fibre has different attenuation characteristics, dispersion properties, and connector quality variation than laboratory-grade fibre. A system validated on specialised fibre and deployed on standard fibre may not perform as specified.

Question 4: How does your PQC layer integrate with existing PKI infrastructure?

Post-quantum cryptography migration requires replacing or augmenting the public-key infrastructure that underpins certificate issuance, TLS, authentication, and code signing. This integration is complex because PKI touches every authenticated system in an organisation's estate.

A strong answer describes a specific integration path for NIST FIPS 203 (ML-KEM for key encapsulation) and FIPS 204 (ML-DSA for signing) within the customer's existing certificate authority, HSM infrastructure, and TLS stack. It addresses hybrid mode (classical + PQC algorithms running simultaneously during transition) and specifies which HSM vendors and certificate authorities are supported.

A weak answer describes PQC as an algorithm layer without specifying the integration path with existing infrastructure, or assumes that the customer will replace all PKI infrastructure with the vendor's own stack.

Question 5: What does your key management architecture look like at scale?

Quantum key distribution generates cryptographic keys continuously. Those keys must be stored, distributed to endpoints, tracked, rotated, and retired in a way that is both secure and operationally manageable. At scale, with hundreds or thousands of endpoints, manual key management is not viable.

A strong answer describes an automated Quantum Key Management System (QKMS) with documented key lifecycle policies, API integration with existing security orchestration tools, high availability architecture, and key generation rate specifications matched to the deployment's bandwidth requirements. A weak answer describes key management as a feature to be discussed later, or as something the customer's existing HSM infrastructure will handle without vendor support.

Question 6: What happens if the quantum channel is interrupted? How does the system fail?

QKD systems depend on a physical quantum channel (optical fibre or free-space) that can be interrupted by fibre cuts, atmospheric conditions (for free-space), or deliberate jamming. The security behaviour of the system when the quantum channel fails is a critical operational specification.

A strong answer specifies: whether the system fails open (falls back to classical encryption, which is a security degradation) or fails closed (blocks communications until the quantum channel is restored, which is a security hold but an operational interruption), what the detection mechanism for channel interruption is, how rapidly failover or restoration occurs, and whether a fallback policy is configurable. A weak answer focuses on uptime metrics without addressing the security behaviour of failure modes.

Question 7: What is your upgrade path as NIST PQC standards evolve?

NIST finalised three PQC standards in August 2024 and selected HQC as a fifth algorithm in March 2025. [Source: NIST migration FAQ] The PQC algorithm landscape will continue to evolve as cryptanalysis research identifies weaknesses in current candidates. A vendor whose product hard-codes specific algorithms without an upgrade path is selling a system that will require full replacement at the next standardisation cycle.

A strong answer describes a Crypto Agility architecture that allows algorithm updates through software or firmware without hardware replacement, specifies the mechanism for delivering algorithm updates to deployed systems, and discusses the vendor's process for monitoring NIST and ETSI standardisation developments. A weak answer treats the current NIST standards as a fixed endpoint rather than a first iteration.

Question 8: How do you handle hybrid deployment during the transition period?

No large organisation will migrate from classical to post-quantum cryptography overnight. During the transition, systems will run both classical and PQC algorithms simultaneously: hybrid mode. The security of this period depends on the system treating the hybrid as additive security (both layers must be broken for a compromise) rather than as a lowest-common-denominator (the weaker layer determines security).

A strong answer specifies the hybrid mode implementation, confirms that security is the stronger of the two layers (not the weaker), and provides a migration timeline framework for transitioning from hybrid to PQC-only mode as deployments are completed. ML-KEM hybrid key exchanges combining X25519 with ML-KEM-768 are already active in production browsers. [Source: arXiv 2603.01091] The vendor's hybrid implementation should be consistent with this standard practice.

Question 9: What is your customer support model for a classified or defence environment?

Quantum security systems deployed in defence, government, or classified environments have support requirements that differ from commercial enterprise. Personnel security clearances may be required for support engineers. Remote access for diagnostics may not be permitted. Support procedures must accommodate classification levels of the systems being maintained.

A strong answer describes cleared support personnel, on-site support availability, support procedures that do not require remote access to classified systems, and a documented escalation path for critical failures. A weak answer describes a standard commercial support model without addressing the specific constraints of classified or defence environments.

Question 10: Can you provide a reference deployment where we can speak to the security or operations team?

A reference deployment in a comparable operational environment is the most direct evidence available that a vendor's technology works at the scale and in the conditions relevant to the buyer. Reference deployments in banking are relevant for BFSI buyers. Reference deployments in naval or defence environments are relevant for defence buyers. Academic or research deployments are less relevant for operational infrastructure buyers.

A strong answer provides specific reference customers in a comparable sector, with permission to contact the security or operations team directly, not just an executive reference. A weak answer provides press releases, case study summaries, or references that are conditional on non-disclosure of technical details.

Must-Know: What QNu Labs Answers to Each of These Questions

Production deployments: 25 naval QKD systems, in BFSI, 500+ km Intercity QKD network with 1000 Km QKDN demonstrated live. Independent validation by global and national institutes

Topologies: point-to-point, hub-and-spoke, QKDN across standard telecom fibre with a 4-node architecture delivering 60% infrastructure reduction vs. global standard.

PKI integration: Hodos PQC implements ML-KEM and ML-DSA across existing PKI infrastructure without full stack replacement.

Key management: QKMS, automated key lifecycle management.

Failure mode: documented in product specifications.

Algorithm agility: Crypto Agility is a platform design principle across QShield

Hybrid mode: supported across Armos and Hodos.

Defence support: cleared personnel, on-site support capability. References: available on request for comparable sectors.

How to Use These Questions in a Procurement Process

Request written responses to all ten questions before scheduling a product demonstration. A vendor who is confident in their production capabilities will answer in writing without qualification. A vendor who asks to discuss questions verbally before providing written answers is managing the information flow.

Score responses on two dimensions: specificity (does the answer contain verifiable specific facts, or does it remain at the level of claims?) and relevance (does the answer address the question that was asked, or does it redirect to adjacent topics?). The pattern of specificity and relevance across ten questions is more informative than any individual answer.

Include at least one reference customer call in the evaluation process. Prepare specific questions for that call: what operational challenges did you encounter during deployment? What was the support experience during a critical failure? Would you deploy this vendor's technology again for a larger programme?

Final Thoughts

The quantum security vendor evaluation process is, at its core, a process of separating marketed claims from operational reality. The ten questions above are designed to make that separation as direct as possible. The vendors who answer them confidently, specifically, and in writing are the vendors whose technology is ready for the environments where quantum security matters most.

QNu Labs has been answering these questions with production deployments, independent validation, and reference customers for ten years. Engage with us at the 19 September Innovation Showcase or contact our team directly to begin the conversation.

Ready to take the next step?

Request a QNu Labs Product Briefing: https://www.qnulabs.com/contact-us

Download: MarketsandMarkets QKD Global Leader Report 2026: https://www.qnulabs.com/whitepaper

Contact QNu Labs: https://www.qnulabs.com/contact-us

Related: Quantum Readiness Assessment Measures (QNu Blog)

Related: QKD Complete Guide: https://www.qnulabs.com/blog/quantum-key-distribution-qkd-complete-guide

Frequently asked questions

How do I tell if a quantum security vendor is selling a prototype versus a production system?
What is information-theoretic security and how is it different from computational security?
What should I look for in a vendor's Crypto Agility implementation?
Does a vendor's QRNG need to be certified independently?
What is the difference between QKD and PQC and does a vendor need to offer both?
How important is the vendor's supply chain provenance for a quantum security deployment?

More blogs