Self-hosted Auth0 alternative for EU data sovereignty

Why a self-hosted Auth0 alternative for EU data sovereignty is a legal question first

For a European company, the first question about replacing Auth0 is not which product has the better login flow. It is whether customer login data, authentication logs and support access can be reached from outside the EEA, and by whom. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and the EDPB's Guidelines 05/2021 treat remote access from a third country, even just displaying data on a screen during support, as a transfer. Identity data is personal data almost by definition: email addresses, profile attributes, login timestamps, IP addresses in logs and, in B2B tenants, the employees of your customers. The short answer is that self-hosting ZITADEL or Keycloak in your own datacenter or an EU provider's datacenter removes the vendor's access path to your data. An Auth0 tenant in its Europe region or Private Cloud keeps data in the EU, but it still depends on the vendor's control and support model, including who can operate, troubleshoot and respond to legal requests from a company subject to U.S. jurisdiction.

The CLOUD Act matters here because 18 U.S.C. 2713 requires providers within its scope to preserve or disclose data in their possession, custody or control regardless of where it is stored. The EDPB's Example 12 says that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be, so the controller must assess that exposure before engaging the processor. Article 48 of the GDPR limits enforcement of third-country disclosure orders to those based on an international agreement such as a mutual legal assistance treaty, which is one of the inputs to that assessment. The answer depends on your own transfer impact assessment, your processor contracts and the vendor's current terms, so confirm it with your data protection officer, counsel and the vendor in writing before you decide.

Start by asking the vendor which entity can access tenant data, from which locations, for which support tasks, and how it responds to government requests, and get the answers in the contract. Then map every copy of identity data, including backups, logs and analytics exports, to a location and an access path. If you move to a self-hosted option, the transfer question shifts to your own operations team and any EU hosting provider you choose, and that provider's own legal exposure becomes part of your assessment. Document the decision so an auditor can follow the reasoning from the transfer analysis to the controls you have implemented.

What GDPR transfer rules and the CLOUD Act require for identity data

Customer identity data moves through more channels than the user table: login records, profiles, logs and support sessions. Each of the rules below attaches to a different one of those channels, so the hosting decision has to be checked against all of them, not just where the database sits.

Article 44 covers every transfer

Article 44 applies Chapter V to every transfer of personal data to a third country, including onward transfers. For identity data, that means the user store, the profile fields and any copies held by a sub-processor all need a lawful basis for leaving the EEA. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, under Article 83(5)(c). Ask any vendor to list every location where tenant data is stored or replicated, including backups.

Remote support access counts as a transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. Storage in a cloud outside the EEA is also a transfer. For identity platforms this matters most for vendor engineers who troubleshoot a failed login from outside the EEA. Ask the vendor where support staff sit, which tooling they use for access, and whether access is logged and approved by your team.

EU processors under foreign law

Example 12 in the same guidelines says that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer. Complying with a third-country authority request, however, would be one. A controller should therefore assess that exposure before engaging the processor. For a hosted identity provider run by a non-EU parent, ask whether its contracts, support tooling or admin consoles depend on parent-company systems that could be compelled.

Schrems II and the Data Privacy Framework

The Court of Justice invalidated the EU-US Privacy Shield in Case C-311/18 (Schrems II) on 16 July 2020, but upheld standard contractual clauses. Commission Implementing Decision (EU) 2023/1795 finds adequacy only for US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. A vendor's certification status can change, so record which transfer mechanism covers each data flow and recheck it at each renewal.

CLOUD Act reach over identity records

18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is stored. A US-parented identity provider in an EU region can therefore receive a US demand for login logs or profile data. EDPB Recommendations 01/2020 say that where a provider needs data in the clear and the authority's powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Ask counsel to map the vendor's parent entity and its control over the tenant.

Self-hosting narrows the disclosure path

When Keycloak or ZITADEL runs in your own datacenter or an EU provider's facility under your control, there is no vendor cloud in the chain for that tenant. Your team still needs to check that the EU provider has no non-EU parent with control over the hardware, remote management, or backups. Keep logs, the PostgreSQL database and backup copies in the same jurisdiction, and document which party holds encryption keys and who may approve access to them.

