Post-quantum cryptography is the rare procurement category where buying the wrong product locks you in for a decade. The keys you provision today protect data whose confidentiality matters in 2035 and beyond. A vendor whose 'quantum-ready' platform turns out to be a marketing layer over RSA-with-extra-steps isn't a recoverable mistake — it's a 10-year exposure.

At the same time, every vendor with a security platform now claims 'PQC-ready' or 'quantum-safe' or 'post-quantum-aligned' in their headline copy. The signal-to-noise ratio in vendor selection is genuinely bad. So here are five questions you can ask in a 10-minute call that will eliminate 80% of the noise.

Red flag 1: They can't tell you which FIPS standard their algorithms implement

NIST finalised three post-quantum standards in August 2024: FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, digital signatures), FIPS 205 (SLH-DSA, hash-based signatures). FIPS 206 (FN-DSA / Falcon) is in draft as of May 2026 with the initial public draft pending publication.

A serious PQC vendor will tell you exactly which of these their platform implements, which parameter sets, and at what security category (NIST L1 / L3 / L5). If the answer is some version of 'quantum-ready algorithms aligned to NIST' without naming a specific FIPS publication — that's a marketing-layer answer, not a technical one. Move on.

What to ask: 'Which FIPS publications does your platform implement, and at what NIST security category?'

What a real answer sounds like: 'ML-KEM-768 by default per FIPS 203, ML-KEM-1024 on government tier; ML-DSA-44 for JWT signing per FIPS 204, ML-DSA-87 for high-assurance; SLH-DSA-SHA2-256f for long-archival per FIPS 205; Falcon-512 and Falcon-1024 ahead of FIPS 206.'

Red flag 2: They have a 'PQC mode' that's a flag-flip on RSA

Some vendors implement PQC by adding ML-KEM as a wrapped-key layer on top of existing RSA-protected secrets. This is fine for hybrid TLS during migration, where you legitimately want both classical and PQC protection. It is not fine as the only PQC story, because it doesn't actually protect against the harvest-now-decrypt-later threat — if the underlying RSA key is compromised through quantum cryptanalysis in 2032, the data is exposed regardless of the ML-KEM wrapper.

What to ask: 'When I store a secret on your platform with PQC enabled, what is the encryption chain? Is the data-encryption key purely PQC-protected, or is there a classical layer underneath?'

What a real answer sounds like: 'On strict tier and above, the DEK is wrapped purely by ML-KEM. On default tier, we support hybrid (X25519+ML-KEM-768) for TLS compatibility during migration. We do not store secrets under a classical-only encryption chain on any paid tier.'

Red flag 3: They have one PQC implementation and no cross-verification

A single PQC implementation is a single point of failure for cryptographic correctness. The libraries that implement these algorithms — liboqs (Open Quantum Safe), @noble/post-quantum, and a handful of commercial implementations — have all had bugs at various points, and the algorithms themselves are young enough that subtle implementation errors are still being found. A vendor running production traffic through one library is one bug-disclosure away from a cryptographic incident.

The fix is independent cross-verification: every signature is signed by one library AND independently verified by a second. A bug in one library is caught at runtime, not in post-incident review.

What to ask: 'Which PQC library do you use? Is there an independent second implementation cross-verifying operations?'

What a real answer sounds like: 'Primary: liboqs 0.15.0 (Open Quantum Safe, native C, statically linked). Secondary on Maximum and Government tiers: @noble/post-quantum 0.6.0 (pure JavaScript, independent codebase). Every signature on these tiers is independently verified by both. Provider attestation is written into the audit chain for every operation.'

Red flag 4: They claim NIST ACVP conformance but can't show you the evidence

NIST's Algorithm Validation Test System (ACVP) publishes canonical test vectors that any PQC implementation can be tested against. A vendor that claims 'NIST-aligned' or 'NIST-compliant' should be able to point you at the specific test results — preferably as a reproducible evidence file that you can verify yourself by re-running the test vectors against the published source code.

What to ask: 'Where is your live NIST ACVP conformance evidence? Can I re-run the test vectors against your published source to verify?'

What a real answer sounds like: 'Live at https://[vendor].com/verify/conformance, regenerated on every release, bound by a SHA-3-256 digest you can re-derive from our public source mirror. Per-algorithm per-test-group pass/fail counts. Both primary and secondary providers separately verified.'

What a marketing answer sounds like: 'We follow NIST best practices' or 'Our platform is built on NIST-finalized algorithms.' That's a non-answer.

Red flag 5: They can't explain their entropy chain

PQC algorithms are only as strong as the entropy used to generate keys. ML-KEM with a weak seed is broken; ML-DSA with predictable randomness leaks the private key. A serious PQC vendor will document where every random byte in their platform comes from — typically a chain from CPU hardware entropy through the operating system's CSPRNG through a NIST SP 800-90A-compliant DRBG.

For high-assurance workloads, the chain extends to an HSM (Hardware Security Module) with FIPS 140-3 validated DRBG, and optionally to a customer-supplied QRNG (Quantum Random Number Generator) mixed into the seed per NIST SP 800-90C RBG3 prediction-resistance reseed semantics.

What to ask: 'Where does the entropy for your PQC operations come from? Can you point me at the documentation?'

What a real answer sounds like: 'CSPRNG path on default and strict tiers: OpenSSL SP 800-90A AES-CTR-DRBG seeded from Linux getrandom(2) which mixes Intel RDRAND/RDSEED, ARM TRNG on Graviton hosts, or AWS Nitro Security Chip TRNG depending on the underlying platform. HSM-DRBG path on Maximum and Government: customer-managed FIPS 140-3 L3 HSM via PKCS#11. QRNG mix-in available as a sales-assisted add-on for the most demanding workloads. Documented at /trust/entropy.'

The 10-minute test

You can run all five questions in a 10-minute discovery call. A serious vendor will answer all five in technical detail. A vendor selling PQC theatre will struggle on at least three. That's enough signal to decide whether to invest the next 40 hours of procurement effort.

None of these questions are gotchas. They're the questions every regulated buyer (financial services, defence, healthcare, government) will ask during the eventual vendor-risk review. Asking them yourself, before procurement, saves you from discovering them when the deal is half-signed.