Ask vendors which NIST post-quantum standards they support, in which parts of the product, with what dates, and what evidence they can show. Vague answers like "quantum-safe" are a sign to dig deeper. The questions below fit a security questionnaire or a renewal call.
The ten questions
- Which NIST standards do you implement today: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), or SP 800-208 stateful schemes?
- Where in the product do they apply: data in transit, stored data keys, signing, certificates, firmware?
- Is post-quantum key exchange on by default, optional, or planned? What is the date?
- Do you use a hybrid mode, and can we choose pure post-quantum later? NIST's draft expects hybrids to be typically temporary.
- Which cryptographic libraries do you use and how do you track their versions? Can you provide an SBOM?
- What is your inventory process for quantum-vulnerable algorithms, and how often is it updated?
- How do you handle algorithm agility: can an algorithm change without a major release?
- Are your cryptographic modules validated under FIPS 140 for the algorithms in question? NIST says it will accommodate hybrid key-establishment modes in FIPS 140 validation.
- What is your plan for signing keys and certificates that have long lifetimes?
- How will you tell us about changes, and how will customers test them?
How to read the answers
Good signs: named standards, named product areas, dates, test environments, and an owner.
Warning signs:
- "Quantum-safe" with no algorithm named.
- Claims of compliance with a draft document.
- Using the word certified for something that is only a standard.
- Only AES-256 cited as the answer. NIST says AES can continue to be used at 128, 192 or 256 bits, so the real questions are key exchange and signatures.
- No view on data lifetime.
Match depth to risk
Not every vendor deserves ten questions. Ask in full of those that hold long-lived sensitive data or sign your software. For low-risk tools, questions 1, 3 and 10 are enough.
Put it in the contract
Where the vendor handles long-lived data, request a commitment to notify you of algorithm changes and to support a documented migration. Avoid contract language that names a draft or a candidate algorithm.
Track the answers
Keep a simple table: vendor, data class, answer date, promised date, follow-up date. Revisit when the promised date passes.
Send the same list to every vendor in a category so answers compare cleanly. Give a response date and name a contact on your side. Vendors that answer clearly and quickly are usually the ones with a plan, and a slow or evasive reply tells you something too.
Quick check
Is a vendor saying quantum-safe enough?
No. Ask which algorithms, where in the product, since when, and whether it is on by default.
Should we ask for a post-quantum certification?
Be careful with the word. The NIST items are standards, and validation is a separate FIPS 140 process. Ask what exactly is validated.
Sources
Last reviewed: 19 October 2026.