Where Auth0's EU options meet the requirement and where they do not

Auth0's Europe region keeps tenant data at rest in EU hosting, which addresses one transfer question. It does not answer the others, because the operator is a US company and the people who access the platform may work from outside the EEA.

Storage location: EDPB Guidelines 05/2021 treat storage in a cloud outside the EEA as a transfer. Confirm which data classes sit in the EU region, including logs, analytics, email delivery data and backups.
Support access: Remote access from a third country is a transfer, even when staff only view data on a screen. Ask where support and engineering staff access tenant data, and how each access is approved and logged.
CLOUD Act reach: 18 U.S.C. 2713 requires US providers to preserve or disclose data in their possession, custody or control, wherever it is located. A Europe region does not remove that exposure on its own.
Government requests: Under GDPR Article 48, a third-country order is recognized in the EU only if it rests on an international agreement, but a provider may still receive and respond to a direct request. Ask how requests are reviewed, challenged and notified.

Ask Auth0 in writing which regions hold tenant data, logs and backups, and record those answers in your transfer assessment before you rely on the region.

Which open-source options fit an EU sovereignty requirement

This table compares ZITADEL, Keycloak and authentik against an EU sovereignty requirement for customer identity data. Read each row as a question to answer in your own environment: the rows show where each option meets the constraint and what you still need to verify. Hosting in your own or an EU provider's datacenter moves the residency question from the vendor's region settings to your operating model.

Requirement area	ZITADEL	Keycloak
Licensing and legal obligations	AGPL-3.0 for the core, Console and hosted login, with Apache 2.0 for APIs, SDKs and Helm charts. Confirm with legal what AGPL source-disclosure duties mean if you modify the code.	Apache 2.0 with no copyleft obligation on modifications. A CNCF incubating project, so governance is shared rather than tied to one company.
Data location and isolation	Instances give full data isolation between tenants, so you can keep each customer's data in a single deployment you control. Confirm that backups, logs and telemetry settings also stay in your chosen region.	Realms separate users and clients within one server. Confirm that all nodes, the database and any external cache or log sink run only in the EU locations you approve.
Database dependency	Requires PostgreSQL 14 to 18 as the sole database. Your sovereignty review covers the PostgreSQL host, its backups and its replicas.	Supports several production databases including PostgreSQL 14 to 18. Requires a synchronously replicated database for the supported high availability designs.
Operational footprint	Runs with Docker Compose, Kubernetes or Linux binaries, and the official Helm chart is recommended for high availability.	Runs as a Java server, typically on Kubernetes through the Keycloak Operator. Plan for cluster sizing, upgrade testing and database schema migration.
Directory and federation	Federates with LDAP and OpenLDAP, Entra ID, Okta and other OIDC or SAML providers, and each customer organization can use its own identity provider.	Built-in user federation with existing LDAP and Active Directory servers, so customer or employee directories can stay where they are.
Support model for regulated teams	Commercial support and enterprise terms are offered by the vendor. Ask in writing for support hours, incident response and where support staff access data.	Community support is free, and Red Hat offers a supported distribution. Ask whether a supported build fits your in-region and access requirements.
Gaps to verify	Confirm the support access model, the exact telemetry and log flows, and any EU hosting option offered by the vendor against your data residency and access controls.	Confirm the telemetry, metrics and log destinations you enable, and whether any default cloud endpoint is contacted during operation.

How to deploy ZITADEL or Keycloak in an EU datacenter under this constraint

This sequence turns a data residency decision into a deployed, backed-up and upgradable identity service in which customer identity data, logs and administrative access stay under the control of the EU organization.

