PQC Vendor Readiness Questionnaire

Quick answer: A useful PQC vendor readiness questionnaire covers ten categories: supported algorithms and parameter sets, validation status, timelines, API and protocol support, certificate handling, HSM and key custody, hybrid mode support, performance data, rollback and interoperability, and lifecycle and support policy. Generic “do you support post-quantum cryptography” questions get generic marketing answers; specific, verifiable questions, ones asking for a CMVP certificate number rather than a roadmap statement, are what actually separate a vendor with real, deployable PQC readiness from one with a slide about it. This guide is that questionnaire.

Vendor evaluation for PQC readiness runs into the same problem repeatedly across this entire industry: the gap between “we support post-quantum cryptography” and “here is our active FIPS 140-3 certificate number covering that support” is wide, and most procurement conversations never close it. This questionnaire is built to close it.

Key Takeaways

• Ask for specific validation evidence, certificate numbers, CMVP queue status, dated projections, not general capability claims.
• Algorithm support questions need to specify exact parameter sets, not just “ML-KEM” or “ML-DSA” generically, since parameter set determines actual interoperability.
• Rollback and interoperability questions are as important as forward capability questions, since a vendor’s plan for handling a mixed classical-and-PQC environment during transition matters as much as their PQC roadmap itself.
• Lifecycle and support policy questions, how long will classical algorithm support continue, what’s the sunset timeline, close a gap most PQC vendor conversations skip entirely.
• This questionnaire applies across HSM, CA, cloud KMS, and application vendors; the categories are consistent even where the specific answers vary by vendor type.

1. Supported Algorithms and Parameter Sets

• Which specific ML-KEM parameter sets do you support (512, 768, 1024), and as of which product version?
• Which specific ML-DSA parameter sets do you support (44, 65, 87), and as of which product version?
• Do you support SLH-DSA, and if so, which variants?
• Do you support hash-based firmware signing schemes (LMS, XMSS)?
• What is your roadmap for FN-DSA (FIPS 206) and HQC once finalized?

2. Validation Status

• What is your current CAVP algorithm validation status for each supported PQC algorithm, with certificate numbers?
• What is your current FIPS 140-3 module validation status, specifically whether it covers PQC algorithms, with certificate number or CMVP queue position (Modules in Process, Implementation Under Test)?
• Do you have Common Criteria or other regional certifications (eIDAS, NIAP) covering your PQC implementation?
• What is your projected date for full module validation, and what happens to our deployment if that date slips?

3. Timelines

• What is your published PQC migration roadmap, with dates, for your own infrastructure or product line?
• Which capabilities are generally available today versus still in beta, preview, or roadmap status?
• How does your timeline align with CNSA 2.0’s January 2027 acquisition gate, or the federal 2030/2031 deadlines, if applicable to our use case?

4. APIs and Protocol Support

• Which TLS versions and hybrid key exchange groups do you support (e.g., X25519MLKEM768), and is support enabled by default or opt-in?
• Do your APIs expose PQC algorithm selection directly, or is it abstracted through a policy layer?
• What is your support status for relevant protocols beyond TLS (IKEv2/IPsec, SSH, S/MIME) if applicable to our use case?

5. Certificate Handling

• Do you support pure PQC certificates, hybrid/composite certificates, or both?
• If composite, which IETF LAMPS draft version do you implement, and how will you handle changes before final RFC publication?
• What is your certificate template and policy support for mapping different algorithms to different CA tiers?

6. HSM and Key Custody

• Where does PQC key generation and signing actually occur, in software, in a validated HSM, or configurable?
• Are your backup, HA, and clustering features confirmed to work with PQC key types on your current firmware?

7. Hybrid Mode Support

• Do you support running classical and PQC algorithms in parallel during a transition period, and for how long is that expected to remain supported?
• Is hybrid treated as a permanent architecture option or explicitly a transition mechanism with a planned sunset?

8. Performance Data

• Can you provide signing throughput, latency, and key generation benchmarks under sustained concurrent load, not just single-operation figures?
• What is the measured performance delta versus classical algorithms on your specific current-generation hardware?

9. Rollback and Interoperability

• What is your documented process for rolling back a PQC deployment if a compatibility issue surfaces after production rollout?
• Have you tested interoperability with the other specific vendors and platforms in our environment?

10. Lifecycle and Support Policy

• How long will classical-only algorithm support continue after PQC capability ships, and what is the deprecation timeline?
• What support commitment do you provide if a specific PQC parameter set is later deprecated or replaced by NIST guidance?

What We’d Actually Recommend

Require specific evidence, certificate numbers, dated CMVP queue status, benchmark data under real conditions, not general capability claims, for every question in this list. Weight validation status and lifecycle policy as heavily as algorithm support itself, since a vendor with broad algorithm support but no validation path or an undefined classical-sunset policy carries real, often underweighted risk. Use this questionnaire consistently across every vendor being evaluated for the same role, so responses are genuinely comparable rather than each vendor answering a slightly different implicit question.

How Encryption Consulting Can Help

Our PQC Advisory Services help organizations run this questionnaire against real vendor responses, evaluate the evidence provided against the specific claims made, and weigh vendor readiness against the risk-prioritized migration plan the vendor selection is meant to support.

Before any vendor conversation, CBOM Secure confirms exactly which of your current vendors and products this questionnaire actually needs to be sent to, based on your real cryptographic footprint rather than a generic vendor list.

Specific Questions Get Specific Answers

“Do you support post-quantum cryptography” is a question every vendor can answer yes to honestly while meaning something different by it. The ten categories in this questionnaire are built to force the distinction that actually matters for a procurement decision: capability claimed versus capability validated, roadmap versus generally available today, and a defined lifecycle policy versus an open-ended assumption. Sending a specific, evidence-demanding questionnaire is what turns a vendor evaluation from a sales conversation into a genuine readiness assessment.

Frequently Asked Questions

What is the single most important question in a PQC vendor questionnaire?

The validation status question, requesting a specific CMVP certificate number or queue status rather than a general capability claim. This is where the gap between marketing language and deployable, compliant readiness most often surfaces.

Why does the questionnaire ask about classical algorithm sunset timelines?

Because a vendor’s plan for deprecating classical support matters as much as their PQC roadmap for planning your own migration timeline, and it is a question most procurement conversations skip in favor of focusing only on forward capability.

Should this questionnaire be used the same way for HSM, CA, and cloud vendors?

The ten categories apply consistently across vendor types, though the specific answers and relative weighting will differ; an HSM vendor’s key custody answers matter differently than a cloud KMS vendor’s, for instance, even though both fall under the same category.

Why ask for specific parameter sets rather than just “do you support ML-KEM”?

Because parameter set determines actual interoperability and regulatory fit. A vendor supporting only ML-KEM-512 does not satisfy a CNSA 2.0 requirement for ML-KEM-1024, even though “we support ML-KEM” is technically a true statement either way.

How should performance data from vendors be evaluated?

Skeptically, as a starting point rather than a final answer. Request sustained-load and concurrency figures, not just single-operation benchmarks, and independently verify against your actual environment before a purchase decision, following the test plan in our HSM benchmarking guide.