We can't lose what we don't expose.

Othentity's security model starts from a single principle: a raw identifier should be encrypted before it leaves the person's device, sealed in a vault no partner can reach, and resolvable only at the moment of a filing. Everything below follows from that.

Client-side cipher

X25519 ECIES

Key custody

Managed KMS

Tenant model

Fully isolated

Encryption & the vault

Sealed before it travels, sealed where it rests.

In-browser encryption

Sensitive fields are encrypted in the browser or app with X25519 ECIES to the vault's public key before a single byte crosses the network. The plaintext identifier never transits our edge in the clear.

ECIES · in the client

Sealed vault

Identifiers come to rest in the Identity Vault, encrypted with ChaCha20-Poly1305 AEAD under per-record keys wrapped by a managed key-management service, HSM-backed custody is a production target. Decryption is bounded to the resolution path.

at-rest · AEAD · KMS-wrapped

Key management

Per-record data keys are wrapped by the key-management service and rotated through it; the wrapping keys are never exported. Token-to-identity resolution requires the KMS, there is no offline copy to steal.

per-record DEKs · KMS-wrapped

The token is the boundary. What leaves the vault is an opaque token. Compromise everything a partner holds and the identifier still stays sealed, see how the layers separate on the architecture page.

Multi-tenancy

One business's data never touches another's.

Every tenant is provisioned with isolated Sandbox and Live workspaces, each on its own Othentity-owned subdomains, with separate keys and an independent audit lane.

Isolation boundaryData, keys, and audit are partitioned per tenant. There is no shared identifier store across businesses.

Dedicated subdomainsLive and Sandbox each resolve under the tenant's own hosts, <tenant>.othentity.com and sandbox.<tenant>.othentity.com, never the tenant's own domain.

Scoped credentialsSecret keys carry scopes (verifications, operations, webhooks); client keys are domain-restricted and cannot read identity data.

Per-tenant auditEvery action, operator, system job, or GitOps change, lands on that tenant's append-only activity log.

Access controls

Least privilege, all the way down.

RBAC

Teams, default and custom roles, and a granular permission matrix scoped to each tenant.

SSO & SCIM

OAuth/OIDC sign-in (Google, Apple, Microsoft) today. SAML 2.0 with Okta and Entra ID, plus SCIM JIT provisioning and group mapping, are on the enterprise roadmap.

MFA enforcement

Workspace-wide MFA policy, authenticator app or hardware security key, with enrollment grace windows.

Network policy

Optional IP allowlists and zero-trust gateways (Tailscale, Cloudflare WARP) to restrict where access originates, on the enterprise roadmap.

Passwordless from the start. Individuals authorize with a device-bound passkey created via WebAuthn, no shared secret, nothing to phish.

Detection & response

We watch the things that matter and prove what happened.

Threat monitoring. Secret-key exposure, anomalous IPs, and impossible-travel sign-ins are flagged in real time and surfaced to admins.

Append-only audit. Every action is written to an append-only, per-tenant log, with export for your own SIEM and compliance review on the roadmap.

Session & device control. Admins see active sessions and the full IP history per member, and can revoke access instantly.

Incident response. A defined runbook covers detection, containment, partner notification, and post-incident review.

Responsible disclosure

Found something? We welcome reports from security researchers and triage them quickly. A coordinated-disclosure policy and a private channel are published with our first production release; a public bug-bounty program follows the SOC 2 milestone.

Keep reading

Security is one face of the same model.

See how the obligations map to certifications, and how the services fit together.

Compliance & certifications System architecture