Skip to main contentInfrastructure 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 AWS Fargate in the eu-central-1 region (Frankfurt, Germany). Services are deployed within private subnets with tightly scoped security groups. Ingress is restricted to Cloudflare origins only. Egress is controlled through security group rules that allow only essential outbound connections to AWS services (KMS, Secrets Manager) and the database. All traffic between services uses VPC endpoints where available to keep data within the AWS network backbone.
Data is stored in NeonDB in Frankfurt, Germany on AWS servers. Storage is encrypted at rest and all client connections require TLS.
Geographic locations
All infrastructure runs in Frankfurt, Germany (AWS eu-central-1 region).
Architecture and isolation
Services run in isolated AWS accounts per environment (production, staging, development). Each environment has its own VPC with network-level isolation. IAM roles are scoped per service following least-privilege principles. ECS task roles grant only the permissions required for each service to function—for example, the API service can decrypt with specific KMS keys but cannot modify IAM policies or access other accounts.
Administrative access to AWS is federated through AWS IAM Identity Center with mandatory multi-factor authentication. All access is temporary and fully logged to CloudTrail. Production access requires justification and is reviewed regularly.
Data flow (high level)
- User/browser connects directly to the frontend over HTTPS.
- Frontend communicates with backend APIs over HTTPS through Cloudflare with origin restrictions. Cloudflare validates requests before they reach AWS.
- Backend services running on AWS Fargate retrieve and decrypt secrets in-memory as needed using AWS KMS envelope encryption and never writes plaintext secrets to disk. ECS tasks use ephemeral storage that is automatically destroyed when tasks stop.
- Backend reads/writes encrypted records in NeonDB over TLS. The database persists only ciphertext for secret values. Database credentials are managed through AWS Secrets Manager and automatically rotated.
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. Data in transit between AWS services uses AWS PrivateLink and VPC endpoints where available, keeping traffic on the AWS network backbone and never traversing the public internet. Origin restrictions and security group 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).
ECS tasks use AWS-managed encryption for ephemeral storage volumes. Task metadata and environment variables containing sensitive configuration are encrypted using AWS KMS and injected at runtime from AWS Secrets Manager.
Authentication and session security
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. 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 ECS task role 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 through AWS IAM Identity Center 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 via change tickets and continuously monitored with real-time CloudWatch and CloudTrail alerting.
We enforce separation of duties and least privilege across environments and AWS accounts. Production and non-production workloads are isolated in separate AWS accounts with no cross-account IAM trust except for narrowly scoped deployment roles. KMS keys have resource-based policies that explicitly deny decrypt operations from human principals and grant access only to service roles with specific conditions (such as VPC origin checks).
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.
We appreciate reports from the security community. To report a vulnerability or suspected issue:
Email us at [email protected]. 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. 