Classify data and map every transfer
The data protection owner, with the identity engineering lead, lists every category of customer identity data (profile fields, credentials, sessions, audit events, support tickets) and every place it will be stored, replicated, backed up or viewed. Each flow is marked as staying in the EEA or leaving it, including remote access from a third country, which the EDPB guidelines treat as a transfer even when data is only displayed. The step is done when the map is signed off and each non-EEA flow has a named legal basis or a decision to remove it.
Select EU hosting and processor terms
Choose between your own datacenter and an EU provider. For a provider, ask in writing for the location of every storage and backup tier, the list of sub-processors with their locations, and whether any provider entity is subject to third-country law with extraterritorial effect. Under EDPB Guidelines 05/2021, using such a processor is not itself a transfer, but complying with a third-country authority request would be, so this exposure needs a documented assessment before signing. The step is done when the contract and sub-processor list match the transfer map.
Size PostgreSQL and the high availability design
Both products store identity state in PostgreSQL. Zitadel supports PostgreSQL 14 through 18, and Keycloak's production list includes PostgreSQL 14 to 18 as well. Keycloak's documented high availability designs require a synchronously replicated database, so the platform team should confirm that the EU hosting provides this across availability zones and that failover behaviour is tested. For Zitadel, the official Helm chart on Kubernetes is the documented route to high availability. The step is done when a failover test has been run in the EU region and the results are recorded.
Configure backups and export limits
Keycloak realm export and import through kc.sh is documented with limitations as a backup mechanism, and all nodes must be stopped while it runs, so it should not be the only recovery path. Build database-level backups stored in the EU, keep encryption keys under your control, and test restores into a separate environment. Record how Zitadel instance data is backed up with its database tooling. The step is done when a restore has been completed in an isolated EU environment and the recovery steps are written down.
Restrict admin and support access paths
Remote administration from outside the EEA counts as a transfer, so define who can reach the admin consoles, the Kubernetes API, the database and the backup store, and from which networks and jurisdictions. Use named accounts with multi-factor authentication, time-limited elevated access and session recording where your policy requires it. If a vendor or implementation partner needs access, agree in writing where that access originates and whether data is displayed or copied. The step is done when access rules are documented and a review confirms no unapproved path exists.
Keep logs and telemetry inside the EU
Identity platforms produce authentication events, audit logs, metrics and error traces that contain personal data. Configure the Keycloak and Zitadel log outputs, the metrics endpoints and any tracing exporters so they write to EU log stores, and confirm that alerting or SIEM forwarding does not send raw events to a third country. Keycloak metrics configuration is documented in its observability guide. The step is done when a test login generates events and each destination is confirmed to be in the EU.
Plan upgrades with manual approval and schema control
On Kubernetes, the Keycloak Operator documentation strongly recommends manual approval mode so updates do not occur automatically. For large deployments, Keycloak's upgrading guide suggests manual schema migration rather than automatic migration at startup, so the database team can review and apply the SQL. Keycloak plans four minor releases a year, and breaking changes in minor releases are opt-in, which should be reflected in the test cadence. The step is done when an upgrade has been rehearsed in a non-production environment and the approval owner is named.

What moving user data out of Auth0 involves under GDPR

The export itself is a processing step you need to plan for under GDPR. Auth0 can produce a bulk user export through the Dashboard or the Management API create export users job (POST /jobs/users-exports), in NDJSON or CSV format. Those files contain personal data for every customer identity, and once they leave the Auth0 tenant they sit on your systems or a migration host. Before running the job, decide where the files will be stored and processed, who can open them, and whether any step involves a support engineer or contractor located in a third country. The EDPB guidelines treat remote access from a third country, even just displaying data on a screen during support, as a transfer. Your data protection officer should map each hop in the migration path against Chapter V of the GDPR before anyone starts the export.

Password hashes add a separate request with no guaranteed date. Standard exports omit password hashes. Customers on paid plans must ask Auth0 support for a password hash export by ticket, the option is not available on the Free tier, and Auth0 does not guarantee a delivery date. Treat that request as its own data flow, with its own record of processing entry, retention limit and deletion step. Ask Auth0 in writing where the hash file is produced, from which region, and under which contractual transfer mechanism it is delivered. If the file is not delivered in time, plan for users to reset passwords, which is a user-facing change you must communicate.

