Security
This page summarizes QNSP security controls and operational practices for buyers and procurement. For vulnerability disclosure and advisories, see Research.
Shared Responsibility Model
QNSP 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.
- QNSP: 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
QNSP 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. Data deletion can be backed up before permanent keys are used for data-at-rest encryption.
- 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: TLS 1.3 with hybrid key exchange (X25519+ML-KEM-768) on all client connections. PQC-TLS termination at AWS ALB with hybrid ciphersuites.
- At-rest: SSE-X (server-side encryption with customer-controlled keys). All storage encrypted with ML-KEM-wrapped keys stored in KMS.
- HSM integration: Root keys can be HSM-backed (Thales Luna, Entrust nShield, AWS CloudHSM, Azure HSM) via PKCS#11 for high-security deployments.
- 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: Each tenant is logically isolated with policy enforcement at every access control.
- 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: All access and cryptographic operations are logged to a tamper-evident audit trail.
QNSP 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
QNSP 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 qnsp-security@cuilabs.io.
Compliance & Certifications
QNSP is designed to support compliance with major regulatory frameworks. Actual compliance status depends on deployment model and customer configuration.
- CSA STAR Level 1: Self-attestation available (CAIQ published)
- NIST PQC Standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) — finalized August 2024
- FIPS 140-3: Supported via customer-managed HSM integration
- SOC 2 Type II: Planned for 2026 (not yet certified)
For compliance questions or audit requests, contact contact@cuilabs.io.
Questions about QNSP security controls or compliance posture?
Contact Us