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

This page summarizes QNSI security controls and operational practices for buyers and procurement. For vulnerability disclosure and advisories, see Research.

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.

Security

Evidence for QNSI security claims

QNSI ships into regulated, mission-critical environments where 'trust us' is not an option. This section indexes the public artifacts supporting named claims and states the scope that each artifact does-and does not-establish.

Compliance framework mapping
Seven frameworks mapped at the control level - SOC 2, HIPAA, GDPR, PCI DSS v4.0.1, ISO/IEC 27001:2022, PDPA (Singapore), and MAS TRM. These are engineering mappings, not certifications or legal opinions.
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 →

Shared Responsibility Model

  • QNSI: platform security, service hardening, cryptographic controls, audit evidence integrity, incident response for platform incidents.
  • Customer: identity administration, tenant policy configuration, access reviews, data classification, and secure handling of exported data.

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

Data Handling & Retention

QNSI stores customer content you upload (secrets, keys, files) encrypted within our hosted AWS environment. We do not access customer data unless required for support (with your permission) or legal compliance.

  • Retention controls: Configure retention periods for audit logs (90 days to 7 years).
  • Deletion: On-demand and scheduled deletion for vault secrets and storage files.
  • Termination: Upon service termination or downgrade, customer data is retained for 30 days before permanent deletion.

For detailed legal terms, refer to the Terms of Use.

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 must not be 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 integration: 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 are performed by dedicated platform components. Vault/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: The platform design uses tenant-scoped identity and policy enforcement. Universal enforcement across every path requires deployment-specific verification.
  • Authentication: Password + MFA (optional), physical U2F/FIDO2 keys supported, along with SAML SSO (Azure AD, Okta, etc.) and OIDC.
  • Authorization: Role-based access control (RBAC) + attribute-based policies (ABAC). Least privilege enforced.
  • Audit logging: QNSI records security and cryptographic events to its 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 strictly controlled via IAM roles and audit logging.

Incident Response

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

Incident categories:

  • Security breach or unauthorized access
  • Data loss or corruption
  • Service outage or degradation
  • Cryptographic downgrade or policy violation

For security incident reports or questions, contact qnsi-security@heossi.com.

Compliance & Certifications

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

  • CSA STAR: Current registry alignment under the QNSI and HEOSSI names is NOT VERIFIED. A self-assessment must not be represented as an independent certification.
  • NIST PQC standards: QNSI publishes 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: Vendor-certificate scope evaluated during customer HSM qualification
  • SOC 2: No independent examination report is currently published; SOC 2 assurance is NOT VERIFIED.

For compliance questions or audit requests, contact qnsi-compliance@heossi.com.

Questions about QNSI security controls or compliance posture?

Contact Us