PQC Vendor Questionnaire for Security and Procurement

Published

By Post Quantum Field · We verify claims against NIST publications, vendor changelogs, and IETF drafts. Experimental support is never presented as production-ready.

Vendors increasingly describe products as quantum-safe, quantum-ready, or PQC-capable. Those labels do not identify the algorithm, operation, protection level, product version, availability status, or evidence. Procurement teams need capability-level answers.

Download the PQC vendor questionnaire CSV. Use this page to understand what a complete response should contain. The questionnaire is not a vendor ranking or certification.

Compare responses with the maintained PQC Vendor Support Matrix and record accepted dependencies in the PQC Migration Plan Template.

1. Product and deployment scope

Ask the vendor to identify product name, edition, version, deployment model, supported operating systems, regions and availability date. Require separate answers for SaaS, self-hosted software, appliance firmware, cloud marketplace images and managed services.

Key questions:

  1. Which released product version contains each PQC capability?
  2. Is it generally available, Preview, beta, experimental, private access or roadmap-only?
  3. Which regions, account tiers and hardware models support it?
  4. Does the capability require a feature flag, support request or separate license?
  5. What compatibility requirements apply to clients and dependencies?

A roadmap response is useful for planning but is not deployed support. Record dates and revalidate them.

2. ML-KEM and key establishment

Ask which exact ML-KEM parameter sets are supported and for what operation. Key generation and decapsulation in a KMS are different from hybrid TLS negotiation, HPKE key import, VPN key establishment or an application API.

Require the vendor to specify:

  • ML-KEM-512, ML-KEM-768 or ML-KEM-1024;
  • standalone or hybrid construction;
  • exact protocol identifier or named group;
  • client and server roles;
  • key generation, encapsulation and decapsulation locations;
  • software, HSM or external key protection;
  • production and validation status;
  • documented fallback behavior.

Do not accept “supports ML-KEM” without a workflow. The cloud-provider comparison demonstrates why provider capabilities differ by service and operation.

3. ML-DSA and signature workflows

Ask which ML-DSA parameter sets are supported and where signatures are created and verified. Separate generic library APIs, managed KMS signing, HSM keys, private certificates, public WebPKI, code signing, document signing, firmware and token authentication.

Questions should cover:

  • ML-DSA-44, ML-DSA-65 and ML-DSA-87;
  • key generation, import, export and backup;
  • signing and verification APIs;
  • pre-hash or pure variants where relevant;
  • certificate and key encoding;
  • audit logs and approval controls;
  • throughput and signature-size limits;
  • verifier and ecosystem compatibility.

An ML-DSA primitive in a library does not prove that a certificate authority, bootloader, browser or relying party accepts it.

4. Certificate lifecycle and PKI

Ask whether the platform can issue, store, renew, rotate, validate, revoke and discover certificates using PQ or composite signatures. Require exact certificate profiles and standards references.

Verify:

  1. Public versus private PKI support.
  2. Root, intermediate and leaf certificate capability.
  3. Classical, PQ and composite chain behavior.
  4. OCSP, CRL, enrollment and automation compatibility.
  5. Certificate-size and protocol limits.
  6. Trust-store and relying-party support.
  7. Migration and rollback when clients reject a new chain.

If the implementation depends on an IETF draft, record the draft version. A draft is not a final RFC, and future changes may break interoperability.

5. HSM and key-management support

“KMS support” can mean software-backed keys while HSM-backed targets remain unsupported. Ask the vendor to identify protection level for each key type and operation.

Require answers for:

  • on-device key generation;
  • imported keys and wrapping method;
  • key export restrictions;
  • rotation and versioning;
  • backup, replication and disaster recovery;
  • deletion and zeroization;
  • PKCS#11, KMIP and provider API behavior;
  • multi-region and high-availability support;
  • hardware and firmware version;
  • FIPS module certificate and whether the exact PQ implementation is in scope.

A product using a FIPS-validated module does not automatically mean every newly added PQ algorithm is covered by that validation. Request the certificate number, security policy and module version.

6. Hybrid cryptography

Ask the vendor to name the classical and post-quantum components, combiner or protocol, negotiation identifier, downgrade handling and failure behavior. Hybrid can refer to key establishment, signatures, certificates or a larger protocol. These are not interchangeable.

