# QNSI - Quantum-Native Security Infrastructure (Full Corpus)

> Produced by HEOSSI (PTE.) LTD, Singapore. Source of truth for QNSI product, architecture, cryptographic guarantees, SDK surface, compliance posture, and pricing. Last updated: 2026-10-13.

## One-paragraph summary

QNSI is an enterprise post-quantum security platform that combines NIST-standardized post-quantum cryptography, infrastructure and local source-code discovery, governed migration contracts, HSM-Sealed Post-Quantum Keys (HSPK), encrypted-data architecture, secure-AI controls, and tamper-evident evidence contracts. Public capability pages state which surfaces are live, source-implemented, deployment-qualified, or roadmap and preserve the exact evidence boundary. It is produced by HEOSSI (PTE.) LTD, a Singapore-incorporated deep-tech company. First-party SDKs ship one package per language - @heossihq/qnsi (npm/TypeScript, including the qnsi CLI and browser subpath), qnsi (PyPI/Python), Go, Rust, and JVM/Android - sharing the same wire contracts; @heossihq/qnsi-mcp 0.4.0 exposes 28 tenant-scoped tools.

## Public product capability areas

- [Cryptographic Discovery & Inventory](https://qnsi.heossi.com/platform/crypto-inventory): Find cryptographic dependencies across cloud infrastructure, hosts, TLS endpoints, certificates, secret managers, Kubernetes, repositories, and imported inventories. Status: Source-backed · deployment evidence required. Evidence boundary: Connector, local-scanning, normalization, classification, checkpoint, and export contracts exist in source. Complete estate coverage, classification accuracy, connector execution, and deployment-specific behavior remain NOT VERIFIED unless linked evidence says otherwise.
- [Post-Quantum Key Management & Custody](https://qnsi.heossi.com/platform/key-management): Govern key creation, rotation, signing, verification, wrapping, import, policy, and qualified customer-managed custody from one tenant-scoped control surface. Status: Source-backed · qualified paths identified. Evidence boundary: KMS routes, policy contracts, BYOK, rotation, signing, wrapping, and eight capability-gated custody connectors exist in source. Complete route execution and platform-wide enforcement remain NOT VERIFIED. The current escrow route is not threshold recovery and is not presented as available.
- [Quantum-Safe Secrets Management](https://qnsi.heossi.com/platform/secrets-management): Manage secret versions, rotation, dynamic credentials, leakage findings, access policy, and audit context behind a consistent tenant boundary. Status: Source-backed · end-to-end envelope path not verified. Evidence boundary: Secret CRUD, version, rotation, dynamic-secret, and leakage-detection routes exist in source and portal surfaces. Genuine ML-KEM envelope migration and complete production execution are NOT VERIFIED.
- [Encrypted Storage & Search](https://qnsi.heossi.com/platform/encrypted-data): Combine governed object storage, retention and replication controls with full-text and vector-search contracts designed for confidential data workflows. Status: Source-backed · cryptographic execution boundary not verified. Evidence boundary: Storage, upload, version, retention, replication, classification, indexing, full-text, and vector-search routes exist in source and portal surfaces. End-to-end searchable-encryption guarantees, plaintext boundaries, and genuine PQC envelope execution remain NOT VERIFIED.
- [Identity, Access & Workload Trust](https://qnsi.heossi.com/platform/identity-access): Apply tenant-scoped identity, authentication, entitlement, policy-decision, quota, JIT access, simulation, federation, and workload-identity controls. Status: Source-backed · deployment effectiveness not verified. Evidence boundary: Authentication, access-control, PDP, quota, tenant, federation, JIT, simulation, and agent-identity routes exist in source. Complete policy coverage, provider configuration, and deployment-specific enforcement remain NOT VERIFIED.
- [AI Security & Confidential Compute](https://qnsi.heossi.com/platform/ai-security): Protect model, prompt, agent, training, inference, and event-intelligence workflows with explicit identity, policy, provenance, enclave, and operator-approval boundaries. Status: Source-backed · production attestation not verified. Evidence boundary: AI orchestration, model registry, prompt-injection, bias, governance, correlation, root-cause, and remediation-proposal routes exist in source. Production enclave attestation, model behavior, detection effectiveness, and end-to-end automated enforcement remain NOT VERIFIED. Remediation proposals do not bypass authorization or operator approval.
- [Security Operations & Cryptographic Response](https://qnsi.heossi.com/platform/security-operations): Connect cryptographic posture, findings, attack paths, certificate lifecycle, key-compromise response, SIEM delivery, webhooks, and approval-aware response workflows. Status: Source-backed · response execution requires evidence. Evidence boundary: Findings, alerts, breach, attack-path, certificate, SIEM, webhook, key-compromise, policy, and remediation-rule routes exist in source. Detection completeness, causal attribution, response effects, and deployment-specific execution remain NOT VERIFIED.
- [Tamper-Evident Audit & Assurance Evidence](https://qnsi.heossi.com/platform/audit-evidence): Preserve service events, cryptographic context, retention policy, signed checkpoints, streaming, evidence packs, and replay-oriented verification boundaries. Status: Source-backed · complete event coverage not verified. Evidence boundary: Audit ingestion, chaining, checkpoint signing, retention, streaming, reporting, and evidence-pack contracts exist in source. Complete service-event coverage, checkpoint publication, replay, and independent production verification remain NOT VERIFIED.
- [Observability, SLOs & Operational Intelligence](https://qnsi.heossi.com/platform/observability): Bring service health, metrics, traces, logs, SLOs, anomalies, costs, security context, and deployment-specific evidence into one operational view. Status: Live portal surface · data depends on connected telemetry. Evidence boundary: The portal fetches live observability and related security-monitoring APIs and explicitly represents unknown or unavailable data. Dashboard presence does not prove service availability, SLO attainment, complete telemetry, or corrective action.
- [Developer Platform & Secure Delivery](https://qnsi.heossi.com/platform/developer-security): Integrate QNSI through first-party SDKs, REST, CLI, MCP, WebSockets, browser patterns, source scanning, code signing, and secure build-pipeline surfaces. Status: Published SDKs · operation support varies by service. Evidence boundary: TypeScript, Python, Rust, JVM/Android, Go, and MCP distribution surfaces are published or documented. Package availability does not prove every SDK method, backend route, cryptographic effect, audit effect, or deployment behavior.
- [Deployment, Isolation & Resilience](https://qnsi.heossi.com/platform/deployment-resilience): Define the network, tenancy, region, compute, custody, observability, continuity, and operational boundaries for QNSI Cloud or a customer-specific deployment. Status: Cloud live · dedicated topologies are engagement-specific. Evidence boundary: QNSI Cloud is the current public service. Private VPC, on-premises, air-gapped, sovereign, isolated-tenancy, failover, GPU, and customer-custody patterns are engagement-specific architecture options. They are not generally available or proven for a customer until provisioned, tested, evidenced, and contractually scoped.

## Buyer and operator use-case catalog

QNSI publishes 100 distinct evaluation scenarios across 25 sectors at https://qnsi.heossi.com/use-cases. Each page names an accountable owner, operational pain, trigger, QNSI contribution, decision artifact, validation boundary, and primary sources. A catalog entry is not proof that a named deployment, regulatory outcome, or control has completed.

### Complete catalog

- [Map cryptography across a bank payment rail before migration](https://qnsi.heossi.com/use-cases/bank-payment-rail-cryptography-inventory): Which payment services can move first without breaking clearing, fraud, or settlement dependencies?
- [Rehearse an HSM-backed signing-key rollover without payment downtime](https://qnsi.heossi.com/use-cases/bank-hsm-signing-key-rollover): Can old and new signing trust coexist long enough to rotate safely across every payment participant?
- [Introduce hybrid post-quantum protection at an open-banking API boundary](https://qnsi.heossi.com/use-cases/open-banking-api-hybrid-pqc): Where can quantum-resistant handshakes be introduced while legacy aggregators still require classical interoperability?
- [Assemble cryptographic evidence for a bank cyber-incident materiality decision](https://qnsi.heossi.com/use-cases/bank-cyber-incident-materiality-evidence): What cryptographic assets, data paths, and business services were affected, and when was that known?
- [Separate digital-asset custody approval from signing execution](https://qnsi.heossi.com/use-cases/digital-asset-custody-signing-policy): Which people, services, thresholds, and key stores may authorize each class of asset movement?
- [Design a recoverable wallet-key lifecycle without creating a master-key shortcut](https://qnsi.heossi.com/use-cases/wallet-recovery-key-lifecycle): How can the service recover from device loss or operator unavailability without introducing an ungoverned universal recovery secret?
- [Contain fintech partner API credentials by product and counterparty](https://qnsi.heossi.com/use-cases/fintech-partner-api-key-isolation): Can one compromised integration credential be prevented from reaching every product, ledger, and partner?
- [Preserve authenticity of stablecoin reserve and reconciliation reports](https://qnsi.heossi.com/use-cases/stablecoin-reserve-report-signatures): Can a reviewer prove which system produced each reserve snapshot and whether the file changed after approval?
- [Prioritize quantum exposure in life-policy archives](https://qnsi.heossi.com/use-cases/insurer-policy-archive-quantum-exposure): Which policy, medical, beneficiary, and actuarial records remain sensitive beyond the life of today's public-key protection?
- [Prove the integrity of claims evidence from intake to settlement](https://qnsi.heossi.com/use-cases/claims-document-signature-integrity): Can the insurer distinguish an original claimant artifact from later transformation, annotation, or fraud-review output?
- [Measure cryptographic concentration across an insurer's SaaS estate](https://qnsi.heossi.com/use-cases/insurer-saas-cryptographic-concentration): Which critical business processes depend on the same certificate authority, cloud KMS, identity provider, or unsupported algorithm?
- [Replace a PQC underwriting checkbox with measurable evidence](https://qnsi.heossi.com/use-cases/cyber-insurance-pqc-underwriting-evidence): Has the applicant identified material cryptographic exposure and funded a credible transition, or only adopted a policy statement?
- [Find ungoverned cryptography around a hospital's ePHI](https://qnsi.heossi.com/use-cases/hospital-ephi-cryptography-discovery): Where is ePHI encrypted, signed, transmitted, or left dependent on unknown cryptographic components?
- [Transition medical-device PKI without interrupting clinical care](https://qnsi.heossi.com/use-cases/hospital-medical-device-pki-transition): Which device cohorts can accept new certificates or algorithms, and which require compensating controls until replacement?
- [Evaluate customer-managed key custody for a healthcare cloud workload](https://qnsi.heossi.com/use-cases/health-cloud-customer-key-custody): Does customer-managed custody materially reduce risk without making recovery or clinical availability fragile?
- [Determine cryptographic scope during a healthcare breach](https://qnsi.heossi.com/use-cases/health-breach-crypto-scope): Was compromised ePHI actually protected, were relevant keys exposed, and which records fall inside the incident boundary?
- [Qualify post-quantum signing for medical-device secure boot](https://qnsi.heossi.com/use-cases/medical-device-secure-boot-signing): Can the boot chain verify a new signature scheme within memory, timing, safety, and update constraints?
- [Bind a medical-device SBOM to the exact released firmware](https://qnsi.heossi.com/use-cases/medical-device-sbom-signature-chain): Can a hospital or assessor verify that the SBOM, vulnerability status, and firmware image describe the same release?
- [Rotate field-update trust on devices that cannot all reconnect](https://qnsi.heossi.com/use-cases/medical-device-field-update-trust): How can offline or intermittently connected devices learn a new update key without accepting an attacker-controlled root?
- [Build the cryptography section of a medical-device premarket file](https://qnsi.heossi.com/use-cases/medical-device-premarket-crypto-file): Is every cryptographic claim connected to a design requirement, implementation, verification result, and residual risk?
- [Keep clinical-trial signatures verifiable through the study lifecycle](https://qnsi.heossi.com/use-cases/clinical-trial-data-signature-longevity): Will consent, source-data, analysis, and submission signatures remain attributable and verifiable years after systems change?
- [Give laboratory instruments distinct, rotatable machine identities](https://qnsi.heossi.com/use-cases/laboratory-instrument-machine-identity): Can each instrument authenticate without shared credentials that outlive ownership or calibration status?
- [Prioritize harvest-now-decrypt-later risk in drug-discovery data](https://qnsi.heossi.com/use-cases/pharma-research-ip-quantum-risk): Which target, compound, genomic, and partnership datasets retain economic value past current encryption assumptions?
- [Prove provenance of transformed regulated laboratory records](https://qnsi.heossi.com/use-cases/regulated-lab-record-provenance): Can an inspector follow a result from instrument output through parsing, normalization, review, and final report?
- [Pilot a dual-stack post-quantum PIV migration](https://qnsi.heossi.com/use-cases/government-piv-dual-stack-migration): How can new credentials and services be tested without locking out users or breaking relying applications?
- [Require a cryptographic bill of materials in government procurement](https://qnsi.heossi.com/use-cases/government-procurement-cryptographic-bom): Does a proposed product expose enough algorithm, library, certificate, and key-custody detail to plan future transition?
- [Protect citizen records with confidentiality horizons longer than system life](https://qnsi.heossi.com/use-cases/government-citizen-record-confidentiality): Which identity, tax, health, benefits, and justice records need protection beyond the next platform replacement?
- [Transition cryptographic trust across an interagency API](https://qnsi.heossi.com/use-cases/interagency-api-trust-transition): Which agency owns issuer trust, version negotiation, revocation, and failure response when algorithms change?
- [Scope a CNSA 2.0 transition for a national-security system](https://qnsi.heossi.com/use-cases/defense-cnsa-system-inventory): Which mission components, interfaces, and data lifetimes fall inside the transition boundary?
- [Test post-quantum interoperability for a coalition mission network](https://qnsi.heossi.com/use-cases/defense-coalition-crypto-interoperability): Can partners negotiate approved protection without exposing the mission to silent downgrade or incompatible credentials?
- [Modernize signing for defense software delivered into disconnected enclaves](https://qnsi.heossi.com/use-cases/defense-software-release-signing): How will an offline enclave verify the release, signer authority, dependency evidence, and revocation state?
- [Challenge a defense supplier's cryptographic assurance claims](https://qnsi.heossi.com/use-cases/defense-supplier-crypto-attestation): Which supplier claims are independently evidenced, configuration-specific, inherited, or still unqualified?
- [Prove tenant separation in a multi-tenant cloud key service](https://qnsi.heossi.com/use-cases/cloud-tenant-kms-separation): Can an operator, software defect, or compromised tenant cross the intended cryptographic boundary?
- [Make service-mesh certificate rotation measurable before PQC change](https://qnsi.heossi.com/use-cases/service-mesh-certificate-agility): Can every workload receive, activate, validate, and retire new trust without hidden static certificates?
- [Prevent a data-centre certificate expiry from becoming a regional outage](https://qnsi.heossi.com/use-cases/data-centre-certificate-expiry-response): Which internal and external services depend on the expiring chain, and can replacement be rolled back safely?
- [Prepare incident evidence for a Singapore foundational digital infrastructure operator](https://qnsi.heossi.com/use-cases/singapore-fdi-incident-evidence): Can the operator rapidly identify affected cryptographic services, supplied functions, customers, and containment actions?
- [Create the cryptography evidence index for a CRA product technical file](https://qnsi.heossi.com/use-cases/cra-product-technical-file-cryptography): Can every material cryptographic design claim be traced to implementation, test evidence, lifecycle support, and residual risk?
- [Connect a product cryptography incident to the CRA reporting clock](https://qnsi.heossi.com/use-cases/cra-vulnerability-reporting-workflow): Does an exploited vulnerability or severe incident meet reporting criteria, and what is known at each deadline?
- [Give SaaS customers verifiable release-signing provenance](https://qnsi.heossi.com/use-cases/saas-release-signing-provenance): Can a customer verify which build produced an artifact and which authorized identity approved it?
- [Find hidden cryptography in a SaaS dependency graph](https://qnsi.heossi.com/use-cases/saas-dependency-crypto-inventory): Which libraries, runtimes, services, and managed dependencies will block a cryptographic transition?
- [Inventory PKI dependencies across 5G network functions](https://qnsi.heossi.com/use-cases/telecom-5g-network-function-pki): Which network functions, vendors, and interfaces depend on shared trust anchors or non-agile certificate profiles?
- [Plan long-lived signature agility for eSIM provisioning](https://qnsi.heossi.com/use-cases/telecom-esim-provisioning-signatures): How will profile-signing and trust anchors evolve across devices that remain deployed for a decade?
- [Reduce long-term quantum exposure in telecom subscriber records](https://qnsi.heossi.com/use-cases/telecom-cpni-archive-quantum-risk): Which call-detail, location, account, and network records remain sensitive long enough to justify early re-protection?
- [Verify network-function software before carrier rollout](https://qnsi.heossi.com/use-cases/telecom-network-software-signing): Does the candidate image originate from the approved vendor build and match the tested configuration?
- [Map cryptography between grid control centres and substations](https://qnsi.heossi.com/use-cases/grid-control-centre-crypto-inventory): Which operational links and devices can migrate, and which must be isolated until replacement?
- [Rotate substation device certificates inside narrow outage windows](https://qnsi.heossi.com/use-cases/substation-device-certificate-rollover): Can relay, gateway, and engineering trust change without creating a protection or visibility gap?
- [Test cryptographic key recovery during a grid blackstart scenario](https://qnsi.heossi.com/use-cases/grid-blackstart-key-recovery): Can essential operators and systems recover credentials when normal identity, network, and key services are unavailable?
- [Constrain supplier remote-access trust in electric operations](https://qnsi.heossi.com/use-cases/grid-supplier-remote-access-trust): Which supplier identity can reach which asset, for what task, using which credential and approval?
- [Inventory cryptographic trust in pipeline remote access](https://qnsi.heossi.com/use-cases/pipeline-remote-access-cryptography): Which human and machine credentials can cross from enterprise access paths into operational pipeline systems?
- [Verify firmware before it reaches a pipeline controller](https://qnsi.heossi.com/use-cases/pipeline-controller-firmware-signing): Can field staff prove that a controller image is authentic, approved, and compatible before installation?
- [Control identity over the lifetime of remote oilfield sensors](https://qnsi.heossi.com/use-cases/oilfield-sensor-identity-lifecycle): How will each sensor authenticate, rotate trust, and be retired when physical access is costly?
- [Produce a pipeline cyber-incident evidence pack during operations](https://qnsi.heossi.com/use-cases/pipeline-cyber-incident-regulatory-pack): Which operational assets and cryptographic controls were affected, and what containment is safe while product continues to move?
- [Establish a cryptographic baseline for a water SCADA network](https://qnsi.heossi.com/use-cases/water-scada-crypto-baseline): Where does cryptography protect control, telemetry, engineering, and business interfaces-and where is it absent?
- [Rotate certificates on remote water PLC gateways](https://qnsi.heossi.com/use-cases/water-remote-plc-certificate-rotation): Can trust be replaced across unmanned sites without losing telemetry or control?
- [Recover treatment-system keys during a flood or facility loss](https://qnsi.heossi.com/use-cases/water-disaster-key-recovery): Can an alternate control location authenticate and decrypt essential systems when the primary site is inaccessible?
- [Expire vendor cryptographic access after water-system maintenance](https://qnsi.heossi.com/use-cases/water-vendor-connection-governance): Does each vendor credential terminate when the approved service task ends?
- [Use machine identity to enforce factory-cell boundaries](https://qnsi.heossi.com/use-cases/factory-machine-identity-segmentation): Can a machine authenticate only to the controllers, brokers, and services required for its production role?
- [Verify robot firmware and configuration before a line restart](https://qnsi.heossi.com/use-cases/factory-robot-firmware-provenance): Does the robot image match the approved safety-tested build and cell configuration?
- [Protect the integrity of data feeding a manufacturing digital twin](https://qnsi.heossi.com/use-cases/digital-twin-data-integrity): Can planners identify which sensors, transformations, and models produced a decision-driving analytical output?
- [Find certificate concentration across an OEM supplier network](https://qnsi.heossi.com/use-cases/manufacturing-supplier-certificate-risk): Which products and factories depend on a supplier root, signing service, or unsupported crypto library?
- [Transition vehicle OTA signing across mixed model years](https://qnsi.heossi.com/use-cases/automotive-ota-signing-transition): Which vehicles can verify a new signing scheme, and how will older fleets receive trusted updates?
- [Measure PKI agility for vehicle-to-everything communications](https://qnsi.heossi.com/use-cases/vehicle-v2x-pki-agility): Can vehicles and roadside units adopt new certificate and signature profiles without losing safety-message interoperability?
- [Replace shared vehicle diagnostic credentials with accountable identities](https://qnsi.heossi.com/use-cases/vehicle-diagnostic-access-identity): Which technician, tool, and service action is authorized for a specific vehicle and time window?
- [Trace cryptographic evidence through automotive tier suppliers](https://qnsi.heossi.com/use-cases/automotive-tier-supplier-crypto-evidence): Which supplier component introduces each algorithm, key, certificate, or software signer into the vehicle?
- [Map cryptography across vessel-to-shore communications](https://qnsi.heossi.com/use-cases/vessel-shore-communications-crypto-map): Which satellite, radio, VPN, identity, and application paths protect operational and commercial data?
- [Verify navigation-data updates before bridge installation](https://qnsi.heossi.com/use-cases/ship-navigation-update-signing): Can bridge staff prove the update source, content, approval, and target system while offline?
- [Assign rotatable identities to port cranes and gate systems](https://qnsi.heossi.com/use-cases/port-ot-machine-identity): Can each crane, gate, scanner, and control service be authenticated without shared terminal credentials?
- [Preserve signature provenance for electronic cargo documents](https://qnsi.heossi.com/use-cases/cargo-document-signature-provenance): Can parties prove who issued, endorsed, transformed, and presented each cargo record?
- [Verify the signing chain for aircraft-loadable software](https://qnsi.heossi.com/use-cases/aircraft-software-signing-chain): Does each loadable part originate from an approved configuration and authorized release identity?
- [Inventory certificates across airport operational technology](https://qnsi.heossi.com/use-cases/airport-ot-certificate-inventory): Which safety or continuity functions share issuers, expired trust, or unmanaged vendor certificates?
- [Prove integrity of digital aircraft maintenance records](https://qnsi.heossi.com/use-cases/aviation-maintenance-record-integrity): Can a reviewer establish who created, changed, approved, and transferred each maintenance record?
- [Modernize identity trust across an airline partner ecosystem](https://qnsi.heossi.com/use-cases/airline-identity-federation-agility): How can crew, ground handlers, alliance partners, and contractors authenticate without permanent overbroad federation?
- [Stage a PKI transition for rail signalling support systems](https://qnsi.heossi.com/use-cases/rail-signalling-pki-transition): Which support, management, and communications components can change trust without affecting safe train movement?
- [Rotate fare-system keys across gates, validators, and mobile wallets](https://qnsi.heossi.com/use-cases/transit-fare-payment-key-lifecycle): Can new keys become active across every channel without rejecting riders or extending old trust indefinitely?
- [Sign rail maintenance work orders at safety-critical handoffs](https://qnsi.heossi.com/use-cases/rail-maintenance-work-order-signing): Can the operator prove which technician completed, inspected, and released work on a specific asset?
- [Time-bound supplier remote diagnostics for rolling stock](https://qnsi.heossi.com/use-cases/rail-supplier-remote-diagnostics): Can a supplier diagnose one fleet subsystem without retaining access to other trains or depots?
- [Enroll unique identities for a citywide sensor fleet](https://qnsi.heossi.com/use-cases/smart-city-device-identity-enrollment): Can each camera, meter, light, and environmental sensor be traced to an authorized manufacturing and enrollment event?
- [Prove secure communications from constrained devices through an IoT gateway](https://qnsi.heossi.com/use-cases/iot-gateway-secure-communications): Where does end-to-end protection terminate, and which gateway can see or modify device data?
- [Rollover OTA signing trust across a fragmented IoT fleet](https://qnsi.heossi.com/use-cases/iot-fleet-ota-key-rollover): Which deployed devices can learn a new signer before the current key or algorithm becomes unsafe?
- [Align IoT cryptographic support with the promised support period](https://qnsi.heossi.com/use-cases/iot-support-period-crypto-evidence): Can the manufacturer maintain keys, certificates, libraries, and update trust for the whole declared support period?
- [Classify quantum exposure in lifetime student records](https://qnsi.heossi.com/use-cases/university-student-record-quantum-risk): Which transcripts, identity, disability, conduct, and financial records remain sensitive for decades?
- [Preserve provenance across a multi-university research consortium](https://qnsi.heossi.com/use-cases/research-consortium-data-provenance): Can collaborators prove which institution, instrument, pipeline, and researcher produced each dataset version?
- [Rotate federation signing keys across campus and research services](https://qnsi.heossi.com/use-cases/campus-federated-identity-key-rotation): Which relying services will reject a new federation signer, and how quickly can stale metadata be corrected?
- [Authenticate data from shared scientific instruments](https://qnsi.heossi.com/use-cases/research-instrument-signing-identity): Can a result be attributed to the correct instrument, configuration, operator, and acquisition session?
- [Keep signed legal evidence verifiable after algorithms and firms change](https://qnsi.heossi.com/use-cases/law-firm-evidence-signature-longevity): What must be preserved so a future reviewer can validate signer authority and document integrity?
- [Prioritize harvest-now-decrypt-later exposure in client archives](https://qnsi.heossi.com/use-cases/law-firm-client-archive-hndl): Which privileged matters retain strategic, personal, or commercial sensitivity beyond current public-key protection?
- [Evaluate customer-controlled keys for a transaction deal room](https://qnsi.heossi.com/use-cases/deal-room-customer-key-boundary): Can the client revoke provider access without making the deal room unrecoverable during a transaction?
- [Sign forensic evidence at every custody handoff](https://qnsi.heossi.com/use-cases/forensic-chain-of-custody-signing): Can every acquisition, copy, analysis, export, and transfer be linked to an authorized actor and unchanged content?
- [Find cryptography that actually touches a retailer's card-data environment](https://qnsi.heossi.com/use-cases/retail-card-data-crypto-inventory): Which terminals, gateways, token services, applications, and vendors are inside or connected to the cryptographic scope?
- [Verify point-of-sale firmware before store deployment](https://qnsi.heossi.com/use-cases/pos-firmware-signing-provenance): Does each terminal image come from the authorized vendor release and match the approved device model?
- [Assess quantum exposure in loyalty and customer-profile data](https://qnsi.heossi.com/use-cases/retail-loyalty-data-quantum-risk): Which behavior, identity, location, and preference records remain exploitable long after collection?
- [Contain seller-app credentials in an ecommerce marketplace](https://qnsi.heossi.com/use-cases/marketplace-seller-app-credential-isolation): Can one compromised seller application be prevented from reading other merchants, orders, payouts, or customer data?
- [Sign media provenance from capture through publication](https://qnsi.heossi.com/use-cases/media-content-provenance-signing): Can audiences and partners verify which device, editor, and publishing system produced an asset?
- [Preserve authenticity of a broadcast archive across format migration](https://qnsi.heossi.com/use-cases/broadcast-archive-signature-preservation): Can the archive prove an asset's origin and editorial state after storage and codec migrations?
- [Protect confidential newsroom sources against future decryption](https://qnsi.heossi.com/use-cases/newsroom-source-confidentiality-horizon): Which communications and source records remain dangerous if captured now and decrypted years later?
- [Rotate streaming distribution keys without blacking out licensed audiences](https://qnsi.heossi.com/use-cases/streaming-distribution-key-rotation): Can origin, CDN, packager, player, and partner trust change within rights and availability constraints?
- [Verify an AI model artifact before production loading](https://qnsi.heossi.com/use-cases/ai-model-artifact-signing): Does the model match the approved training run, evaluation, code, and release authority?
- [Trace training data from source agreement to model run](https://qnsi.heossi.com/use-cases/ai-training-data-provenance): Which dataset version, license, transformation, and approval contributed to a specific model?
- [Protect integrity of logs supporting a high-risk AI review](https://qnsi.heossi.com/use-cases/high-risk-ai-log-integrity): Can reviewers trust the model version, input context, human intervention, and output recorded for each consequential decision?
- [Govern credentials used by autonomous AI agents](https://qnsi.heossi.com/use-cases/ai-agent-credential-lifecycle): Which agent instance may call which tool, with what credential, data boundary, and expiration?

## Commercial engagement options

- [PQC Readiness Assessment](https://qnsi.heossi.com/services/pqc-readiness-assessment): Create a defensible cryptographic inventory, prioritize quantum exposure, and leave with an evidence-backed migration roadmap. Commercial model: Fixed scope and written quotation after a no-cost scoping call.
- [30-90 Day PQC Migration Pilot](https://qnsi.heossi.com/services/pqc-migration-pilot): Move one bounded workload from discovery through governed hybrid or PQC cutover, with rollback, reconciliation, and evidence. Commercial model: Milestone-based written quotation after technical scoping.
- [Enterprise QNSI Platform](https://qnsi.heossi.com/services/enterprise-qnsi-platform): Deploy QNSI as the control plane for cryptographic discovery, governed migration, key and secret operations, and verifiable evidence. Commercial model: Subscription and implementation scope defined in a written order form; public cloud, private, sovereign, and air-gapped options.

## Platform service inventory

The repository contains 18 manifest-declared services: 16 proxied application services, the edge
gateway, and the infrastructure provisioner. Manifest presence proves source inventory, not route
reachability, production deployment, complete policy coverage, cryptographic execution, or
control effectiveness. The public capability pages above are the canonical buyer-facing
interpretation of this inventory.

## Cryptographic boundaries

- Standardized algorithms: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). FN-DSA/Falcon remains draft and is not represented as finalized.
- Catalog: 90 algorithms across 14 families form a software migration and interoperability surface, not a claim that every algorithm executes in every live service or HSM.
- Transition: optional classical-plus-PQC compositions may be used at explicitly selected interoperability boundaries. Production negotiation requires observed deployment evidence.
- Bulk cryptography: AES-256-GCM and other symmetric constructions remain dependent on genuine key establishment or wrapping, nonce handling, policy, and the exact service path.
- HSM: six PKCS#11 connector implementations and two REST custody adapters exist. A named device, operation, configuration, firmware, and certificate scope become supported only after qualification.
- HSPK: QNSI performs ML-DSA in software while the qualified HSM performs RSA-OAEP custody. The software ML-DSA operation does not inherit the HSM module's validation.
- Escrow: the current route is not M-of-N threshold recovery and is not presented as available.

## NIST ACVP conformance evidence

QNSI runs the OFFICIAL NIST ACVP test vectors (mirrored from usnistgov/ACVP-Server gen-val/json-files via paulmillr/acvp-vectors) against its @noble/post-quantum implementation on every build. Current state:

QNSI ships TWO independent PQC providers and runs the same NIST ACVP vector suite against each:

**Provider 1 - @noble/post-quantum (pure-JS reference, cross-verification secondary):**
- 435 / 435 ACVP test cases passed, 0 failed, 0 skipped - 100% pass rate
- FIPS 203 ML-KEM keyGen: 75/75 (ML-KEM-512/768/1024)
- FIPS 203 ML-KEM encapDecap: 165/165 - encapsulation AFT (75/75), decapsulation VAL (30/30), encapsulationKeyCheck (30/30 - FIPS 203 §7.2 modulus + length), decapsulationKeyCheck (30/30 - FIPS 203 §7.3 H(ek) hash + length)
- FIPS 204 ML-DSA keyGen: 75/75 (ML-DSA-44/65/87)
- FIPS 205 SLH-DSA keyGen: 120/120 - all 12 parameter sets (SHA2/SHAKE × {128,192,256} × {f,s})

**Provider 2 - @heossihq/liboqs-native 0.16.0 (native-C, primary production engine across every QNSI backend service):**
- 240 / 240 ACVP test cases passed across every ML-KEM operation NIST defines (100% of the addressable surface)
- FIPS 203 ML-KEM keyGen: 75/75 pass - via OQS_KEM_keypair_derand bound in the native addon
- FIPS 203 ML-KEM encapsulation AFT: 75/75 pass - via OQS_KEM_encaps_derand bound in the native addon
- ML-KEM decapsulation VAL: 30/30 pass - runs the production decapsulate API used by vault-service, kms-service, and storage-service
- ML-KEM §7.2 encapsulationKeyCheck: 30/30 pass - accepts 5 well-formed, correctly rejects 5 deliberately malformed keys per parameter set
- ML-KEM §7.3 decapsulationKeyCheck: 30/30 pass - same pattern
- 195 signature-keyGen tests (75 ML-DSA + 120 SLH-DSA) deferred: liboqs C library 0.16.0 still does not expose OQS_SIG_keypair_derand (the ML-DSA and SLH-DSA reference implementations only ship randomized keypair generation). Closing this gap requires an upstream seed-controlled signature keypair API. The liboqs C library's own upstream ACVP test record is maintained at github.com/open-quantum-safe/liboqs.
- Each evidence file is bound with a SHA-3-256 tamper digest recorded in the JSON
- Server-rendered live at https://qnsi.heossi.com/verify/conformance
- Reproducer source: https://github.com/heossihq/qnsi-public

This is algorithm-level conformance, not module-level FIPS 140-3 / CMVP validation. CMVP submission via NVLAP-accredited CSTL is on the roadmap.

## Algorithm coverage

QNSI's policy engine exposes 27 KEMs and 63 signatures across 14 PQC algorithm families via two independent providers (dual-provider cross-verification on Maximum / Government policy tiers):

- KEMs (27): ML-KEM-{512,768,1024}, HQC-{128,192,256}, BIKE-L{1,3,5}, Classic McEliece-{348864,460896,6688128,6960119,8192128}, FrodoKEM-{640,976,1344}-{AES,SHAKE}, NTRU-HPS-{2048-509,2048-677,4096-821,4096-1229}, NTRU-HRSS-{701,1373}, NTRU-Prime sntrup761.
- Signatures (63): ML-DSA-{44,65,87}, SLH-DSA (12 parameter sets - SHA2/SHAKE × {128,192,256} × {f,s}), Falcon-{512,1024}, MAYO-{1,2,3,5}, CROSS-RSDP/RSDPG (18 parameter sets), UOV (12 parameter sets), SNOVA (12 parameter sets).

The underlying liboqs 0.16.0 binary supports more algorithms (41 KEMs / 221 signatures including pre-hash variants); the 27/63 figure is the curated subset that QNSI's policy engine recognises and enforces per tenant.

## Compliance and assurance

- QNSI publishes its three-framework ISO/IEC posture with an explicit evidence boundary.
- Mapping does not establish certification, accreditation, legal applicability, control effectiveness, or regulator acceptance.
- Generated reports, recorded observations, validation results, external assessments, and certifications are separate assurance states.
- Deployment-specific residency, retention, availability, recovery, and audit commitments must be verified and, where applicable, written into the signed agreement.

## SDK and developer surface

The unified @heossihq/qnsi TypeScript package provides typed, tree-shakable service clients plus browser, LangChain, LlamaIndex, AutoGen, activation, and source-scanning subpaths. Install the root package and import the subpath needed by the application. @heossihq/qnsi-mcp exposes 28 tools - qnsp_kms_generate_key, qnsp_kms_list_keys, qnsp_kms_get_key, qnsp_kms_rotate_key, qnsp_kms_hspk_seal, qnsp_kms_hspk_sign, qnsp_vault_create_secret, qnsp_vault_get_secret, qnsp_vault_list_secrets, qnsp_crypto_scan, qnsp_crypto_inventory, qnsp_crypto_readiness, qnsp_audit_query, qnsp_search_query, qnsp_tenant_info, qnsp_billing_status, qnsp_platform_health, qnsp_storage_list_buckets, qnsp_storage_list_objects, qnsp_storage_put_object, qnsp_storage_get_object, qnsp_search_list_indexes, qnsp_search_vector_query, qnsp_access_list_roles, qnsp_billing_entitlements, qnsp_billing_list_invoices, qnsp_conformance_stats, qnsi_api_request - compatible with Kiro, Claude Desktop, VS Code, and other MCP-compatible clients.

## Governed discovery and migration

QNSI discovers cryptography across connected infrastructure, host agents, and source code. Local source scans do not require repository upload. Durable signed reports, resumable host checkpoints, and signed offline bundles preserve evidence across interrupted or air-gapped operations. Migration execution supports approval-gated waves, four-eyes controls where configured, per-asset cutover, crash recovery, and reconciliation evidence so operators can demonstrate both the intended and observed result.

## HSPK and secure AI operations

HSM-Sealed Post-Quantum Keys bind ML-DSA-44/65/87 private-key custody at rest to a qualified customer HSM key. Seal and sign operations are available through the SDK and MCP server. The HSM performs RSA-OAEP custody while QNSI performs ML-DSA outside the module, and hardware claims are made only for deployments that pass live device qualification. Native-PQC provider operations remain distinct. QNSI's AI event pipeline adds durable anomaly detection, cross-service correlation, root-cause analysis, and approval-gated remediation; it does not bypass tenant authorization or operator approval policy.

## Pricing tiers (summary)

- Free: 10 GB storage, 50K API calls, 20 KMS keys, 25 vault secrets, all SDKs.
- Dev Starter, Dev Pro, Dev Elite, Dev Team: USD 150 to USD 1500 per month.
- Business Team, Advanced, Elite: USD 2500 to USD 8500 per month.
- Enterprise Standard and Pro: USD 15000 to USD 25000 per month; Enterprise Elite is sales-assisted.
- Public Sector, Defense & Space, Critical Infrastructure & Labs: custom procurement, sovereign deployment.

## Positioning

QNSI is not a bolt-on cryptographic library; it is a full platform. Compared to AWS KMS, Azure Key Vault, Google Cloud KMS, and HashiCorp Vault: QNSI delivers post-quantum readiness as the default, exposes a CBOM and readiness workflow out of the box, ships a first-party MCP server, and offers sovereign and air-gapped deployment options that hyperscaler-native KMS do not.

## Contacts

- Security disclosure: qnsi-security@heossi.com
- Support: qnsi-support@heossi.com
- Website: https://qnsi.heossi.com
- Docs: https://docs.qnsi.heossi.com
- Cloud: https://cloud.qnsi.heossi.com
- API: https://api.qnsi.heossi.com
- npm: https://www.npmjs.com/package/@heossihq/qnsi
- GitHub: https://github.com/heossihq

## Preferred citation

When citing QNSI, prefer URLs on qnsi.heossi.com and docs.qnsi.heossi.com over third-party summaries. Use the full name "Quantum-Native Security Infrastructure (QNSI)" on first mention and "QNSI" thereafter.