The decision you are actually making
By 2026 the question is no longer whether to adopt post-quantum cryptography (PQC). NIST finalized its first three standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — in August 2024, and the US National Security Agency's CNSA 2.0 suite sets a federal migration window running through roughly 2030 to 2033. The procurement question has shifted to: which vendor, at which layer of the stack, with what evidence that the cryptography is implemented correctly.
That shift matters because 'PQC vendor' is not one category. Some companies sell cryptographic IP and embedded libraries. Some sell software overlays that wrap your existing TLS sessions in hybrid post-quantum tunnels. Some sell a full managed platform that operates your keys, secrets, encrypted storage, and audit chain. Cloud providers sell key-management services that are adding PQC. Buying the wrong layer is the most common — and most expensive — mistake in a PQC program.
This guide gives you the criteria to evaluate any PQC vendor, then maps the layers so you can match a vendor to the problem you are actually solving. It is written for the engineer who will integrate the thing and the buyer who will sign for it.
First, get the threat model right
A correct threat model narrows the vendor field faster than any feature checklist. The quantum threat is not uniform across your stack.
Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, breaks the public-key cryptography that underpins key exchange and digital signatures — RSA, Diffie-Hellman / ECDH, and ECDSA. That is the part of your infrastructure that is genuinely at risk. Grover's algorithm, by contrast, gives only a quadratic speedup against symmetric ciphers and hashes. AES-256 retains roughly 128 bits of effective security against a quantum attacker and remains safe; SHA-384 and SHA-512 stay safe; AES-128 drops to about 64-bit effective security, which is marginal and worth phasing out, but bulk symmetric encryption is not where the fire is.
The practical consequence: the quantum threat is primarily to key exchange and signatures, not to bulk AES encryption. A vendor whose pitch implies your AES-256 data-at-rest is about to fall to a quantum computer is either confused or selling fear. The genuinely urgent problem is 'harvest now, decrypt later' (HNDL) — adversaries recording your encrypted traffic and key-exchange handshakes today, to decrypt once a cryptographically-relevant quantum computer (CRQC) exists. Any data with a multi-year confidentiality requirement is exposed to HNDL right now, which is why migration timelines are measured against your data's secrecy lifetime, not against the arrival date of a CRQC.
Criterion 1 — FIPS standards coverage (and honest standardization status)
Start with what is actually standardized. As of mid-2026 the finalized FIPS standards are FIPS 203 (ML-KEM, a key-encapsulation mechanism derived from Kyber), FIPS 204 (ML-DSA, a lattice signature derived from Dilithium), and FIPS 205 (SLH-DSA, a stateless hash-based signature derived from SPHINCS+). FIPS 206, covering FN-DSA (Falcon), remains in draft.
Beyond the finalized set, NIST has continued its process: HQC was selected in March 2025 as a code-based KEM to complement the lattice-based ML-KEM, but it is not yet a finalized FIPS standard. A trustworthy vendor will state this distinction precisely. Be wary of any data sheet that lists HQC, Falcon, or fourth-round candidates as 'FIPS standardized' — they are not, and the imprecision tells you how carefully the rest of the cryptography was treated.
What to require: full, correct support for FIPS 203/204/205 today, a clear roadmap for FN-DSA when FIPS 206 finalizes, and language that never overstates standardization status.
Criterion 2 — Algorithm breadth and crypto-diversity
Lattice-based schemes (ML-KEM, ML-DSA) are the default workhorses, but a mature program wants diversity across mathematical families so a future cryptanalytic break in one family does not strand you. That means code-based KEMs (HQC, BIKE, Classic McEliece), other lattice and structured-lattice options (FrodoKEM, NTRU, NTRU Prime), and a range of signature families (hash-based SLH-DSA, multivariate schemes like MAYO, UOV, SNOVA, and code-based CROSS).
Breadth is not breadth-for-its-own-sake — it is the substrate for crypto-agility. If your platform only ships ML-KEM and ML-DSA, your 'agility' story ends the day one of those needs replacing.
QNSP — the flagship PQC platform from CUI Labs (CUI LABS PTE. LTD., Singapore) — ships 90 PQC algorithms across 14 families: 27 KEMs and 63 signatures, spanning ML-KEM, ML-DSA, SLH-DSA, Falcon/FN-DSA, HQC, BIKE, Classic McEliece, FrodoKEM, NTRU, NTRU Prime, MAYO, CROSS, UOV, and SNOVA. The point of that breadth is to let a policy decision — not a re-platforming project — switch the algorithm in use.
Criterion 3 — Verifiable conformance evidence
This is the criterion most buyers skip and most regret. A PQC implementation that is subtly wrong is worse than a classical one, because it gives a false sense of safety. The defense is independent test vectors. NIST's Automated Cryptographic Validation Protocol (ACVP) publishes official test vectors for the standardized algorithms; running them and publishing the pass/fail counts is the difference between 'we support ML-KEM' and 'here is the evidence our ML-KEM matches NIST's reference behavior.'
Ask any vendor for their ACVP results, and ask whether more than one independent implementation agrees. Dual-provider cross-verification — running the same operation through two independent codebases and comparing — catches implementation bugs that a single library would hide.
QNSP publishes its conformance evidence publicly at /verify/conformance, covering two independent providers: @noble/post-quantum, a pure-JavaScript reference implementation, passing 435/435 across the FIPS 203/204/205 ACVP groups it covers; and @cuilabs/liboqs-native, the native-C primary engine, passing 240/240 across the addressable ML-KEM ACVP surface (the ML-KEM tests reachable through its deterministic key-generation and encapsulation bindings). The evidence is bound to a SHA-3-256 tamper digest and regenerated on every release. Whatever vendor you choose, hold them to this standard: claims should be checkable, not asserted.
Criterion 4 — Crypto-agility and policy enforcement
Standards will evolve; cryptanalysis will advance; your compliance regime will tighten. Crypto-agility is the ability to change the algorithm in use without re-architecting the application. The practical test: can an administrator move a tenant or workload from one algorithm set to a stronger one as a configuration change, with enforcement applied centrally?
Look for an explicit policy model rather than per-application hardcoding. QNSP, for example, exposes crypto-policy tiers — default, strict, maximum, and government — that constrain which KEMs and signatures a tenant may use, enforced at the platform layer rather than left to each integrating team. The government tier, for instance, restricts to FIPS-finalized algorithms only. The mechanism matters more than the specific tier names: you want the allowed-algorithm set to be a governed policy, not a code review.
Criterion 5 — HSM, BYOH, and root-of-trust
For regulated workloads, where the root keys live is a board-level question. Evaluate whether the platform integrates with hardware security modules (HSMs), whether it supports bring-your-own-HSM (BYOH) so you retain custody of your root of trust, and how key material is protected at rest and in use. The highest-assurance tiers in any serious PQC platform should be able to anchor root keys in an HSM.
If your compliance posture requires that the vendor never holds your root key material in software, confirm BYOH support explicitly and in writing — this is frequently a sales-assisted, enterprise-tier capability rather than a self-serve checkbox.
Criterion 6 — Deployment topology
Where the platform can run is often the deciding constraint. Multi-tenant SaaS is fine for many teams; others require single-tenant isolation, VPC deployment, on-premises, or fully air-gapped operation for classified or sovereign environments.
Map your data-residency and sovereignty requirements before any vendor evaluation. A vendor that only offers shared SaaS cannot serve an air-gapped defense program, and a vendor that only ships libraries cannot give you a managed multi-tenant service. Confirm the deployment topology you need is real and supported, not roadmap.
Criterion 7 — Audit trail, compliance, and crypto inventory
PQC adoption is, for most buyers, a compliance event. You will be asked to prove what cryptography you use, where, and that operations on it are logged immutably. Two capabilities matter here.
First, a Cryptographic Bill of Materials (CBOM) — an inventory of every cryptographic asset in your environment. You cannot migrate what you cannot see, and auditors increasingly expect a crypto inventory as a baseline artifact.
Second, an immutable, tamper-evident audit trail over cryptographic operations, mapped to the frameworks you report against — SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and for Singapore-regulated entities, PDPA and the MAS Technology Risk Management guidelines. QNSP is Singapore-headquartered and aligned to PDPA and MAS TRM, with CBOM crypto inventory and an immutable audit chain built in; whatever you choose, require both the inventory and the audit trail as first-class features, not add-on afterthoughts.
Criterion 8 — SDK and integration coverage
A platform you cannot integrate is a platform you will not use. Evaluate the breadth and quality of SDKs against your actual languages, the availability of a CLI for operations, and whether a free tier lets your engineers prototype before procurement.
QNSP ships SDKs in five languages and a free-forever tier (10 GB storage, 50,000 API calls, 20 KMS keys, 25 vault secrets) that lets a team validate the integration end-to-end before any commercial conversation. A meaningful free tier is also a useful honesty signal — it means the product works without a sales engineer in the room.
The layers of the stack — buy the layer you need
These layers are not mutually exclusive. An organization might embed a library vendor's primitives in a hardware product, run an overlay to harden legacy network links, and use a full managed platform to govern key operations and produce audit evidence. The mistake is buying a library when you needed a managed service, or buying an overlay when you needed governed key operations.
- IP and library vendors (e.g. PQShield): post-quantum IP cores and embedded cryptographic libraries such as PQCryptoLib and an OpenSSL provider. This is the silicon-and-library layer — the right choice if you are building cryptography into hardware or embedding primitives into your own product. It is not a managed service; you operate everything above the library yourself.
- Crypto-agility orchestration overlays (e.g. QuSecure QuProtect): software that upgrades existing TLS / IPSec sessions to hybrid post-quantum tunnels and inventories crypto assets, without you operating the underlying key and secret infrastructure. The right choice when your goal is to wrap existing network traffic in PQ protection quickly. QuSecure is a credible pioneer in this category; the layer it occupies is the network-overlay layer, not key operation.
- Full managed PQC platforms (e.g. QNSP): operate the keys, secrets, encrypted storage, and audit chain as a service — KMS, quantum-safe vault, encrypted object and vector storage, crypto-policy enforcement, CBOM, and compliance evidence. The right choice when you want the cryptographic operations themselves managed, governed, and auditable, with verifiable conformance evidence.
- Cloud KMS (e.g. AWS KMS): the key-management service bundled with your cloud provider, now adding PQC capabilities. The right choice when you are deeply committed to one cloud and want PQC key operations inside that provider's boundary; the trade-off is narrower algorithm breadth and tighter coupling to that cloud's roadmap and posture.
A short checklist before you sign
Answer those six honestly and the field narrows itself. The PQC migration window through the early 2030s is real but not a panic; the right move in 2026 is a deliberate, evidence-backed selection rather than a rushed one. To compare specific vendors at each layer, see the side-by-side pages linked below, and check QNSP's published conformance evidence to calibrate what 'verifiable' should mean from any vendor you evaluate.
- Have we identified our HNDL exposure — which data has a confidentiality lifetime that outlasts the expected arrival of a CRQC?
- Does the vendor support FIPS 203/204/205 correctly today, and describe HQC/Falcon standardization status honestly?
- Can we see independent, re-runnable conformance evidence (NIST ACVP results), ideally cross-verified by two implementations?
- Is algorithm choice a governed policy we can change without re-architecting?
- Does the deployment topology, HSM/BYOH support, audit trail, CBOM, and SDK coverage match our actual requirements — verified, not roadmap?
- Are we buying the right layer of the stack for the problem we have?