Security Policy

1. Security Commitment

Security is not an add-on at QuantaSeal — it is our core product and our foundational operating principle. As a post-quantum cryptography company, we hold ourselves to the highest security standards across every layer of our platform, infrastructure, and organisation.

This Security Policy describes the technical and organisational measures we implement to protect the confidentiality, integrity, and availability of our platform and your data. It applies to all QuantaSeal Pty Ltd systems, personnel, contractors, and third-party service providers.

We pursue alignment with internationally recognised security frameworks including ISO/IEC 27001, SOC 2 Type II (in progress), NIST Cybersecurity Framework (CSF), and the Australian Government Information Security Manual (ISM) where applicable.

2. Cryptographic Standards

QuantaSeal implements a hybrid cryptography model that combines classical and post-quantum algorithms, ensuring security against both current and future quantum-computing threats.

2.1 Approved Algorithms

2.2 Key Management

• All encryption keys are managed via AWS Key Management Service (KMS) with CloudHSM-backed hardware security modules.
• Per-tenant Customer Master Keys (CMKs) ensure cryptographic isolation between customers.
• Automatic key rotation is enforced with configurable rotation schedules (default: 90 days for data keys, 365 days for CMKs).
• Key material is never stored in plaintext; all keys are protected by KMS envelope encryption.
• Deprecated keys are revoked immediately and data is re-encrypted under new keys during migration windows.

2.3 Cryptographic Agility

QuantaSeal's Cryptographic Agility Engine allows algorithm migration without service downtime. As NIST and international standards evolve, we can upgrade all customers to new algorithms within a single maintenance cycle. Algorithm selection is configurable at the tenant level for enterprise customers.

3. Infrastructure Security

3.1 Cloud Environment

• All production infrastructure is hosted on Amazon Web Services (AWS) in the ap-southeast-2 (Sydney) region, keeping Australian customer data within Australian borders by default.
• Infrastructure is managed as code (Terraform) with all changes peer-reviewed and applied through CI/CD pipelines — no manual console changes in production.
• AWS Organisations with Service Control Policies (SCPs) enforce guardrails across all accounts.
• AWS Config rules continuously monitor for configuration drift and non-compliant resources.

3.2 Container & Runtime Security

• All services run as Docker containers orchestrated with strict resource and capability limits.
• Container images are scanned for vulnerabilities using automated tools on every build.
• Images are pulled from private registries only; no public image sources in production.
• Secrets are injected via AWS Secrets Manager at runtime — never baked into images or environment files.

3.3 Environments

Production, staging, and development environments are strictly isolated in separate AWS accounts with no cross-environment data access. Production data is never used in non-production environments.

4. Data Protection

4.1 Encryption at Rest

• All Customer Data is encrypted at rest using ML-KEM-768 + AES-256-GCM hybrid encryption before being written to any storage layer.
• Database storage volumes (PostgreSQL on RDS) use AWS KMS-managed AES-256 encryption.
• S3 buckets storing backups and artefacts use SSE-KMS with tenant-specific keys.
• Plaintext data never persists to disk, logs, or temporary storage.

4.2 Encryption in Transit

• All traffic between clients and QuantaSeal APIs is protected by TLS 1.3 minimum. TLS 1.2 is supported for legacy compatibility; TLS 1.0/1.1 are disabled.
• Valid certificates from a trusted CA are enforced; self-signed certificates are not used in production.
• Internal service-to-service communication within the platform is mutually authenticated via mTLS.
• The Quantum-Safe API Proxy adds an additional ML-KEM-768 encryption layer over TLS for supported connections.

4.3 Data Minimisation & Logging

We apply strict data minimisation principles. Application logs contain metadata (timestamps, request IDs, status codes) but never payload content, credentials, or personally identifiable information. Log aggregation is handled by AWS CloudWatch with access restricted to authorised operations personnel.

5. Access Control

• Zero Trust Architecture: No implicit trust is granted to any user, service, or network segment. Every request is authenticated and authorised.
• Multi-Factor Authentication (MFA): Required for all internal staff accessing production systems, cloud consoles, and source code repositories.
• Role-Based Access Control (RBAC): Permissions are granted based on job function using least-privilege principles. Access is reviewed quarterly.
• Privileged Access Management: Production system access is time-limited, logged, and requires approval via a just-in-time access workflow.
• Single Sign-On (SSO): Internal tooling and cloud accounts are managed via SSO with centralised identity governance.
• API Authentication: Customer API access uses rotating API keys with configurable expiry. JWT tokens are signed with ML-DSA-65.
• Access Reviews: All access rights are reviewed quarterly; terminated employee access is revoked within 24 hours of departure.

6. Network Security

