Self-hosted Okta alternative for EU data sovereignty

For European organizations with Okta's EMEA cell and its sub-processor language under review, self-hosted Keycloak in an EU datacenter keeps identity data, logs and support access under your control, with trade-offs to confirm.

Book a callTalk to us
On this page

Why EU data sovereignty changes the Okta decision

For a European regulated organization, self-hosted Keycloak in its own datacenter or in an EU provider's datacenter is the main option that keeps identity data, logs and support access under its control. The question is less where Okta's EMEA cell sits and more whether anything in the chain reaches the data: a sub-processor outside the EEA, a remote support session that displays records from a third country, or a foreign legal order. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet the conditions in Chapter V. EDPB Guidelines 05/2021 treat even remote viewing for support, and storage in a cloud outside the EEA, as transfers.

Okta's documentation describes its cloud service and sub-processors, but the locations and access paths can change, so confirm them in Okta's current terms and data processing agreement before scoring the option. Ask for the sub-processor list with processing locations, where system and authentication logs are stored, and whether support staff can view tenant data from outside the EEA. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c), so the answers belong in your transfer assessment. Contract clauses alone may not close a gap where a provider must access data in the clear and foreign public authority powers exceed what is necessary and proportionate, as EDPB Recommendations 01/2020 explain.

Self-hosting moves that exposure to decisions you control: who holds administrator rights on the Keycloak cluster, where the PostgreSQL database and backups are kept, and which logs leave your network for a SIEM. If you choose an EU provider, assess that provider's exposure to third-country law before signing, because the EDPB notes that complying with a third-country authority request would itself be a transfer. Keycloak is licensed under Apache 2.0 and is a CNCF incubating project, so the software carries no vendor-hosted data path. Confirm the datacenter location, operator access model and log destinations in writing, and record them in your records of processing.

What GDPR and the EU Data Act require of identity data

Identity data is personal data, so every place it is stored, replicated or viewed from outside the EEA is a transfer question. The cards below cover the transfer rules, the legal basis for US-linked providers, the reach of US law, and the switching rights that apply to cloud identity services.

Transfers include remote access

Article 44 of the GDPR applies to every transfer of personal data to a third country, including onward transfers. The EDPB's Guidelines 05/2021 treat remote access from a third country as a transfer, even when staff only view data on a screen for support. For an identity provider, that means a vendor's support engineer in another country viewing user records or logs is part of your transfer analysis, not only where the database sits. Ask any provider for a list of countries where support and sub-processors can access tenant data.

Schrems II and the DPF appeal

In Case C-311/18 (Schrems II), the Court of Justice invalidated the Privacy Shield while keeping standard contractual clauses valid. The current EU-US Data Privacy Framework adequacy decision covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Ask a US-linked identity vendor whether it is certified under the framework, what transfer tool covers the rest, and how the answer would change if the appeal succeeded.

US CLOUD Act reach

The CLOUD Act provision at 18 U.S.C. 2713 requires providers of electronic communication and remote computing services to preserve or disclose data they hold, custody or control, wherever it is located. A US-parented provider hosting in the EU can therefore still receive a US order for your identity data. GDPR Article 48 limits this: a third-country disclosure order is enforceable in the EU only where it rests on an international agreement, such as a mutual legal assistance treaty. Ask how the vendor responds to government requests and whether it commits to challenge them.

Data Act Article 32 safeguards

Article 32 of the EU Data Act, Regulation (EU) 2023/2854, requires providers of data processing services to take technical, organizational and legal measures against third-country governmental access to non-personal data held in the Union where that access would conflict with EU or national law. Identity logs and configuration that are not personal data fall under this article. Ask for the provider's written measures, its data location commitments and how they are audited.

Switching rights and charges

The Data Act has applied since 12 September 2025. It gives customers the right to move from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Check your contract for export formats, notice terms and any fees that apply before that date, since exporting identity data from a cloud IdP is often the hardest step in an exit.

How Keycloak, authentik and ZITADEL meet the constraint

Running Keycloak in your own datacenter keeps the identity server, its database and its logs under your direct control. The project is an open source identity and access management server, so no vendor sits between your directory and the software that handles authentication. Keycloak is the most direct answer to the question of where identity data physically lives, because you decide the hosting location and the people who can reach it.

  • License: Keycloak is licensed under Apache 2.0 and is a CNCF incubating project, so you can run it without a per-user subscription.
  • Protocols and federation: It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and has built-in user federation with existing LDAP and Active Directory servers, so directory data can stay in your own directory.
  • Production database: Supported production databases include PostgreSQL 14 to 18, along with MariaDB, MySQL, Microsoft SQL Server, Oracle Database and others. The development file database is not for production.
  • Current release: Keycloak 26.8.1, released October 13, 2026, is the current version to plan against, and the project plans four minor releases a year.
  • Support access: Your own staff or your integrator hold administrative access, so you control who can view logs and user records.