Keycloak import and the transfer rules apply to the target as well. Keycloak exports and imports realms as JSON with kc.sh export and kc.sh import, but the Keycloak documentation warns about limitations as a backup mechanism and requires all nodes to be stopped during the operation. Staging copies, test realms and backups created during the move inherit the same GDPR obligations, so keep them in the EU location you approved and delete them when the cutover is verified. The EU Data Act gives customers switching rights for data processing services from 12 September 2025, and bans switching charges from 12 January 2027. Whether those rights reach your Auth0 contract or your provider's terms is a question for counsel to confirm, so ask them before you rely on it in negotiations.

What auditors and data protection authorities ask for

Whichever identity platform you choose, a data protection authority or auditor will ask you to show where customer identity data sits, who can reach it, and why any third-country exposure is acceptable. The cards below list the records to assemble before that conversation starts. DeployOpen prepares systems, controls and evidence, but independent auditors and certification bodies issue any audit report or attestation.

Transfer impact assessments

A transfer impact assessment records whether any third-country law could force the provider to disclose data, and what supplementary measures you applied. Under EDPB Recommendations 01/2020, if a provider must access data in the clear and the foreign authority's powers exceed what is necessary and proportionate, no effective technical measure may exist. Check whether the Auth0 contract, its sub-processors and its support staff sit inside that analysis, and document the same for any EU hosting provider you choose.

Records of processing

Article 30 of the GDPR requires a controller to keep a record of processing activities, covering purposes, categories of data subjects, recipients, transfers and retention. For customer login, the record should name each identity attribute, the social and enterprise identity providers that supply it, and any log destination. Update it whenever you move from a hosted tenant to self-hosted Keycloak or ZITADEL, because the recipients and locations change.

Data location and sub-processor lists

Ask every vendor for a written list of data centers, backup regions and sub-processors that touch identity records, logs or support tickets. Under Article 44, storing identity data in a cloud outside the EEA counts as a transfer, so a Europe region setting alone does not answer the question. For a self-hosted platform, the list is shorter but still includes your database host, backup vendor, monitoring stack and any managed Kubernetes provider.

Support access logs

Remote access from a third country, even only viewing a screen during support, is a transfer under EDPB Guidelines 05/2021. Keep a log of every support session that reaches user records, including who connected, from where, what they viewed and under which approval. With Auth0, request these logs from the vendor in writing. With a self-hosted platform, record access in your own admin tooling and your VPN or bastion logs.

Encryption keys and database controls

Document where encryption keys are generated, stored and rotated, and who holds administrative rights over the PostgreSQL database that backs ZITADEL, or the database Keycloak uses in production. Keycloak supports PostgreSQL 14 to 18 among its production databases, and ZITADEL supports versions 14 through 18. Record disk and backup encryption settings and the key custodian for each. Auditors will ask whether a cloud operator can read keys in the clear.

Processor contracts and deployment evidence

Article 28 requires a written contract with any processor, and the contract should cover instructions, confidentiality, sub-processing and deletion. If DeployOpen or an EU hosting provider runs the platform, keep the signed scope and data processing terms. Keep deployment configuration evidence too: the Keycloak Operator manifests or ZITADEL Helm values, version pins, and the record of update approvals. Each item should match the running system.

Questions buyers ask about EU hosting for Auth0 alternatives

Does an Auth0 Europe region satisfy GDPR on its own?

Hosting data in an EU region reduces transfer exposure, but it does not settle GDPR compliance by itself. Under the EDPB Guidelines 05/2021, remote access from a third country, even just displaying data on a screen for support, counts as a transfer, and so does storage in a cloud outside the EEA. Your review should cover where the vendor's support staff sit, which entities in the vendor group can reach tenant data, and whether a third-country authority could compel disclosure under the CLOUD Act. Ask Auth0 in writing for its data processing terms, sub-processor list, and support access model, and have your data protection officer and counsel assess the result. Compliance is your obligation as controller. A self-hosted deployment in your datacenter or an EU provider's datacenter removes the vendor from the data path, which makes the assessment simpler.

Does the CLOUD Act apply to an EU-hosted identity provider?

