Trust & Security

Cerynix does not yet hold third-party certifications. You will not find a SOC 2 or ISO/IEC 27001 badge on this page, because we have not completed those audits — and we won't display badges we haven't earned.

What we can say truthfully today:

• The product's own control library is aligned to ISO/IEC 27001:2022 and NIS2, and we run Cerynix on Cerynix — our internal security programme is managed in the product itself.
• Formal certification is on the roadmap; as an early-stage vendor we prioritise the engineering controls described below first.
• Our infrastructure providers carry their own attestations (see sub-processors), which cover the hosting layer — not the Cerynix application.

Isolation between customers is enforced in two independent layers:

• Application layer. Every tenant-scoped row carries an organization and workspace id, and every query filters on the authenticated principal's tenant. Cross-tenant access returns 404 — not 403 — so even the existence of another tenant's data is never leaked. This behaviour is covered by a dedicated automated test suite.
• Database layer. PostgreSQL Row-Level Security is available as defense-in-depth beneath the application filter: RLS policies are enabled — and forced with FORCE ROW LEVEL SECURITY — on every tenant table, matching a per-request transaction variable. The application connects as a non-superuser role so the policies actually bind, and enforcement is verified at deploy time.

On top of that, self-hosted deployments give you the strongest isolation there is: your instance runs entirely on your own infrastructure, with no cloud dependency and no phone-home.

• No hardcoded secrets. All secrets (JWT key, database, cache and object-store credentials) come from the environment; CI runs an enforced secret scan on every change.
• Passwords are hashed with bcrypt — no plaintext, no reversible storage.
• API tokens are stored hashed; only a short prefix is indexed for lookup.
• Integration credentials (e.g. an Entra ID client secret) are encrypted at rest with Fernet and are never returned by the API — endpoints expose only a "has secret" flag.
• Backups are encrypted with age before they leave the box (see backups).
• Object storage keys are namespaced per organization; the local backend prevents path traversal.

• TOTP multi-factor authentication (RFC 6238) with enrolment, verification and backup codes, including a replay guard. The login flow issues a dedicated MFA-challenge token that cannot be used as a session.
• Enterprise sign-on: SAML SSO, LDAP authentication and SCIM 2.0 provisioning.
• Short-lived JWT sessions (access + refresh pair) with configurable lifetimes.
• Account lockout after repeated failed logins, with uniform failure messages to prevent user enumeration.
• Rate limiting: tight per-endpoint limits on auth routes plus a coarse per-IP throttle on every mutating request.
• Role-based access control with five system roles (admin, security manager, IT manager, auditor, executive) resolved from a single in-code permission matrix — fast, testable and auditable.

• Security headers on every response: X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy, cross-origin isolation headers, a restrictive Permissions-Policy and Strict-Transport-Security over TLS.
• Strict Content-Security-Policy for the web app: per-request script nonces with strict-dynamic — no unsafe-inline, no arbitrary script hosts — and connect-src 'self' so an injected script has nowhere to exfiltrate to. A second CSP layer at the reverse proxy covers anything the middleware doesn't.
• API responses are never cached (Cache-Control: no-store) so tenant data can't linger in intermediaries; CORS is restricted to configured origins.
• Minimal network surface: only the reverse proxy (80/443) and SSH face the network. The database, cache, object store and raw API bind to loopback; /metrics is blocked from the internet and interactive API docs are disabled in production.

Append-only audit logs capture logins and failures, role and permission changes, control status changes, evidence upload, deletion and export, risk acceptance, management approvals, member invites and more — with actor, IP, user agent, before/after state, severity and correlation id.

The ledger is tamper-evident: each entry is SHA-256 hash-chained to the previous entry per organization, and a verification endpoint recomputes the chain on demand to confirm integrity.

• Signed licensing, no phone-home. License keys are Ed25519-signed offline by the vendor and verified locally by your instance — there is no license server, no telemetry and no callback from your deployment.
• Provenance chain. The codebase maintains a deterministic source manifest with SHA-256 hashes of every file, regenerated and verified in CI, alongside signed commits and signed release tags.
• Continuous scanning in CI: an enforced Trivy secret scan (no hardcoded secrets can merge), a repository vulnerability and misconfiguration scan, and image-level scans of every built container so OS-package and base-image CVEs are caught before release.

The bundled backup tooling encrypts every backup with age public-key encryption before it is written, so a stolen backup file is useless without the key — which the install guide instructs you to keep off the server it protects. The updater snapshots the database and running application before every upgrade and attempts to restore the application snapshot if the new build fails its self-test. Application rollback is not database rollback: a schema migration can require recovery from the pre-upgrade backup. See the upgrade and disaster-recovery runbooks.

See the backups section of the install guide for the exact procedure.

Self-hosted deployments involve no Cerynix sub-processors for your content — your data never leaves your infrastructure. For the managed (SaaS) model, primary storage is in the EU (Germany) and the current sub-processor list is short:

• Per-tenant configurable data retention, and a personal-data flag on evidence records.
• PII and secret masking is required before any external LLM call — AI features never see unmasked personal data.
• Sub-processor changes are notified in advance under the DPA, with a right to object on data-protection grounds.

If you believe you have found a security vulnerability in Cerynix, please report it privately — do not open a public issue or post details publicly before a fix is available.

• Email [email protected] with the subject prefix SECURITY — reports with this prefix are triaged with priority.
• Include reproduction steps, affected component/version and impact as you understand it.
• Disclosure is coordinated: we will acknowledge your report, keep you informed while we fix, and credit you if you wish.