Confirm internally who will hold database and admin access, where backups are stored, and which logging sinks receive authentication events.

What Okta's EMEA cell does and does not settle

A regional cell settles where the primary data is stored, but it does not settle every place identity data is touched. Before relying on an EMEA cell for EU data sovereignty, get written answers from Okta on four points: the current sub-processor list and the country where each one processes data, the support access model, the location and retention period of logs, and whether any processing could be compelled under a third-country legal order. Okta's own terms describe sub-processors that may process data outside the region, so the cell is a starting point for the assessment, not the end of it. Ask for the documents that govern these answers, and check them against the version your contract references.

Remote access is the point most often missed. Under EDPB Guidelines 05/2021, a support engineer in a third country who can view data on a screen counts as a transfer, even without a copy. Ask Okta which support teams can open tenant data, from which countries, under what approval, and whether access is logged and visible to your administrators. Also ask where System Log events and Admin Console audit records are shipped, whether a central monitoring or SIEM copy sits outside the EEA, and how long each copy is kept. Logs often contain usernames, IP addresses and application names, so they count as personal data.

Put the answers into a register that your data protection officer can sign off, and map each item to a data flow: directory data, authentication events, logs and support tickets. A Keycloak instance in your own or an EU provider's datacenter removes most of these questions by design, but it moves the operational duties to you, including who can reach the database host and where backups are stored. Keep the register as the evidence base for either choice, and reassess it whenever Okta changes its sub-processors or a relevant court decision changes the transfer rules.

Deploying Keycloak in an EU datacenter

This sequence moves identity data, logs and support access into an EU hosting location that you control, with each data flow mapped and each operational control written down before users log in. The result is a Keycloak deployment whose data locations, failover, backups and access trail you can show to your data protection officer and auditors.

  1. Map identity data flows and sub-processors

    Your privacy team and the platform owner list every place identity data goes: user attributes, login and audit events, metrics, backups, email delivery for MFA and password resets, and any vendor that touches the stack. Record which flows leave the EEA, including remote access from a third country, since the EDPB guidelines treat displaying data on a screen for support as a transfer too. Done when each flow has an owner, a location and a legal basis noted in a register.

  2. Select EU hosting and contract terms

    Choose between your own EU data center and an EU infrastructure provider. For a provider, ask in writing where storage, backups and support sessions occur, which sub-processors have access, and whether any entity outside the EU can be compelled to disclose data under foreign law. Review that exposure against the EDPB Recommendations 01/2020 and Example 12 of the Guidelines 05/2021 before signing. Done when the contract, the data location schedule and the sub-processor list match your register.

  3. Deploy Keycloak with the Operator

    Platform engineers install the Keycloak Operator through Operator Lifecycle Manager, the recommended method, in a Kubernetes cluster located in the chosen EU site. Set the operator to manual approval for updates so that no upgrade starts without a reviewed change record. Keycloak 26.8.1 is the current release according to the Keycloak website, so confirm the version you pin against the release notes before rollout. Done when the Keycloak custom resource reports ready and an admin login works over the hostname you control.

  4. Configure a supported database with replication

    Provision a production database from Keycloak's supported list, such as PostgreSQL 14 to 18, in the same EU region. Keycloak's high availability designs require a synchronously replicated database, so confirm with your database team that replication is synchronous and tested for failover. Decide how schema changes are applied: Keycloak migrates automatically at startup by default, but the upgrading guide suggests manual migration for large deployments, which many teams prefer for controlled change windows. Done when a failover test completes without losing committed identity changes.

  5. Federate LDAP or Active Directory directories

    If identities live in an on-premises directory, configure Keycloak user federation against your LDAP or Active Directory servers so that the authoritative source stays in your EU network. Test bind accounts with least privilege, the attribute mappings your applications need, and what happens when the directory is unreachable. Keycloak keeps its own copy of users it imports, so document which attributes are stored locally. Done when a sample of real test accounts authenticates through federation and the stored attributes match your register.

  6. Route logs and metrics into EU storage

    Send Keycloak event logs, admin events and metrics to a log platform and storage that sit in the EU, and set retention periods that your policy defines. Check that the metrics endpoint and any collector agents do not forward personal data to external services. Confirm that backups of log stores follow the same location rules as the identity database. Done when a test login and a test admin change appear in EU-hosted storage and nowhere else.

  7. Define logged support access procedure

    Write a procedure that states who may open a support session, how access is approved, which tools are used, and where the session is recorded. Treat remote screen viewing from outside the EEA as a transfer and either block it or cover it with the legal basis in your register. Use named accounts, time-limited grants and a session log that the security team reviews. Done when a support engineer can complete a documented test task and the access record is retrievable from EU storage.

  8. Plan and test backups and restores

    Keycloak's realm export and import with kc.sh is documented as having limitations as a backup mechanism, and it requires all nodes to be stopped while it runs, so it cannot be your only recovery path. Back up the production database with point-in-time capability, keep copies in the EU, and use realm export for configuration snapshots during a planned maintenance window. Run a restore into an isolated environment and time the result against your recovery objectives. Done when a restore test is signed off and the runbook names the person who starts it.

