What is supplier PQC readiness?
Supplier PQC readiness is evidence that a product or service you rely on can protect your use of it as cryptography changes. It is judged for the specific product, release and deployment you run, not for the supplier as a company. It covers which cryptography the product uses, what is available versus configured versus deployed, who owns configuration and testing, dependencies on other providers, and how claims stay current.
New to this? Read Cryptographic inventory: definition, scope and required fields first. After this, continue with What should you ask vendors about PQC?.
In one sentence: Readiness belongs to a product, release and deployment, not to a supplier's brand.
Why it matters
Much of an organization's cryptography runs inside products and services it buys. A supplier announcement can describe a capability that is not in your release, not enabled in your configuration, or not used by the flows that matter.
QCI-QS1 requires supplier scope to identify products and releases, the actual customer deployment, and who owns configuration, testing, monitoring and remediation (QCI-7.1-01).
Illustrative example: a managed file-transfer provider says its platform "supports post-quantum key exchange." Your tenant runs an older release, and the partner connections you depend on negotiate a classical method. The supplier has a capability; your deployment does not yet have the protection.
Four levels a readiness claim can describe
| Level | Question it answers | What evidence looks like |
|---|---|---|
| Supplier | Does the company have a plan? | Roadmap, policy statement |
| Product and release | Does this release contain the capability? | Release notes, scoped inventory or CBOM, test results for that release |
| Configuration | Is it enabled for you? | Configuration export, settings evidence from your tenant or instance |
| Deployment | Do your critical flows actually use it? | Observed protocol or handshake evidence, customer acceptance records |
Scope and dependencies
- Include cloud, SaaS, managed services, embedded products and material subservice providers (QCI-7.1-01).
- Identify which cryptographic functions the supplier affects: identity and trust, signing, secure communications, key management, long-lived confidentiality, transaction integrity or relevant AI infrastructure (QCI-7.1-01).
- A critical supplier is not excluded because it will not provide evidence (QCI-1.1-02).
Ongoing oversight
Readiness is not a one-time answer. Relationship owners track milestones and material changes at least quarterly (QCI-7.3-01). Attestations are refreshed at least annually and on material cryptographic change (QCI-7.2-03).
How this differs from Pillar 5 and the G70 gate
| Topic | What it is | Where to read more |
|---|---|---|
| Supplier PQC readiness (this page) | The general idea of product- and deployment-level evidence | This page |
| Pillar 5 | A maturity rubric scoring how an organization runs supplier oversight across all critical suppliers, levels 0–5 | Pillar 5 page |
| G70 gate | A pass/fail condition that caps the score at 70 unless every critical supplier has a current, adequate response and authorized attestation | G70 page |
What organizations should do
- List suppliers that materially affect trust, signing, communications, key management or long-lived data.
- For each, record the products, releases and deployment you actually use.
- Record who owns configuration, testing, monitoring and remediation.
- Separate what the supplier offers from what is enabled and what is observed in use.
- Set a quarterly review of milestones and material changes.
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 |
|---|---|---|---|---|---|
| Critical supplier list with scope | All suppliers meeting Clause 7.1 criteria | Vendor-risk lead with Quantum Risk Owner | Reviewed at least quarterly | Check products, releases, deployment and ownership are recorded | QCI requirement (QCI-7.1-01) |
| Supplier and product records in the QASI | Each critical system's supplier dependencies | System owner | Per validation cycle | Check linked supplier/product records exist | QCI requirement (QCI-5.2-01) |
| Deployment evidence from your environment | Critical flows using the supplier | Engineering owner | Within the evidence age limit | Compare observed use with supplier claim | Editorial suggestion |
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 which suppliers are in scope and requires their scope to be recorded at product, release and deployment level. Pillar 5 scores the oversight; G70 caps the score when evidence is missing.
| Requirement | Clause | Relationship | Pillar | Gate |
|---|---|---|---|---|
| QCI-7.1-01 | 7.1 | explicit requirement | P5 | — |
| QCI-1.1-02 | 1.1 | explicit requirement | — | — |
| QCI-7.3-01 | 7.3 | explicit requirement | P5 | — |
| QCI-6.10-01 | 6.10 | supporting evidence | P5 | — |
Common mistakes
- Rating a supplier as "ready" from a company-wide press statement.
- Leaving out subservice providers that hold keys or terminate connections.
- Treating the supplier's capability as your deployed protection.
- Excluding a critical supplier because it will not answer.
Questions for the board
- Which critical suppliers have product- and deployment-specific evidence, and which only have a general statement?
- Who owns configuration and testing for each critical supplier's product?
Questions
Is supplier readiness the same as the supplier's roadmap?
No. A roadmap describes future plans. Readiness evidence also shows what is present in your release and what your deployment uses. QCI-QS1 states a roadmap shall not be represented as deployed protection (QCI-7.1-02).
Do cloud and SaaS providers count?
Yes, where they materially affect trust, signing, communications, key management, long-lived confidentiality, transaction integrity or relevant AI infrastructure (QCI-7.1-01).
What if a supplier refuses to share evidence?
Record the gap as a limitation and handle it through the exception and escalation process. The supplier stays in scope (QCI-1.1-02, QCI-7.2-04).
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 1.1. Supports: Scope and criticality.
- 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.
- QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 6.3. Supports: G70 supplier gate pass condition.
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.). What is supplier PQC readiness?. https://quantumcoreinstitute.com/learn/suppliers/supplier-pqc-readiness
Link: https://quantumcoreinstitute.com/learn/suppliers/supplier-pqc-readiness