• VPC Isolation: All production resources reside in a dedicated AWS VPC with private subnets. No direct public internet access to databases or internal services.
• Web Application Firewall (WAF): AWS WAF is deployed in front of all public-facing APIs and the web application to filter OWASP Top 10 attack patterns.
• DDoS Protection: AWS Shield Standard is active across all production endpoints; AWS Shield Advanced is evaluated for enterprise deployments.
• Security Groups & NACLs: Strict allow-list firewall rules; default-deny posture on all security groups.
• Rate Limiting: API gateways enforce per-IP and per-key rate limits to prevent abuse and brute-force attacks.
• DNS Security: DNSSEC is enabled for the quantaseal.io domain. All DNS queries for internal services use private hosted zones.

7. Secure Development Lifecycle (SDLC)

• Security by Design: Threat modelling is performed at the design phase for all new features involving data handling or external integrations.
• Code Review: All code changes require peer review before merging. Security-sensitive changes require additional review by a security-aware engineer.
• Static Analysis (SAST): Automated static analysis (Ruff, ESLint security plugins, Bandit) runs on every pull request.
• Dependency Scanning: Third-party dependencies are scanned for known CVEs on every build using automated tools. High-severity vulnerabilities block deployments.
• Secrets Scanning: Pre-commit hooks and CI pipeline checks prevent credentials or secrets from being committed to source control.
• Penetration Testing: Annual third-party penetration tests are conducted against production systems. Critical findings are remediated within 7 days.
• Security Training: All engineers complete secure coding training annually and are briefed on new vulnerability classes relevant to our stack.

8. Vulnerability Management

We apply a risk-based approach to vulnerability remediation using the following SLA targets:

Infrastructure is continuously scanned using Amazon Inspector and AWS Security Hub. Findings are triaged daily and tracked through to closure.

9. Incident Response

QuantaSeal maintains a documented Incident Response Plan (IRP) covering detection, containment, eradication, recovery, and post-incident review phases. Our response process:

To report a suspected security incident involving your QuantaSeal account, contact security@quantaseal.io immediately.

10. Vendor & Supply Chain Security

All third-party vendors and sub-processors who access or process QuantaSeal data are vetted for security practices before onboarding and reviewed annually. Our vendor security requirements include:

• Evidence of ISO 27001 certification, SOC 2 Type II report, or equivalent security assurance.
• Signed Data Processing Agreements (DPAs) and confidentiality obligations.
• Data residency commitments aligned with our primary region (Australia / ap-southeast-2).
• Incident notification obligations within 24 hours of a suspected breach affecting QuantaSeal data.
• Dependencies in our software supply chain are pinned to specific versions and reviewed for licence compliance and known vulnerabilities.

11. Business Continuity & Disaster Recovery

Backups are encrypted with CMK-protected AES-256 and stored in geographically isolated S3 buckets with versioning and object lock enabled to prevent accidental deletion.

12. Personnel Security

• Background checks are conducted for all personnel with access to production systems or customer data, subject to applicable privacy laws.
• All staff and contractors sign confidentiality and data protection agreements before being granted system access.
• Security awareness training is provided at onboarding and annually thereafter, covering phishing, social engineering, and data handling procedures.
• A clear-desk and clear-screen policy applies to all work environments.
• Personnel security incidents (e.g., lost devices, suspected phishing) must be reported to security@quantaseal.io within 24 hours.

13. Physical Security

QuantaSeal is a cloud-native company. We do not operate on-premises data centres. All physical infrastructure security is provided by AWS, which maintains:

• 24/7 physical security guards, video surveillance, and access control at all data centre facilities.
• ISO 27001 and SOC 2 Type II certifications covering physical security controls.
• Multi-layer perimeter controls including biometric access, mantraps, and enforced visitor policies.

AWS data centre compliance documentation is available at aws.amazon.com/compliance.

14. Responsible Disclosure

QuantaSeal welcomes responsible disclosure of security vulnerabilities. If you believe you have found a security issue in our platform or any QuantaSeal-owned service, please:

1. Email security@quantaseal.io with a detailed description of the vulnerability, steps to reproduce, and potential impact.
2. Encrypt sensitive reports using our PGP public key (available on request).
3. Do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and remediate — typically 90 days.
4. Do not access, modify, or delete customer data during your research.

We commit to:

• Acknowledge receipt of your report within 2 business days.
• Keep you informed of our investigation progress.
• Not pursue legal action against researchers acting in good faith under this policy.
• Publicly credit researchers (with permission) when vulnerabilities are resolved.

15. Policy Updates

This Security Policy is reviewed and updated at least annually, or following any significant security incident, material change to our infrastructure, or relevant regulatory update. Changes will be reflected by an updated Effective Date. We will notify enterprise customers of material changes to this policy.