Evidence regulators and auditors ask for

A data sovereignty position is only as strong as the records that show it. The cards below list the artifacts a regulator, customer or independent auditor will ask to see, and each one should be traceable to a specific system, transfer or operational decision.

Records of processing and transfer assessments

Your Article 30 record of processing should name every location where identity data, including user attributes, credentials references and session data, is stored, administered or viewed. Where any element sits outside the EEA or can be reached from a third country, record a Chapter V transfer assessment that considers EDPB Recommendations 01/2020. Check that the assessment covers remote administration as well as storage, because displaying data on a screen from abroad also counts as a transfer.

Supplier and sub-processor inventory

For a self-hosted Keycloak, the inventory should list the database host, backup storage, the hosting or colocation provider, any managed Kubernetes or operator tooling, monitoring vendors receiving log data, and any EU provider's own sub-processors. Ask each provider to confirm in writing where support staff are located and whether any of them can reach your environment remotely. Keep the list current, since a new monitoring agent can create a new transfer.

Configuration and access logs showing data location

Auditors look for evidence, not statements. Keep infrastructure-as-code or configuration records that show the region and cluster in which Keycloak, its database and its backups run, plus access logs for the admin console and the database. Confirm that metrics and event logs exported to a SIEM are stored in the same jurisdiction, and that log retention matches your stated policy. Keycloak metrics are documented, so decide which fields leave the cluster before exporting them.

Documented support access approvals

Every time a vendor engineer, an EU provider or DeployOpen accesses production identity data, there should be a written approval naming the person, the reason, the scope, the duration and the approver. A standing support account with remote access from outside the EEA is the finding most likely to trigger a transfer question. Record each session in your ticketing system so the approval and the actual access can be matched.

Backup and restore test records

Keycloak's realm export and import is documented as having limits as a backup mechanism, and it requires all nodes to be stopped during the operation. Your evidence should therefore include the database backup method, the location of backup copies, encryption details, and dated restore tests that show a realm and its clients came back in the same region. Confirm the restore procedure in your own environment rather than relying on the export command alone.

Patch and upgrade records

Regulators and auditors ask how quickly security fixes reach production and who decided on each upgrade. Keep change tickets for every Keycloak release you deploy, the approval for operator updates, and the test results from a staging environment. The Keycloak Operator documentation recommends manual approval mode for updates, so record who approved each one. Also record database schema migrations, which Keycloak runs automatically at startup unless you configure manual migration.

Questions European buyers ask before choosing a hosting model

Does self-hosting Keycloak remove all GDPR transfer risk?

No. Self-hosting reduces exposure to third-country transfers, but it does not remove the obligation to assess them. Transfers under GDPR Article 44 cover more than where a vendor's servers sit. The EDPB guidelines treat remote access from a third country, even just displaying data on a screen for support, as a transfer. So if your own administrators, a vendor's engineers or a support provider in another country can reach identity data, those paths still need a transfer assessment. Your organization still needs its own documented assessment of where identity data, logs and support access actually flow, under its own legal basis and records of processing.

Does an EU hosting provider remove CLOUD Act exposure?

Not automatically. Whether an EU provider is exposed to the US CLOUD Act depends on its own corporate ties, such as a US parent company, US-based staff with access to systems, or US-controlled subprocessors. The CLOUD Act provision at 18 U.S.C. 2713 applies to providers in its possession, custody or control regardless of where data is stored. The EDPB guidance notes 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 controllers should assess that exposure before signing. Ask the provider in writing about its ownership, its subprocessors, and how it handles government requests.

What drives the cost of self-hosting Keycloak in the EU?

The cost is made up of components, and who you pay for each one matters. Infrastructure in your own data center or an EU cloud account is one recurring cost. A production database, a highly available cluster with a synchronously replicated database, backups, monitoring and staff time are others. Migration work, integration with your applications and directories, and a support subscription from a vendor or partner are typically one-time or periodic costs. Costs rise with the number of sites, the availability target, the size of the user base and the number of applications and directories to connect. DeployOpen does not publish a price list. A quote follows from a written scope that lists these components, so ask for each line item separately.

How long does an Okta to Keycloak migration take in the EU?

