The question that actually decides the purchase
By 2026 nobody needs convincing that post-quantum cryptography is coming. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024; Executive Order 14412 (June 2026) puts PQC on federal High-Value Assets by 2030 for key establishment and 2031 for signatures; CNSA 2.0 reaches new national-security systems in January 2027; DORA is already in force. Every vendor deck now says quantum-safe. The purchase decision comes down to one question: which claims can you verify before you sign?
This guide is our answer to that question. It walks the eight criteria a serious buyer scores any PQC platform on - and for each one gives QNSI's answer, together with the way to check it yourself, today, without a sales call. QNSI is the quantum-native security platform from HEOSSI. We built it to win exactly this evaluation, which is why we would rather you run the tests than take our word.
Criterion 1 - Conformance evidence you can re-run (start here)
A PQC implementation that is subtly wrong is worse than the classical cryptography it replaced, because it feels safe. So the first question for every vendor on your shortlist is not which algorithms they list - it is what independent evidence exists that the implementations match NIST reference behavior, and whether you can reproduce that evidence yourself. Most vendors answer with a PDF.
QNSI answers with a URL. Our NIST ACVP conformance evidence is published live at qnsi.heossi.com/verify/conformance: official test vectors run against both of our providers - the pure-JavaScript noble implementation passing 435/435 across the FIPS 203/204/205 groups it covers, and the native-C liboqs engine passing 240/240 across its addressable ML-KEM surface - bound to a SHA-3-256 tamper digest and regenerated on every release. No account, no NDA, re-runnable by you. That is not a certification claim; it is something an engineer can act on faster.
Criterion 2 - FIPS coverage, stated honestly
Require full support for the three finalized standards - FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA - and require precision about everything else: FN-DSA (Falcon) is still a draft, and a datasheet that blurs draft into finalized tells you how carefully the rest of the cryptography was handled.
QNSI's source and published conformance evidence cover the three finalized standards and label FN-DSA as draft. The Government policy source restricts the configured set to finalized algorithms; platform-wide production enforcement remains NOT VERIFIED.
Criterion 3 - Algorithm breadth is your exit strategy
Breadth is not a vanity metric; it is what makes crypto-agility real. A platform that ships two algorithms ends your agility story the day one of them needs replacing - and cryptanalysis does not schedule its surprises.
QNSI catalogs 87 PQC algorithms: 24 KEMs and 63 signatures across 13 mathematical families. Source defines liboqs as primary and noble as an overlapping verification provider. Catalog presence, live route support, dual-provider execution, and failure handling must be verified separately for the exact operation.
Criterion 4 - Agility as governed policy, under dual control
The practical test of crypto-agility: can you move a tenant to a stronger algorithm set as a policy change rather than a re-architecture - and can a single careless administrator weaken it back?
On QNSI every tenant carries a crypto policy tier - default, strict, maximum, or government - enforced by the platform at key creation and key use, not by convention in each team's code. Keys upgrade to stronger algorithms in place, and rotation policies run on your schedule.
Since July 2026, crypto-policy changes are dual-controlled: maker-checker approvals, so the person who requests a change can never be the person who approves it. The same control covers tenant deletion and root and master key revocation. Ask every vendor who can weaken your algorithm policy acting alone. Our answer is: no one.
Criterion 5 - Root of trust: your keys, your hardware, your recovery
For regulated workloads, custody decides the purchase, so demand evidence. QNSI provides BYOK, 8 capability-gated BYOHSM connector implementations, and the current escrow route, which is not threshold recovery and is not presented as available. Hardware custody is asserted only after the selected device, configuration, key operations, interruption handling, audit path, and vendor-certificate scope pass qualification.
Criterion 6 - More than a KMS: the data plane is quantum-safe too
Keys are a third of the problem. Secrets, objects, and search indexes carry the same long confidentiality horizons. QNSI source defines Vault, storage, search, and transport targets behind shared policy contracts. Genuine PQC envelopes, plaintext boundaries, public-edge negotiation, and complete audit effects remain NOT VERIFIED until deployment-specific evidence proves them.
Criterion 7 - CBOM, audit, and the artifacts your auditor will ask for
You cannot migrate what you cannot see, and you cannot pass an audit you cannot evidence. EO 14412 made the Cryptographic Bill of Materials concrete - CISA and NIST are to publish CBOM minimum elements within 270 days of the June 2026 order - and security questionnaires are already catching up.
QNSI's source defines cryptographic discovery across 11 cloud-vendor connector families and 36 inventory source types plus CycloneDX CBOM export. The audit source defines hash chaining and ML-DSA checkpoint signatures, while compliance surfaces package recorded observations against framework mappings. Connector coverage, complete event ingestion, report availability, control effectiveness, and auditor acceptance remain separate evidence questions.
Criterion 8 - Integration in your language, at a price you can start on today
A platform you cannot integrate is a platform you will not use. QNSI ships SDKs for TypeScript/Node (@heossihq/qnsi), Python (qnsi), Go, Rust (qnsi), and JVM/Android (com.heossi:qnsi), plus a CLI and an MCP server for agentic workflows. Pricing is public: a Free Forever tier (10 GB storage, 50,000 API calls, 20 KMS keys, 25 vault secrets), developer plans from $149/month, enterprise custom. Your engineers can finish the technical evaluation before procurement opens a ticket.
# Start free - no card, no sales call: cloud.qnsi.heossi.com
pnpm add @heossihq/qnsi # TypeScript/Node
# pip install qnsi | cargo add qnsi | com.heossi:qnsi | Go | CLI | MCP
export QNSI_API_KEY="<your key>"import { QnsiClient } from "@heossihq/qnsi";
const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY! });
// Your first post-quantum key - minutes after signup
const key = await qnsi.kms.createKey({
keyType: "data",
algorithm: "dilithium-3", // ML-DSA-65 (FIPS 204)
purpose: "signing",
});Where the other layers fit - and where QNSI wins
The PQC market splits into four layers, complementary as often as competitive. PQShield sells cryptographic IP cores and embedded libraries - the right buy when you are putting PQC into silicon or firmware you manufacture. QuSecure QuProtect is a crypto-agility overlay that wraps existing TLS and IPSec in hybrid post-quantum tunnels - the right buy for hardening network links you do not otherwise control. Cloud KMS offerings such as AWS KMS add PQC key operations inside one provider's boundary, with narrower algorithm breadth and coupling to that provider's roadmap.
QNSI is the fourth layer: the full managed platform that operates keys, secrets, encrypted storage and search, policy, and audit as one governed service with published evidence. If what you need is governed PQC operations your board and your auditor can verify, that is the layer you are buying - and it is the layer QNSI was built to win. The side-by-side comparisons are linked below; we keep them sourced and fair.
Score us first: the evaluation you can run this afternoon
That is one afternoon, it costs nothing, and it recalibrates what you accept as proof from every other vendor in the process.
- Open qnsi.heossi.com/verify/conformance and inspect the live ACVP results - no account required.
- Sign up Free Forever and mint a key in each algorithm family your program needs; all 13 families are on the menu from day one.
- Set a crypto policy tier, then attempt an out-of-policy key request - and watch the platform refuse it.
- Request a crypto-policy change and observe the maker-checker flow block self-approval.
- Run a CBOM discovery against one cloud account and export the CycloneDX.
- Generate a compliance evidence pack for the framework you report against.
Start now
Create a Free Forever workspace at https://cloud.qnsi.heossi.com/auth?mode=signup - no card, no sales gate. If you are running a formal selection, bring your scoring sheet to an architect at /contact and we will map every criterion to a live surface. The evidence is already public: qnsi.heossi.com/verify/conformance.