A vendor saying that its platform is quantum-ready has not yet made a testable promise. The buyer needs to know which cryptographic operations exist, which NIST-standardized algorithms and protocol profiles will be supported, which product versions and regions are covered, how customers enable them, what remains quantum-vulnerable, and what happens to unsupported deployments. Cloud and software contracts matter because suppliers often control libraries, certificate services, hardware, network endpoints, update channels, and data copies that customers cannot migrate independently.
The joint CISA, NSA, and NIST quantum-readiness guidance tells organizations to discuss vendor roadmaps and plan changes to new and existing contracts. Procurement should turn that recommendation into evidence, dates, test rights, and remedies. The goal is not to force an immature universal deadline; it is to prevent a supplier dependency from remaining invisible until the buyer's own migration window closes.
Scope the purchased cryptographic dependency
Map the product to business services, data journeys, identities, interfaces, deployment models, and required confidentiality or authenticity lifetimes. Identify whether the supplier controls transport security, storage encryption, key management, code signing, update verification, identity federation, certificates, backups, tenant exports, or embedded devices. Ask about all editions, regions, managed and self-hosted variants, agents, mobile clients, APIs, command-line tools, connectors, and disaster-recovery paths. A roadmap for the vendor's newest hosted service does not cover an older appliance that protects the buyer's most durable records.
Write requirements as evidence questions
Require a machine-readable or structured cryptographic inventory that identifies operations, algorithms, parameters, protocols, certificates, libraries, hardware dependencies, data formats, and product versions without exposing secret key material. Ask which observations are measured, inferred, or supplier-declared and how often the inventory changes. The NIST NCCoE migration program treats cryptographic visibility and interoperability as separate workstreams; a good questionnaire does the same. Inventory proves scope, while test results prove that a replacement works.
| Topic | Question | Acceptable evidence | Weak answer |
|---|---|---|---|
| Inventory | Where is public-key cryptography used in this product? | Versioned CBOM linked to operations | We use industry-standard encryption |
| Standards | Which final standard and protocol profile is implemented? | Algorithm, parameters, profile, module | PQC compatible |
| Roadmap | What ships when, for which editions and regions? | Dated release plan with dependencies | On our roadmap |
| Enablement | Can the customer select, observe, and disable algorithms? | Configuration and telemetry samples | Automatic and transparent |
| Interoperability | What peers, limits, and middleboxes were tested? | Compatibility matrix and failures | Passed internal testing |
| Legacy retirement | When and how is vulnerable use removed? | Deprecation policy and end date | Supported as needed |
Contract the roadmap and change process
Attach the roadmap to a maintained schedule with product identifiers, milestones, assumptions, customer prerequisites, and a notice process. Milestones should distinguish development, preview, customer testing, general availability, default enablement, and legacy disablement. Tie dates to authoritative standards or profiles where appropriate, using the NIST post-quantum project as the source of algorithm status rather than freezing informal names. Require notice when cryptanalysis, implementation defects, standards changes, or ecosystem constraints materially alter the plan. Define governance for mutually agreed revisions instead of allowing silent postponement.
Secure test and acceptance rights
Buyers need a non-production endpoint, representative client or appliance, configuration access, protocol traces, performance limits, and support for interoperability tests. Acceptance should cover successful target-only operation, rejection of prohibited legacy paths, mixed-version behavior, key and certificate lifecycle, failover, rollback, monitoring, and historical data or signature compatibility. Include payload, latency, memory, and throughput constraints relevant to the deployment. When independent testing is restricted for legitimate security reasons, require an agreed assessor or evidence package and a process for reproducing material failures.
| Stage | Supplier duty | Buyer right | Remedy or decision |
|---|---|---|---|
| Pre-release | Maintain roadmap and dependency disclosure | Quarterly evidence review | Escalate blocked critical path |
| Preview | Provide representative test environment | Run buyer workloads and negative tests | Reject unmet acceptance criteria |
| Production | Meet availability and security baseline | Observe selected crypto and configuration | Service credit plus remediation |
| Material defect | Notify, contain, patch, preserve evidence | Incident details and retest | Emergency mitigation or suspension |
| Deprecation | Give notice and supported migration path | Export, dual-run, and verify | Extended support or funded migration |
| Exit | Return data and portable evidence | Validate deletion and historical access | Assistance at pre-agreed terms |
Allocate incident and supply-chain duties
Define notification for compromise or material weakness in algorithms, implementations, random generation, keys, certificates, signing infrastructure, cryptographic modules, and critical dependencies. The supplier should identify affected versions, operations, tenants, and time periods; provide mitigations; preserve relevant evidence; and update the inventory. Require flow-down to subcontractors that control cryptographic functions. A generic security incident clause may not require notice of a cryptographic defect before confirmed exploitation, yet that information can be necessary for a buyer to stop collecting vulnerable ciphertext or distributing untrustworthy signatures.
Negotiate upgrade cost, support, and exit
State whether PQC capability is a security update, included feature, new edition, hardware replacement, or professional service. Allocate costs for certificates, bandwidth, HSM capacity, client upgrades, data conversion, validation, and extended support. Prevent forced migration to a materially different commercial bundle merely to obtain necessary security. Define support horizons for legacy platforms and an exit path when the supplier cannot meet the buyer's risk deadline: portable data, keys where appropriate, configuration, CBOM, verification tools, audit evidence, and transition assistance. The 2026 NIST crypto-agility guidance reinforces that replaceability must preserve operations; contractual exit is part of that capability.
Evaluate the vendor response with gates
Make inventory completeness, standards specificity, critical-version coverage, target-only testing, legacy retirement, incident notice, and exit feasibility mandatory gates rather than weighted conveniences. Score roadmap confidence from shipped evidence, named ownership, dependencies, customer prerequisites, dated milestones, and performance on comparable transitions. Score assurance from design records, validated modules where required, review, secure development, vulnerability handling, telemetry, and reproducible negative tests. Score interoperability against the buyer's clients, proxies, regions, hardware, failover, payloads, and counterparties. Score operations from configuration, lifecycle automation, capacity, support, emergency change, rollback, and visibility of prohibited fallback.
Commercial scoring should include included upgrade rights, replacement hardware, professional services, certificate and bandwidth cost, support horizon, notice, data conversion, remedies, and portable evidence. Keep qualifications beside each score. A high total cannot cure an answer limited to a future edition when a critical appliance is excluded. Conditional acceptance needs an owner, date, compensating restriction, and deployment stop if the supplier misses the dependency milestone. Re-run gates at renewal and after acquisition, architecture change, cryptographic incident, roadmap slip, standard revision, or major release. Preserve rejected evidence and failed tests so a future reviewer understands why an attractive claim did not satisfy the requirement.
- Ask whether customer-managed keys change the answer; the supplier may still control protocol libraries, certificate profiles, metadata, backups, signing, or key-wrapping paths.
- Require disclosure of unsupported clients and end-of-support products early enough to budget replacement rather than discovering them during target-only testing.
- Specify which party obtains new certificates, updates trust stores, rotates credentials, validates modules, manages dual operation, and proves final legacy disablement.
- Make telemetry contractually usable: customers need selected protocol and algorithm, configuration state, failures, and fallback evidence without access to other tenants or supplier secrets.
- Address acquisitions and subcontractor changes because cryptographic roadmap ownership, hardware supply, signing infrastructure, and support capability can move after contract signature.
- Link remedies to consequence: missed documentation may require correction, while a missed critical migration gate may justify deployment restriction, extended support, funded transition, or termination.
- Require retained historical verification tools or services when signed records and artifacts must outlive the supplier's active product support.
For renewals, compare the supplier's current evidence with the baseline promised at signature. Identify roadmap dates moved, product lines excluded, profiles changed, interoperability gaps discovered, and customer prerequisites added. Require an updated risk treatment where the buyer's data lifetime or migration deadline now precedes supplier delivery. Procurement, architecture, security, legal, and the service owner should approve the decision together. A renewal that checks only price and availability can unintentionally reset leverage just as the cryptographic transition becomes operationally urgent.
PQC vendor contract takeaways
- Scope every edition, interface, region, client, appliance, and recovery path the buyer actually uses.
- Require a versioned cryptographic inventory plus separate interoperability and performance evidence.
- Contract roadmap milestones from preview through default enablement and legacy retirement.
- Reserve target-only, downgrade, mixed-version, lifecycle, failover, and historical-compatibility tests.
- Make cryptographic defects and critical dependency changes explicit notification events.
- Set upgrade economics, support horizons, portable exit evidence, and remedies before urgency removes leverage.
PQC vendor questionnaire FAQ
Should a contract mandate one algorithm forever? No. Reference approved standards and controlled profiles while preserving a change process. Permanent algorithm lock-in defeats crypto agility.
Is a roadmap legally binding? It can be made a maintained contractual schedule with milestones, notice duties, acceptance gates, and remedies. A public marketing page alone usually lacks that precision.
What if the vendor cannot disclose implementation details? Use scoped confidential disclosure, independent assessment, structured CBOM fields, and observable acceptance tests. Security sensitivity does not justify a wholly untestable claim.
Conclusion
Quantum-safe procurement is dependency management expressed in enforceable terms. Ask where cryptography lives, demand standards-specific evidence, test real integrations, govern roadmap change, and preserve an exit when support misses the data's risk window. Those controls let suppliers adapt as standards mature without leaving buyers dependent on promises they cannot verify.