Assessing third-party and vendor post-quantum readiness
Most of your cryptographic risk lives in software you did not write. How to fold PQC readiness into vendor risk management — the questions to ask, the contract language to add, and how to prioritize.
Your migration is only as fast as your vendors
A large share of your cryptography is embedded in third-party products, SaaS, and libraries you cannot change directly. You can only migrate them by making PQC readiness a procurement requirement: ask every critical vendor for a roadmap, bake it into contracts and renewals, and prioritize the vendors that handle your long-lived or externally-facing data.
You can migrate your own code on your own schedule. You cannot migrate your vendors' — you can only pressure, prioritize, and plan around them. Since most organizations' cryptography lives substantially in purchased software and services, third-party readiness is not a footnote to the program; it is a large fraction of it.
Fold PQC into existing vendor risk management
Do not build a parallel process. Add post-quantum readiness as a dimension of the vendor risk assessment you already run at onboarding and renewal. That way it inherits your existing cadence, ownership, and leverage points rather than becoming an orphan questionnaire nobody enforces.
The questions to ask every critical vendor
- Do you have a published post-quantum cryptography roadmap, with target dates?
- Which of your products use quantum-vulnerable public-key cryptography (RSA, ECDH, ECDSA) today, and where?
- Do you support, or plan to support, the NIST standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) — and hybrid key exchange?
- Is your product crypto-agile — can algorithms be updated without us re-integrating?
- How will you notify us of cryptographic changes, and what is the upgrade path?
- Do your own subprocessors and supply chain have PQC plans?
Ask for evidence, not assurances
"We take security seriously" is not a roadmap. Ask for the actual document, the actual target dates, and the actual list of affected products. A vendor that cannot produce these has not started, and that is itself a risk finding you should record and track.
Contract and procurement language
- **Roadmap disclosure** — require vendors to maintain and share a PQC migration roadmap.
- **Standards commitment** — commit the vendor to support NIST-standardized PQC within a defined window for products handling your sensitive data.
- **Crypto-agility** — prefer products that can update algorithms without a re-integration project on your side.
- **Notification** — require advance notice of cryptographic changes and end-of-support for vulnerable algorithms.
- **Right to audit / attest** — the ability to request evidence of readiness.
Prioritize the vendors that matter most
You cannot chase every supplier at once. Rank vendors by the same lens you use internally: which handle data with a long confidentiality shelf life, which terminate your externally-facing encryption, and which are hardest to replace. A vendor that stores decades-sensitive data over connections it controls is a top-tier concern; a vendor that never touches sensitive data is not.
Do not let 'the vendor will handle it' become a blind spot
Assuming vendors will quietly take care of PQC is how organizations discover, too late, that a critical supplier had no plan. Trust is not a control. Track each critical vendor's readiness as a metric, escalate the laggards, and have a contingency for the ones that will not move — including replacement.