It can, if the provider is a US-headquartered company or controls data held by one. The CLOUD Act provision at 18 U.S.C. 2713 requires providers of electronic communication and remote computing services to preserve or disclose data in their possession, custody or control, wherever that data is located. The EDPB's Example 12 says that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. Under GDPR Article 48, a foreign disclosure order is recognized only when it rests on an international agreement such as a mutual legal assistance treaty. Assess this exposure before you sign with any processor. Self-hosted Keycloak or ZITADEL, run by your team or by a contracted implementation partner in infrastructure you control, leaves no vendor holding the keys to your user store.

What does self-hosting an Auth0 alternative cost in components?

The cost has five main parts, and most of them are not licence fees. Keycloak and ZITADEL are open source, so the recurring costs are the people and infrastructure that run them:

Staff: engineers to deploy, patch, monitor and upgrade the identity service, plus an owner for login flows and client configuration.
PostgreSQL: a supported database version (ZITADEL supports PostgreSQL 14 to 18, and Keycloak lists PostgreSQL 14 to 18 among its supported databases), with backups and replication.
High availability: multiple nodes, load balancing and a synchronously replicated database, which Keycloak requires for its supported HA designs.
Support: community support is free but has no response commitment. Paid support, retainers or a vendor distribution such as Red Hat build of Keycloak are separate line items.
Datacenter: compute, storage, network, and in-region hosting, or an EU provider's fees.

Ask for each component as a separate line in any quote, and separate one-time setup from recurring operations.

How long does migrating off Auth0 take?

No fixed duration applies to every migration, so treat any single number with caution. The main drivers are the number of users and applications, how many enterprise connections and social logins must be recreated, whether you can obtain password hashes, how much Auth0 Actions logic must be ported, and how many SDK integrations must move to standard OIDC. Password hash exports are not in the standard export: customers on paid plans request them through a support ticket, Auth0 does not guarantee a delivery date, and the option is unavailable on the Free tier. If hashes cannot be obtained, plan for just-in-time migration or forced password resets, which extend the rollout. Ask any implementation partner for a written timeline tied to a fixed scope, with dependencies on the hash request named explicitly.

What must our internal team supply for a migration?

Your team supplies the decisions and access that only your organization can give. Expect to provide:

Business owners who approve the tenant and organization model, login policies and MFA rules.
Infrastructure access and a hosting decision, including the datacenter or EU provider, network design and DNS.
Identity sources such as existing SAML or OIDC enterprise connections, directories and the contacts at each customer or partner.
A named application owner for every client that will change SDKs or redirect URIs.
Security approval for the Auth0 export handling, storage of exported data and deletion of export files afterward.
Time for testing, cutover and user communication.

Agree these responsibilities in the written scope so that dependencies are visible from the start.

Can our own engineers run Keycloak or ZITADEL without outside help?

