Skip to main content

​
Infrastructure and network

​
Current state

The frontend is hosted on Vercel in the European Union. Requests are filtered by the Vercel Firewall and terminate over HTTPS. Cloudflare is placed before the backend APIs (edge/WAF/DDoS), Vercel WAF is used for the frontend. All Cloudflare connections enforce a minimum of TLS 1.2 and prefer TLS 1.3. Our backend runs on Hetzner in Nuremberg, Germany. Ingress is restricted to Cloudflare origins and management endpoints. Administrative access requires multi-factor authentication and is fully logged. Data is stored in NeonDB in Frankfurt, Germany on AWS servers. Storage is encrypted at rest and all client connections require TLS.

​
Geographic locations

Frontend and database workloads run in Frankfurt, Germany. The backend runs in Nuremberg, Germany and is scheduled to migrate to AWS in Frankfurt.

​
Planned upgrades

We are moving the database to AWS RDS in Frankfurt with KMS-managed encryption at rest and automated backups. The backend will move to AWS in the EU within private subnets and tightly scoped security groups with controlled egress. All services will run in isolated AWS accounts per environment (prod/staging/dev), with VPC-level isolation and per-service IAM roles following least-privilege. The planned migration will take place in Q4 2025.

​
Data flow (high level)

  1. User/browser connects directly to the frontend over HTTPS.
  2. Frontend communicates with backend APIs over HTTPS through Cloudflare with origin restrictions.
  3. Backend retrieves and decrypts secrets in-memory as needed using AWS KMS envelope encryption and never writes plaintext secrets to disk.
  4. Backend reads/writes encrypted records in NeonDB over TLS. The database persists only ciphertext for secret values.

​
Encryption and key management

​
Envelope encryption with AWS KMS

​
Per-environment keys

Within Enkryptify, every project contains one or more environments (for example: development, staging, production). Each of these project environments has its own data-encryption key (DEK). This scope ensures that compromising one project environment does not grant access to others—even within the same project—let alone to other projects.

​
Generation and storage

When encryption is needed, the backend asks AWS KMS to generate or decrypt a DEK under our managed KMS key. KMS returns the DEK in two forms: a plaintext DEK (used transiently in memory) and an encrypted DEK (often called an EDEK) that only KMS can unwrap. We store only the EDEK alongside the ciphertext. The plaintext DEK is never persisted.

​
Decryption and disposal

To decrypt a value, the backend sends the EDEK to KMS, receives the plaintext DEK in memory and uses it to decrypt the ciphertext (AES-GCM). Plaintext exists only in process memory for the duration of the operation and is discarded immediately after use. Plaintext is never logged or written to disk.

​
Rotation and re-encryption

  • Planned: automatic daily rotation of DEKs for each project environment without downtime.
  • Current state: rotation is performed manually ad-hoc (also without downtime) by rewrapping DEKs and progressively resealing stored values.

​
Multi-layer encryption and transport posture

Secret data is protected by multiple, independent layers of encryption whose keys are managed on different platforms. Application-level encryption (envelope encryption using AWS KMS) ensures the database stores only ciphertext, the database provider also encrypts storage at rest with its own keys. Because each layer is governed by a distinct provider and control plane, a compromise of any single provider does not expose plaintext data. All network traffic requires TLS 1.2 or higher. In practice, more than 99% of traffic uses TLS 1.3. Origin restrictions and firewall rules further reduce exposure, and plaintext secrets are confined to process memory only during cryptographic operations. We also enforce HSTS (max age is 6 months; applied to all subdomains; preload enabled and No-Sniff Header included).

​
Authentication and session security

Authentication and session management are handled by Clerk. We support OAuth providers only and do not offer email/password logins. Within the application, authorization is enforced at the role and project scope for all actions, including secret retrieval. Administrative operations require elevated roles and are fully audited. Session cookies are HttpOnly and Secure. For API requests, the session token is presented as a Bearer token in the Authorization header, and state-changing operations include CSRF protections.

​
CLI security model

​
Authentication

The ek login command opens a browser window to complete an OAuth flow with Clerk. After successful authentication, a short-lived code is exchanged for a token that the CLI stores securely on your machine.

​
Token storage

By default, the token is written to the operating system’s credential store (macOS Keychain, Linux Secret Service/KWallet or Windows Credential Manager). In environments without a credential store (for example, minimal containers or some servers), skip ek login and provide an API key via the ENKRYPTIFY_TOKEN environment variable. The CLI reads this environment variable when present and does not attempt to persist credentials to disk.

​
Audit logging and tamper evidence

We record all permanent actions (create, update and delete) as well as sensitive reads such as secret views. Each record includes the actor, target, timestamp, data before and data after (if applicable). The logging system is append-only. To make tampering evident, each entry carries a hash of its own content using SHA256 and the hash of the previous entry, forming a verifiable hash chain. Any modification or deletion breaks the chain and is detected during verification. Periodic verification processes recompute and compare hashes to ensure integrity.

​
Employee access to customer data

Employees cannot view plaintext customer secrets. Decryption is performed exclusively by backend services using AWS KMS under tightly scoped service identities and plaintext exists only in process memory for the duration of a request. We do not provide internal tooling to display or export plaintext secrets and IAM/KMS policies deny decrypt permissions to human identities. Operational access to production infrastructure uses short-lived, audited credentials and is limited to tasks that do not require viewing secrets. In exceptional incident scenarios, a time-bound, multi-party break-glass workflow is required to perform changes. This grants narrowly scoped infrastructure privileges and does not enable human decryption of customer secrets. All steps are strongly authenticated, justified and continuously monitored with real-time alerting. We enforce separation of duties and least privilege across environments and accounts. As we complete the AWS migration, we are adding further controls such as m-of-n approvals and strengthened key custody to reduce blast radius even more.

​
Compliance and testing

We are actively working toward ISO 27001 with Vanta with our audit scheduled for mid-December 2025. Independent penetration tests occur annually; the first engagement is scheduled for November 2025. During day-to-day development, dependencies are scanned continuously, critical findings are triaged and remediated quickly and every change goes through code review and CI checks before deployment.

​
Responsible disclosure and contact

We appreciate reports from the security community. To report a vulnerability or suspected issue: Email us at security@enkryptify.com. Please include a clear description, steps to reproduce, potential impact and any relevant logs or screenshots. Avoid accessing data that does not belong to you, if you are unsure whether something is sensitive or in scope, contact us and we will guide you. We will investigate promptly and keep you informed. If you are unsure whether something is in scope or sensitive, reach out and we will guide you.
⌘I