Security

Security

AdminUpdated Sep 11, 2026

Atlas is an authentication platform. Security is not a feature we bill for — it is the substrate every deployment runs on. The same posture applies to the smallest free instance and the largest enterprise tenant, on day one, with no security features held back behind a pricing tier.

This Trust Center describes, honestly and in detail, how Atlas protects data and accounts. Where a control is aspirational rather than in place today, we say so and point to the roadmap — a security product that overstates its posture is worse than one that is candid about it.

At a glance

  • Tenant isolation enforced at the data layer — no request crosses a tenant boundary, and cross-tenant reads return 404, never a 403 that would confirm a record exists.

  • Encryption at rest for every secret, using per-instance data keys wrapped by a root key (envelope encryption, AES-256-GCM).

  • Encryption in transit everywhere: TLS for all traffic, HSTS enabled at the edge.

  • Modern session security: short-lived RS256 access tokens verified against a signed JWKS, refresh-token rotation with reuse detection, and session tokens stored only as hashes.

  • Strong authentication: passkeys (WebAuthn), TOTP and recovery codes, breach-password checks, and enumeration-resistant sign-in.

  • Attack protection: per-key and per-IP rate limits, progressive lockout, optional CAPTCHA, and SSRF-hardened, HMAC-signed webhooks.

  • Access control: role-based access control with organization scoping, least-privilege API keys, and SSO/SCIM for enterprises.

  • Auditability: an append-only, tamper-evident audit log and streaming to your own SIEM.

Self-hosted or managed — you choose where your data lives

Atlas is self-hostable. You can run the entire platform inside your own infrastructure, in your own region, under your own key management — in which case Atlas operates no subprocessors on your behalf and your data never leaves your environment. The same build also powers our managed service for teams who would rather not operate it themselves. This Trust Center notes where the two models differ (for example, backups and data residency).

How this Trust Center is organized

  • Data protection — encryption at rest and in transit, tenant isolation, data residency, backups and disaster recovery.

  • Application security — the session model, multi-factor authentication, attack protection, and secure defaults.

  • Access control — RBAC, least-privilege API keys, and SSO/SCIM.

  • Compliance & privacy — GDPR posture, our DPA, and the status of SOC 2 and ISO 27001.

  • Responsible disclosure — how to report a vulnerability and what we commit to in return.

  • Subprocessors — who processes data on behalf of the managed service.

Contact

Security questions, or a report to make? Email security@atlasauth.net. Legal documents — the DPA, subprocessor list, privacy notice and terms — live at legal.atlasauth.net.

Was this page helpful?
Security