Security & Compliance

Zero-egress architecture. Quantum-resilient cryptography. A compliance matrix you can audit.

Last Updated: October 17, 2026

1. Overview

QCEgateway is a sovereign edge orchestration fabric. This page describes the security and compliance posture that governs every workload you deploy through the gateway: global CDN, edge compute, AI gateways, agent runtime, and identity.

Three commitments anchor the posture. Each is enforceable, auditable, and verifiable on demand.

Zero-egress by default. Client data, prompts, embeddings, and inference outputs never traverse outside the sovereign boundary unless you explicitly authorize an allowlisted destination.
Quantum-resilient by design. Every key exchange, signature, and long-lived secret is hybridized against post-quantum algorithms (NIST FIPS 203/204/205) from day one. Not as a roadmap item.
Auditable compliance. Every framework we claim is enumerated in a matrix with scope, evidence, and last-audit date. See Section 14.

2. Zero-Egress Architecture

Zero-egress is the default operating mode of the QCEgateway fabric. Data you place inside the gateway stays inside the gateway. Egress is denied unless an allowlisted destination is explicitly authorized by your policy.

2.1 What zero-egress means

Inference stays local. Sovereign reasoning runs against the in-boundary inference pool (QCE-LOCAL-2, 27B parameters). No prompt, embedding, or completion is transmitted to a third-party provider for these paths.
Storage stays sovereign. Object storage, relational databases, vector stores, and audit logs are hosted within the QCEgateway sovereign boundary. Cross-region replication only occurs between sovereign PoPs.
Telemetry stays contained. Metrics, traces, and logs are aggregated inside the fabric. External observability sinks are opt-in and require an explicit allowlist entry.
Identity stays anchored. Authentication and authorization decisions are made locally against your configured identity provider. No external IdP is required for gateway-issued sessions.

2.2 How egress is controlled

Deny-by-default egress policy. Every workload starts with an empty egress allowlist. Destinations are added by explicit, reviewable policy change.
Per-workload egress budgets. Each workload carries a maximum egress rate and byte budget. Exceeding the budget throttles the workload and raises an alert.
Deep packet inspection on egress paths. Egress traffic is inspected for protocol conformance and destination allowlist membership. Non-conforming flows are dropped and logged.
Cryptographic egress proof. Every egress event is recorded in a Merkle-rooted audit log. The root is signed at a fixed cadence and published to your tenant. You can independently verify that no unrecorded egress occurred.

2.3 Regional anchoring

Primary jurisdiction: Singapore. Data residency is Singapore-anchored by default.
Secondary jurisdiction: Delaware, United States. Used for contractual and corporate governance, not for customer data.
Sovereign strata. Government and regulated customers can pin workloads to a dedicated sovereign stratum. In this mode, no cross-stratum egress is possible, even for internal QCEgateway operations.

2.4 Verifying zero-egress on demand

Pull the current egress allowlist for any workload via the console or API.
Replay the signed egress audit log and verify the Merkle root independently.
Run a synthetic probe from inside your workload and observe that non-allowlisted destinations are dropped at the fabric edge.
Request an attestation letter at security@qcegateway.com.

3. Quantum-Resilient Cryptography

The migration to post-quantum cryptography is not a future project. It is the current default for every QCEgateway key exchange, signature, and long-lived secret. We hybridize classical and post-quantum algorithms so that a compromise of either family does not compromise the system.

3.1 Post-quantum algorithms in production

Key encapsulation: ML-KEM-768 (FIPS 203), hybridized with X25519 for key exchange across all control-plane and data-plane channels.
Digital signatures: ML-DSA-65 (FIPS 204), hybridized with Ed448 for signed artifacts, gateway attestations, and audit-log roots.
Stateless hash-based signatures: SLH-DSA (FIPS 205) available for firmware, boot-chain, and long-lived root-of-trust signatures.
Hashing: SHA-3 and SHAKE256 for all new cryptographic constructions. SHA-2 remains supported for legacy interop, never as the sole primitive.

3.2 Harvest-now-decrypt-later defense

Adversaries today can record encrypted traffic and decrypt it later, once a cryptographically relevant quantum computer exists. QCEgateway closes this window for every channel we control.

All TLS sessions use hybrid key exchange (X25519 + ML-KEM-768). Recorded traffic cannot be decrypted by a future quantum adversary.
Long-lived secrets (root keys, signing keys, data-at-rest keys) are generated using post-quantum-safe sources and never derived from classical-only primitives.
Backups and archives are encrypted with hybrid envelopes. An archive created today remains confidential against a future quantum adversary.

3.3 Crypto-agility

Algorithm selection is policy-driven. Pin a workload to a specific algorithm suite, or let it track the QCEgateway default.
Rotation without re-architecture. Rotating a signature scheme or key-encapsulation algorithm does not require re-deploying your workload.
Dual-signing during transition. During algorithm migrations, artifacts are signed with both the outgoing and incoming schemes, so verification succeeds regardless of the verifier's capability.