The vendor should explain whether both components must succeed, how secrets are combined, whether the construction follows a final standard or draft, and how it will be upgraded. See Hybrid Cryptography Explained for terminology.

7. Cryptographic inventory and discovery

For discovery products, ask which layers they actually see:

  • network handshakes and certificates;
  • application code and configuration;
  • container images and dependencies;
  • cloud services and KMS keys;
  • HSMs and appliances;
  • firmware and embedded systems;
  • third-party SaaS;
  • undocumented or custom cryptography.

Request a sample export schema, supported integrations, false-positive handling and evidence of coverage. Automated discovery should complement owner attestation because no tool sees every embedded dependency. Use the Cryptographic Inventory Guide to evaluate coverage.

8. Testing, monitoring and rollback

Ask for test endpoints, interoperability matrices, conformance evidence, performance results and known limitations. Performance should include handshake or operation latency, message size, throughput, memory and HSM capacity on named hardware.

Operational questions:

  1. Which logs identify the negotiated or used algorithm?
  2. Can policy violations and classical fallback trigger alerts?
  3. How is cryptographic drift detected?
  4. Can a deployment be scoped to a pilot population?
  5. What is the documented rollback procedure?
  6. How long are old keys and configurations retained?
  7. How are incidents and breaking changes communicated?

Marketing benchmark results are not enough. Request the method, versions and configuration needed to reproduce them.

9. Migration roadmap and support lifecycle

Ask for dated capability milestones but classify them as commitments only when contractual. Request end-of-support dates for classical-only products, upgrade paths for appliances, and the vendor’s response when a draft or algorithm profile changes.

For long-lived devices, require a firmware and trust-anchor migration path. A cloud service can change centrally; embedded products may remain deployed for a decade and depend on boot ROM, limited storage, constrained bandwidth or offline signing infrastructure.

10. Evidence and response scoring

Score evidence, not brand reputation:

StatusMeaning
VerifiedPrimary documentation and test evidence match the exact capability
DocumentedOfficial documentation exists but your team has not tested it
PreviewVendor offers limited or changeable access
RoadmapDated intention, no usable capability
UnsupportedVendor confirms no capability
UnknownResponse is vague or evidence is missing

Do not collapse these fields into one overall “PQC readiness score.” A vendor can have production hybrid TLS and no HSM-backed PQ signing. Preserve the capability matrix.

Procurement decision record

For every accepted claim, store the source URL, document version, product version, date verified, reviewer and test result. Add contractual requirements for capability, notification of material changes, evidence access, export, rollback and support lifecycle where appropriate.

PQC support does not establish SOC 2, HIPAA or another compliance status. It is one technical capability within a broader control environment.

Frequently asked questions

Can a vendor be called PQC-ready if it only supports hybrid TLS?

Describe the exact TLS capability instead. It says nothing about signatures, PKI, HSMs, code signing, storage or application cryptography.

Should Preview support satisfy procurement requirements?

Usually only for a controlled pilot. Production requirements should specify stability, support, compatibility and rollback expectations.

Is a FIPS-validated library sufficient evidence?

No. Confirm that the exact algorithm, module version and operating environment fall within the validation scope.

How often should vendor answers be refreshed?

At contract review, major release, capability change, migration milestone, security incident or a scheduled interval appropriate to risk.

Should responses be published?

Publish only claims supported by sources the vendor permits you to share. Keep confidential architecture and contractual material in the procurement record.

Sources

Related articles

Cryptographic Inventory Guide

Practical guide to building a cryptographic inventory. Tools, scanning techniques, and prioritization methods for PQC migration planning.

OpenSSL 3.0 to 3.5 PQC Migration Worksheet

A practical worksheet for inventorying, testing, rolling out, and rolling back an OpenSSL 3.0-to-3.5 migration for post-quantum cryptography.

PQC Migration Plan Template for Enterprise Teams

Download and use a practical PQC migration plan covering ownership, crypto functions, dependencies, testing, rollback, dates, and evidence.

Cryptography Bill of Materials Guide and Template

Build a useful CBOM for post-quantum migration with a downloadable component inventory, dependency fields, evidence, and ownership guidance.