Rollout and supply-chain readiness: the crypto you don't control
Much of your quantum-vulnerable cryptography lives in vendor products and services you cannot patch yourself. How to assess supplier readiness, ask the right questions, and manage the rollout.
You can only migrate what you control — the rest you must govern
A large share of your cryptography sits inside SaaS, appliances, and libraries owned by third parties. For those, migration becomes supplier management: ask vendors for their PQC roadmap and CBOM support, write quantum-readiness into contracts and renewals, and track supplier readiness as roadmap dependencies with owners and dates — because a lagging vendor can block an entire wave.
Two realities collide in rollout. First, most estates depend heavily on cryptography they cannot directly change: cloud services, security appliances, payment processors, and third-party libraries. Second, change management for the parts you do control still has to happen without breaking production. Rollout is where the migration meets the rest of the organization and its suppliers.
Assessing vendor readiness
Treat PQC readiness as a procurement and third-party-risk question, not just an engineering one. The questions that actually discriminate a prepared vendor from an unprepared one:
- Do you have a published PQC migration roadmap with dates, aligned to NIST FIPS 203/204/205?
- Which of your products already support hybrid key exchange or PQC signatures, and behind what configuration?
- Can you provide a CBOM or equivalent cryptographic inventory for the components we consume?
- How will you handle certificate and signature size increases in your protocols and appliances?
- What is your plan for algorithm agility, so the next transition does not require a forklift upgrade?
"We support post-quantum" is not an answer
Vague vendor assurances hide the details that determine whether you can actually deploy: which algorithms, in which product versions, enabled by default or behind a flag, interoperable with what. Push for specifics — algorithm names (ML-KEM-768, ML-DSA), version numbers, and configuration steps. A marketing claim of PQC support with no deployable specifics is a risk you are carrying, not one the vendor has retired.
Contracts and procurement leverage
The strongest lever is the renewal and the new purchase. Write quantum-readiness requirements into contracts, RFPs, and SLAs: crypto-agility expectations, a committed PQC timeline, and the right to a cryptographic inventory of what you are buying. New systems especially should be required to be crypto-agile from day one — it is far cheaper to demand agility at purchase than to retrofit it later.
Change management for the parts you own
- **Stage the rollout** — pilot, canary, then broad, with the validation gates from the testing phase at each step.
- **Communicate the fallback** — make sure operators know classical fallback remains during transition and what a rollback trigger looks like.
- **Keep rollback ready** — every wave has a tested rollback path, because a downgrade to the previous (still-classical) state is safer than an outage.
- **Feed exceptions back** — vendor systems that cannot yet migrate become tracked, time-boxed risk acceptances, not silent gaps.
The output of rollout is a moving front: systems you control migrate on your schedule, systems you do not migrate on your suppliers' schedules, and both are tracked in the same roadmap so leadership sees a single, honest picture of readiness — including the parts that are waiting on someone else.