QNSIThe complete platform
Each area below has a public evaluation page covering the buyer outcome, source-backed capability, operating workflow, integrations, maturity, and exact evidence boundary.
Cryptographic Discovery & Inventory
Find cryptographic dependencies across cloud infrastructure, hosts, TLS endpoints, certificates, secret managers, Kubernetes, repositories, and imported inventories.
Source-backed · deployment evidence required
Review capability →
Post-Quantum Key Management & Custody
Govern key creation, rotation, signing, verification, wrapping, import, policy, and qualified customer-managed custody from one tenant-scoped control surface.
Source-backed · qualified paths identified
Review capability →
Quantum-Safe Secrets Management
Manage secret versions, rotation, dynamic credentials, leakage findings, access policy, and audit context behind a consistent tenant boundary.
Source-backed · end-to-end envelope path not verified
Review capability →
Encrypted Storage & Search
Combine governed object storage, retention and replication controls with full-text and vector-search contracts designed for confidential data workflows.
Source-backed · cryptographic execution boundary not verified
Review capability →
Identity, Access & Workload Trust
Apply tenant-scoped identity, authentication, entitlement, policy-decision, quota, JIT access, simulation, federation, and workload-identity controls.
Source-backed · deployment effectiveness not verified
Review capability →
AI Security & Confidential Compute
Protect model, prompt, agent, training, inference, and event-intelligence workflows with explicit identity, policy, provenance, enclave, and operator-approval boundaries.
Source-backed · production attestation not verified
Review capability →
Security Operations & Cryptographic Response
Connect cryptographic posture, findings, attack paths, certificate lifecycle, key-compromise response, SIEM delivery, webhooks, and approval-aware response workflows.
Source-backed · response execution requires evidence
Review capability →
Tamper-Evident Audit & Assurance Evidence
Preserve service events, cryptographic context, retention policy, signed checkpoints, streaming, evidence packs, and replay-oriented verification boundaries.
Source-backed · complete event coverage not verified
Review capability →
Observability, SLOs & Operational Intelligence
Bring service health, metrics, traces, logs, SLOs, anomalies, costs, security context, and deployment-specific evidence into one operational view.
Live portal surface · data depends on connected telemetry
Review capability →
Developer Platform & Secure Delivery
Integrate QNSI through first-party SDKs, REST, CLI, MCP, WebSockets, browser patterns, source scanning, code signing, and secure build-pipeline surfaces.
Published SDKs · operation support varies by service
Review capability →
Deployment, Isolation & Resilience
Define the network, tenancy, region, compute, custody, observability, continuity, and operational boundaries for QNSI Cloud or a customer-specific deployment.
Cloud live · dedicated topologies are engagement-specific
Review capability →
18 manifest-declared services. 11cloud-vendor connector families spanning 36 inventory source types. 87 PQC algorithms (24 KEMs + 63 signatures). 8 capability-gated HSM connector implementations. 6 SDK languages. Operated as one security infrastructure layer. Public SDKs and integration examples are independently verifiable at the public SDK and integration source mirror at github.com/heossihq/qnsi-public.
Deployment topologies
The homepage architecture diagram renders the Cloud-default flow - the model most self-serve customers start on. Regulated buyers, sovereign-cloud operators, and air-gapped environments compose a different topology from the same underlying platform. The Cloud-default topology is live today; the VPC, private-endpoint, on-premises, and air-gapped topologies are provisioned per tenant on an enterprise engagement. Ask in any sales / security engagement for the one that matches your posture.
Default
Public internet → QNSI edge gateway → multi-tenant cloud services.
Fastest onboarding and the current public service. Shared client contracts are published, but operation availability and behavior still depend on the service, version, entitlement, and observed deployment.
Self-serve developers · SMBs · early-stage enterprise pilots · proof-of-value engagements.
Topology
Private VPC peering between customer VPC and a QNSI VPC in the customer's AWS region.
Private-connectivity architecture intended to keep the application path off the public internet. Network routing and any PQC or hybrid transport claim require deployment-specific provisioning and observed evidence.
Regulated FSI · enterprises with private-network discipline · workloads under DLP / network-segmentation policy.
Topology
AWS PrivateLink / Azure Private Endpoint / GCP Private Service Connect terminating QNSI services.
QNSI services reachable only via private DNS inside the customer's chosen cloud. No NAT, no public ingress, no shared edge. Best for single-cloud enterprises that have standardised on PrivateLink-class connectivity.
Single-cloud enterprise (AWS-only, Azure-only, GCP-only) · platform teams enforcing zero-public-ingress.
Topology
QNSI services run inside the customer's datacenter, container platform, or dedicated rack.
Control plane and data plane both live in customer infrastructure. QNSI delivers signed update bundles; telemetry can be locally retained or streamed to the customer's SIEM. No outbound dependency on the QNSI cloud for steady-state operation.
High-classification government · defence · SCIF / IL5-class environments · critical-infrastructure operators.
Topology
Fully disconnected - no inbound or outbound network path to the QNSI cloud at all.
Updates delivered as signed offline bundles (PQC-signed manifests + cryptographic provenance). Telemetry written to local SIEM only. Crypto policy enforcement, audit chain, and evidence packs all operate inside the air-gap.
Sovereign defence · SCIFs · classified workloads · critical national infrastructure · regulators requiring physical-network isolation.
Composable across five orthogonal axes
The deployment model above is the network-topology axis. Four additional axes - tenancy, HSM custody, region / failover, and compute class - are configured independently. Any combination is supported subject to your tier and regulatory posture.
Axis
Network topology
5 declared deployment types - independently reproducible from the public mirror.
Axis
Tenancy
Three isolation knobs toggle independently per tenant.
Axis
HSM custody
8 connector implementations - 6 via PKCS#11 (AWS CloudHSM · Azure Dedicated HSM · Thales Luna · Entrust nShield · Utimaco CryptoServer · Marvell LiquidSecurity) and 2 via REST API (HashiCorp Vault Transit · Fortanix DSM). The generic PKCS#11 path is verified with SoftHSM, the Vault REST path is verified with a live Vault backend, and QNSI's shipped provider plus HSPK custody path are proven on AWS CloudHSM hsm2m.medium in FIPS mode. Named hardware is enabled only after per-deployment qualification. AWS CloudHSM can provide FIPS 140-3 Level 3 custody under Marvell Semiconductor, Inc.'s certificate #4703 only after the customer provisions and QNSI qualifies that service for the deployment. Native-PQC HSM and cloud-KMS products now exist; their algorithms, firmware, and validation scope vary. QNSI's current HSPK API supports ML-DSA-44/65/87 as a software signing compatibility path rooted in qualified HSM custody, while QNSI's 87-algorithm catalog is a broader software migration and interoperability surface.
Axis
Region & failover
Region, failover, and residency provisioned per tenant on enterprise engagement.
Axis
Compute class
Enclave capacity is an add-on; bring-your-own GPU-enclave hardware supported.
The Cloud-default topology is live today. The combinations are governed by tier and add-on entitlements; sales-assisted topologies (VPC, on-premises, air-gapped, sovereign, isolated tenancy, CloudHSM-managed clusters) are provisioned per tenant on a procurement engagement. Talk to sales for the right mix.
Reference architectures
The public cloud service and enterprise-provisioned topologies are deliberately separated. Source presence does not make a private, on-premises, or disconnected deployment generally available.
Public cloud service
Customer workloads reach the QNSI edge through the public service boundary.
Qualification boundary: Operation availability still depends on service version, tenant policy, entitlement, provider, and observed evidence.
Provisioned per tenant
Private routing joins a customer VPC to a tenant-scoped QNSI deployment boundary.
Qualification boundary: Routing, region, tenancy isolation, transport, failover, telemetry, and evidence are qualified for the deployment.
Provisioned per tenant
Cloud-provider private connectivity and private DNS expose the qualified service surface without public ingress.
Qualification boundary: Provider service, DNS, routing, identity, operation coverage, and assurance require observed deployment evidence.
Enterprise engagement
QNSI control and data services operate inside the customer-managed environment.
Qualification boundary: Compute, storage, custody, update, backup, telemetry, support, and evidence procedures are customer-specific.
Contract-scoped deployment
No steady-state dependency on the public QNSI service is assumed.
Qualification boundary: Offline update, signing, import/export, key custody, recovery, local SIEM, and operator procedures require scope-specific proof.
Enterprise evaluation
Each path starts from public evidence and makes the unresolved qualification boundary visible.
Enterprise architecture
Trust boundaries, request flow, service planes, deployment axes, and customer/QNSI responsibilities.
Reference architectures →Security and cryptography
Conformance runners, benchmark data, provider boundaries, capability maturity, and explicit gaps.
Verification hub →Platform engineering
SDKs, CLI, MCP, agents, request lifecycle, local examples, and governed migration contracts.
Developer platform →Risk, audit, and compliance
Control mappings, audit-event contracts, evidence status, public artifacts, and independent-assessment gaps.
Compliance mappings →Procurement and technical diligence
Capability registry, security package index, licensing, status, disclosure, provenance, and request paths.
Diligence index →Security framework
Quantum Threat Model v2.0
Comprehensive threat modeling aligned with NIST PQC standards and CRQC timeline assumptions.
Cryptographic Attestation
Forensic-grade cryptographic evidence with NIST algorithm lifecycle tracking and compliance assessment.
Cryptographic Policy Engine
Tenant-configurable PQC enforcement with algorithm allowlists and HSM requirements.
Cryptographic Provenance · Pinned Versions
Auditable provenance for every cryptographic primitive - pinned upstream library + language bindings, all versions verifiable against published releases.
Cross-Verification · Dual-Provider Crypto
Maximum and Government policy sources can require dual-provider verification; complete runtime coverage across every cryptographic operation remains NOT VERIFIED.
Provider Attestation in Audit Chain
The provider-attestation contract can record which implementation produced an output; complete operation coverage and audit ingestion remain NOT VERIFIED.
Signed Audit Evidence
Cryptographically signed, hash-chained audit trail for compliance and forensics.
Compliance Frameworks · 48 Controls
Real-time control evaluation against 7 compliance frameworks via live service health probes.
Key Compromise Response
Automated 6-step remediation for suspected or confirmed key compromises.
Downgrade Attack Remediation
Real-time detection and response to cryptographic downgrade attempts.
Fail-Closed Edge Enforcement
Two-layer entitlement enforcement at the edge gateway before any service proxy. Fail-closed for cryptographic services.
PQC-TLS Production Canary
Production canary designed to observe PQC-TLS negotiation on selected endpoints. Current proof must come from its live result; deployment alone is not verification.
Cryptographic Hot-Reload + Drift Control
Live tenant policy updates without service restart. Continuous validation that environment stays migrated.
Migration journey
QNSI is designed to become the active trust platform your workloads consume, not a passive reporting overlay. The operating path is Connect → Discover → Analyze → Govern → Migrate → Validate → Operate.
1. Connect
Attach cloud/API connectors for managed providers and install QNSI agents for private, self-hosted, or on-prem sources.
2. Discover
Run discovery to normalize keys, secrets, certificates, protocols, providers, and cryptographic dependencies across internal and external estates.
3. Analyze
Measure quantum exposure, policy violations, deprecated algorithms, and the actual cutover blockers preventing migration to QNSI.
4. Govern
Define crypto policy, lifecycle rules, enforce-vs-audit behavior, transition exceptions, and the tenant target state before cutover.
5. Migrate
Move keys, secrets, certificates, and workload trust paths into QNSI so applications call QNSI KMS, Vault, storage, search, and governed services directly.
6. Validate + Operate
Prove cutover with readiness evidence, CBOM, QBOM, SBOM, and continuous monitoring so the environment stays migrated instead of drifting back.
Comparing vendors?
The master feature matrix (33 features × 4 vendor categories), the three-bucket competitor landscape, and five per-vendor deep-dive pages (Fortanix, SandboxAQ, AWS KMS, Azure Key Vault, HashiCorp Vault) have moved to a dedicated hub so a buyer in evaluation mode has one destination.
Statement of Direction
Capabilities under active development for clients with multi-year cryptographic procurement and architectural requirements. Not generally available. Published forward direction enables long-horizon procurement, architecture, and assurance teams to plan against QNSI's strategic platform programme.
Quantum key distribution (QKD)
Partner integrationHardware-channel integration paths for BB84 and E91 protocols. Partner engagement with QKD hardware vendors (Toshiba, IDQ, MagiQ) for physical-layer key exchange across metropolitan and inter-data-centre links.
Fully homomorphic encryption (FHE)
Active developmentComputation over encrypted data - analytics, machine-learning inference, and aggregation performed against ciphertexts that never leave their encrypted form. Schemes under evaluation: BFV, BGV, and CKKS via OpenFHE.
PQC-protected federated learning
Active developmentDistributed model training with post-quantum-encrypted gradients across organisational boundaries. Designed for financial-sector consortia and healthcare federations where central pooling of sensitive data is constrained by regulation.
Data residency & trust controls (DRTC)
Architecture phaseSovereign residency enforcement at the platform layer - geographic, legal-jurisdiction, and operator-class controls embedded into every cryptographic operation, with auditable evidence end-to-end.
For clients with these capabilities on a procurement timeline, QNSI supports co-development engagements and early-access partnerships. Contact your account team or open a Free Forever account to begin the conversation.
Where to go next
18 manifest-declared services, hardware-enclave architecture, unified cryptographic policy, and NIST-finalized PQC standards.
The Quantum Threat
Cloudflare and Google target PQC migration by 2029. NIST transitions quantum-vulnerable algorithms out by 2035, with high-risk systems earlier. No authoritative CRQC arrival date exists. HNDL risk is active today.
Understand the threat →
Developer Platform
First-party SDKs in TypeScript, Python, Go, Rust, and JVM/Android + OpenAPI REST, WebSocket, CLI. Free on every plan.
Start building →
Solutions & Use Cases
Sourced operational scenarios, industry solution briefs, and developer implementation patterns with explicit evidence boundaries.
View use cases →
Transparent Pricing
Published self-service and enterprise tiers with quotas, capability boundaries, and engagement-scoped deployment options.
See pricing →
Enterprise Onboarding
Scope cloud, VPC-peered, private-endpoint, on-premises, air-gapped, or sovereign requirements through an architecture and security review.
Get in touch →
Frequently asked questions
The platform questions buyers and AI assistants ask most about algorithms, FIPS posture, deployment, and the quantum threat.
QNSI catalogs 87 PQC algorithms across 13 families - 24 KEMs and 63 signatures. The source defines liboqs as the primary provider and noble as an overlapping cross-verification provider. Complete runtime availability and dual-provider coverage across every operation remain NOT VERIFIED.
QNSI implements the NIST-finalised standards - FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) - and both providers pass the official NIST ACVP test vectors (noble 435/435, liboqs 240/240 on ML-KEM), published with a SHA-3-256 tamper digest at /verify/conformance. CAVP module validation is in progress.
Harvest-now, decrypt-later is an attack where an adversary captures encrypted traffic today and stores it until a cryptographically relevant quantum computer can break it. Long-life data - financial, medical, classified, legal - is exposed the moment it crosses a wire. Applying PQC now keeps captured ciphertext protected past quantum arrival.
QNSI runs as QNSI Cloud today; VPC-peered (AWS, Azure, or GCP), on-premises, air-gapped, and sovereign data-residency topologies are provisioned per tenant on an enterprise engagement. Hardware enclaves include Intel SGX and TDX, AMD SEV-SNP, AWS Nitro, NVIDIA Confidential Computing, ARM TrustZone and CCA, and IBM Secure Execution for confidential AI workloads.
Four crypto-policy tiers - default, strict, maximum, and government - define which algorithms and parameter sets each tenant may use. Enforcement runs in-line at the edge gateway, KMS, and vault. A tier requiring HSM custody fails closed unless a qualified HSM path is active.
Start with the public cloud service or scope an enterprise topology through an architecture and security review. No credit card is required for the free tier.