The duration depends on scope, not on a fixed figure. The main drivers are the number of SAML and OIDC applications to re-federate, the number of directories and LDAP or Active Directory sources to connect, how many users and groups must move, and how password and MFA re-enrollment will be handled. Data residency decisions also add time, because hosting location, support access controls and logging design must be settled before cutover. Work is usually agreed as a fixed scope with deliverables and a timeline in writing before it starts. Ask for a scope document that names the applications, directories and cutover approach, and check the timeline against it.

Can our team run Keycloak alone after a migration?

It can, if the team has the right skills and capacity. A production setup needs people who own the following areas:

  • Operations: cluster health, database maintenance, backups and restore tests, and capacity planning.
  • Patching: applying Keycloak minor releases, which the project ships several times a year, and reviewing breaking changes. The Keycloak Operator documentation recommends manual approval for operator updates to avoid unintended upgrades.
  • Security: monitoring, incident response, certificate and secret rotation, and access control for administrators.
  • Integration: onboarding and offboarding applications, and maintaining directory federation.

If these roles are not available in-house, a retainer for upgrades, testing and support can cover the gap. Confirm the staffing model in writing before cutover.

Who has access to identity data and logs in a self-hosted setup?

In a self-hosted setup, access is whatever your own controls allow, and that needs to be written down. Map who can reach the database, the Keycloak admin console, log stores and backup files, including vendor or partner engineers during support. Each of those paths is a potential transfer if it is reachable from outside the EEA. Keep support access time-limited and logged, and decide where logs are stored and for how long. Keycloak also exposes metrics that feed your monitoring stack, so include them in the same review. Your records of processing should reflect this map, and an independent auditor can later test whether the controls work.

What does the EU Data Act change for switching identity providers?

The EU Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure. It has applied since 12 September 2025, with a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027 (Articles 25, 29 and 50). This matters when you negotiate with an EU-hosted identity service, because it limits lock-in. Article 32 also requires providers to take measures against third-country governmental access to non-personal data held in the Union. Confirm with your provider how these rights are reflected in its contract and how exports would work in practice.

Moving users and apps without re-running the whole identity program

Treat the move of users and applications as a separate, scoped project with its own cutover plan, rather than a rerun of the original identity program. The data-location decision sets the target, but the migration itself is mostly about exporting identities you can legally and technically carry across, then re-federating each application. Okta gives you three routes for user lists: the Password Health report CSV in the Admin Console, the community Rockstar browser extension, or the List Users API with a filter. The API route is the one to script and version, because you can filter to active users and capture the attributes your target realm needs, such as email, username and group membership.

Plan for the fact that password hashes generally do not leave the source system in a usable export. That means users will re-enroll passwords and MFA factors in the new identity provider, and the cutover must allow for that. Ask your Okta administrator and your target platform team to confirm what the exports include in your tenant, and test a sample import in a non-production Keycloak realm before committing to a date. Run a pilot group first, and keep the Okta tenant read-only and available for a defined period so users and support staff can fall back during the transition.

Re-federating applications is the larger effort. Inventory every SAML and OIDC integration, its redirect URIs, signing certificates, attribute mappings and claims, then recreate each as a Keycloak client and confirm the relying party accepts the new issuer. For detailed steps on exports, app re-federation and password and MFA re-enrollment, follow the Migrate from Okta to Keycloak guidance in the sibling topic rather than repeating it here. Record which applications process personal data for which controllers, because each re-federation changes where identity data flows and should be reflected in your records of processing.

How DeployOpen deploys Keycloak under EU data residency rules

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure, including EU data centers and EU provider accounts. For EU sovereignty work, we start by mapping where identity data, logs and support access actually travel, then build the deployment to keep them there.

How we scope

  • Map every flow of identity data, logs and support access, including sub-processors and remote administration paths.
  • Confirm hosting location, provider jurisdiction and the data controller's transfer assessment inputs before design starts.
  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work begins.

How we build

  • Deploy Keycloak in your EU datacenter or EU provider account, with the database, backups and logs kept in the agreed region.
  • Configure LDAP or Active Directory federation, SAML and OIDC clients, and access controls that limit administrator and vendor access.
  • Test the deployment, including security testing of the login flows and admin console, and document the results.

How we hand over

  • Deliver architecture, data flow and sub-processor documentation so your compliance team can assess the setup independently.
  • Document backup and restore procedures, including the realm export limitations and how to run them without data loss.
  • Prepare systems, controls and evidence for your compliance assessment; independent auditors issue any formal opinion or certification.

How we support

  • Patch and upgrade Keycloak on a planned schedule, with operator update approvals kept under your change control.
  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • Confirm with us, in writing, which support access paths exist and who approves each one before go-live.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com