Choosing a post-quantum cryptography vendor in 2026 is no longer a capability-matrix exercise. Migration roadmaps tell you what to do. Vendor slides tell you what is supported. Neither tells you how to tell the difference between a supplier who has done the engineering and one who has done the marketing.
PQ-VES 1.0 is a vendor-neutral evaluation standard for that gap. It is written for procurement leads, CISOs, architects and technical assessors buying discovery tooling, cryptographic libraries, HSMs, PKI platforms, encryptors, signing infrastructure or migration services. This page is the method in brief. The scorecard, question bank and PDF are the documents you actually run.
Why 2026 selection is different
Three shifts have made older evaluation habits unsafe.
The mandates became binding. Canada's Treasury Board now requires PQC procurement clauses in Government of Canada digital contracts from 1 April 2026. The United States issued Executive Order 14412 in June 2026, with OMB M-26-15 following two days later. Australia's Protective Security Policy Framework Release 2026 makes a maintained PQC transition plan a requirement for Commonwealth non-corporate entities. A supplier who cannot evidence conformance becomes your audit finding.
The failure modes became public. KyberSlash and CVE-2024-37880 were not algorithm failures. They were implementation failures in code that vendors could accurately describe as standards-conformant. Standards conformance and implementation assurance are separate questions, and they must be scored separately.
The assurance infrastructure did not keep pace. The CMVP modules-in-process list stood at 217 in August 2026. "In the validation queue" is legitimate information. It is not validation. A framework that treats FIPS as a binary pass or fail will either exclude good vendors or accept bad claims.
How to run the evaluation
Work the stages in order. The most common failure in PQC procurement is scoring vendors against a requirement the buyer has not yet defined.
| Stage | What you do | What you should have |
|---|---|---|
| 0 | Write the requirement | Risk horizon, jurisdictions, product category, non-negotiables, pilot acceptance criteria |
| 1 | Apply the hard gates | A shortlist, and a documented reason for every exclusion |
| 2 | Score twelve criteria, capped by evidence | A weighted ranking you can defend |
| 3 | Verify the claims that decide the ranking | A verification log |
| 4 | Run a falsifiable pilot | Pass or fail against criteria you wrote before the vendor arrived |
| 5 | Contract for agility | Terms that survive the next algorithm change |
| 6 | Govern after signature | Re-evaluation triggers and an exit path |
Do not start at the scorecard. Stage 0 changes which vendor wins. If you operate across jurisdictions, map hybrid posture before you see a demonstration: France's ANSSI mandates hybrid; Australia's ASD does not recommend it; CNSA 2.0 does not require it. A product with a single hybrid posture transfers that conflict to you.
Cap every score by evidence
A vendor's claim, their documentation, a live demonstration, an independent test and an accredited certification are five different things. PQ-VES scores capability from one to five, then caps that score at the tier of evidence supplied.
| Tier | What it is | Score cap |
|---|---|---|
| E0 | Unevidenced claim: a slide, a website, a sales assertion | 1 |
| E1 | Documented claim: product docs, a tender response, release notes | 2 |
| E2 | Demonstrated: working demo on your data, a test you observed | 3 |
| E3 | Independently tested: third-party audit, CAVP, inspectable source | 4 |
| E4 | Accredited certification: CMVP FIPS 140-3 or Common Criteria, covering the deployed configuration | 5 |
Worked example: a vendor claims a formally verified, constant-time ML-KEM implementation. On capability that would score 5. If the only evidence is a marketing page, the criterion scores 1. Nothing about the product changed. What changed is what you can defend if the decision is later questioned.
Two rules prevent gaming. Evidence must cover the configuration you will deploy, not a different architecture or a different algorithm. Evidence must be current: a historical CMVP certificate, or a verification two years behind the shipping commit, drops a tier.
Ten hard gates
Hard gates are pass or fail. A vendor who fails any gate is excluded regardless of strength elsewhere. The purpose is to stop a structural defect being compensated for by an impressive score in a category that does not matter.
- Named algorithms and named parameter sets - ML-KEM-768, ML-DSA-65, SLH-DSA-SHA2-128s. "Supports post-quantum cryptography" is a fail. Brand-era names (Kyber, Dilithium, Falcon) in current documentation mean the docs have not been maintained since 2024.
- No proprietary core primitive - proprietary implementations of published standards are acceptable. Proprietary cryptography is not.
- Deployment model satisfies your data governance constraint - tested against what you wrote at Stage 0, not against what is theoretically possible. Periodic connectivity for licensing or telemetry fails a disconnected requirement.
- Algorithm substitution without product replacement - configuration or a signed update. "We would issue a new version" means crypto-agility is a roadmap item.
- Machine-readable cryptographic inventory - CycloneDX 1.6 or later, ideally 1.7, with
cryptoProperties. A PDF is a deliverable, not an inventory. - Known-vulnerability currency - which library, which version, which commit, and confirmation that the KyberSlash fixes and CVE-2024-37880 mitigation are present. Unable to answer within one business day is itself an answer.
- Jurisdictional algorithm policy coverage - including hybrid posture for every jurisdiction on your map.
- Named implementation provenance - in-house, named open source, or licensed, with verification status. "Proprietary implementation" with no further detail is a fail.
- Vulnerability disclosure and cryptographic-weakness commitment - published policy, security contact, remediation target, and a commitment to notify customers of cryptographic weaknesses.
- No substitution of quantum key distribution for PQC - different technology, different problem. Several national authorities will not accept QKD as a PQC answer.
For every exclusion, record the gate, the evidence, the date and the assessor. If the decision is challenged, the gate log is what defends it. The question bank turns each gate into the questions you actually ask.
The twelve criteria
Vendors who pass the gates are scored on four pillars. Default weights suit a general enterprise or critical infrastructure buyer. Defence, civilian government, financial services, OT and commercial profiles reweight them. Use one profile, then adjust once with a documented reason.
| Pillar | Weight | What it decides |
|---|---|---|
| A. Cryptographic assurance | 30% | The right algorithms, at the right parameter sets, implemented so they resist the attacks that have actually broken PQC deployments, with independent validation where it exists |
| B. Architectural fitness | 30% | Crypto-agility, named integrations, and where your keys, inventories and scan results actually live |
| C. Program enablement | 25% | Discovery coverage (including what the tool cannot see), CycloneDX CBOM quality, and control-level audit evidence |
| D. Counterparty risk | 15% | Whether the vendor will still be here across a multi-year migration, how they handle disclosure, and whether the commercial model punishes agility |
Crypto-agility is the single highest-weighted criterion in the default profile, because it is the only one that protects you against being wrong about everything else. Discovery tooling is defined by its blind spots: network analysis cannot see data at rest; agents cannot see appliances that reject them; a questionnaire cannot see what you do not already know. Ask for the coverage statement, including explicit exclusions, and treat a vendor who will not produce one as having failed the question.
Score inside a product category, never across categories. A discovery platform, a cryptographic library and an HSM fail in different ways. The PDF includes category overlays for each.
Four mistakes that decide the outcome early
- Buying the inventory instead of the migration. Producing a cryptographic inventory is now close to a commodity. Prioritisation against your risk model, execution in legacy and operational technology, and re-verification after change are the hard problems.
- Treating algorithm support as the decision. Algorithm support is table stakes. Implementation quality, crypto-agility and integration decide whether the migration succeeds.
- Confusing validation types. CAVP is not CMVP. In process is not validated. A module certificate does not tell you the PQC algorithms sit inside the boundary until you read the security policy.
- Letting the vendor write the acceptance criteria. Write the pilot tests at Stage 0. A criterion a vendor helped you write is not a test.
The other four - accepting source-level claims about binary-level properties, scoping the pilot to the easy estate, ignoring hybrid divergence until after signature, and treating selection as a one-time decision - are in the PDF, with the contract clauses that stop them recurring.
Frequently asked questions
How many post-quantum algorithms are actually standardised?
Three. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), all finalised on 13 August 2024. FIPS 206 (FN-DSA) has not been published, not even as a draft. HQC was selected in March 2025 and has no published standard. A vendor describing either as standardised is either behind or overstating.
What does "FIPS validated" actually tell me?
Less than most buyers assume. FIPS 140-3 validation is module-scoped: a vendor can hold a valid certificate whose approved algorithm list contains no post-quantum algorithm at all. Ask for the certificate number, read the security policy, and confirm that the PQC algorithms sit inside the cryptographic boundary in approved mode. A CAVP algorithm certificate is a weaker and different signal. A modules-in-process listing is not validation.
Is hybrid deployment required?
It depends on your jurisdiction, and the positions are close to opposite. France's ANSSI mandates it. Australia's ASD does not recommend it. The NSA's CNSA 2.0 does not require it. If you operate across these markets, require configurable hybrid posture as a hard gate.
How do I compare a discovery tool against a cryptographic library?
You do not. They solve different problems and fail in different ways. Run separate evaluations per product category and combine the results at the architecture level rather than in a single score.
Is quantum key distribution an alternative to PQC?
No, and treating it as one is a red flag. QKD addresses key distribution over a physical channel with different assumptions and no built-in authentication. The UK's NCSC stated in August 2025 that it will not support QKD for government or military applications and recommends PQC as the mitigation.
Publisher note
Published by ExeQuantum. ExeQuantum is a vendor in the market this standard describes. That is a conflict of interest. The honest response is disclosure plus design. PQ-VES names no products, including ExeQuantum's. It contains no vendor recommendations. Every criterion is written so that it could be applied to ExeQuantum by a buyer, with the same evidence tiers and the same disqualifiers.
PQ-VES 1.0 is released under Creative Commons Attribution 4.0. Fork it, embed it in your tender documents, disagree with a weighting in public. Version 1.0 reflects the regulatory position as at 12 August 2026. Check dated claims before you rely on them in a tender.
Get the evaluation pack if you are going to use it. The scorecard is the ranking. The question bank is the conversation. The PDF is the method you can put in front of an auditor.