Ask each vendor which public-key algorithms they use, which NIST standards they plan to adopt, by when, and how they will tell you. Treat a dated, specific answer as useful and a vague claim of being quantum safe as a prompt for follow-up questions.
Why ask
Much of your cryptography is not yours. Hosted services, appliances, SaaS and libraries decide your key exchange and signatures. NIST's PQC page says organizations should begin migrating now, and the NIST FIPS 203, 204 and 205 standards are final, so vendors have something concrete to answer against.
The eight questions
- Which public-key algorithms and key sizes do you use today for TLS, signing and key management?
- Which of the NIST standards (ML-KEM in FIPS 203, ML-DSA in FIPS 204, SLH-DSA in FIPS 205) do you plan to support?
- Do you support hybrid key exchange for TLS today? Which groups?
- What is your dated roadmap, and where is it published?
- How will changes reach us: automatic, opt in, or a paid change? Will anything break for our integrations?
- Which components depend on third parties or hardware you cannot change quickly?
- How do you inventory your own cryptography, and how often is it reviewed?
- How will you notify us of a change or a cryptographic vulnerability?
How to read the answers
Good answers name algorithms, versions and months. They separate what is shipped from what is planned. They admit what is not covered, such as hardware devices.
Warning signs: the phrase quantum safe with no algorithm named, a claim of certification with no document, or an answer that quietly swaps in a different topic like AES-256. Remember that AES is not what the PQC migration is about.
Check claims before repeating them
If a vendor says an algorithm is validated or certified, ask for the document, the module name and the scope. Do not copy such a claim into your own questionnaire answers without seeing it. Where a standard is still in draft, such as NIST IR 8547 or the HQC standard, ask the vendor whether they are tracking the final text.
Record and follow up
Put the answers in your vendor register with the date asked. Set a review for a year out. Vendors who cannot give any plan by then are a risk item for any data with long confidentiality needs.
Quick check
Should I make post-quantum support a purchase requirement?
For new contracts covering long-lived sensitive data, asking for a dated roadmap is reasonable. Making it a hard gate depends on your risk and your market options.
What if the vendor says they use AES-256 so they are fine?
AES-256 addresses stored data. The open question is public-key exchange and signatures. Ask the question again about those.
Safeguard's compliance and evidence automation can keep vendor answers attached to the controls and reviews that use them, and the free scan at gold.safeguard.sh/scan covers your own dependencies.
Sources
- NIST Post-Quantum Cryptography project page
- NIST announcement of approved PQC standards
- NIST announcement: HQC selected
Last reviewed: 19 October 2026.
