QNSI
Start building free
Platform
Platform overviewCapabilitiesAlgorithm catalogWhy QNSI
Solutions
Solutions by Use CaseSolutions by IndustryAssessment & migrationPQC migration guideCompare platforms
Developers
DocumentationDeveloper hubBuild patternsAI assistants (MCP)Public source & evidence
Pricing
Company
About HEOSSIChangelogContactKnowledge CentreResearchNews & Insights
TrustHub
TrustHub overviewSecurity programCompliance mappingPublic evidenceService statusResponsible disclosureLegal & Policy LibraryTerms of ServicePrivacy PolicyData Processing AddendumSub-processors
Start building free

Security

Security at QNSI

QNSI Cloud ships into regulated, mission-critical environments where 'trust us' is not an option. This page states what we operate, what we can prove today, and where a claim is not yet independently verified. Every figure below is derived from the same single-source facts the policy engine, ACVP evidence and service registry use.

QNSI Cloud is a managed platform: we secure the underlying infrastructure and platform services; you control your tenant configuration, user access, and how you use the platform to process data. Where evidence does not yet support a universal claim, we label it NOT VERIFIED rather than imply more than we can prove.

At a glance

Security posture in numbers

Charts state their scope; they do not replace the linked evidence. An available observation does not prove an auditor has accepted the control.

  • 435/435ACVP vectors (noble)liboqs 240/240
  • 1 / 3 / 5 / 5NIST security floorsdefault · strict · maximum · government
  • 4Crypto-policy tiersone shared definition
  • 3Compliance frameworks17 mapped controls
  • 8HSM connectorsPKCS#11 and REST custody paths
  • 18Manifest-declared servicessource inventory, not runtime proof
Open the evidence hub →
default
1
PQC-native baseline
strict
3
Commercial floor
maximum
5
High assurance
government
5
Sovereign

Evidence

Evidence for QNSI security claims

This section indexes the public artifacts supporting named claims, and states the scope each artifact does and does not establish.

Compliance framework mapping
Three company frameworks: ISO/IEC 27001:2022 for information security, ISO/IEC 42001:2023 for AI governance and safety, and ISO/IEC 19790:2025 for cryptographic modules. These are internal posture statements, not accredited certifications.
Control mappings and authenticated operational observations are surfaced separately. Availability of an observation does not prove that an auditor has accepted the control.
/security/compliance →
NIST ACVP conformance - live
Server-rendered algorithm test-vector evidence for QNSI's two PQC providers. The page identifies the vector source, provider version, and integrity boundary.
Algorithm-level evidence only. It is not a CMVP certificate and does not, by itself, prove that every production request executed the tested primitive.
/verify/conformance →
Reproducible PQC benchmarks
Recorded measurements with an identified build, environment, methodology, and public reproduction path.
Benchmark evidence applies only to the recorded build and environment. It is not a standing production-performance guarantee.
/benchmarks →
Auditable entropy chain
Architecture documentation for supported entropy paths with citations to NIST SP 800-90A / 90B / 90C and relevant provider documentation.
Documentation is not runtime proof. The active source and qualification status remain deployment- and provider-specific.
/security/entropy →

Controls

How QNSI protects your data

The operational controls behind the platform, grouped by domain. Each bullet states the capability and, where applicable, the current evidence boundary.

Encryption & key management

In transit
Public edge transport uses the protocol actually negotiated with each client. End-to-end PQC-native transport across every production path is NOT VERIFIED by the currently published evidence. Hybrid compatibility is not represented as pure PQC.
At rest
QNSI provides SSE-X and PQC envelope capabilities. Fleet-wide enforcement of ML-KEM wrapping for every stored customer object is NOT VERIFIED by the currently published evidence.
HSM custody
Capability-gated PKCS#11 connectors allow root-key custody only after the selected device and configuration pass live qualification.
Key boundaries
Key management and cryptographic operations run in dedicated platform components. Vault and KMS keys are never sent to untrusted clients.

Exact security and certification level (FIPS 140-3, etc.) depends on deployment model and HSM configuration.

Access controls

