Most companies will not migrate every cryptographic component alone. Cloud platforms, CDNs, identity providers, HSM vendors, VPN suppliers, signing services and software libraries all shape the path to post-quantum cryptography. The difficult part is not asking whether a supplier is “quantum ready”. It is asking for evidence that can be attached to a system, a date and an owner.
NIST's Migration to Post-Quantum Cryptography project separates the work into two useful themes: cryptographic visibility and risk management, plus interoperability and benchmarking. That is a helpful lens for supplier conversations. You need to know where a provider's cryptography is used, and you need to know what a proposed change does to compatibility, performance and operations.
A roadmap slide is not the same as a tested migration path. Supplier evidence should let your team answer a more practical question: if this provider changes a public-key algorithm or protocol, what must we change, test, monitor and approve inside our own environment?
Ask about the boundary first.
Start each supplier review with a named service and a named data flow. Avoid broad questions such as “Do you support PQC?” They invite a marketing answer. Ask which product, region, endpoint, protocol, certificate path, library or hardware boundary is covered, and which parts remain outside the claim.
Turn answers into a supplier evidence pack.
Store the response beside the asset in your cryptographic inventory. The record does not need private keys or sensitive configuration. It needs enough context for an engineer, security owner and procurement lead to read the same facts and see the same limitation.
A FOUR-PART SUPPLIER PACK
- Current state. Capture the service, protocol, algorithms, versions, certificate path and dependency owner.
- Future state. Record the named post-quantum standards, delivery channel, target date and client prerequisites.
- Test evidence. Ask for a reproducible test condition, observed result, compatibility limits and rollback route.
- Decision record. Assign the next action, risk acceptance, procurement question and review date.
Separate support from proof.
A supplier may offer a useful roadmap without offering a guarantee. Treat “planned”, “available in preview”, “available for selected regions” and “negotiated in production” as different states. Also separate a hybrid handshake result from a claim that every certificate, client, private service and stored dataset is protected. The evidence should say exactly what was tested and what was not.
BEFORE YOU ACCEPT A SUPPLIER CLAIM
- Does the answer name the exact product, boundary, version and region?
- Does it distinguish a roadmap from a capability your team can test today?
- Have you asked for compatibility, performance, monitoring and rollback evidence?
- Is the data lifetime or signing requirement connected to the migration priority?
- Does someone on both sides own the next review and the evidence refresh?
NIST's guidance makes the same practical point: organizations need visibility into the cryptography used by their systems, applications and services before they can prioritize migration. Use the NIST migration FAQ as a reference for the questions, then attach the answers to one real boundary. The Q-Ready Check can provide a public-signal starting point; supplier evidence explains what happens beyond that edge.
WATCH · NIST
Why the migration deserves a plan.
This short NIST explainer introduces post-quantum cryptography, the risks around future quantum attacks and why standards-based preparation belongs on today’s roadmap.
Watch the NIST videoRESEARCH NOTE
Use evidence as the hand-off.
The strongest pilot record connects an observed asset to its owner, risk, test result and next action. That is how technical discovery becomes a decision leaders can fund and teams can repeat.
Read the NIST NCCoE FAQ