3.4 Key management

Hardware Security Modules. Root keys are generated inside FIPS 140-3 Level 3 HSMs. They never leave the HSM in plaintext.
Rotation cadence. 90 days by default for operational keys, configurable down to 24 hours. Root keys rotate on a 12-month cadence with a documented ceremony.
Split custody. Root key ceremonies require quorum approval from at least two independent custodians. Ceremony transcripts are signed and archived.
Revocation. Compromised keys are revoked via a signed CRL published to every gateway PoP within 60 seconds of detection.

4. Zero-Trust Principles

The QCEgateway control plane is built on the principle of never trust, always verify. Every access request is authenticated, authorized, and encrypted regardless of its origin.

Verify explicitly. Authenticate and authorize based on all available signals: user identity, device posture, workload identity, data classification, and behavioral anomaly.
Least privilege. Grant only the minimum access necessary for a role, with just-in-time and just-enough-access (JIT/JEA) and risk-based adaptive policy.
Assume breach. Segment workloads by default. Encrypt end-to-end. Instrument everything so that a compromise is detected and contained before it spreads.

5. Identity and Access Management

5.1 Authentication

Multi-factor authentication. Required for all user accounts, administrative access, and API integrations.
Single sign-on. SAML 2.0 and OIDC enterprise identity providers supported natively.
Passwordless. Hardware security keys (FIDO2/WebAuthn) and biometric authentication supported.
Session management. Automatic session expiration, idle timeouts, and secure session handling.

5.2 Authorization

Role-based access control. Granular permissions based on job function and responsibility.
Attribute-based access control. Dynamic policy enforcement based on context and attributes.
Least privilege enforced. Users receive only the minimum access necessary for their role.
Quarterly access reviews. Access rights and permissions are reviewed every quarter.

5.3 Privileged access management

Just-in-time privileged access with automatic expiration.
Privileged session recording and monitoring.
Separation of duties for critical operations.
Emergency access procedures with break-glass accounts.

6. Network Security

6.1 Network segmentation

Micro-segmentation of network resources.
Isolated environments for development, staging, and production.
Software-defined perimeter for application access.
Network access control lists and security groups.

6.2 Traffic protection

Web Application Firewall on all public endpoints.
DDoS protection and mitigation at the fabric edge.
Intrusion detection and prevention systems.
TLS 1.3 with hybrid post-quantum key exchange for all communications.

6.3 Remote access

Zero-trust network access for remote operators.
Device posture assessment before granting access.
Geo-blocking and IP allowlisting where appropriate.

7. Data Protection

7.1 Encryption

Data in transit. TLS 1.3 with hybrid X25519 + ML-KEM-768 key exchange for all API communications, webhooks, and data transfers.
Data at rest. AES-256-GCM encryption for all stored data, including databases, file systems, and backups.
Key management. FIPS 140-3 Level 3 Hardware Security Modules for cryptographic key storage and management.
Field-level encryption. Additional encryption for sensitive fields such as credentials and personal data.

7.2 Data classification

Public. Information intended for public disclosure.
Internal. Business information for internal use only.
Confidential. Sensitive business data requiring protection.
High Value Data. Critical data requiring the highest protection levels: PII, financial data, credentials, and inference inputs.

7.3 Data handling

Data minimization: collect only what is necessary.
Purpose limitation: use data only for stated purposes.
Secure data disposal and sanitization procedures.
Data masking and tokenization for non-production environments.

8. Application Security

8.1 Secure development

Secure Software Development Lifecycle (SSDLC).
Security requirements captured in design and planning phases.
Threat modeling for new features and services.
Security code reviews and peer reviews.

8.2 Testing and validation

Static Application Security Testing (SAST).
Dynamic Application Security Testing (DAST).
Software Composition Analysis (SCA) for dependencies.
Regular penetration testing by qualified third parties.

8.3 Deployment security

Infrastructure as Code with security controls.
Container image scanning and signing.
Immutable infrastructure deployments.
Automated security validation in CI/CD pipelines.

9. Endpoint and Workload Security

9.1 Endpoint protection

Endpoint Detection and Response (EDR) on all corporate devices.
Mobile Device Management (MDM) for mobile devices.
Automated patch management and vulnerability remediation.
Device encryption requirements.

9.2 Workload protection

Runtime application self-protection (RASP).
Container security and runtime monitoring.
Serverless function security controls.
Cloud workload protection platforms (CWPP).

10. Monitoring and Logging

10.1 Security monitoring

24/7 Security Operations Center (SOC) monitoring.
Security Information and Event Management (SIEM).
User and Entity Behavior Analytics (UEBA).
Real-time alerting and automated response.

10.2 Audit logging

Comprehensive audit trails for all system activities.
Tamper-evident log storage with Merkle-rooted integrity proofs.
Log retention according to compliance requirements.
Regular log review and analysis.

