QNSI: quantum-nativesecurity infrastructure.
Post-quantum cryptography for sensitive data, critical systems, and AI workloads - enforced from day one, provable on request.
Operate keys, secrets, storage, audit, posture, governed PQC migration, and AI security from one enterprise infrastructure layer.
Traffic recorded today is being stored for decryption later. The only decision left is which side of the switch your data is on.
Operated as one infrastructure layer.
Sized to your organisation's regulatory posture.
Built for governments, defence, financial institutions, critical infrastructure, enterprises, AI companies, sensitive-data platforms, and production trust teams.
Quantum-Native Security Infrastructure
Start with the cryptographic problem you need to solve.
Compare the relevant workflow, integration requirements, and published evidence before choosing a deployment.
Cryptographic discovery and inventory
Review discovery sources, local scanning, CBOM exports, and the evidence needed to establish coverage of your estate.
Post-quantum key management
Evaluate key lifecycle workflows, algorithm policy, customer-managed custody, and HSM qualification requirements.
Secrets management
Review secret versioning, access boundaries, rotation workflows, and integration requirements for your applications.
Governed post-quantum migration
Plan assessment, approval, migration waves, and reconciliation around the cryptographic assets you need to transition.
Company and marketplace records
Company information
Company: HEOSSI (PTE.) LTD, Singapore UEN 202532790K. Review the product listing, published SDK, and public source before evaluating an integration. About QNSI sets out the product identity and the company behind it, the research library collects the primary sources QNSI is built on, and the changelog records what has shipped.
Start with the decision you own
Concrete questions for accountable operators.
Four modelled situations show how a recognisable operational problem can move through QNSI to a decision artifact and independently validated result.
CISO · Head of Payments · Cryptography Lead
Map cryptography across a bank payment rail before migration
Which payment services can move first without breaking clearing, fraud, or settlement dependencies?Read modelled case study →Mobile Core Security · Network Architecture · PKI
Inventory PKI dependencies across 5G network functions
Which network functions, vendors, and interfaces depend on shared trust anchors or non-agile certificate profiles?Read modelled case study →ML Platform · AI Security · Model Risk
Verify an AI model artifact before production loading
Does the model match the approved training run, evaluation, code, and release authority?Read modelled case study →OT Access Management · Vendor Risk · Operations
Constrain supplier remote-access trust in electric operations
Which supplier identity can reach which asset, for what task, using which credential and approval?Read modelled case study →Platform architecture - Cloud-default flow
Your stack stays. QNSI becomes your trust layer.
QNSI sits between your applications, HSMs, and multi-cloud estate as a dedicated security infrastructure layer. Customer systems stay where they are; QNSI provides post-quantum key operations, vaulting, storage protection, policy enforcement, posture telemetry, and tamper-evident evidence across them. The diagram below renders the Cloud-default topology - one of five deployment models supported. Compare all five deployment topologies →
Your organisation
Apps · AI workloads
Whatever stack you operate today. TypeScript · Python · Go · Rust · JVM/Android · REST · CLI · MCP.
Customer HSMs
Capability-gated BYOHSM connectors: six PKCS#11 implementations and two REST backends. Each named device or service must pass live qualification before use.
Your multi-cloud estate
11 connector families: AWS · Azure · GCP · IBM · Oracle · Alibaba · Akamai · Cloudflare · Fastly · DigitalOcean · HashiCorp Vault.
QNSI Edge Gateway
Single ingress · transport-policy boundary · multi-tenant routing · authentication · entitlement enforcement · capability gates · rate limits.
Identity & Decision
Authentication · access control · policy decisions
Control
Tenancy · entitlements · platform APIs
Data
KMS · vault · storage · search
Evidence
Audit chain · evidence packs
Operations
Crypto inventory · AI orchestration · security monitoring · observability
Tamper-Evident Audit Ledger
Merkle-tree chain · ML-DSA-signed checkpoints · 90-day → 7-year retention tiers · WebSocket streaming for SIEM.
Compliance Evidence
Evidence packs aligned to ISO/IEC 27001:2022, ISO/IEC 42001:2023, and ISO/IEC 19790:2025. Signed and exportable on demand.
Crypto-posture insights
Continuous discovery, NIST PQC readiness scoring, CycloneDX CBOM export across your multi-cloud estate.
Deployment topologies:
Cloud (default)VPCOn-premisesAir-gappedSovereignNote:
Architecture is illustrative and current as of Q2 2026. Public SDKs and integration examples are independently verifiable at github.com/heossihq/qnsi-public.
Detailed implementation documentation is available under mutual NDA.
Third-party product names, logos, and trademarks are the property of their respective owners and are referenced solely for compatibility and integration documentation.
Their inclusion does not imply endorsement, partnership, or affiliation unless explicitly stated.
Security & assurance
Three standards, one operating posture.
QNSI follows HEOSSI's selected frameworks for information security, AI governance and safety, and cryptographic module security.
Information Security
ISO/IEC 27001:2022
Evaluated and aligned under ISO/IEC 27001:2022.
AI Governance & Safety
ISO/IEC 42001:2023
Developed and maintained under ISO/IEC 42001:2023.
Data Encryption Standards
ISO/IEC 19790:2025
Core cryptographic components verified under ISO/IEC 19790:2025.
Internal framework posture; accredited certification and independent conformity assessment are not claimed.
HEOSSI (PTE.) LTD owns and administers the company compliance programme and is the prospective certificate holder. BEE, QNSI, and other HEOSSI offerings may be included within the documented organisational or technical scope; they are not separate certificate holders. ISO/IEC 19790 applies only to specifically identified cryptographic modules or components.
Tentative target: Q4 2026 or Q1 2027, subject to funding. This is planning information, not a promised certification or completion date.
Real throughput · committed benchmark suite · reproducible by anyone
8833M post-quantum key agreements a day. Per core.
8833M post-quantum key agreements per day. Per core. That is 102k ML-KEM-768 encapsulations every second - measured on a single Apple M4 Max, committed to this repo, and reproducible from the public mirror with one npm command. In the 0.15 seconds it takes you to blink, that same core mints 16k keypairs. Post-quantum does not mean slow: the cryptography is not your bottleneck. Your approval queues are.
And the spread between the smallest and largest signature in the catalog is 519x (96 B vs 50k B). Moving between them is one allow-list entry in the tenant policy - not a rewrite.
Reproduce it yourself: /benchmarks carries the full methodology, and /api/sandbox/pqc-runtime runs live operations right now.
Harvest now, decrypt later
Your data already has a deadline.
Record a session today and an adversary can store it for years before spending a single quantum second on it. Whether a secret survives depends on when the cryptography protecting it was switched - not on when the attacker gets the machine.
Crypto agility, drawn
Swapping algorithms is a policy change. Not a migration project.
The same policy engine that rejects weak parameter sets accepts new ones the day NIST finalizes them - keys, TLS, tokens and audit chain all move together.
- Step 1Tenant policy editAllow-list the new parameter set, set the level floor, keep the old set during transition.
- Step 2KMS issues new PQC keysNew keys are generated under the updated policy; rotation cadence stays enforced.
- Step 3Edge enforces per requestPQC-TLS termination, PQC-signed tokens and algorithm validation all check the same policy.
- Step 4Audit chain signs the switchEvery policy change lands in the tamper-evident, PQC-signed audit trail.
Before you talk to anyone
The three objections, answered with evidence.
These are the questions every serious buyer asks. Each answer links to the artifact that settles it - no sales call required.
8833M ML-KEM-768 key agreements per day, per core, from the committed benchmark suite. The cryptography is not the bottleneck.
See the reproducible numbers →Both independent PQC providers run against the official NIST ACVP vectors - 435/435 and 240/240 passed, published with a SHA-3-256 tamper digest anyone can re-run.
Verify it yourself →Crypto inventory discovers what you already have across 36 inventory source types (11 cloud-vendor connector families), and algorithm swaps are tenant-policy changes - not rewrites.
Read the migration approach →Trust now, forge later
Signatures have a deadline too.
Harvest-now-decrypt-later is about data someone recorded. The other half of the quantum threat is about statements someone signed: the moment a cryptographically relevant quantum computer exists, every classical signature still standing becomes forgeable - including the ones binding your software supply chain, your TLS identity, and your audit evidence.
Code-signing certificates, SAML assertions, signed audit checkpoints, firmware images, contract records. Each one was meant to prove, years from now, that a specific act happened and was not altered. PQC migration is not finished when the keys are swapped - it is finished when everything still standing has been re-signed under a post-quantum key.
The US Department of War's CIO memorandum (October 2026) mandates PQC hardening across the department within five years and, notably, targets PQC against “trust now, forge later” attacks - not only harvest-now-decrypt-later. Its requirements also prohibit downgrading during migration, explicitly excluding pre-shared keys, symmetric key distribution and quantum key distribution as substitutes.
See the timeline and sources →Public assurance sandbox · no signup · no API key
Run live post-quantum operations before onboarding.
Execute fresh FIPS 203, FIPS 204, and FIPS 205 post-quantum operations from a public verification surface. Inspect generated key material, ciphertexts, signatures, verification status, timing data, and integrity checks before creating an account.
The sandbox uses the same pinned implementation family as QNSI's public SDKs and produces new outputs per request. Results are not precomputed, replayed, or served as canned examples.
Operations covered
- ML-KEM - key generation, encapsulation, decapsulation
- ML-DSA - key generation, signing, verification
- SLH-DSA - key generation, signing, verification
Evidence available
Live output · implementation version · algorithm identifiers · timing data · integrity status · conformance vectors · public SDK and integration source mirror · API route access.
Every request produces fresh verification output. Sandbox key material is generated for assurance testing only and must not be used in production systems. Conformance vectors verify deterministic implementation behavior against pinned library versions.
$ curl -s https://qnsi.heossi.com/api/sandbox/pqc-runtime | jq .
QNSI transition
From existing trust stack to QNSI-operated trust.
Already operating across cloud KMS, HSMs, Vault, certificates, secrets, storage, or legacy PKI? QNSI can assess your current trust stack, identify exposure, prioritise critical workloads, and guide transition into QNSI-operated security infrastructure. Every phase below maps to a real cloud-portal surface and a real backend service route.
Your existing trust stack
- 01Discover
Connect cloud accounts through 11 vendor connector families and deploy QNSI discovery agents into private networks. Inventory keys, secrets, certificates, TLS endpoints, hardware modules, and storage across 36 normalized source types.
- 02Map
Score quantum exposure per asset, generate a CycloneDX CBOM, identify deprecated algorithms still in use, and map controls against the regulatory frameworks that apply to your organisation.
- 03Prioritise
Define transition rules per workload class, draft compliance policies, and produce migration plans that sequence assets by data-lifetime risk, blast radius, and audit obligation.
- 04Transition
Source defines dry-run and cutover modes plus BYOK and qualified BYOH coexistence. Complete migration effects and audit-chain coverage remain NOT VERIFIED and must be proven from returned reconciliation evidence.
- 05Operate
Continuous drift-control validation, automated key-compromise response, attack-path analysis, and evidence for ISO/IEC 27001:2022, ISO/IEC 42001:2023, and ISO/IEC 19790:2025 assessments.
QNSI-operated security infrastructure
Post-quantum KMS · encrypted vault · PQC-native storage · vector search · tamper-evident audit chain · access control · identity federation · hardware enclaves · AI workload security · multi-cloud crypto-posture · compliance evidence - operated across cloud, VPC, on-premises, air-gapped, and sovereign deployment models.
Every portal path above resolves in the QNSI cloud portal at cloud.qnsi.heossi.com. Backend services that implement the transition flow: crypto-inventory-service (23 routes), kms-service (BYOK · BYOH · rotation), and security-monitoring-service (continuous ops). Public SDKs and integration examples are independently verifiable at the public SDK and integration source mirror at github.com/heossihq/qnsi-public.
Technical integration
Integrate through standard runtimes and APIs.
QNSI is consumed through package managers and runtimes technical teams already use. One package per language, one shared OpenAPI surface, one activation call. Start on Free Forever, then carry the same integration path into cloud, VPC, sovereign, on-premises, or air-gapped deployment.
Swift (iOS / macOS)
.package(url: "https://github.com/heossihq/qnsi-public.git", exact: "0.1.0")Same wire contracts
All runtimes call the same OpenAPI surface with identical request/response shapes, error codes, and algorithm identifiers.
One activation path
Self-service activation registers against the Free Forever production tier. Enterprise deployments use the same integration model.
No proprietary build pipeline
Standard package managers, registries, versioning, and CI/CD workflows. No bespoke compiler, vendored toolchain, or custom build system required.
Standards-based evaluation
REST · OpenAPI · JWT · API keys · public registries · SBOM-friendly releases · public source mirror
Self-service activation is free and instant. No credit card required. Same integration path carries into enterprise deployment.
Sectors served
Designed for high-consequence sectors.
QNSI supports organisations where cryptographic failure, exposed secrets, weak audit trails, or long-life data compromise can create operational, financial, regulatory, or national-security risk.
Government & sovereign systems
Protect citizen data, sovereign cloud workloads, inter-agency systems, classified-adjacent records, and long-life archives with post-quantum key management, encrypted storage, policy controls, and audit evidence.
Protects
- ·citizen records
- ·digital identity systems
- ·inter-agency data sharing
- ·long-retention public-sector archives
- ·regulated procurement evidence
Deployment: sovereign · VPC · on-prem · air-gapped
Explore use cases →Defence & military
Secure mission systems, operational data, command workflows, signing operations, and sensitive communications where confidentiality, integrity, and long-term cryptographic resilience are non-negotiable.
Protects
- ·mission data protection
- ·defence supply-chain trust
- ·secure signing workflows
- ·operational audit trails
- ·long-life classified-adjacent data
Deployment: air-gapped · sovereign · on-prem
Explore use cases →Banks & financial institutions
Protect payment systems, customer records, transaction evidence, signing workflows, vault secrets, and long-life regulated data with quantum-native security infrastructure.
Protects
- ·payment infrastructure
- ·customer PII
- ·transaction signing
- ·audit evidence
- ·secrets and key governance
- ·long-retention compliance data
Critical infrastructure
Protect energy, telecom, transport, water, healthcare, and industrial systems where cryptographic failure can create physical-world disruption, operational downtime, or national resilience risk.
Protects
- ·OT/IT trust boundaries
- ·infrastructure control-plane secrets
- ·telemetry protection
- ·vendor access controls
- ·incident evidence
Deployment: sovereign · VPC · on-prem · air-gapped
Explore use cases →Enterprises
Consolidate keys, secrets, storage protection, audit evidence, access control, and crypto-posture across business units, cloud estates, applications, and regulated data environments.
Protects
- ·multi-cloud key governance
- ·secrets sprawl
- ·application encryption
- ·access policy what-if analysis
- ·internal audit evidence
- ·vendor-risk response
AI companies
Protect model pipelines, embeddings, training data, inference workloads, prompt surfaces, model registries, and AI audit trails with trust controls built for high-value AI systems.
Protects
- ·model registry protection
- ·prompt-injection monitoring
- ·training-data protection
- ·vector search security
- ·inference audit trails
- ·confidential AI workloads
Sensitive-data platforms
Secure SaaS platforms, data rooms, healthcare systems, legal workflows, research platforms, and regulated applications that store, process, or exchange high-value sensitive data.
Protects
- ·encrypted customer data
- ·tenant isolation
- ·regulated file storage
- ·signed audit trails
- ·API security
- ·customer evidence packs
Healthcare & life sciences
Protect patient records, clinical workflows, research data, genomic datasets, regulated file exchange, and long-retention medical archives.
Protects
- ·patient records
- ·clinical systems
- ·research data
- ·regulated exchange
Telecom, cloud & digital infrastructure
Protect network trust, platform control planes, customer data, service credentials, edge workloads, and infrastructure audit evidence.
Protects
- ·control-plane secrets
- ·edge workloads
- ·service credentials
- ·customer data
Organized for executives, security leaders, architects, engineers, risk teams, and procurement.
Live platform
Live infrastructure. Public service health.
QNSI Cloud exposes live production service health for its public AWS-hosted control plane. Private, sovereign, VPC, on-premises, and air-gapped deployments are monitored through deployment-specific status and observability endpoints.
Control plane
Authentication, tenancy, billing, entitlement checks, policy enforcement, and access-control services are monitored through the public status surface.
Data plane
KMS, vault, storage, search, audit, and AI orchestration services publish health independently so operational issues are visible by capability.
Dedicated deployments
VPC, sovereign, on-premises, and air-gapped deployments use dedicated status and observability endpoints separate from QNSI Cloud.
Public health endpoints show externally exposed QNSI Cloud service checks. Internal production services and dedicated deployments are monitored through private observability and deployment-specific status endpoints.
AWS and AWS region names are referenced for deployment-location clarity only and do not imply endorsement or affiliation.
QNSI Cloud Public Health Surface
Checking live service status...
Ready to evaluate quantum-native security infrastructure?
Start with Free Forever, review public assurance evidence, or speak with an architect about sovereign, VPC, on-premises, and air-gapped deployments.
Free Forever · developer plans from $150/month · enterprise + sovereign deployments custom-priced · see all plans →