Knowledge base
Reports, whitepapers, datasheets, guides - every entry is a real artifact.
No academic primers. No filler. Every link below points at an artifact already published on qnsi.heossi.com - suitable for forwarding to your board or your auditor.
At a glance
The platform in numbers
Derived from the same single-source facts the policy engine, ACVP evidence and service registry use; charts state scope, not deployment proof.
- 90PQC algorithms27 KEM · 63 signatures · 14 families
- 4Crypto-policy tiersNIST floors 1 / 3 / 5 / 5
- 18Manifest-declared servicessource inventory, not runtime proof
- 435/435ACVP vectors (noble)liboqs 240/240
- 3Compliance frameworks17 mapped controls
- 8HSM connectorsPKCS#11 and REST custody paths
Featured evidence
The three artifacts most often requested in vendor reviews
If you only have ten minutes, start here. Each is independently verifiable.
NIST ACVP Conformance Evidence
435/435 test vectors passed across ML-KEM keyGen + encapsulation, ML-DSA keyGen, and SLH-DSA keyGen. Dual-provider evidence; current runtime providers are noble 0.7.1 + liboqs 0.16.0. SHA-3-256 tamper-bound digest.
QNSI PQC Performance Benchmarks
Reproducible per-algorithm latency + throughput across ML-KEM, ML-DSA, FN-DSA, SLH-DSA. p50 / p95 / p99 timing, cold-start vs warm-start, multi-process concurrency scaling, native vs pure-JS comparison. Published as schema.org Dataset.
Compliance Frameworks - three ISO/IEC standards
HEOSSI framework posture for ISO/IEC 27001:2022, ISO/IEC 42001:2023, and ISO/IEC 19790:2025, with evidence boundaries stated explicitly.
3 reports
Reports
Tamper-bound evidence files. Each is regenerated per release, SHA-3-256 bound, and downloadable as raw JSON for ingestion into your compliance pipeline.
NIST ACVP Conformance Evidence
435/435 test vectors passed across ML-KEM keyGen + encapsulation, ML-DSA keyGen, and SLH-DSA keyGen. Dual-provider evidence; current runtime providers are noble 0.7.1 + liboqs 0.16.0. SHA-3-256 tamper-bound digest.
QNSI PQC Performance Benchmarks
Reproducible per-algorithm latency + throughput across ML-KEM, ML-DSA, FN-DSA, SLH-DSA. p50 / p95 / p99 timing, cold-start vs warm-start, multi-process concurrency scaling, native vs pure-JS comparison. Published as schema.org Dataset.
ACVP Evidence (raw JSON)
Tamper-bound machine-readable evidence file. Suitable for ingestion into customer compliance pipelines. Includes per-algorithm pass/fail, run timestamp, dual-provider versions, and SHA-3-256 of the full payload.
2 whitepapers
Whitepapers
Architecture-grade documentation of how QNSI composes cryptographic primitives. Citation-dense - NIST, IETF, vendor FIPS records.
QNSI Entropy Chain
End-to-end documentation of QNSI's three-chain entropy architecture (CSPRNG, HSM DRBG, optional QRNG mix-in). Cites NIST SP 800-90A / 90B / 90C, Linux getrandom, Intel RDRAND/RDSEED, AWS Nitro DRBG, and per-vendor HSM FIPS 140-3 records.
Security Hub - Verifiable Evidence Index
Index of every verifiable trust artifact QNSI publishes. Each entry is downloadable, dated, and reproducibly bound to a build SHA. Designed for use in regulator review and audit packs.
20 articles
Articles
Practical writing on PQC migration, vendor evaluation, compliance, and the platform engineering behind QNSI.
Building a CBOM Your Auditor Can Re-Run
The inventory is the first real deliverable of a PQC migration. A CBOM that nobody can reproduce is a snapshot, not evidence. Here is what belongs in it and what makes it re-runnable.
NIST IR 8547 Is Final: Two PQC Deadlines, Not One
The final IR 8547 keeps 2030 and 2035 and puts a shorter clock underneath them: high value federal systems face 2030 for key establishment and 2031 for signatures. What changed, what did not, and how to plan against both schedules.
IBM Defined Application-Level Crypto-Agility. QNSI Takes It Into Enterprise Execution
IBM Research has given crypto-agility a rigorous application-level model. We mapped it against QNSI's shipped code: strong overlap, a broader enterprise execution layer - and two gaps our forensic review found and then closed.
Native PQC HSMs Are Here: How QNSI Solves the Real Migration Problem
Native PQC and HSPK evidence boundaries; live multi-tenant production operation is NOT VERIFIED.
Post-Quantum Claims Should Be Verifiable: How QNSI Proves Them
Security teams cannot migrate regulated estates on adjectives. See how QNSI connects discovery, governed change, qualified custody, reproducible conformance evidence, and dual-signed product facts.
Migrating a Bank's Cryptography to Quantum-Safe via QNSI: A 2026 Field Guide
A source-mapped bank migration reference; end-to-end production execution is NOT VERIFIED.
Five PQC Vendor Evaluation Questions - and QNSI's Evidence Boundaries
Separate PQC evidence from marketing; QNSI production execution beyond published artifact scope is NOT VERIFIED.
'Harvest Now, Decrypt Later' Is on a 2027 Clock - Here's How to Beat It with QNSI
An HNDL migration planning framework; QNSI production execution is NOT VERIFIED.
MAS TRM and PQC: How Singapore Financial Institutions Comply with QNSI
A MAS TRM source mapping, not production control proof; runtime effectiveness is NOT VERIFIED.
What ML-KEM Does - and How QNSI Runs It for You Today
ML-KEM concepts and QNSI architecture boundaries; end-to-end production execution is NOT VERIFIED.
Continuous Compliance vs. Snapshot Reports: QNSI Source Contracts and Evidence Boundaries
Continuous-compliance architecture and evidence boundaries; QNSI production effectiveness is NOT VERIFIED.
Is AES Quantum-Safe? What to Keep, What to Replace, and QNSI's Required Design
Keep AES-256 only after genuine PQC establishment; QNSI end-to-end production execution is NOT VERIFIED.
ML-DSA on QNSI: Signature Contracts and Evidence Boundaries
ML-DSA concepts and source contracts; QNSI production signing behavior is NOT VERIFIED.
Crypto-Agility Is an Operating Capability: How QNSI Connects Policy, Inventory, and Migration
When an algorithm falls, policy alone is not enough. QNSI connects per-tenant controls over 90 algorithms with CBOM inventory, governed migration, approvals, and signed evidence.
How to Choose a Post-Quantum Cryptography Platform in 2026 | QNSI
Eight criteria decide any PQC platform purchase. This guide states each one, gives QNSI's answer, and shows how to verify it yourself - live ACVP evidence, 90 algorithms, governed crypto policy, and a Free Forever tier to test today.
SLH-DSA on QNSI: Hash-Based Signatures for Your Most Conservative Signing Paths
Keys you can never re-key deserve the most conservative signature NIST finalized. Deploy SLH-DSA (FIPS 205) on QNSI with one API call, or enforce it as per-tenant policy - and verify our live ACVP evidence before you trust it.
The Quantum Timeline Doesn't Matter - Your Data's Lifetime Does. Start on QNSI Today
Use data lifetime and migration time to plan; QNSI deployment timelines and execution are NOT VERIFIED.
Composite Interoperability Without Guesswork: X25519 + ML-KEM on QNSI
PQC-native is primary; X25519MLKEM768 is explicit composite-interop, and production negotiation is NOT VERIFIED.
CNSA 2.0 Compliance on QNSI: ML-KEM-1024 and ML-DSA-87 as a Policy Setting
A CNSA 2.0 source-contract mapping; deployment-wide QNSI enforcement is NOT VERIFIED.
Beyond AWS KMS: Migrating to Post-Quantum Key Management with QNSI
A reversible AWS KMS migration reference; QNSI end-to-end production execution is NOT VERIFIED.
17 datasheets
Datasheets
Per-product and per-algorithm reference. Every datasheet maps to a real backend service running on the QNSI platform today.
QNSI Platform Architecture
18 production services across identity, decision, enforcement, data, operations, control, evidence, edge, and provisioning boundaries. Manifest-driven routes and 4 crypto-policy enforcement tiers.
Capabilities
Maturity ladder (Discover → Enforce → Scale), named-service tiles (KMS, Vault, CBOM, Edge-Gateway, Audit, Enclaves), and the CISO pain-set this platform addresses.
Compliance Frameworks - three ISO/IEC standards
HEOSSI framework posture for ISO/IEC 27001:2022, ISO/IEC 42001:2023, and ISO/IEC 19790:2025, with evidence boundaries stated explicitly.
ML-KEM - Module-Lattice-based Key Encapsulation Mechanism
NIST's primary post-quantum key encapsulation standard, finalised August 2024 as FIPS 203. QNSI policy sources select ML-KEM across PQC-native tiers and define it for transport and envelope targets; complete production negotiation and envelope execution remain NOT VERIFIED.
ML-DSA - Module-Lattice-based Digital Signature Algorithm
NIST's primary post-quantum digital signature standard, finalised August 2024 as FIPS 204. ML-DSA powers JWT signing, audit-log integrity, code-signing, and authn token issuance across QNSI.
SLH-DSA - Stateless Hash-based Digital Signature Algorithm
NIST's hash-based digital signature standard, finalised August 2024 as FIPS 205. SLH-DSA's security rests only on the hardness of finding hash function preimages - the most conservative assumption available - making it the natural choice for long-archival signatures and government-tier policy.
FN-DSA - FFT-based NTRU Digital Signature Algorithm
NIST's fourth standardised PQC signature scheme, formally FN-DSA under FIPS 206 - the initial public draft is still the current publication as of October 2026. Falcon's signatures are the most compact of the lattice-based PQC schemes, making it preferred for size-constrained transport.
HQC - Hamming Quasi-Cyclic Key Encapsulation
NIST-selected code-based backup KEM (selected March 2025); its draft standard is still pending as of October 2026. QNSI offers HQC as an explicit diversity option with liboqs 0.16.0, which updates the implementation to the 20250822 specification; ML-KEM remains the FIPS-final default.
BIKE - Bit Flipping Key Encapsulation
Code-based KEM finalist (round 4 of NIST PQC standardisation) using QC-MDPC codes. Available in liboqs for QNSI customers seeking additional code-based alternatives.
Classic McEliece - Classic McEliece Code-Based KEM
The original code-based public-key cryptosystem, in continuous study since 1978 - by far the oldest cryptographic assumption in the PQC catalogue. Trades extremely large public keys for the most-studied security assumption available.
FrodoKEM - Frodo Key Encapsulation Mechanism
Plain Learning With Errors (LWE) KEM - same lattice family as ML-KEM but without the additional ring or module structure. Larger keys and ciphertexts but built on the most conservative lattice assumption.
NTRU - Number Theoretic Research Unit Cryptosystem
One of the oldest lattice-based KEMs, in continuous study since 1996. NTRU was a NIST PQC finalist but not selected for FIPS standardisation in favour of ML-KEM.
NTRU Prime - NTRU Prime (Streamlined / Light NTRU Prime)
NTRU variant designed to use a prime-degree ring polynomial, removing certain structural concerns. Notably deployed in OpenSSH's default post-quantum key exchange.
MAYO - Multivariate Quadratic Signatures (MAYO)
Multivariate quadratic signature scheme advanced to Round 3 of NIST's additional digital signature process (NIST IR 8610, October 2026). Short signatures and small public keys; trades signing speed against parameter size.
CROSS - Codes and Restricted Objects Signature Scheme
Code-based signature using the MPC-in-the-head paradigm over restricted syndrome decoding. Reached Round 2 of NIST's additional digital signature process but was not among the nine candidates advanced to Round 3 (October 2026), so it remains research and diversity only.
UOV - Unbalanced Oil and Vinegar Signatures
Multivariate signature scheme based on the Unbalanced Oil and Vinegar (UOV) construction, one of the longest-studied multivariate schemes. Advanced to Round 3 of NIST's additional digital signature process (NIST IR 8610, October 2026).
SNOVA - Simple Noncommutative-ring-based UOV Algorithm
Multivariate signature scheme using a non-commutative ring structure to reduce public-key size relative to plain UOV. Advanced to Round 3 of NIST's additional digital signature process (NIST IR 8610, October 2026).
4 guides
Guides
Buyer-side migration paths, vendor evaluation rubrics, and the operating model for moving production trust onto QNSI.
PQC Migration Guide
Five-stage migration path: inventory → parallel-deploy → cross-verify → automate → evidence. Concrete actions, tooling, and timeline for each stage.
The Quantum Imperative
HNDL exposure model, NIST PQC standards timeline, CNSA 2.0 mandate dates, the migration window. The case for moving now, not in 2030.
Why QNSI
Algorithm breadth, dual-provider verification, 4 policy tiers, audit chain, and 8 capability-gated HSM connector implementations - the buyer-evaluation rubric.
Vet PQC Vendors - Five Red Flags
Five patterns of PQC theatre to catch in a 10-minute call: 'quantum-ready' without algorithm specifics, single-implementation lock-in, missing FIPS evidence, no algorithm-agility story, no audit chain.
6 comparisons
Comparisons
Side-by-side QNSI vs the platforms enterprise teams already use - AWS KMS, Azure Key Vault, HashiCorp Vault, Fortanix DSM, SandboxAQ.
QNSI vs AWS KMS
Side-by-side comparison: PQC algorithm coverage, FIPS validation, multi-cloud crypto posture, dual-provider cross-verification, crypto-policy enforcement, APAC regulatory home, and pricing transparency.
QNSI vs Azure Key Vault
Side-by-side comparison: PQC algorithm coverage, FIPS validation, multi-cloud crypto posture, dual-provider cross-verification, crypto-policy enforcement, APAC regulatory home, and pricing transparency.
QNSI vs HashiCorp Vault
Side-by-side comparison: PQC algorithm coverage, FIPS validation, multi-cloud crypto posture, dual-provider cross-verification, crypto-policy enforcement, APAC regulatory home, and pricing transparency.
QNSI vs Fortanix DSM
Side-by-side comparison: PQC algorithm coverage, FIPS validation, multi-cloud crypto posture, dual-provider cross-verification, crypto-policy enforcement, APAC regulatory home, and pricing transparency.
QNSI vs SandboxAQ
Side-by-side comparison: PQC algorithm coverage, FIPS validation, multi-cloud crypto posture, dual-provider cross-verification, crypto-policy enforcement, APAC regulatory home, and pricing transparency.
Competitive Analysis
Side-by-side QNSI vs cloud KMS, dedicated HSM platforms, and specialist PQC vendors. Algorithm coverage, FIPS posture, multi-cloud, sovereignty, pricing transparency.
3 faqs
FAQ
Concrete answers - no marketing fluff - to the questions every prospective customer asks.
FAQ - Getting Started
What is QNSI, how the free tier works, what happens when you exceed limits, how upgrades and downgrades work.
FAQ - Technical
Algorithms supported, hardware enclaves, HSM integration. Concrete technical answers without marketing fluff.
FAQ - Compliance
FIPS 140-3 posture, compliance frameworks, data residency, where customer data lives.
35 terms
PQC glossary
Buyer-grade definitions. Every entry cites a NIST publication, FIPS standard, IETF RFC, or QNSI source-of-truth file. Browse the dedicated glossary for term pages and related concepts.
PQC concepts (9)
Standards & programs (11)
QNSI platform (6)
FAQ
Getting Started
4 concrete answers - no marketing fluff.
What is QNSI?
QNSI (Quantum-Native Security Infrastructure) is a comprehensive security platform implementing NIST-standardized post-quantum cryptography. It provides 18 production microservices including auth, storage, search, KMS, vault, and AI orchestration - all protected with quantum-resistant encryption.
How does the free tier work?
The free tier has no time limit or credit-card requirement and includes published allocations for storage, API calls, KMS keys, vault secrets, and SDK access. Entitlement does not prove every service operation, PQC envelope, or PQC transport path; verify the exact route and evidence required.
What happens when I exceed free tier limits?
When you approach your limits, you'll receive notifications via the cloud portal. You can upgrade to a paid tier anytime. There's no automatic overage billing - your account will be rate-limited until you upgrade or your monthly quota resets.
Can I upgrade or downgrade my plan?
Yes. You can upgrade anytime through the cloud portal with immediate effect. Downgrades take effect at the end of your current billing period. Annual plans are billed at exactly 12 times the monthly price, with no automatic annual discount.
FAQ
Technical
3 concrete answers - no marketing fluff.
What post-quantum cryptography algorithms does QNSI use?
QNSI implements 90 PQC algorithms across 14 families. NIST-finalized: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). Additional families include BIKE, Classic McEliece, FrodoKEM, NTRU, MAYO, CROSS, UOV, and SNOVA.
What hardware enclaves does QNSI support?
QNSI supports 8 hardware enclave types: Intel SGX, AMD SEV, NVIDIA CC, Intel TDX, ARM TrustZone, ARM CCA/RME, AWS Nitro Enclaves, and IBM Secure Execution. All include cryptographic attestation.
How does QNSI integrate with HSMs?
QNSI provides capability-gated connectors for major PKCS#11 HSMs and REST custody backends. Root keys become hardware-backed only after the customer's exact device, firmware, mode, credentials, mechanisms, and evidence path pass qualification.
FAQ
Compliance
3 concrete answers - no marketing fluff.
Is QNSI FIPS 140-3 certified?
No - QNSI publishes algorithm-level conformance evidence, not a QNSI module-level FIPS 140-3 / CMVP validation. A customer HSM's vendor certificate applies only to the specific validated model, firmware, operating mode, and approved deployment configuration.
What compliance frameworks does QNSI support?
HEOSSI (PTE.) LTD owns and administers the company compliance programme and is the prospective certificate holder. QNSI is a HEOSSI product that may be included within the documented scope; it is not a separate certificate holder. The posture covers ISO/IEC 27001:2022 and ISO/IEC 42001:2023, while ISO/IEC 19790:2025 applies only to specifically identified cryptographic modules or components. Accredited certification is not currently claimed.
Where is customer data stored?
QNSI Cloud (hosted) runs on AWS ap-southeast-1 (Singapore). Enterprise tiers support region selection, VPC deployment, on-premises, and air-gapped deployments for data residency requirements.
Next