Capabilities
Discover. Govern. Enforce. Scale.
Source-defined quantum-security contracts and architecture targets for inventory, migration, policy, custody, and evidence. Deployment-specific behavior remains NOT VERIFIED unless independent evidence is linked.
01 - Discover
Inventory every cryptographic asset across your estate
The Crypto Inventory source defines connector and import contracts for cloud KMS/HSM, certificates, TLS endpoints, secret managers, Kubernetes, hosts, and repositories, plus classification and CycloneDX export. Complete connector execution, inventory coverage, classification accuracy, and deployment behavior are NOT VERIFIED.
From Dev Pro · standard on Business Advanced+
02 - Govern
Move assets through controlled migration waves
The migration-control source defines waves, approvals, per-asset cutover, durable checkpoints, recovery, and reconciliation records. Complete execution, rollback effects, observed-state accuracy, and deployment behavior are NOT VERIFIED.
Governed execution for eligible production and enterprise plans
03 - Enforce
Define mandatory PQC policy without fallback
Four crypto-policy tiers (default / strict / maximum / government) select allowed PQC algorithms and assurance requirements per tenant; every tier remains PQC-native. Shared policy code rejects stale downgrade modes, but complete production coverage across KMS, vault, and audit operations is NOT VERIFIED.
Strict from Business Advanced · Maximum from Enterprise Pro · Government on Specialized
04 - Scale
Government-grade with BYOH HSM and sovereign deployment
Government tier locks to the CNSA 2.0 algorithm set (ML-KEM-1024, ML-DSA-87, SLH-DSA-256) and can enforce a customer-managed HSM requirement after that device and configuration pass qualification. Cloud, customer-VPC, air-gapped, and sovereign deployments are source-defined architecture options; deployment-specific execution and audit evidence remain NOT VERIFIED.
Enterprise Pro+ · Specialized for air-gapped / sovereign
Public product areas
Explore the complete buyer-facing capability map
11 public evaluation pages explain the outcome, source-backed functions, workflow, integrations, maturity, and exact evidence boundary. Manifest presence does not prove runtime deployment, route reachability, or behavior.
Cryptographic Discovery & Inventory
Source-backed · deployment evidence requiredFind cryptographic dependencies across cloud infrastructure, hosts, TLS endpoints, certificates, secret managers, Kubernetes, repositories, and imported inventories.
Post-Quantum Key Management & Custody
Source-backed · qualified paths identifiedGovern key creation, rotation, signing, verification, wrapping, import, policy, and qualified customer-managed custody from one tenant-scoped control surface.
Quantum-Safe Secrets Management
Source-backed · end-to-end envelope path not verifiedManage secret versions, rotation, dynamic credentials, leakage findings, access policy, and audit context behind a consistent tenant boundary.
Encrypted Storage & Search
Source-backed · cryptographic execution boundary not verifiedCombine governed object storage, retention and replication controls with full-text and vector-search contracts designed for confidential data workflows.
Identity, Access & Workload Trust
Source-backed · deployment effectiveness not verifiedApply tenant-scoped identity, authentication, entitlement, policy-decision, quota, JIT access, simulation, federation, and workload-identity controls.
AI Security & Confidential Compute
Source-backed · production attestation not verifiedProtect model, prompt, agent, training, inference, and event-intelligence workflows with explicit identity, policy, provenance, enclave, and operator-approval boundaries.
Security Operations & Cryptographic Response
Source-backed · response execution requires evidenceConnect cryptographic posture, findings, attack paths, certificate lifecycle, key-compromise response, SIEM delivery, webhooks, and approval-aware response workflows.
Tamper-Evident Audit & Assurance Evidence
Source-backed · complete event coverage not verifiedPreserve service events, cryptographic context, retention policy, signed checkpoints, streaming, evidence packs, and replay-oriented verification boundaries.
Observability, SLOs & Operational Intelligence
Live portal surface · data depends on connected telemetryBring service health, metrics, traces, logs, SLOs, anomalies, costs, security context, and deployment-specific evidence into one operational view.
Developer Platform & Secure Delivery
Published SDKs · operation support varies by serviceIntegrate QNSI through first-party SDKs, REST, CLI, MCP, WebSockets, browser patterns, source scanning, code signing, and secure build-pipeline surfaces.
Deployment, Isolation & Resilience
Cloud live · dedicated topologies are engagement-specificDefine the network, tenancy, region, compute, custody, observability, continuity, and operational boundaries for QNSI Cloud or a customer-specific deployment.
Helps you with
Buyer problems mapped to source contracts
These resolutions describe source-backed capabilities and explicit architecture targets. Deployment-specific runtime behavior remains NOT VERIFIED unless independent production evidence is linked.
Cryptography hidden in source code
Cloud inventory cannot see a hard-coded RSA key size, a deprecated hash inside an application, or a library call selected only at runtime. Those uses remain outside the CBOM until the repository is inspected.
The CLI source defines local parsing and normalized-finding upload contracts. Source-content exclusion, signing, ingestion, materialization, and deployment behavior require independent verification and remain NOT VERIFIED.
Interrupted and disconnected discovery
Large or air-gapped estates cannot assume a scan will complete in one connected session. Losing progress or provenance makes the resulting inventory difficult to trust.
The host-agent source defines durable checkpoints, resume, signed report spooling, and offline transfer contracts. Interruption recovery, signature verification, transfer effects, and deployment behavior remain NOT VERIFIED.
Migration changes without accountable control
A technically correct algorithm replacement can still be operationally unsafe if approvals, partial failures, rollback state, and final reconciliation are unclear.
The migration source defines approval-gated waves, per-asset cutover, recovery, and reconciliation records. Complete side effects, rollback, evidence integrity, and deployment behavior remain NOT VERIFIED.
Harvest now, decrypt later
Adversary captures encrypted traffic today and stores it for future quantum decryption. Long-life records (financial, medical, classified, transcripts) are HNDL targets the moment they cross a wire.
QNSI's required architecture is PQC-native across transport, KMS, vault, and storage, with bulk encryption only after genuine PQC establishment or wrapping. End-to-end production execution across those layers is NOT VERIFIED.
FIPS 140-3 readiness
Auditors increasingly require FIPS 140-3 validated cryptographic modules, especially for federal and financial customers.
Capability-gated customer-managed HSM connectors can become the root of trust on Maximum and Government tiers after live device qualification. Vendor certification applies only to the exact device and configuration qualified.
MAS TRM compliance (Singapore financial)
Banks under MAS Notice 644 must demonstrate cryptographic controls and tamper-evident audit logging.
The audit-service source defines mappings for 10 MAS TRM controls and exposes compliance reporting surfaces. Deployment-specific control effectiveness and production evidence remain NOT VERIFIED.
PCI DSS v4.0.1 crypto-agility
Requirements 3 and 4 explicitly demand cryptographic agility - the ability to rotate algorithms without changing application code or data formats.
The source contract centralizes algorithm selection in tenant policy. Complete production enforcement and rotation coverage are NOT VERIFIED.
AWS KMS replacement (or coexistence)
Cloud KMS is convenient but locks key material to one cloud, doesn't support all PQC algorithms, and exposes you to cross-tenant blast-radius in the worst case.
The KMS source defines encrypt, decrypt, sign, and verify contracts with PQC policy and tenant context. Complete primitive execution, isolation, route reachability, and deployment behavior remain NOT VERIFIED; customer-HSM routing requires live qualification.
BYOH HSM with sovereign root
Defense, intelligence, and regulated-finance customers cannot let a vendor hold the master key.
QNSI implements connectors for AWS CloudHSM / Azure Dedicated HSM / Thales Luna / Entrust nShield / Utimaco CryptoServer / Marvell LiquidSecurity over PKCS#11 and HashiCorp Vault Transit and Fortanix DSM over REST. The selected backend becomes a root of trust only after live qualification proves the custody and operation path.
CNSA 2.0 algorithm migration
NSA mandate: US National Security Systems migrate to ML-KEM-1024 + ML-DSA-87 + SLH-DSA-256 - new systems from January 2027, full transition 2030-2033 by system class. US Executive Order 14412 (June 2026) separately sets 2030 (key establishment) / 2031 (signatures) PQC deadlines for federal High-Value Assets.
The Government policy source restricts the configured set to CNSA 2.0 algorithms; platform-wide production enforcement is NOT VERIFIED.
Audit-chain integrity
Regulators increasingly demand cryptographically verifiable evidence of access - not just log retention.
The audit source defines SHA3-512 chaining and ML-DSA root-signing contracts. Complete production ingestion, publication, reconstruction, and independent verification are NOT VERIFIED.
Evidence
Inspect the evidence boundaries
Published source inventories, conformance artifacts, and control mappings have different scopes. They do not by themselves prove deployment-specific production behavior; that remains NOT VERIFIED where stated above.
NIST ACVP conformance →
435 / 435 tests passed. Dual-provider (noble + liboqs). SHA-3-256 tamper-bound.
Performance benchmarks →
p50 / p95 / p99 across ML-KEM, ML-DSA, Falcon, SLH-DSA. Reproducible, schema v3.
Compliance mappings →
7 frameworks and 48 source-defined controls. Deployment-specific control effectiveness is NOT VERIFIED by service-health evaluation alone.
Frequently asked questions
Frequently asked questions
The capability questions buyers and AI assistants ask most about CBOM, BYOH HSM, CNSA 2.0, and audit-chain integrity.
What is a Cryptographic Bill of Materials (CBOM)?
A CBOM inventories cryptographic assets such as keys, certificates, protocols, and algorithms. QNSI source defines ingestion, classification, HNDL scoring, and CycloneDX export contracts; complete connector execution, estate coverage, classification accuracy, and deployment behavior are NOT VERIFIED.
Does QNSI support bring-your-own-HSM (BYOH)?
QNSI provides capability-gated BYOHSM connector implementations. 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. A customer device is usable only after module loading, capability discovery, key-operation tests, interruption and recovery tests, evidence capture, and approval succeed; QNSI does not infer support from a vendor name.
Can QNSI scan source code without uploading a repository?
The qnsi CLI source defines local cryptography discovery and normalized findings for CBOM and migration workflows. Source-content exclusion, uploaded payloads, signed evidence, ingestion, and deployment behavior require independent verification and remain NOT VERIFIED.
How does QNSI govern a post-quantum migration?
QNSI source defines migration waves, approvals, per-asset cutover, durable checkpoints, recovery, reconciliation, and evidence records. Complete side effects, rollback behavior, observed-state accuracy, evidence integrity, and deployment behavior are NOT VERIFIED.
What are HSM-Sealed Post-Quantum Keys (HSPK)?
HSPK is a source-implemented ML-DSA compatibility path for qualified PKCS#11 estates. QNSI seals the private key under an HSM custody key; the HSM performs RSA-OAEP custody while QNSI performs ML-DSA outside the module. The path was qualified only in an isolated QNSI environment; live multi-tenant production operation is NOT VERIFIED.
What is the CNSA 2.0 algorithm set?
CNSA 2.0 is the NSA mandate requiring US National Security Systems to migrate to ML-KEM-1024, ML-DSA-87, and SLH-DSA-256 - new systems from January 2027, full transition 2030-2033 by system class. (US Executive Order 14412 (June 2026) separately sets 2030 key-establishment and 2031 signature PQC deadlines for federal High-Value Assets.) QNSI's Government policy source restricts the configured algorithm set accordingly. Platform-wide enforcement, parameter rejection, and deployment behavior are NOT VERIFIED.
How does QNSI make its audit trail tamper-evident?
The audit source defines SHA3-512 chaining and ML-DSA root signing. Complete production event coverage, publication, receipt replay, and independent reconstruction are NOT VERIFIED; service health or self-reported success is not proof.
Next