Most organisations will not complete post-quantum transition alone.
They will depend on:
- Vendors.
- Cloud providers.
- SaaS platforms.
- Identity providers.
- Payment providers.
- Software suppliers.
- Managed service providers.
- Cybersecurity vendors.
- Certificate authorities.
- Hardware and firmware suppliers.
- Legacy product owners.
That makes vendor readiness one of the most important parts of PQC planning.
It also creates a dangerous assumption: “Our vendors will handle it.”
- Some will, but some won’t.
- Some will handle their side, but still require customer action.
- Some will support new standards only in newer versions.
- Some will provide a roadmap but no deployment evidence.
- Some legacy products may never transition cleanly.
That is why organisations need to ask better questions now.
Vendor Preparedness is Never Optional.
NIST finalised its first three post-quantum cryptography standards in August 2024: FIPS 203 for ML-KEM key establishment, FIPS 204 for ML-DSA digital signatures and FIPS 205 for SLH-DSA digital signatures.
This does not mean every product, platform or vendor service is automatically ready.
The real work is transition: understanding where cryptography is used, which systems and suppliers are affected, what customer-side changes will be required and what evidence can be provided.
ASD’s vendor-readiness guidance notes that supplier readiness may be one of the biggest factors influencing whether organisations can transition to PQC within recommended timeframes.
For leadership executives, this becomes a procurement, governance and business-continuity issue — not only a cryptography issue.
The Wrong Question for Vendors
A weak question is: “Are you quantum-safe?”
This is because the question is too broad.
A stronger question is: “For the products and services we use, which cryptographic dependencies have you identified, what is your PQC roadmap, what customer action will be required, and what evidence can you provide?”
This question is more complex, providing specific answers from vendors.
The following questions are an example of strong and weak questions:
Question 1: Do you have a published PQC roadmap for the products or services we use?
A vendor may have a general PQC strategy, but that does not mean your specific product, module, deployment model or service tier is covered.
Strong Answer: “Yes. We have a PQC roadmap for the specific product modules you use. It identifies affected cryptographic functions, expected release stages, customer responsibilities, testing guidance and target availability dates. We can provide a customer-facing roadmap summary under the NDA.”
Why it is strong: This answer is specific, product-level and evidence-backed. It tells you the vendor has moved beyond general awareness and can explain what applies to your organisation.
Weak answer: “We are monitoring post-quantum developments and will update customers when needed.”
Why this is weak: This may sound responsible, but it does not confirm assessment, timelines, customer impact, support arrangements or evidence. It leaves your organisation waiting.
Question 2: Which parts of your product or service rely on traditional asymmetric cryptography?
PQC transition affects more than “encryption”. It may involve TLS, certificates, digital signatures, key exchange, authentication flows, APIs, code-signing, software updates and identity integrations.
Good answer: “The service uses RSA and ECDSA certificates for TLS, ECDH for key exchange in some integrations, signed tokens for identity federation, and RSA-based code-signing for desktop agents. We are mapping these dependencies to our PQC migration plan.”
Why this is good: This answer identifies actual cryptographic functions and where they appear. It allows your team to understand transition impact, affected workflows and testing requirements.
Weak answer: “Our platform uses strong encryption.”
Why this is weak: “Strong encryption” is not an inventory. It does not tell you which algorithms, protocols, certificates, signatures or customer-facing dependencies may require change.
From here, The Questions become Practical.
Once a vendor can answer those first two questions, your organisation can go deeper.
The next questions should cover:
- which responsibilities belong to the vendor and which belong to the customer;
- whether agents, SDKs, APIs, certificates, integrations, firmware or applications need updates;
- when customer testing and production support will be available;
- how transitional or hybrid approaches will be handled;
- what evidence the vendor can provide;
- whether old products, versions or hardware models will be unsupported;
- whether PQC changes affect performance, availability or interoperability;
- how future updates and responsibilities will be communicated.
That is where vendor readiness becomes operationally useful.
Our PQC-Readiness Checklist
It includes 10 vendor questions with:
- why each question matters;
- an example of a good answer;
- why that answer is useful;
- an example of a weak answer;
- what the weak answer fails to prove.
The checklist is designed for CIOs, CISOs, risk leaders, procurement teams, vendor managers, technical stakeholders and boards who need a clear way to assess supplier readiness.
You should use it when speaking with:
- cloud providers;
- SaaS platforms;
- identity providers;
- payment providers;
- software vendors;
- managed service providers;
- cybersecurity providers;
- certificate authorities;
- hardware and firmware suppliers;
- legacy system vendors.
The Practical Conclusion
Vendor readiness will shape post-quantum transition, but your organisation cannot rely on vendor reassurance alone.
You need specific answers, mapped dependencies, customer responsibilities, timelines, testing guidance and evidence.
The goal is not to pressure suppliers unfairly. It is to avoid being surprised later.
