QUANTASEAL
QUANTASEAL
A breach of any single layer leaves the other two intact. Defence-in-depth by design.
TLS 1.3 + ML-KEM-768 hybrid
AES-256-GCM + AWS KMS
Zero-plaintext runtime
No home-grown cryptography. No experimental algorithms. Every primitive is standardised by the National Institute of Standards and Technology.
Key Encapsulation
Data-in-Transit Encryption
192-bit post-quantum
Digital Signatures
API Auth & Code Signing
192-bit post-quantum
Stateless Hash Signatures
Long-term Data Signing
256-bit post-quantum
Symmetric Encryption
Payload Encryption Layer
256-bit classical
Key Derivation
Per-Session Key Material
512-bit output
| Algorithm | FIPS Standard | Type | Use in QuantaSeal | Security Level | Role |
|---|---|---|---|---|---|
| ML-KEM-768 | FIPS 203 | Key Encapsulation | Data-in-Transit Encryption | 192-bit post-quantum | Primary |
| ML-DSA-65 | FIPS 204 | Digital Signatures | API Auth & Code Signing | 192-bit post-quantum | Primary |
| SLH-DSA | FIPS 205 | Stateless Hash Signatures | Long-term Data Signing | 256-bit post-quantum | Secondary |
| AES-256-GCM | FIPS 197 | Symmetric Encryption | Payload Encryption Layer | 256-bit classical | Hybrid |
| HKDF-SHA-512 | FIPS 198-1 | Key Derivation | Per-Session Key Material | 512-bit output | Supporting |
Cryptographic Agility Engine
QuantaSeal's Cryptographic Agility Engine allows seamless algorithm migration without re-encrypting your data. When NIST publishes new standards or updates existing ones, your platform migrates automatically \u2014 on the next key rotation cycle.
The attestation page runs real ML-KEM-768 and ML-DSA-65 operations every time it loads and validates the output against NIST FIPS 203 / 204 specification tables. No cached fixtures - fresh cryptographic operations on every request.
NIST ACVP Demo — Test Session 738724
Only PQC middleware with NIST-submitted ML-KEM-768 + ML-DSA-65 test vectors. Submitted to demo.acvts.nist.gov via mTLS 2026-06-05. Verifiable by any acquirer.
The CBOM Scanner inspects every connected integration and reports which systems still use classical cryptography (RSA-2048, ECDHE, AES-128) and which are protected by QuantaSeal's ML-KEM-768 + ML-DSA-65 envelope. It calculates a risk score per integration based on data sensitivity and protection status, and generates a remediation roadmap with estimated time-to-fix.
{
"total_components": 5,
"quantum_safe": 4,
"quantum_vulnerable": 1,
"overall_risk_score": 12,
"vulnerable_component": "SAP S/4HANA"
}
Every QuantaSeal control maps to a concrete threat. Here is our full threat model and how we address each vector.
Adversaries collect today’s encrypted traffic to decrypt it once quantum computers are available. Data with a 10-year sensitivity window is at risk right now.
Our Mitigation
ML-KEM-768 hybrid encryption makes harvested ciphertext permanently unrecoverable — even with a quantum computer.
A single compromised key can expose all data encrypted under it — the classic single point of failure in traditional KMS architectures.
Our Mitigation
Per-tenant CMKs with automatic rotation mean a compromised key exposes exactly one tenant’s data from one rotation period.
Engineers with database or infrastructure access can read sensitive data in systems that don’t enforce field-level encryption.
Our Mitigation
QuantaSeal encrypts at the field level before data reaches the database. With MPC split-key custody enabled, even QuantaSeal staff with full KMS access cannot reconstruct the signing key - making insider access mathematically impossible.
Compromised dependencies or build pipelines can inject malicious code that exfiltrates secrets during execution.
Our Mitigation
Pinned dependency versions, SBOM generation, automated vulnerability scanning on every build, and signed releases via ML-DSA-65.
Malformed requests can exploit processing pipelines to leak data or execute unintended operations.
Our Mitigation
Input validation against strict JSON schemas, parameterised queries only, rate limiting, and HMAC-signed API payloads.
Sophisticated actors with access to near-future quantum hardware target long-lived sensitive data in financial, healthcare, and government sectors.
Our Mitigation
NIST FIPS 203/204/205 algorithms are specifically designed and validated to resist attacks from cryptographically relevant quantum computers.
Our security control library is mapped to SOC 2 Type II, NIST CSF 2.0, ISO 27001, and the Australian Privacy Act. Full documentation available to Enterprise customers under NDA.
Encryption at Rest
AES-256-GCM + AWS KMS per-tenant CMK
Encryption in Transit
TLS 1.3 + ML-KEM-768 hybrid key exchange
Authentication
OAuth 2.0 + PKCE, JWT with issuer/audience validation
Authorisation
RBAC with least-privilege defaults, per-endpoint auth
Rate Limiting
Per-endpoint limits, fail-closed when service degraded
Cryptographic Agility
Automatic algorithm migration on NIST updates
Observability
OpenTelemetry traces, metrics, and distributed tracing
Logging
Immutable audit logs — all access events
Feature Flags
Controlled rollouts with admin-only flag management
Vulnerability Scanning
Daily SAST/DAST on CI pipeline
Dependency Auditing
GitHub Dependabot + OSV Scanner
Penetration Testing
External pentest before GA launch
Incident Response
24h detection SLO, public status page
Data Residency
Australia (ap-southeast-2), EU (eu-west-1) optional
Backup Encryption
Separate backup CMK, cross-region replication
Zero-Knowledge Logs
Logs contain no sensitive field values ever
Error Handling
Sanitised responses — no internal details exposed
We take security reports seriously. If you discover a vulnerability, we commit to:
24 hours
Initial acknowledgement
72 hours
Severity triage complete
90 days
Maximum remediation window
Email security@quantaseal.io with a detailed description of the issue. PGP key available on request. We practise coordinated disclosure and will credit researchers in our security advisories.
Every vault entry is encrypted under a per-tenant Customer Master Key (CMK) that exists only in your tenant's AWS KMS. Our engineers have zero standing access to your keys or plaintext data.
No QuantaSeal employee has a role that allows reading vault plaintext. Any privileged access requires a break-glass procedure with full audit trail.
Your KMS Customer Master Key is created in your AWS account (or QuantaSeal-managed KMS), never shared with other tenants, and never exported.
Any attempt to access vault entries - by staff or automation - is recorded in an SHA3-256 hash-chained audit log that cannot be modified without detection.
On Enterprise plans, vault unseal operations run inside AWS Nitro Enclaves. Even QuantaSeal application code never sees plaintext - only the enclave does.
Read our complete threat model and access control architecture
Vulnerability Disclosure & Security PolicyQuantaSeal uses liboqs 0.14.1 (Open Quantum Safe) - the same C library used in OpenSSL and BoringSSL PQC testing. Algorithm names match the NIST-finalized FIPS designations exactly.
$ docker exec quantaseal-backend python3 tests/verify_pqc.py
All 5 algorithms verified · liboqs 0.14.1 · NIST-finalized names
liboqs version
0.14.1
NIST-finalized algorithm names
Hybrid mode
Mandatory
ML-KEM-768 + AES-256-GCM always both active
CAVP status
Roadmap
OQS CAVP submission in progress (Q3 2026)
Quanta Copilot gives your team natural-language access to audit logs, compliance scores, and vault metadata. Here is exactly what it can - and cannot - do, and how we defend against AI-specific attack vectors.
Prompt injection defence
All database content returned to the LLM is scanned for injection patterns (e.g. "ignore previous instructions") and sanitised before entering the context window.
Immutable tool-call audit
Every tool call is logged with SHA3-256 hashes of the arguments and response, ML-DSA-65 signed, in an append-only chain. No tool call can be erased.
Daily rate limiting
Copilot enforces per-tenant daily and per-minute message limits to prevent automated probing of model behaviour via hundreds of crafted messages.
CISO disable toggle
Tenant admins can disable Copilot entirely via Settings. When off, all /agent/* endpoints return 403. No LLM surface exists until re-enabled.
A full Copilot threat model document is available on request for enterprise security reviews. Contact us
MPC split-key custody divides your HMAC signing key into two shares using XOR secret sharing. QuantaSeal holds one share in AWS KMS. You hold the other as a 32-byte custody key. Neither party alone can reconstruct the key - or read your vault.
01
Seal with MPC
Pass X-Vault-Enable-MPC: true when sealing. QuantaSeal splits the HMAC key: qs_share is KMS-wrapped, customer_mask is AES-256-GCM encrypted with your custody key. The custody key is returned once and never stored.
02
Store your custody key
The 32-byte hex custody key is yours to store - in your password manager, HSM, or secrets vault. QuantaSeal has no copy. If you lose it, the vault entry cannot be recovered.
03
Unseal requires both
Pass X-Vault-Custody-Key to unseal. QuantaSeal reconstructs the HMAC key by XOR-combining both shares. If the custody key is wrong, HMAC-SHA-512 verification fails - decryption is blocked.
Security Guarantee
Even with full KMS access, a QuantaSeal employee has only qs_share. Without customer_mask, the reconstructed HMAC key is random noise - signature verification fails - vault access is denied. Every access attempt without the custody key fires a VAULT_INTERNAL_ACCESS_ALERT audit event visible in your log.
# Seal with MPC
curl -X POST /vault/seal \
-H "X-Vault-Enable-MPC: true"
# Unseal (requires custody key)
curl -X POST /vault/unseal/UUID \
-H "X-Vault-Custody-Key: <hex>"
Deploy post-quantum protection across all your systems in 30 minutes or less.