Tenant isolation
Tenant-scoped identity and policy enforcement by design. Universal enforcement across every path requires deployment-specific verification.
Authentication
Password with optional MFA, physical U2F / FIDO2 keys, SAML SSO (Azure AD, Okta and others) and OIDC.
Authorization
Role-based access control (RBAC) plus attribute-based policies (ABAC), least privilege enforced.
Audit logging
Security and cryptographic events are recorded to the audit plane. Complete coverage of every operation is NOT VERIFIED by public evidence.

QNSI operates an internal least-privilege IAM model. Access to AWS backend resources and data is controlled via IAM roles and audit logging.

Data handling & retention

Storage
Customer content you upload (secrets, keys, files) is stored encrypted within our hosted AWS environment. We do not access customer data except for support with your permission or legal compliance.
Retention
Configurable retention periods for audit logs, from 90 days to 7 years.
Deletion
On-demand and scheduled deletion for vault secrets and storage files.
Termination
On service termination or downgrade, customer data is retained for 30 days before permanent deletion.

Model

Shared responsibility

Private, VPC, sovereign and air-gapped deployments shift responsibilities based on the chosen deployment model.

QNSI operates

Platform security, service hardening, cryptographic controls, audit evidence integrity, and incident response for platform incidents.

You operate

Identity administration, tenant policy configuration, access reviews, data classification, and secure handling of exported data.

Operations

Incident response

QNSI operates an incident response process covering triage, investigation, remediation and recovery. For critical incidents affecting hosted production, customer notification is provided based on severity and impact.

Security breach or unauthorized access

Data loss or corruption

Service outage or degradation

Cryptographic downgrade or policy violation

Report a security incident or question to qnsi-security [at] heossi.com.

Compliance

Compliance & certifications

QNSI is designed to support compliance with major regulatory frameworks. Actual compliance status depends on deployment model and customer configuration. We label each posture honestly.

NIST PQC standards

Evidence published

Algorithm-level evidence for ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). This is not a FIPS 140-3 module certificate.

FIPS 140-3

Deployment-scoped

Vendor-certificate scope evaluated during customer HSM qualification.

CSA STAR

Not verified

Registry alignment under the QNSI and HEOSSI names is NOT VERIFIED. A self-assessment is not an independent certification.

SOC 2

Not verified

No independent examination report is currently published. SOC 2 assurance is NOT VERIFIED.

For compliance questions or audit requests, contact qnsi-compliance [at] heossi.com. Detailed legal terms are in the Terms of Use.

Disclosure

Vulnerability disclosure & advisories

How QNSI receives, remediates, and publishes security issues. Report findings under the terms in our security policy; good-faith research is covered by safe harbour.

How to report

Report privately via security.txt or qnsi-security [at] heossi.com. Stay within scope, avoid accessing other parties' data, and give us reasonable time to remediate before public discussion.

How we remediate

Target acknowledgment within 48 hours and initial assessment within 5 business days. Issues in QNSI Cloud, our hosted service, are fixed server-side with no action required from you. We confirm resolution on the live service before closing a report.

Advisories & CVEs

Hosted-service fixes are tracked with HEOSSI advisory identifiers (HEOSSI-YYYY-NNN) and credited below. We request CVE identifiers for issues in distributed artifacts that customers run themselves, such as the QNSI SDKs, the MCP package, the editor extension, and self-hosted deployments, where a downstream operator needs to upgrade.

Disclosure

Security researcher acknowledgments

We thank the researchers who report issues responsibly under our vulnerability disclosure policy. Good-faith research that follows the safe-harbour terms in our security policy helps keep QNSI customers safe, and we credit it here with the reporter's consent.

kta1kri

November 2026

Responsibly disclosed a broken-access-control issue affecting read access on a gateway API surface. Reported within our disclosure policy; remediated by HEOSSI.

HEOSSI-2026-001

Mamun Khanka

September 2026

Responsibly disclosed a weakness in the OAuth dynamic client registration flow. Reported within our disclosure policy; remediated by HEOSSI.

HEOSSI-2026-002

To report a vulnerability, see our security.txt or contact qnsi-security [at] heossi.com.

Questions about QNSI security controls or compliance posture?

Contact Us