Security & compliance

This page sums up Livqeno's security and compliance status. It covers what is in place today and what is still in progress. If your security team needs more detail, write to security@livqeno.com and ask for the security whitepaper, the subprocessor list or the draft DPA.

Certifications

Livqeno does not hold a SOC 2, ISO 27001 or HIPAA attestation today. We are preparing for SOC 2. Until a report exists, we will not describe the platform as "compliant" with any of these frameworks.

What is in place

Encryption

• Media is always encrypted between your users' apps and our servers with DTLS-SRTP. WebRTC has no unencrypted mode.
• Signaling and chat run over WSS. The REST API runs over HTTPS.
• Stored secrets:
  • Webhook signing secrets, chat moderation-hook secrets, two-factor seeds, restream stream keys and your APNs/FCM push credentials are encrypted with AES-256-GCM. Each value records which key sealed it, so keys can be rotated without downtime.
  • API key secrets and dashboard passwords are hashed with bcrypt and can't be recovered. Two-factor recovery codes are stored only as hashes.
• The database is encrypted at rest by our managed Postgres provider.

Access control

• Each credential does one job. API keys, RTC tokens, chat tokens and dashboard sessions are signed with separate keys. One can never stand in for another. See Security.
• Tokens are short-lived and can be revoked. RTC tokens last 10 minutes by default and chat tokens 1 hour. Your backend can revoke either one early with DELETE /v1/rooms/{roomId}/rtc-tokens/{tokenId} or DELETE /v1/chat/tokens/{tokenId}.
• Dashboard accounts support two-factor authentication. Turn on an authenticator app (TOTP) under Settings → Security and keep the ten single-use recovery codes. A project owner or admin can require two-factor for every member of a project.
• Suspension takes effect at once. When we suspend an account, its dashboard sessions stop working on their next request and the API keys of the projects it owns stop authenticating, within 30 seconds.
• Team access uses roles. Owner, Admin, Developer and Viewer, per project. See Roles & permissions.
• Changes are recorded. Every change to keys, members and webhooks goes in your project's audit log. The database refuses edits and deletions of audit entries, and a failed write is retried rather than dropped.

Tenant isolation

Every API key and token is tied to one project and one environment. The server reads your project from the credential, never from the request body. Our database's public data API is turned off for every table.

Webhooks

• Every delivery is signed with HMAC-SHA256 over a timestamp and the body. Reject anything older than 5 minutes. See Webhooks.
• We refuse to deliver to private or internal network addresses. The check runs when the connection is made.

Supply chain

Every change to the platform goes through these automated checks:

• secret scanning over the full code history;
• dependency vulnerability audits for Node, Python and Go;
• container image scanning;
• weekly dependency updates.

Your data

What we store and for how long

Requests from your users

Use these API-key endpoints when one of your users asks to see or delete their chat data:

• Export: GET /v1/chat/users/{userId}/export
• Erase: DELETE /v1/chat/users/{userId}/data blanks the content of their messages and the edit history of those messages, deletes the attachments they uploaded (the files too), and removes their reactions, read state, devices and blocks. The response counts each. If attachmentObjectsFailed is above zero, storage refused some deletions; the call is safe to repeat.
• Delete a conversation: DELETE /v1/chat/conversations/{room}. Its attachment files are deleted too.

One gap remains: call data has no erase endpoint yet. RTC participant records and usage records are not covered.

Your own account

Under Settings → Security in the dashboard you can:

• Export your data as JSON: profile, sign-in methods, memberships, projects you own with API key metadata, notifications and your activity. It never contains a password hash, key secret or signing secret.
• Delete your account. Schedule each project you own for permanent deletion first. Deleting the account then removes those projects at once.

Subprocessors

We use these subprocessors:

• Supabase: database.
• Our infrastructure provider: the servers that run the API and media.
• Vercel: the dashboard and docs.
• Resend: email to developers.
• An S3-compatible storage provider: attachments and live-stream output.
• Cloudflare: DNS.
• Apple and Google: push notifications, only if you turn push on.

Ask us for the current list with regions.

Work in progress

We would rather tell you now than have you find out in a review.

We do not offer an uptime SLA yet.

Healthcare and other regulated data

Do not send protected health information (PHI) through Livqeno yet. We cannot sign a Business Associate Agreement (BAA) today.

Some guidance applies now and will still apply once a BAA is available:

• Use opaque IDs for participant identities, room names and metadata. Do not use patient names or record numbers.
• Set a chat retention period.
• Keep push notification text generic, such as "New message".
• Turn off link previews.
• Don't use live streaming for sensitive sessions.

GDPR

For your users' data, Livqeno is your processor and you are the controller. A data processing addendum (DPA) with the EU Standard Contractual Clauses is being prepared. Contact us if you need one.

Reporting a vulnerability

Email security@livqeno.com. Don't open a public issue. We acknowledge reports within 3 business days and offer safe harbour for good-faith research. See Security → Reporting a vulnerability.