Marin Ivezic
NIST finalised its first three post-quantum cryptography standards on August 13, 2024. Since then, most enterprise vendors have converged on roughly the same paragraph for customers who ask about them. The vendor monitors developments at NIST. The vendor takes cryptographic security seriously. The vendor is committed to supporting industry standards as they mature.
That paragraph isn’t dishonest. It also isn’t information. It says nothing about which algorithms run inside the product you already bought, nothing about whether anyone on the engineering side has checked, and nothing about what will ship or when. Post-quantum cryptography, or PQC, means the family of algorithms designed to resist attack by a large quantum computer, and the paragraph above is compatible with a vendor that has replaced every one of its key exchanges and with a vendor that has replaced none of them.
Governance teams respond to this by building a questionnaire. The questionnaire usually asks the same question at greater length, spread across twenty rows, and twenty versions of the same paragraph come back. Nobody has been evasive. Nobody has learned anything either.
The problem is upstream of the vendor. It’s in the questions.
Question Shape Determines Answer Shape
Vendor security questionnaires went through exactly this once already. The early ones asked whether a supplier had an information security policy, whether access to production was controlled, whether customer data was encrypted at rest. Every supplier answered yes, and every supplier was telling the truth at some level of generality. Those questionnaires became useful when they stopped asking about posture and started asking for artifacts: the SOC 2 Type II report with its observation window, the penetration test summary with its date, the name of the control owner. The question changed from what the vendor believes about itself into what the vendor can produce on request.
Post-quantum questions are still at the earlier stage. Most of the sets in circulation ask about intent. Do you have a plan. Are you aware of the risk. Are you committed to the standards. Intent questions have one correct answer, every vendor knows it, and answering correctly costs nothing.
One test separates a question worth asking from a question that will waste both parties’ time. A vendor that has done the work and a vendor that has done nothing must not be able to answer it the same way. Everything below is an application of that single test.
Four Question Shapes That Hold Up
Ask for the inventory, not the intention
Weak: Does your product use cryptography that is vulnerable to quantum attack?
Every product does. Answering yes is free and tells you nothing about scope.
Stronger: For the version of the product we are licensed to run, list every cryptographic algorithm and key length used for data in transit, data at rest, code signing, and administrator authentication. Name the library or module that implements each one.
This is a request for a cryptographic bill of materials, usually shortened to CBOM. The idea borrows directly from the software bill of materials, or SBOM, that many procurement teams already request: an SBOM lists the components in a build, and a CBOM lists the cryptographic assets, meaning the algorithms, key lengths, certificates and the places they are used. The CycloneDX specification added cryptographic asset support in version 1.6, which is what turned a CBOM into something a vendor can generate from a build pipeline rather than assemble by hand in a spreadsheet.
The request tests whether such a document exists at all. A vendor that can send a partial CBOM in two weeks has run a discovery exercise, and a vendor that promises one and goes quiet has not. Record that silence as the finding rather than chasing the document for a quarter.
Ask for a document with a revision date
Weak: Do you have a post-quantum migration roadmap?
Stronger: Name the internal document that contains your post-quantum migration plan and give its current revision date. State which product release will first offer an ML-KEM key exchange, and whether that release is in the published roadmap or still under discussion.
ML-KEM (formerly CRYSTALS-Kyber) is the key-encapsulation mechanism standardised as FIPS 203, and it’s the algorithm most vendors will adopt first because it protects session keys during negotiation. Naming it in the question does two useful things. It shows you know what a first step looks like, and it stops the answer drifting into general commitments.
The release number is the part that carries weight. A vendor who says “2027” has a slide. A vendor who says “the 9.2 release, currently scheduled for the second half of next year, behind a configuration flag” has an engineering plan with someone’s name attached to it.
Ask what evidence would exist
Crypto-agility means the ability to replace one cryptographic algorithm with another through configuration or a routine update, rather than through a redesign of the product. It is the property everyone wants and the word everyone claims.
Weak: Is your product crypto-agile?
Stronger: Describe the last occasion on which you changed a cryptographic algorithm or key length in this product in production. What was the change, which release carried it, how much notice did customers receive, and what did customers have to do?
Past tense defeats aspiration. A vendor that deprecated SHA-1 in a point release with six months of notice and a migration script has demonstrated agility. A vendor that has never changed an algorithm since the product shipped in 2013 may still be agile, but nobody knows, including them.
Pair it with a question about validation: If the cryptographic module in this product has been validated under FIPS 140-3, give the certificate number. FIPS 140-3 is the US and Canadian standard for cryptographic modules, and the Cryptographic Module Validation Program tests modules against it and publishes the results. The certificate either exists or it doesn’t, which is precisely why it belongs in a questionnaire. This isn’t a requirement, and plenty of good products carry no validation. You’re establishing what independent evidence is available, so that you know in advance which claims you’ll be taking on trust.
Ask about their suppliers
Weak: Do you assess your third parties for quantum risk?
Stronger: Which cryptographic library does the product use for TLS, at which version, and who inside your organisation decides when that library is upgraded?
A vendor whose transport security comes from a widely used open-source library has inherited that project’s release schedule and can move roughly when the project moves. A vendor with a bespoke implementation written a decade ago by someone who has since left is carrying a different kind of risk, and the answer to “who decides when it is upgraded” will tend to be vague in a way the first answer isn’t.
The same question applies to hardware. If keys are generated or stored in a hardware security module, ask which model and which firmware branch, because the vendor’s post-quantum timeline can’t run ahead of the module’s.
Reading What Comes Back
Sort the responses into three grades rather than scoring them out of five.
Measured. The answer contains algorithms, versions, release numbers or dates that came from somewhere specific. Someone looked. You can act on this, and you can check it later.
Planned. No results yet, but there is a named document, a named owner, and dates that the vendor is willing to put in writing. This is a normal and respectable place for a mid-sized supplier to be right now.
Asserted. Adjectives. Commitment, awareness, alignment, monitoring. Treat an asserted answer as equivalent to no answer, and say so plainly in the assessment record, because a risk register entry that reads “vendor confirmed commitment” will be read by someone next year as coverage.
One signal sits outside the grading. Watch who replies. If the response arrives from the account manager in the same wording as the marketing page, the question never reached engineering. If a solutions architect forwards two paragraphs from an internal wiki with a revision date on them, it did. You can encourage the second outcome by saying in the covering note that the questions are technical and that a written answer from an engineer is preferred over a call.
And give credit for candour. “We haven’t inventoried this product yet, the work starts in Q3, and the owner is our head of platform security” is a better answer than a confident non-answer, and vendors will only give it if the first honest response doesn’t cost them the renewal.
Scale the Effort to What Actually Breaks
Twelve detailed questions across four hundred suppliers is not a programme, it’s a mailing. Sort first, then ask.
Vendors whose function is cryptography. Hardware security modules, PKI and certificate management, VPN and remote access, code signing, secrets management. These get the full set, and the technical team joins the call. Their readiness sets the ceiling on yours, because you can’t deploy an algorithm your key infrastructure can’t hold.
Vendors holding data with a long confidentiality life. This is where harvest now, decrypt later applies: an attacker copies encrypted traffic or archives today and stores them until a quantum computer capable of breaking the key exists. The relevant question isn’t how sensitive the data is today, but how long it stays sensitive. Health records, sealed legal material, long-term contracts and identity data all outlive most encryption assumptions. These vendors get the inventory question and the dependency question.
Everything else. Two questions. Does a post-quantum migration plan exist, and when was it last revised. Log the answer and move on. Coming back in eighteen months costs almost nothing once the question is in the standard pack.
Put the Questions Where They Have Force
The same four shapes belong in three places, with different consequences attached.
In an RFP, they are scored. Bidders learn quickly that a paragraph about monitoring NIST earns fewer points than a release number, and the scoring rubric does more to change vendor behaviour than any amount of correspondence after signature.
At onboarding, the answers become a baseline. Store them with dates. A CBOM received in March of this year is a document you can hold up against the same request next March, and the delta is the whole assessment.
At renewal, they have the only bargaining power that consistently works. Renewal is the moment when a supplier’s incentive to give you a real answer is highest, which is exactly why the questions should go out before the commercial conversation rather than alongside it.
Contract language sits on top of this, and it works best when it references the answers rather than restating them: the plan the vendor named, at the revision they gave, with an obligation to notify on material change. A clause that requires generic quantum-safety is difficult to enforce. A clause that requires the vendor to maintain the specific document they already named is not.
The Skill Underneath the Questionnaire
None of this is procurement technique in isolation. Recognising that a vendor’s answer describes signature migration when the risk in that product is key exchange, or that a stated 2030 date can’t be met because the underlying hardware module has no post-quantum firmware branch, takes working knowledge of what the migration actually involves. Regulatory timelines are converging. NIST’s draft IR 8547 sets out transition guidance without fixing hard deprecation dates, NSA’s CNSA 2.0 gives dates for US national security systems, and the UK NCSC has published a migration timeline with checkpoints in 2028, 2031 and 2035. Suppliers will be asked these questions by everyone. The organisations that get useful answers will be the ones asking precisely.
For the methodology behind sequencing a migration across an estate, see pqcframework.org. For a longer treatment of the vendor engagement problem, including contract structure, there’s detailed coverage on PostQuantum.com.
Quantum Academy trains governance, risk and procurement teams to read cryptographic answers rather than collect them, alongside the technical certifications for the architects and engineers who will do the migration itself. Current programs and enrollment details are at quantumacademy.com/.