How do you evaluate a vendor's quantum-readiness claim?
Evaluate a vendor's quantum-readiness claim by checking its scope, its tense and its evidence. Confirm it names your product, release and deployment. Separate what is available, enabled and observed in use from what is promised. Match each present-tense claim to assessable, dated evidence, and check that evidence is current. Record what is missing as a limitation rather than filling the gap with assumption.
New to this? Read What should you ask vendors about PQC? first. After this, continue with What should PQC contract language address?.
In one sentence: Check scope, separate present from future, match claims to current evidence, and record gaps.
Why it matters
A claim can be true and still irrelevant: true for another release, another region or a configuration you have not enabled.
QCI-QS1 counts a response as adequate only when it identifies product and deployment scope, separates available, configured and deployed posture, and supplies assessable evidence for material present-tense claims (QCI-7.2-03).
Review workflow
- 1. Scope: does the claim name the legal entity, product, release, deployment model and exclusions?
- 2. Tense: is each statement present capability, enabled configuration, observed use, or future commitment?
- 3. Evidence: does each material present-tense claim have assessable evidence or controlled access?
- 4. Assurance type: is the evidence a supplier assertion, an algorithm test, a module validation or full-system acceptance? These are recorded separately (QCI-4.8-03).
- 5. Currency: is the evidence within its validity, and has any material change invalidated it?
- 6. Deployment check: does evidence from your own environment agree with the claim?
- 7. Decision: record adequacy, or the reasons for inadequacy, with engineering and vendor-risk sign-off (QCI-7.2-03).
Hypothetical examples
Both examples are invented. They do not describe any real vendor or product.
| Element | Incomplete claim | Stronger claim |
|---|---|---|
| Scope | "Our platform is quantum-safe." | Names product, release 8.2, the cloud-hosted deployment model, and excludes the on-premises connector |
| Tense | Mixes "supports" and "will support" without distinction | States hybrid key exchange is available and off by default in 8.2; on by default planned for 9.0, estimated, not committed |
| Evidence | None attached | Scoped inventory with method and limitations; interoperability test report naming versions |
| Validation | "Uses NIST-approved algorithms" | Lists algorithm test results and module validation status separately, with caveats; does not claim full-system validation |
| Signing | Unsigned web page | Attestation signed by a named officer with stated authority and as-of date |
Advertised versus deployed capability
Supplier availability, a plan, an accepted risk or a pilot does not count as migration completion (QCI-6.2-02). A supplier's "quantum-safe" label does not alone establish production approval (QCI-4.5-02). A validated algorithm or module is not assurance of the complete deployed system (QCI-4.8-03).
Scope omissions and stale evidence
- Look for missing subservice providers, regions, editions or connectors.
- Superseded or materially invalidated evidence does not pass G70 (QCI-7.2-03).
- Critical evidence is no older than 90 days unless a documented review confirms unchanged configuration; stale evidence does not support a gate (QCI-5.1-04).
What organizations should do
- Run each supplier response through the seven review steps.
- Tag every statement as available, enabled, observed or committed.
- Collect evidence from your own deployment to confirm key claims.
- Record the adequacy decision and reasons.
Evidence an auditor should expect
Rows marked "QCI requirement" come from the standard. Rows marked "Editorial suggestion" are QCI's practical advice and are not requirements.
| Artifact | Scope | Owner | Currency | Verification | Basis |
|---|---|---|---|---|---|
| Claim review worksheet | Each supplier response | Engineering reviewer | At review | Check each claim is tagged and linked to evidence | Editorial suggestion |
| Assurance type record | Each validation or test claim | Engineering reviewer | At review | Supplier assertion, algorithm test, module validation and system acceptance kept distinct | QCI requirement (QCI-4.8-03) |
| Adequacy decision | Each response | Engineering and vendor-risk reviewers | At review | Acceptance or reasons recorded | QCI requirement (QCI-7.2-03) |
How NIST or other primary authorities address it
This concept originates with QCI in QCI-QS1. NIST and other standards bodies do not define or endorse it.
How QCI-QS1 addresses it
QCI-QS1 defines adequacy and the separation of assurance types. Level 5 of Pillar 5 adds independent review of a risk-based sample of supplier claims against technical or customer evidence (QCI-6.10-01). This page does not rank or endorse any vendor.
| Requirement | Clause | Relationship | Pillar | Gate |
|---|---|---|---|---|
| QCI-7.2-03 | 7.2 | explicit requirement | P5 | G70 |
| QCI-4.8-03 | 4.8 | explicit requirement | — | — |
| QCI-4.5-02 | 4.5 | supporting evidence | P4 | — |
| QCI-5.1-04 | 5.1 | supporting evidence | P2 | — |
| QCI-6.10-01 | 6.10 | supporting evidence | P5 | — |
Common mistakes
- Treating "NIST-approved algorithms" as proof the whole system is protected.
- Accepting a claim for the latest release when you run an older one.
- Relying on evidence from before a material change.
- Filling evidence gaps with assumption instead of recording a limitation.
Questions for the board
- How many critical supplier claims have been checked against our own deployment evidence?
- Has any supplier claim been independently reviewed?
Questions
Does QCI publish a list of ready vendors?
No. QCI does not rank or endorse vendors. Readiness depends on your product, release and deployment, so it is assessed by the customer.
What makes evidence stale?
Under QCI-QS1, critical evidence older than 90 days without a documented review confirming unchanged configuration, or evidence invalidated by a material change (QCI-5.1-04, QCI-7.2-03).
Is module validation enough?
No. A validated algorithm or module is not assurance of the complete deployed system (QCI-4.8-03).
Sources
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 7. Supports: Supplier identification, request content, adequacy, attestation and oversight.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 4.8. Supports: Assurance types.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 4.5. Supports: Production approval.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 5.1. Supports: Evidence age.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 6.10. Supports: P5 supplier rubric.
Related learning
Back to Suppliers and procurement · All Knowledge Center topics
Page history
- Published
- Not yet recorded
- Standard edition
- QCI-QS1 v2.3 (September 23, 2026)
Cite this page
Quantum Core Institute. (n.d.). How do you evaluate a vendor's quantum-readiness claim?. https://quantumcoreinstitute.com/learn/suppliers/evaluate-pqc-vendor-claims
Link: https://quantumcoreinstitute.com/learn/suppliers/evaluate-pqc-vendor-claims