MFA and SSO on every account. Step-up auth on every destructive action. Tenant isolation by design, an encrypted credential vault, and an insert-only ledger signed per tenant. Every claim on this page maps to something you can inspect in the product.
Multi-factor on every account, single sign-on for organisations, and the same auth surface across the app, the API and the SDK. The basics, done properly.
Any RFC 6238 authenticator app. Ten single-use recovery codes issued at enrolment, hashed at rest, regenerable - and admins are notified when a member regenerates them.
Bring Okta, Entra ID, Google Workspace or any compliant IdP. SCIM provisioning on Enterprise, so deprovisioning in your directory ends the Lyhnis session too.
Deleting a workflow, rotating a credential, removing MFA, dropping a tenant - for those, an active session is not enough. The user re-authenticates every time, and the re-auth is itself an audit entry.
The API marks the route as sensitive. No "recently authenticated" grace window, no session-age exemption, no admin bypass.
The user proves possession again - TOTP code, or a fresh IdP assertion under SSO-only mode. The challenge is bound to the specific action.
Two ledger entries: the step-up itself, then the action. Both signed, both actor-tagged, both exportable to your SIEM.
Workspace administrators set the security floor. These policies inherit to every member, every API key and every workflow automatically - there is no way to weaken them from inside a session. Policy changes are themselves audited, behind step-up auth.
Every tenant is a hard boundary - data, files, credentials and audit ledgers. Credentials never appear in logs, never come back from an API read, and never leave the vault except to execute a single activity.
Tenant scope is applied at the query layer, not the view layer: every read carries the tenant, and there is no code path that returns a row without one. Storage, credentials and ledgers are partitioned the same way.
Fernet (AES-128-CBC + HMAC) with keys derived per tenant. A credential read returns metadata only - name, type, last-used, rotation date. The secret decrypts inside the worker, for one activity, and is redacted from every log sink.
GET /v1/credentials/cr_8812
{
"name": "stripe_live",
"type": "API_KEY",
"secret": null, # never returned
"last_used": "2026-05-26T14:32:08Z",
"rotated_at": "2026-04-02T09:11:00Z"
}Not a debugging convenience - a tamper-evident record of every action in the platform. Insert-only at the database level. Each entry signed with HMAC-SHA256 over a per-tenant key. Streamed to your SIEM in real time.
The application role holds no UPDATE or DELETE grant on the ledger table. Not policy - permissions.
HMAC-SHA256 over a per-tenant key, chained so a removed row is detectable on export.
AGENT, HUMAN or SYSTEM plus the resolution source, on every single row.
NDJSON for arbitrary ranges, CSV for auditors, real-time sink into your SIEM.
Where it lives, who touches it, how long it stays and how it leaves - documented, and answerable by a person rather than a form.
Choose EU (Frankfurt) or US (Virginia) at provisioning. Data, files, credentials and ledger stay in-region - including backups.
A standard Data Processing Addendum covering roles, security measures, subprocessors, breach notification and transfer mechanisms.
Every third party in the processing chain, what it does and where it runs. Material changes are announced 30 days ahead.
Ledger retention runs 90 days to 7 years by plan. Deletion requests are executed within 30 days and confirmed in writing.
Read the docs, then ask us for the report. We would rather you checked.
Drag activities, place your approval gates, hit run. No local setup, same execution layer.
See pricing →