Security model

​

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. Our backend runs on AWS in the eu-central-1 region (Frankfurt, Germany). Services are deployed within private subnets with tightly scoped security groups. 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).

​

Data flow (high level)

1. User/browser connects directly to the frontend over HTTPS.
2. Frontend communicates with backend APIs over HTTPS.
3. Backend services running on AWS 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.
4. 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 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. 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. 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.

​

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), this is not possible yet due to security restrictions. 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. See Audit logging for details on what is logged and how tamper evidence works.

​

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).

​

Access control

Workspace access is managed with role-based access control (RBAC) and granular scoping down to the environment level. See Roles and permissions for details.

​

Compliance and testing

Enkryptify is ISO 27001 certified. Independent penetration tests occur annually. 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.