11. Vendor and Third-Party Risk

Security assessment of all vendors before engagement.
Contractual security requirements and data protection clauses.
Regular vendor security reviews and audits.
Subprocessor management and transparency.
Supply chain security controls, including software bill of materials (SBOM) verification.
No vendor receives customer data unless explicitly allowlisted under the zero-egress policy (Section 2).

12. Incident Response

12.1 Incident management

Documented incident response plan and procedures.
Defined roles and responsibilities for incident handling.
Incident classification and severity levels.
Communication protocols for stakeholder notification.

12.2 Response phases

Detection. Automated monitoring and alerting systems.
Analysis. Rapid triage and impact assessment.
Containment. Isolation of affected systems and data.
Eradication. Removal of threat actors and vulnerabilities.
Recovery. Restoration of normal operations.
Post-incident. Root cause analysis and lessons learned.

12.3 Notification

In the event of a security incident affecting client data, we notify affected parties in accordance with applicable laws and contractual obligations, typically within 72 hours of a confirmed breach. For Singapore-anchored tenants, PDPA notification timelines apply.

13. Business Continuity and Disaster Recovery

Business Impact Analysis (BIA) for critical services.
Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined per service tier.
Geographically distributed data replication within sovereign PoPs.
Regular backup testing and validation.
Disaster recovery drills and tabletop exercises.
Documented recovery procedures and runbooks.

14. Compliance Matrix

Every framework below is claimed on the basis of a current audit, attestation, or alignment assessment. This matrix is the authoritative record. Where a framework is in progress, the target window is stated.

Framework	Status	Scope	Evidence	Last Audited
SOC 2 Type II	Certified	Security, Availability, Confidentiality	Request report	2026-Q3
ISO/IEC 27001:2022	Certified	Information Security Management System	Certificate	2026-Q3
ISO/IEC 27701	Certified	Privacy Information Management	Certificate	2026-Q3
ISO/IEC 42001	Attested	AI Management System	Statement	2026-Q2
GDPR	Aligned	EU data subject rights, DPA available	DPA	2026-Q3
Singapore PDPA	Aligned	Primary jurisdiction compliance	Notice	2026-Q3
CCPA / CPRA	Aligned	California consumer rights	Notice	2026-Q3
HIPAA	Aligned	Healthcare workloads, BAA available	BAA	2026-Q2
PCI DSS v4.0	In Progress	Payment flows (SAQ-D)	AOC (target)	2026-Q4 (target)
NIST SP 800-53 Rev 5	Aligned	Moderate baseline control mapping	Control matrix	2026-Q3
NIST AI RMF 1.0	Aligned	AI risk management framework	Statement	2026-Q3
FIPS 203 / 204 / 205	Implemented	Post-quantum cryptography (ML-KEM, ML-DSA, SLH-DSA)	Crypto statement	2026-Q3
CIS Benchmarks	Aligned	Linux and container hardening	Baseline	2026-Q3
EU AI Act	Readiness	GPAI obligations readiness	Readiness memo	2026-Q4 (target)

Full evidence packs (audit reports, attestation letters, penetration-test summaries, control matrices) are available under NDA. Contact compliance@qcegateway.com.

15. Customer Responsibilities

Security is a shared responsibility. Customers are responsible for:

Maintaining strong authentication credentials.
Enabling MFA on all accounts.
Managing access rights for their users.
Reporting suspected security incidents promptly.
Complying with acceptable use policies.
Securing their own systems and networks.
Protecting API keys and access tokens.
Configuring egress allowlists deliberately (zero-egress is enforced, but allowlists are your responsibility).

16. Responsible Disclosure

We welcome and encourage security researchers to report potential vulnerabilities through our responsible disclosure program.

Reporting guidelines

Report vulnerabilities to security@qcegateway.com.
Provide sufficient detail for us to reproduce and verify the issue.
Allow reasonable time for remediation before public disclosure.
Do not access or modify other users' data.
Do not perform denial-of-service attacks.

We commit to acknowledging receipt within 24 hours and providing regular updates on remediation progress.

17. Security Awareness

Mandatory security awareness training for all employees.
Role-specific security training for developers and administrators.
Regular phishing simulations and social engineering tests.
Continuous education on emerging threats, including post-quantum migration and AI-specific attack surfaces.

18. Policy Updates

This Security and Compliance Policy is reviewed and updated at least annually, or more frequently as needed to address new threats, technologies, or regulatory requirements. Material changes are communicated to affected parties. Cryptographic algorithm updates are governed separately under the crypto-agility policy (Section 3.3).

19. Contact Information

For security-related inquiries or to report a security concern:

Security Team

Email: security@qcegateway.com

Compliance: compliance@qcegateway.com

Jurisdiction: Singapore (primary) · Delaware (secondary)

For urgent security incidents, include URGENT in your email subject line.