Turn vendor claims into an actionable plan
“Quantum ready” is not a precise product specification. Ask which operation is protected, in which supported release, under which configuration, and how you can verify it. A good answer identifies limits as clearly as capabilities.
Start with the vendors that handle long-lived sensitive data, difficult-to-replace devices, or shared services that block other migrations. NIST's migration project emphasizes discovering cryptographic dependencies and testing interoperability.
A questionnaire you can copy
Adapt this to the product and send it through your established support or procurement channel. Avoid including private infrastructure details or secrets unless they are necessary and the channel is appropriate.
Product/service and exact version:
Deployment model, region, and enabled features:
1. Which connections, signatures, and stored-key operations use PQC today?
2. What exact algorithms, parameter sets, protocol versions, and encodings apply?
3. Is this generally available and supported, or preview/roadmap only?
4. What must both peers run, and which policy or license settings are required?
5. What is enabled by default? When can it fall back to classical cryptography?
6. How can we observe the algorithm actually used in our deployment?
7. Which internal services, subprocessors, SDKs, and devices are still dependencies?
8. How do you migrate certificates, signing keys, wrapped keys, and historical data?
9. What are the interoperability, performance, rollback, and recovery test results?
10. If claiming validation, what exact certificate/module/version/mode is covered?
11. What are the supported release, patch, end-of-support, and migration dates?
12. Who owns open gaps, and when will you provide updated evidence?
Requested response: dated documentation plus a reproducible test procedure.Classify the response
| What you receive | How to record it | Follow-up |
|---|---|---|
| A marketing statement | Unverified claim; readiness unknown | Request the exact feature, release, scope, and documentation. |
| A future delivery date | Roadmap dependency, with source/date | Assign an owner and a checkpoint; do not mark deployed. |
| Supported release/configuration documentation | Vendor-documented capability | Confirm your configuration and arrange a representative test. |
| Your dated test with peer/version/algorithm | Observed evidence for the tested scope | Retain limits, cover remaining paths, and schedule regression checks. |
| A validation or certification claim | Claim tied to its exact certificate and boundaries | Verify the record and that your release, environment, and mode are included. |
For example, algorithm conformance and cryptographic-module validation are different. Use the CMVP record when a vendor claims module validation; a library containing ML-KEM does not establish that claim for every deployment. The standards reference separates these levels.
Agree on acceptance tests before rollout
- Scope: enumerate each relevant path: user-to-edge, edge-to-origin, internal service, administrative access, signing, and key management.
- Representative peers: include supported OS/runtime versions, agents, proxies, VPNs, and recovery clients. A vendor's lab client may differ from yours.
- Positive evidence: require the selected algorithm or verified artifact, successful identity checks, and the version/configuration used.
- Failure behavior: test incompatible peers, certificate problems, unavailable keys, and timeouts. Specify when fallback is allowed and how it becomes visible.
- Operational behavior: measure latency, handshake/artifact size, resource use, renewal, rotation, and recovery. Record the expected limits.
- Recovery: preserve an approved rollback, verify it, and retain the unresolved migration issue if the rollback restores classical cryptography.
Use a staging environment or controlled canary with a known recovery path. This is a proposed acceptance checklist, not a claim that CheckPQC has tested the vendor.
Handle gaps without hiding them
For a missing feature, capture whether the plan is an upgrade, a replacement, a supported architectural change, or a documented temporary exception. Record the business owner, data sensitivity, dependency, evidence source, target date, and next review. An exception is a decision to manage a gap; it is not successful migration.
Require documentation for what a “PQC tunnel” or gateway covers. It may protect one exposed network segment while endpoints still use classical signatures or store vulnerable wrapped keys. Use the connection diagram, signature checklist, and key lifecycle checklist to make the scope explicit.
Keep a dated dependency record
Track vendor-documented capability separately from implementation status in your readiness worksheet. Recheck high-change roadmaps and retest after release or policy changes. Avoid a single “ready percentage” that masks an unassessed signing service or critical device.
Documentation reviewed 25 September 2026. The questionnaire and acceptance checklist are CheckPQC planning aids, not a vendor endorsement or compliance certification.