Obexal Docs

Docs/Security and compliance/Data residency and sovereignty

Data residency and sovereignty

Where Obexal runs, what it depends on, its certification status and how you leave with your data, stated factually.

Sovereignty claims are easy to make and hard to verify. This page states the facts: where the data lives, the exact list of what the request path depends on, the real certification status, and how you get your data back out.

Data residency

Obexal is hosted in France, in a datacenter in the Paris region, with data residency in the European Union. All personal data resides in the EU: users, credentials, sessions, audit entries, MFA factors, passkey public keys, OAuth clients, tokens and signing keys.

Residency is enforced, not declared: each tenant carries a data region (default eu), and creating a tenant in a region outside the server's allowlist is refused.

No non-EU dependency in the request path

No request that Obexal serves depends on a service operated outside the EU. Concretely:

  • Compromised-password checks run against a local list embedded in the service. There is no call to an external breach API.
  • GeoIP resolution (for conditional access by country) reads a local .mmdb database on disk. The format is open and provider-agnostic; no network lookup is ever made.
  • Transactional email (invitations, magic links, OTP codes) goes through an EU SMTP relay over TLS. No US email SaaS.
  • Fonts and static assets are self-hosted and served from the same domain. No third-party CDN.
  • No third-party analytics, telemetry or log shipping. Framework telemetry is disabled at build time.
  • Signing keys are generated and held inside the platform, the private key encrypted at rest. No third-party KMS or HSM sits in the request path.
Note

Social sign-in through Google or Microsoft is the one deliberate exception: an explicit federation choice made by your administrator, disabled by default. The strict sovereign mode (SOCIAL_SOVEREIGN_ONLY=true) refuses to enable non-EU providers even when configured; the generic OIDC connector lets you federate with an EU identity provider instead.

Self-hosting on your own infrastructure

Every component is open source and self-hostable: a static Go binary, PostgreSQL, Redis, and self-hosted Next.js front ends. You can run the entire platform on your own EU infrastructure, with no mandatory third-party SaaS. Start with Requirements.

Certifications: current status

As of July 2, 2026:

FrameworkStatus
ISO/IEC 27001Not certified. A control-by-control mapping to ISO/IEC 27001:2022 Annex A is maintained and documented
SOC 2Not certified
HDS (French health data hosting)Not certified
SecNumCloud (ANSSI)Not qualified. A roadmap toward qualification exists; the platform's residency, encryption and audit design targets its requirements
GDPRNot a certification: compliance tooling is built in, see GDPR and data protection

We publish this status plainly rather than implying certifications we do not hold. It will be updated as audits complete.

Reversibility by open standards

Leaving must be as standard as arriving:

  • All integration surfaces are open standards: OpenID Connect / OAuth 2.1, SAML 2.0, SCIM 2.0, WebAuthn. There is no proprietary SDK your applications depend on.
  • Users can export their account data as JSON, and admins can read the directory through the Admin API.
  • Outbound SCIM can push your directory to another system continuously, which doubles as a migration path.
  • At the end of the contract, data is deleted or returned, at the controller's choice, per the DPA.