Yes, many teams do, if they have the skills and capacity to own a production identity service. Keycloak runs on a range of databases and offers an Operator for Kubernetes that manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources. ZITADEL self-hosts with Docker Compose, Kubernetes or Linux binaries, and recommends the official Helm chart for high availability. The hard parts are operational: backups and restores (Keycloak's export and import has documented limitations and requires all nodes stopped), upgrades on a schedule, securing the admin interface, and keeping login flows correct. Keycloak's Operator documentation strongly recommends manual approval mode for updates. Assess whether your team can staff this on call, or whether a fixed-scope engagement covering build, hardening, backup and handover fits better. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure, and offers ongoing support as a retainer.

What should we request in a fixed-scope quote for an identity migration?

Ask for a written scope that lists each deliverable, the environments covered, the assumptions and the exclusions. A useful quote separates one-time work (design, data migration, connection rebuilds, application changes, testing, cutover and handover) from recurring work (patching, upgrades, monitoring, backups and support). Request the number of users, applications, tenants or organizations assumed, the enterprise connections in scope, and how password hashes and Actions logic are handled. Confirm who obtains the Auth0 exports and hash files, where they are stored, and how they are destroyed. Ask for the deployment target, the database version, the high availability design, and the acceptance criteria. Finally, ask what is needed from your team and what happens if the hash request is delayed. DeployOpen does not publish a price list; a quote follows from the written scope.

Do EU data rules affect the audit logs and support access too?

Yes. Logs contain personal data such as user identifiers, IP addresses and event details, so they fall under the same transfer analysis as the user store. Under the EDPB Guidelines 05/2021, support access from a third country counts as a transfer, even when staff only view the data on screen. With a self-hosted design, you decide where logs are stored, who can read them and how long they are kept, and you can limit support access to named staff in your own jurisdiction. Confirm with any vendor or partner which systems hold log copies, which support staff can view tenant data, and how those actions are recorded. Your records of processing should list these flows, and your data protection impact assessment should address them where required.

What self-hosting does not solve

Moving the identity store into your own datacenter or an EU provider does not remove transfer exposure on its own. If customers sign in through federated upstream providers such as Entra ID or Google, those providers still receive authentication requests and may process personal data under their own terms and locations. Map every identity provider a Keycloak realm or ZITADEL instance brokers to, record where each one stores and processes data, and confirm the contractual transfer basis for each with that provider. The same applies to email delivery, SMS or push MFA vendors, and any hosted monitoring that receives login events.

Licensing is a separate legal question. ZITADEL's core, Console and hosted login moved to AGPL-3.0 with v3.0 on 31 March 2025, while its APIs, SDKs and Helm charts remain Apache 2.0. If your team modifies the core or offers a modified login service to users over a network, the AGPL network-use terms may require you to publish those changes. Have counsel review this before you fork or patch ZITADEL. Keycloak, under Apache 2.0, does not carry the same obligation, but your own integrations should still be checked against the license. For the transfer analysis, the EU-US Data Privacy Framework is also not a settled basis. The adequacy decision (EU) 2023/1795 is under appeal as Case C-703/25 P, so confirm its status with counsel before relying on it for any US-linked vendor, and keep standard contractual clauses in place as a fallback.

Finally, self-hosting shifts operations to you. As controller, you remain responsible for security operations, patching of Keycloak or ZITADEL and their PostgreSQL database, and monitoring of administrative access. Keycloak's operator documentation strongly recommends manual approval for operator updates, and its database schema migrates automatically at startup unless you choose manual migration, so decide that before the first upgrade. Backups also need testing: Keycloak's export and import of realms has documented limitations as a backup mechanism and requires all nodes to be stopped while it runs. Restore a copy into a separate environment on a schedule and record the results as evidence.

How DeployOpen deploys identity platforms under EU sovereignty constraints

DeployOpen plans, implements, hardens, documents and supports self-hosted identity platforms inside the client's own infrastructure, including EU datacenters and air-gapped networks. For Auth0 replacements, we start from where customer identity data, logs and support access would sit, then build ZITADEL or Keycloak to match that position.

How we scope

Map where user records, password hashes, logs and support sessions would sit under each option, including any third-country access path.
Agree a fixed-scope written plan covering platforms, environments, deliverables and timelines before any work starts.
Confirm with your legal and privacy team which transfer tools, processors and datacenter locations apply to your organization.
Define which identity providers, applications and customer organizations move first, and which stay on the current tenant during cutover.

How we build

Deploy ZITADEL or Keycloak in your chosen EU or on-premises environment, with PostgreSQL and high availability designed to your requirements.
Configure organizations or realms, identity brokering and passkeys, and rebuild login flows in standard OIDC or SAML.
Run security testing on the login, token and admin surfaces before go-live, and harden access to the administrative console.
Plan the Auth0 export and password hash request so exported data is handled under the agreed controls, not copied to new locations.

How we hand over

Document the architecture, data locations, access model, backup and restore steps, and the support access procedure you approved.
Prepare the control evidence and configuration records your auditors may request, while noting that independent auditors issue any attestation.
Walk your operations and security teams through upgrades, including how Keycloak's manual approval mode and schema migration are handled.
Provide runbooks for user migration, rollback and incident response so your team can operate the platform after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Review platform releases and configuration changes against the sovereignty and access decisions recorded during scoping.
Repeat security testing on a schedule agreed with you, covering applications, APIs and the identity infrastructure itself.
Ask any quote to itemize the scope, the retainer terms and the items your own team will still own.