1 · Algorithm breadth
87 PQC algorithms across 13 families
A broad migration catalog spanning finalized standards and candidate families.
24 KEMs and 63 signatures are present in the catalog for policy, interoperability, conformance, and migration work. Algorithm presence does not establish production route support, regulatory approval, or deployment qualification; evaluate the exact family, operation, provider, and evidence required.
2 · Algorithmically-distinct backup KEM
Code-based KEMs - a non-lattice backup to ML-KEM
Algorithmically-distinct migration options alongside ML-KEM.
ML-KEM is a structured-lattice scheme, while Classic McEliece and BIKE are code-based alternatives. QNSI catalogs both for policy, interoperability, and migration evaluation. Catalog presence does not prove that every service route or deployment supports them. HQC remains excluded while the pinned cryptographic provider disables the relevant implementation.
3 · Dual-provider verification policy
Dual-provider cross-verification
liboqs (native C) + noble (pure JS) on their overlapping surface.
Maximum and Government policy sources can require cross-verification between the two providers for supported overlapping algorithms. Exact operation coverage, comparison semantics, failure handling, provider attestation, and audit ingestion must be verified for the target deployment.
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
Audit-chain and checkpoint contracts
Hash chaining, Merkle checkpointing, receipt verification, and PQC signing boundaries.
The source defines crypto-critical event contracts, hash chaining, Merkle checkpoints, receipt verification, and outbound integration surfaces. Complete producer coverage, real-time delivery, root publication, and successful independent replay remain NOT VERIFIED without deployment evidence.
6 · BYO-everything, no lock-in
8 HSM connector implementations + 11 cloud-vendor connector families
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 contracts span 11 cloud-vendor connector families and 36 inventory source types without treating source presence as proof of observed estate coverage or custody.
Review the public SDK, source, and integration evidence-together with each stated runtime boundary-at github.com/heossihq/qnsi-public. Independent reproduction matters more than a vendor's own claim.