Trust is built on specifics.

Here’s how IdRa protects identity data, how it’s checked, and where compliance stands.

How it’s built

Isolation: Each organization has its own Postgres database, and tenant-specific session and token secrets derived per tenant. Tenants are resolved from the request’s Host, never from a forwarded host header.
Secrets at rest: Tokens, keys and vault entries are encrypted with AES-256-GCM, and integration credentials are write-only. Vault reveals are logged.
Administrators: Admins must use MFA to sign in, sensitive actions need recent MFA, and administrators can’t be impersonated.
Outbound requests: Admin-supplied URLs go through an SSRF guard that requires https and checks that the address is public before connecting.
Audit trail: Admin changes write audit log events, with filters, CSV export and configurable retention.
Browser defenses: A Content Security Policy that blocks inline scripts, host-only cookies by default, and refusal of cross-origin cookie mutations.

Internal security audits of the full repository in 2026, with every high-severity finding fixed
The OpenID Foundation’s conformance suite for OpenID providers, run by us, with no failures
SAML sign-on against SimpleSAMLphp as the service provider
Unit tests and browser end-to-end tests on the main sign-in, admin and tenancy flows, before every release

SOC 2 Type I, audit in progress

IdRa’s SOC 2 Type I audit is in progress, alongside the internal audits and conformance runs on this page.

This site sets no cookies and loads no analytics or third-party scripts. It stores one thing in your browser: your theme choice.

Self-hosting gives you control of the database, the encryption key and the network. The self-hosting guide covers deployment and backups.

Pick an address and confirm your email, then sign in as its first admin. A setup wizard takes you through the rest.