Encryption, Key Management, and Data Destruction

Scope of this document

This page is the canonical cryptographic reference for Zeuslock. It is written for security architects performing vendor assessments, CISOs preparing risk reviews, and auditors mapping our controls to SOC 2 Type II, ISO 27001, and ENS. Every algorithm, region, and rotation cadence listed here matches the configuration deployed in production. If anything is unclear, your account team can provide the underlying KMS key IDs, CloudTrail samples, and DPA on request.

Zeuslock's threat model assumes a sophisticated, well-funded adversary with intermittent access to network paths and the possibility of legal compulsion against cloud providers. The controls below are designed to keep customer data confidential even in those scenarios, and to give Sovereign Edition customers the ability to revoke our access at any moment.

Encryption in transit

All traffic between the browser extension, desktop agent, CLI, and the Operator Console terminates on TLS 1.3 only. Older protocols (TLS 1.0, 1.1, 1.2) are disabled at the load balancer. Cipher selection follows the Mozilla Modern profile: AEAD ciphers only, ECDHE for Perfect Forward Secrecy, and HTTP/2 as the application-layer protocol.

Strict-Transport-Security is served on every response with max-age=31536000; includeSubDomains; preload, and zeuslock.ai is on the Chromium HSTS preload list. The desktop agent additionally enforces certificate pinning. We use multiple pin slots with overlapping validity windows so that certificate rotation never bricks an agent in the field — operators can roll a new certificate weeks before retiring the old pin.

TLS profile at a glance

Encryption at rest

All persisted data is encrypted with AES-256-GCM. Each customer tenant is partitioned at the storage layer; queries cannot cross tenant boundaries even with elevated database credentials. Backups are written to a separate AWS account, encrypted with a distinct KMS key, and region-locked to the EU. Cross-region replication is disabled by default and only enabled at the customer's explicit request.

Encryption matrix

Key management

Default tenants: Zeuslock-managed KMS

Default plans use AWS KMS in eu-west-3 (Paris). Master keys (CMKs) are rotated automatically every 365 days; on-demand rotation is available through our internal API and propagates to all encrypted resources within minutes. Data keys are generated per object via GenerateDataKey so the same DEK is never reused across customers or even across incidents within the same tenant.

Access to KMS administrative operations is gated by dual control: no single engineer can decrypt customer material or disable a key. Key policies pin kms:Decrypt to the production service role only, and break-glass access requires two SREs plus a security officer with separate hardware tokens. Every Encrypt, Decrypt, and GenerateDataKey call emits a CloudTrail event with the calling principal, source IP, encryption context, and request ID.

Sovereign Edition: customer-managed keys (BYOK)

Sovereign Edition customers provide an AWS KMS key in their own AWS account. Zeuslock receives a cross-account grant — never a key copy. The grant is scoped to the minimum operations required (Decrypt, GenerateDataKey) and explicitly excludes destructive verbs. If the customer revokes the grant or disables the key, Zeuslock loses access immediately and all encrypted material — incidents, payload snapshots, audit logs — becomes unreadable.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ZeuslockProdGrant",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ZEUSLOCK_PROD_ACCOUNT_ID:role/zeuslock-data-plane"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "dynamodb.eu-west-3.amazonaws.com",
          "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/TenantId}"
        }
      }
    },
    {
      "Sid": "DenyDestructive",
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::ZEUSLOCK_PROD_ACCOUNT_ID:role/zeuslock-data-plane"
      },
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey",
        "kms:PutKeyPolicy",
        "kms:RevokeGrant"
      ],
      "Resource": "*"
    }
  ]
}

The encryption context binds each operation to a specific tenant ID, so even a compromised data-plane role cannot decrypt a different customer's data. We recommend mirroring this policy verbatim, customising only the principal ARN and the tenant ID tag scheme.

Rotation cadence

• Data keys (DEKs): rotated automatically per object via GenerateDataKey. No reuse.
• Master keys (CMKs): rotated annually by AWS KMS; immediate re-encryption of headers, lazy re-encryption of payloads.
• On-demand: any customer can request out-of-cycle rotation via support or the management API; we complete it within 24 hours and confirm with a CloudTrail extract.
• TLS certificates: rotated every 90 days; pin slots overlap by at least 30 days.

Internal secrets handling

No plaintext secret ever sits in source code, container images, environment variables, or CI logs. Production credentials are stored in AWS Secrets Manager and fetched at runtime through short-lived federation tokens (1-hour TTL) issued via AWS STS. Static IAM access keys are forbidden in production accounts and blocked by a service control policy.

Developers never receive production secrets on their workstations. Local development uses isolated sandbox accounts with synthetic data, and pre-commit hooks plus the Zeuslock CLI itself scan every commit for credential patterns before push.

Data destruction guarantees

Right to erasure (GDPR Article 17)

An erasure request submitted via the Operator Console or the REST API triggers a hard delete within 24 hours across the live data plane. The same identifiers are then purged from rolling backups within 30 days, matching the backup retention window. We issue a signed deletion certificate on completion.

Customer offboarding

When a customer terminates their contract we perform cryptographic shredding first: the per-tenant master key is deleted, which renders every encrypted blob mathematically irrecoverable within seconds — including any in-flight backups. Physical deletion of the underlying storage objects is then scheduled and completed within 30 days. Sovereign Edition customers can perform the shred themselves by deleting their KMS key; we cannot block or delay this action.

Backup retention

Backups are kept on a 30-day rolling window. Older snapshots are overwritten in place; we never archive customer data to colder storage tiers without explicit consent.

Audit and transparency

Every cryptographic operation — TLS handshakes, KMS calls, secret retrievals — generates a structured log forwarded to our SIEM. KMS event records are retained for one year and can be exported to a customer on request, either as a CloudTrail JSON dump or as a CSV reconciliation. Sovereign Edition customers see these events directly in their own CloudTrail without involving us.

Our controls are aligned with SOC 2 Type II (Security, Availability, Confidentiality) and ISO 27001 Annex A. We are audited annually; the latest report and bridge letter are available under NDA.

FAQ

Can Zeuslock decrypt my data if subpoenaed by US authorities?

Sovereign Edition: no. We do not hold the key. We can hand over ciphertext that we are unable to read, and we will notify you unless legally gagged. Default plan: data is hosted in France and processed under French law. We push back on extraterritorial requests, require valid mutual legal assistance treaty (MLAT) procedure, and publish an annual transparency report.

What hash algorithms do you use for sensitive identifiers?

SHA-256 with a per-tenant salt for any cryptographic use (deterministic lookups, fingerprinting, deduplication of sensitive identifiers). We use BLAKE3 for non-cryptographic deduplication of large payloads where speed matters and adversarial collisions are not part of the threat model. MD5 and SHA-1 are banned in new code.