> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cymph.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Security architecture

> How Cymph is deployed, where the trust boundaries sit, and how tenant data is separated.

This page is a summary of Cymph's security posture for security reviewers, architects and procurement teams. It covers both deployment models; where they differ, the difference is called out.

## Deployment models

Cymph is delivered as a **managed cloud tenant** or as a **self-hosted** deployment. Both are dedicated single-instance deployments running the same product — neither is a shared multi-tenant service. What differs is who operates the infrastructure.

|                                                | Managed cloud tenant               | Self-hosted                                |
| ---------------------------------------------- | ---------------------------------- | ------------------------------------------ |
| Infrastructure operated by                     | Cymph                              | You                                        |
| Location                                       | AWS `eu-west-1` (Europe / Ireland) | Your infrastructure                        |
| Database                                       | AWS managed PostgreSQL             | PostgreSQL container inside the deployment |
| TLS certificates, DNS, backups, upgrades       | Cymph                              | You                                        |
| Encryption key custody                         | Cymph                              | You                                        |
| Network path to integrations                   | Cymph's egress addresses           | Entirely within your network               |
| AI provider                                    | Supplied by you, or disabled       | Supplied by you, or disabled               |
| Application configuration, users, integrations | You                                | You                                        |

[Deployment models](/deployment/models) has the full responsibility split. A self-hosted deployment has no runtime dependency on Cymph: it does not call home for licensing, updates or telemetry — see [Architecture](/deployment/self-hosted/architecture) for the full service inventory.

## Trust boundaries

A deployment has exactly one externally exposed entry point: the `nginx` service, which terminates TLS and reverse-proxies to the application. The web application, API, embedding service and database are bound to an internal network only — none of them is published on the host — so every request that reaches the application has passed through TLS termination. There is no second, unencrypted path in.

See [Networking](/deployment/networking) for the inbound and outbound specifics.

Outbound, Cymph connects only to the integration endpoints you configure and to an AI provider if one is enabled. Semantic search embeddings are generated by a service inside the deployment, so playbook content is not sent anywhere for search to work.

## Tenant and data isolation

Each customer deployment — managed or self-hosted — is a **separate instance with its own database**. There is no shared data store across customers.

Within a deployment, Cymph uses **logical data isolation**: users and organisations share the instance while their data remains segregated. The isolation boundary is the **workspace**. Playbooks, executions, assets, integrations and presets all belong to a workspace, and access is determined by workspace membership:

* Every user has a private **individual workspace** that nobody else can be added to.
* Every organisation has a **default workspace** that all members join automatically, and which they leave automatically when they leave the organisation.
* Organisation admins can create **additional workspaces** with independently managed member lists, so a subset of the organisation can work in isolation from the rest.

[Workspaces](/key-features/workspaces) covers the model in full, including how membership is managed.

Organisation membership is a separate axis: a user belongs to one organisation at a time, and their [role](/administration/user_roles) within it determines what administrative actions they can take and how widely they can share playbooks.

## Encryption

**In transit.** All browser and API traffic is served over HTTPS. In a self-hosted deployment you supply the certificate and key and TLS is terminated at nginx — see [TLS certificates](/deployment/self-hosted/tls-certificates); in a managed tenant Cymph provisions and renews them. Connections from the application to PostgreSQL can additionally require SSL, and are configured to do so whenever the database is not on the same host as the application.

**At rest.** Sensitive integration data — the credentials, tokens and endpoint secrets you enter when configuring a SIEM, SOAR platform, ticketing system or repository — is encrypted before it is stored, using key material generated at random when the deployment is created. In a self-hosted deployment that key material (`CYMPH_ENCRYPTION_KEY` and `CYMPH_ENCRYPTION_IV`) is generated on your host and never leaves it.

See [Data protection](/security/data-protection) for what this means for backups and key custody.

## Authentication and authorisation

Accounts authenticate with a password plus optional TOTP multi-factor authentication, or through an external identity provider. Authorisation is role-based at the organisation level and membership-based at the workspace level. See [Authentication & access control](/security/authentication-access-control).

## Auditability

Administrative and product activity is recorded and reviewable in the application, with actor, target and metadata per event. See [Audit & logging](/security/audit-logging).