PQC Supplier Due Diligence

Assessing supplier readiness for post-quantum cryptography

Supplier due diligence for post-quantum readiness fails when the questions are general. Asking whether a supplier is quantum safe produces an assurance that cannot be assessed. Asking which algorithms protect specific data, in which product version, enabled by default or not, produces evidence that can be scored.

Why standard security questionnaires do not work here

Existing supplier assurance frameworks were written before post-quantum cryptography was a procurement consideration. They ask whether data is encrypted in transit and at rest to an industry standard, which every supplier can answer affirmatively while using algorithms scheduled for withdrawal.

Three specific gaps recur. The questionnaire does not ask which algorithms are in use, so the answer carries no information about exposure. It does not ask about default behaviour, so a supplier can claim support for a capability that is never negotiated in practice. And it does not ask about subprocessors, so a compliant supplier may depend on parties who are not.

The result is a completed assurance pack that tells the customer nothing about whether the supplier's cryptography will still be sound when the contract ends.

What to ask suppliers, and what a good answer looks like

The distinction running through the table is between evidence and intent. A version number, a validation certificate and a dated milestone are all verifiable. A commitment is not.

How to assess post-quantum cryptography companies as suppliers

Where the supplier is being engaged specifically for post-quantum work, whether as a product vendor or a consultancy, a further set of tests applies.

Ask what the recommendation would be if the answer were to change nothing yet. A supplier whose assessment always concludes with a purchase is selling rather than assessing. Legitimate findings include deferring work on assets with short refresh cycles.

Ask which algorithms and parameter sets are supported, specifically. ML-KEM without ML-DSA does not address authentication. Neither addresses firmware signing, which requires LMS or XMSS under NIST SP 800-208. A vendor unaware of that distinction is unlikely to handle an operational technology estate well.

Ask what happens when the algorithm changes again. Candidate algorithms have been broken during standardisation, Rainbow and SIKE both in 2022, and NIST selected HQC as a backup key encapsulation mechanism precisely because of that risk. A product that hardcodes today's algorithms recreates the problem it was bought to solve.

Ask for evidence of delivery rather than capability. Reference engagements in comparable environments, with comparable constraints, are more informative than a feature matrix.

Finally, apply scrutiny to performance and support claims, which are frequently stated in terms of availability rather than deployed behaviour. This is covered further in why PQC vendor claims need scrutiny.

Red flags in vendor responses

A countdown clock to Q-Day indicates a marketing position rather than an analytical one, since expert opinion on quantum timelines is a wide distribution rather than a date.

Claims of quantum-proof or unbreakable encryption misstate what post-quantum algorithms provide, which is resistance to known quantum attacks under current analysis.

Proprietary algorithms are a serious concern. The NIST algorithms were selected through eight years of public cryptanalysis, and proprietary alternatives have not been subjected to equivalent scrutiny.

Quantum key distribution offered as a replacement for post-quantum cryptography rather than as a complement misrepresents its scope, since it provides no authentication and requires dedicated optical infrastructure

An inability to name a product version containing the support usually indicates that the support is on a roadmap rather than shipped.

Contract terms worth introducing

Leverage exists at renewal, tender and material change, and largely nowhere else. The terms below are the ones that matter, in rough order of value.

Algorithm disclosure, with an obligation to notify on material change, converts an unknown into a monitored dependency. A dated migration commitment for key establishment and signatures, treated separately, addresses timeline dependency. Subprocessor disclosure covering cryptographic position closes the fourth-party gap. Provision of a cryptographic bill of materials, in a defined format at a defined interval, makes the position verifiable rather than asserted. Notice periods for cryptographic change protect integrations from unannounced breakage. Support for customer-managed keys, where the data justifies it, removes inheritance altogether.

Regulatory movement strengthens this position. Executive Order 14412 directed the FAR Council to propose a rule requiring covered contractors to comply with post-quantum FIPS by 31 December 2030, and the Department of War strategy extends requirements across the defence industrial base. Suppliers serving US federal or defence markets are increasingly obliged to answer these questions regardless of who asks.

How to scope the exercise proportionately

Assessing every supplier at this depth is neither achievable nor useful. Three tiers work.

Tier one covers suppliers holding data with long confidentiality requirements, or issuing credentials your systems trust, including identity providers and code signing dependencies. These receive the full question set, contract terms and subprocessor disclosure.

Tier two covers suppliers of platforms that would need to change during migration, where the concern is timeline rather than exposure. These receive the roadmap and version questions only.

Tier three is everything else, which receives the standard assurance process with algorithm disclosure added.

Tier one is usually smaller than expected, which makes the exercise tractable within a normal vendor management cycle.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We identify which supplier relationships carry material cryptographic exposure through our PKI health check and cryptographic bill of materials services, including federation and integration dependencies that vendor management registers rarely capture. We then support procurement and vendor management teams in framing assessable questions, scoring the responses and drafting cryptographic contract terms.

We also sit on the other side of this process. As a consultancy holding partnerships across the HSM, certificate authority and certificate lifecycle landscape rather than reselling a single product, we expect to be assessed on the same criteria set out above, and our PKI consultancy engagements are scoped to produce evidence rather than a purchase recommendation.

‍