1 · Algorithm breadth
87 PQC algorithms across 13 families
Most vendors ship 3–4. QNSI supports the entire NIST + IETF candidate field.
24 KEMs (ML-KEM, BIKE, Classic McEliece, FrodoKEM, NTRU, NTRU-Prime/sntrup761) and 63 signatures (ML-DSA, SLH-DSA, FN-DSA, MAYO, CROSS, UOV, SNOVA). If your regulator requires a code-based fallback (McEliece, NSA preference), a hash-based fallback (SLH-DSA), or any non-lattice scheme — QNSI can ship it today. Fortanix publicly lists 4. SandboxAQ doesn't publish a count.
2 · Algorithmically-distinct backup KEM
Code-based KEMs — a non-lattice backup to ML-KEM
Algorithmically-distinct backups to ML-KEM, in production today.
ML-KEM (Kyber) is a structured-lattice scheme. Classic McEliece and BIKE are code-based — a fundamentally different mathematical foundation — so an algorithmic break in lattices does not break the entire KEM stack. QNSI ships Classic McEliece (5 parameter sets) and BIKE (L1/L3/L5) in production today; most vendors still ship only ML-KEM. If structured lattices fall, your KEM is not breached. (HQC, the other NIST code-based KEM, is held back until liboqs ships its corrected 2025-spec implementation — we don't ship algorithms our crypto library disables for an unresolved security flaw.)
3 · Two implementations on every operation
Dual-provider cross-verification
liboqs (native C) + noble (pure JS). Every crypto op verified by both.
On Maximum and Government crypto-policy tiers, every signature is signed by one provider and verified by the other; provider attestation is recorded in the audit ledger. 18 NIST-finalised algorithms overlap between the two independent codebases. A single-implementation bug — like the kind that historically affects new cryptographic code — is caught at runtime. No competitor publishes this architecture.
4 · Enforced policy, not flexible guidance
Four crypto-policy tiers (default → strict → maximum → government)
Hard algorithm restrictions enforced at edge-gateway, KMS, and vault — not just UI suggestions.
Default supports the full algorithm registry. Strict and Maximum narrow the permitted algorithms. Government enforces FIPS-finalized-only algorithms and an HSM-custody requirement. The requirement fails closed unless a qualified HSM path is active; policy selection alone is never evidence of hardware custody.
5 · Tamper-evident, PQC-signed audit chain
59 crypto-critical event types across 12 source services
ML-DSA-65-signed events with SHA3-256 hash chains and SHA3-512 Merkle checkpoints.
Every key operation, signature, policy decision, and entitlement check from kms-service, vault-service, access-control-service, storage-service, search-service, ai-orchestrator, auth-service, security-monitoring-service, edge-gateway, tenant-service, billing-service, and audit-service flows into a single hash-chained ledger. Real-time WebSocket streaming to SIEM (Splunk, Datadog, Slack, GitHub, AWS, Azure, GCP, Okta). Receipt-replay verification lets any party independently re-validate any signed event without trusting QNSI's database.
6 · BYO-everything, no lock-in
8 HSM connector implementations + 11 cloud connectors
Customer hardware. Customer cloud. Customer crypto. No QNSI-managed lock-in required.
QNSI implements six PKCS#11 HSM connectors and two REST custody backends. Each named backend is enabled only after live qualification. Crypto-posture connectors cover 11 cloud vendors, letting regulated buyers assess their existing estate without treating connector code as proof of access or custody.
