Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.
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 - and every security vendor now has 'quantum-ready' in the headline. The signal-to-noise ratio in PQC vendor selection is genuinely bad, and your procurement clock (CNSA 2.0 requires PQC for new national-security systems from January 2027) is not waiting for it to improve.
Here are the five questions that eliminate most of the noise in a 10-minute call - and, because we would rather you test us than trust us, QNSI's on-the-record answer to each one, with the public page where you can verify it before you ever book a call.
Red flag 1: they can't name the FIPS standard they implement
NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024; FN-DSA (FIPS 206) is in draft. A serious vendor tells you exactly which publications, which parameter sets, and at what NIST security category. 'Quantum-ready algorithms aligned to NIST' is a marketing answer - move on.
QNSI's answer: 87 PQC algorithms - 24 KEMs and 63 signatures across 13 families - including ML-KEM-512/768/1024 per FIPS 203, the full ML-DSA set per FIPS 204, all twelve SLH-DSA parameter sets per FIPS 205, and FN-DSA (Falcon-512/1024) ahead of the draft FIPS 206. Per-tenant crypto policy tiers pin the sets: government tier permits FIPS-finalized algorithms only - ML-KEM-1024 for key establishment, ML-DSA-87 and SLH-DSA-256f variants for signatures. The full catalog is public at qnsi.heossi.com/algorithms.
Red flag 2: their 'PQC mode' is a flag-flip on RSA
Some vendors add ML-KEM as a wrapper over existing RSA-protected secrets. That is fine for hybrid TLS in transit during migration; it is not fine as the only story at rest - if the classical layer falls to quantum cryptanalysis, the data is exposed regardless of the wrapper. Ask: when I store a secret with PQC enabled, what is the encryption chain? Is the data-encryption key purely PQC-protected?
QNSI's source target is versioned Vault secrets and SSE-X objects protected by genuine PQC-native envelopes, with strict policy restricting KEM choices. Vault and Storage envelope execution plus complete policy enforcement are NOT VERIFIED.
Red flag 3: one implementation, no cross-verification
A single PQC implementation is a single point of failure for cryptographic correctness. These algorithms are young, and implementation bugs are still being found; a vendor running production traffic through one library is one bug-disclosure away from a cryptographic incident. Ask: which library do you use, and is there an independent second implementation verifying it?
QNSI source includes liboqs and @noble/post-quantum providers plus policy contracts requiring cross-verification for defined algorithm sets. Complete runtime cross-verification, provider attestation ingestion, audit coverage, and deployment behavior are NOT VERIFIED; ACVP artifacts prove only vector conformance.
Red flag 4: ACVP claims with no evidence you can run
NIST's ACVP program publishes canonical test vectors that anyone can run. A vendor claiming 'NIST-aligned' should point you at specific, reproducible results - 'we follow NIST best practices' is a non-answer. Ask: where is your live conformance evidence, and can I re-run it myself?
QNSI's answer: live at qnsi.heossi.com/verify/conformance - per-algorithm, per-test-group pass counts, regenerated on every release, bound by a digest you can re-derive, with primary and secondary providers verified separately. You do not need an account, and you do not need to take our word for it:
# QNSI's live ACVP evidence (no account needed)
curl -s https://qnsi.heossi.com/pqc-evidence/acvp-latest.json | \
node -e 'const j=JSON.parse(require("fs").readFileSync(0));console.log(j.summary)'
# Public-edge negotiation procedure only; deployment behavior is NOT VERIFIED
echo | openssl s_client -connect api.qnsi.heossi.com:443 \
-groups X25519MLKEM768 2>&1 | grep 'group:'Red flag 5: they can't explain their entropy chain
PQC keys are only as strong as the randomness underneath: ML-KEM with a weak seed is broken, and ML-DSA with predictable randomness leaks the private key. A serious vendor documents where every random byte comes from - hardware entropy, the OS CSPRNG, NIST SP 800-90A DRBG semantics, and the hardware path for high-assurance tiers. Ask for the documentation, not assurances.
QNSI source documents OS/OpenSSL entropy and conditional customer-HSM contracts at qnsi.heossi.com/security/entropy. Deployment-specific entropy execution and hardware-rooted randomness or custody remain NOT VERIFIED until independently qualified.
The 10-minute test - run it on us first
A serious vendor answers all five in technical detail; a vendor selling PQC theatre struggles on at least three. These are exactly the questions your vendor-risk review will ask eventually - asking them now saves 40 hours of due diligence on a marketing pitch.
QNSI publishes source catalogs, policy mappings, conformance artifacts, entropy documentation, and a migration architecture. Each artifact proves only its stated scope; end-to-end deployment execution remains NOT VERIFIED.
Start now
Inspect the five evidence scopes before evaluating a workspace at https://cloud.qnsi.heossi.com/auth?mode=signup. A successful call is not independent proof of primitive execution or deployment-wide coverage.