Self-hosted Entra ID alternative for EU data sovereignty

Why EU data sovereignty changes the Entra ID decision

A European CISO or DPO reviewing Microsoft Entra ID usually finds that the tenant has a fixed home location, while some identity data, including MFA data, can be processed and stored in North America. The decision in front of them is whether application SSO should keep running on a service whose data flows they cannot fully control. Moving application SSO to a Keycloak deployment under your own control addresses the transfer and third-country access exposure, while Microsoft 365 sign-in may reasonably remain on Entra ID. This is a constraint decision driven by where personal data lives and who can compel access to it, not a verdict on Microsoft's security or service quality.

The legal starting point is GDPR Article 44, which requires every transfer of personal data to a third country, including onward transfers, to meet Chapter V conditions. The EDPB's Guidelines 05/2021 treat storage in a cloud outside the EEA, and even remote display of data for support, as transfers. The exposure also comes from foreign law: the US CLOUD Act at 18 U.S.C. 2713 applies to data in a provider's possession, custody or control wherever it sits, and EDPB Recommendations 01/2020 say no effective technical supplementary measure can be envisioned where a cloud provider must access data in the clear and the public authority's powers go beyond what is necessary and proportionate. Ask your provider which identity data categories are stored outside the EEA, and who can access them.

What GDPR and EU rules require of identity data

Identity data such as user records, group memberships and MFA enrolments is personal data, so every copy that leaves the EEA or falls under foreign legal reach is a transfer question. The cards below set out the rules that shape that decision for a Microsoft Entra ID review. This is not legal advice; confirm the position with your data protection officer and counsel.

Chapter V applies to remote access too

Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when a support engineer only views data on a screen, and treat storage in a cloud outside the EEA as a transfer. For identity, check where Microsoft support and administrators can view directory data and MFA records, not only where the tenant is pinned. Ask Microsoft to document these access paths in writing.

Fines under Article 83(5)(c)

Infringements of Articles 44 to 49 fall in the higher fine tier of Article 83(5)(c), with fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. Identity systems are a common place for these gaps to hide because MFA and directory data often flow through support tooling. Record the transfer analysis for each identity data category in your records of processing, so the exposure is visible to your board.

Schrems II and the transfer tools

In Case C-311/18 the Court of Justice invalidated the EU-US Privacy Shield adequacy decision while upholding standard contractual clauses, which means each transfer needs a tool plus an assessment of the destination's law. EDPB Recommendations 01/2020 state that where a provider needs data in the clear and foreign public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Document your transfer impact assessment for Entra ID before relying on contract terms alone.

Data Privacy Framework status

Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment upholding the framework is pending as Case C-703/25 P, so its long-term stability is open. Check whether your Microsoft contracting entity is certified, and plan for a fallback transfer mechanism in case the framework is struck down.

CLOUD Act reach over EU data

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 that data is located. An EU tenant pinned to European datacenters does not remove this reach if the provider controls the data. Ask your provider for its government request policy and how it handles conflicts with EU law, and treat that exposure as part of the Article 44 assessment.

Article 48 limits on disclosure orders

Article 48 allows a third-country court judgment or administrative decision demanding personal data to be recognized or enforced in the EU only if it rests on an international agreement in force with the Union or a Member State, such as a mutual legal assistance treaty. Without such an agreement, a foreign order does not automatically override GDPR for an EU controller. This is a limit on enforceability, not a guarantee that a disclosure request will be refused, so review it with counsel.

Data Act switching rights

Regulation (EU) 2023/2854 applies from 12 September 2025 and gives customers of data processing services the right to switch 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. Article 32 also requires providers to take measures against third-country governmental access to non-personal data held in the Union. Use these rights as leverage in the contract review, and confirm the terms with your provider.

Where Entra ID meets the constraint and where it does not

Entra ID is tied to a tenant, and the tenant has a home location that an organization generally cannot move after creation. That fixed anchor is only part of the picture. Identity data such as directory objects, sign-in logs and multi-factor authentication records can be processed in more than one place, and some of those places may be outside the EEA. Whether a given data type is stored in the EU, processed elsewhere or accessed remotely by support staff is a question for Microsoft's documentation and contract terms, not for assumptions drawn from the tenant location.

Tenant location: The home location chosen at tenant creation anchors the directory, but it does not automatically cover every data category.
MFA data: Authentication method data may be processed in North America, which is the concern this page starts from.
Sign-in and audit logs: Log retention and processing location should be checked separately from the directory.
Remote access: Under EDPB Guidelines 05/2021, even remote viewing of data from a third country counts as a transfer, so support access paths matter.
Self-hosted contrast: With Keycloak on your own servers in an EU location, you decide where each data category is stored and who can reach it.

Ask Microsoft for the current data location documentation for each Entra ID service you use, and map each data category to a location in your own record of processing.

Which open-source options keep identity data under your control

This table compares Keycloak, authentik, ZITADEL and FreeIPA on where identity data is stored, how each is licensed and supported, and which Entra ID capabilities each covers. Read each row as a question to answer in your own assessment, because the storage location and transfer analysis depend on your hosting choice and contracts. The main takeaway is that all four run in infrastructure you select, but they differ in support model and in how far they replace Entra ID features.

Criterion	Keycloak	authentik	ZITADEL	FreeIPA
Where identity data lives	In the PostgreSQL or other supported database you run, in a region you choose	In the PostgreSQL database you run, in a region you choose	In the PostgreSQL 14 or later database you run, in a location you choose	In the directory servers you run, on your own Linux hosts
License	Apache License 2.0	MIT for the open-source core, separate authentik EE License for enterprise features	AGPL-3.0 with Apache 2.0 and MIT exceptions for specific directories	Open source, used as a Linux identity stack
Protocols	OpenID Connect, OAuth 2.0, SAML 2.0, LDAP and AD federation	OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication	Certified OIDC, SAML 2.0, SCIM 2.0 and LDAP	Kerberos, LDAP and integration with Microsoft Active Directory through trusts
Support model	Community support, with commercial support from Red Hat through its build of Keycloak	Community support in the free edition, ticket support and SLAs in paid tiers	Confirm the support tier and terms directly with ZITADEL	Community support, with commercial support from vendors that package it
Conditional Access equivalent	Conditional authentication flows you build and maintain yourself	Policies and flows, with some Entra ID-style controls only in the Enterprise edition	Confirm the policy features you need against current documentation	Not applicable
Entra ID integration	Can federate with Entra ID as an upstream identity provider	Entra ID integration is an Enterprise feature	Can federate with Entra ID for sign-in	Can form trusts with Microsoft Active Directory, not with Entra ID directly
Fit for application SSO	Strong fit for web and enterprise app SSO and SAML apps	Good fit for mixed apps, network devices and Linux hosts	Good fit for multi-tenant or customer-facing identity	Directory and Kerberos source beside an SSO server, not an SSO product

How to deploy Keycloak in an EU location you control

This sequence moves application SSO onto a Keycloak deployment that your organization hosts in a location it chooses, with a production database, tested high availability, federated directory sources, re-pointed applications and a backup routine. The end state is a documented, operable identity service with its data placement decided in advance.

Fix hosting location and provider terms
Your data protection, legal and security leads choose where the Keycloak nodes and database will run, and whether that is your own data center, an EU cloud account you control, or a provider you contract with directly. Record the processing location, any remote support access from outside the EEA, and whether the provider is subject to third-country law with extraterritorial effect, so you can assess that exposure before signing. Ask the provider in writing to confirm where backups, logs and support sessions are stored and accessed from. The step is done when the location decision, the contract terms and the data flow diagram are signed off by your privacy and security owners.
Deploy Keycloak on a supported production database
Your platform team installs Keycloak in production mode on the infrastructure chosen in the previous step, using a supported production database rather than the development file database. Keycloak's documentation lists PostgreSQL 14 to 18 among its supported databases, so confirm the exact version you deploy against the current database guide before provisioning. If you run on Kubernetes, install the Keycloak Operator through Operator Lifecycle Manager, which is the recommended method, and keep the database credentials in your secrets store. The step is done when a single node serves the admin console over TLS and connects to the database without using the development database.
Configure high availability with synchronous replication
Your platform team sets up the high availability design that matches your availability needs, choosing among the single cluster option (optionally spread across availability zones), the multi-cluster v2 design without external Infinispan, or the deprecated v1 design. Both supported designs require a synchronously replicated database, so confirm with your database team that replication is synchronous across the sites you plan to use. Test node failure and database failover in a non-production environment before cutover. The step is done when a planned node loss and a database failover both complete without losing sessions or configuration that your team considers critical.
Federate existing AD or LDAP directories
Your identity team connects Keycloak to the existing Active Directory or LDAP server through Keycloak's user federation, so that identities remain in the directory you already govern while Keycloak handles application sign-in. Use a read-only bind account, map the attributes your applications need, and decide whether group and role mappings are imported or resolved at login. Confirm with your directory owners how password changes, account disablement and group membership changes will propagate to Keycloak. The step is done when a test user from each directory population signs in and the attributes your applications require appear in the token claims.
Re-point SAML and OIDC applications
Your application owners register each SAML 2.0 and OpenID Connect client in Keycloak and switch the application's identity provider settings from the Entra ID enterprise app to the Keycloak realm, one application at a time. Keep the redirect URIs, signing certificates and claim mappings documented for each client, and run the old and new sign-in paths side by side until each owner signs off. Your team can express clients as code using the Operator's KeycloakOIDCClient and KeycloakSAMLClient resources if you want them versioned. The step is done when every in-scope application signs in through Keycloak in a test environment and the change record lists each client's owner and rollback path.
Set manual approval for Operator updates
Your platform team configures the Keycloak Operator subscription to manual approval mode, which the Operator documentation strongly recommends to avoid unintended automatic upgrades. Each proposed Operator or Keycloak version is then reviewed against the release notes and the upgrading guide before someone approves it in a change window. Pin the version in your deployment manifests so that a cluster rebuild cannot pull a newer release by accident. The step is done when an approval request is visible in your cluster tooling, the approval owner is named in your runbook, and no update has been applied without a recorded review.
Choose the database schema migration method
Your platform team decides how database schema changes are applied during upgrades. By default Keycloak migrates the schema automatically at startup, which is simple for small deployments. The upgrading guide suggests manual migration for large deployments, where administrators review and apply the SQL themselves under a database change process. Document which method you use, test an upgrade on a copy of production data, and confirm that your database backup is current before applying any migration. The step is done when a test upgrade completes with the chosen method and the runbook records the rollback steps.
Back up and verify restore paths
Your operations team sets up backups of the database and the server configuration, and treats realm export as a supplementary artifact rather than the primary backup. The Keycloak documentation warns that the export and import commands have limitations as a backup and restore mechanism, and that all nodes must be stopped while the export runs, so schedule exports in a maintenance window if you use them. Run a restore into a separate environment at least once and time how long it takes, so the recovery procedure is known rather than assumed. The step is done when a restore test succeeds and the backup owner, schedule and retention policy are recorded in the operations runbook.

What can stay on Entra ID and what should move

The move usually starts with application SSO, not the whole identity estate. Microsoft 365 sign-in, Exchange, SharePoint and Teams depend on Entra ID in ways Keycloak does not replace, so those services typically stay where they are unless the organization decides to re-platform them entirely. The useful question for each application is what personal data it processes, where that data is held, and whether the sign-in path sends that data through Entra ID's infrastructure. Applications that hold employee or customer records in a third country, or that depend on remote support from outside the EEA, are the first candidates. Confirm with Microsoft which Entra ID tenant data and sign-in logs are stored and where, using the tenant's own data location documentation, rather than assuming the tenant location settles the question for MFA and sign-in telemetry.

For each application, run a transfer analysis before changing the sign-in path. Under the EDPB guidelines on Article 3 and Chapter V, storage in a cloud outside the EEA and remote access from a third country are transfers, so an identity provider that a third-country team can administer or support needs the same scrutiny as the application it protects. Record whether the processor could be compelled under the US CLOUD Act to disclose data it controls, and whether the Data Privacy Framework still covers the provider relationship at the time of the review, since an appeal in Case C-703/25 P is pending. Keycloak moves control of the identity store into your own infrastructure, but the analysis still has to cover your hosting provider, your backup location and any external support contract.

Use the switching rights in the Data Act as leverage in the contract conversation. Under Regulation (EU) 2023/2854, customers can switch 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, and switching charges are banned from 12 January 2027. Ask your Microsoft account team how those notice and transition periods apply to your agreement, and document each application's exit plan (its SAML or OIDC client definitions, group mappings and attribute releases) before notice is given. Treat the Data Act timing as a planning constraint, not a deadline you can rely on to finish a migration, because re-pointing each application still needs testing in your own environment.

Evidence that regulators and auditors ask for

Moving application SSO to Keycloak under your own control only helps a sovereignty review if the paperwork shows where identity data lives, who can reach it and how the platform is run. The cards below list the records a data protection authority or an independent auditor is likely to ask for, and the checks that make each one trustworthy. DeployOpen prepares this evidence but does not issue audit reports or certifications; independent auditors and certification bodies do.

Record of processing and transfer map

Record every identity data flow in the Article 30 record of processing, including user attributes, MFA factors, session logs and the sign-in traffic to Microsoft services that stays on Entra. For each flow, note the storage location, the operator, and whether any remote administration or support session displays data from a third country. EDPB Guidelines 05/2021 treat that display as a transfer, so the map must show it. Check that the map matches the actual Keycloak database and backup locations.

Processor and sub-processor assessment

Document each processor and sub-processor that touches the identity stack, such as hosting, managed database, backup, monitoring and support providers. For each one, record whether it is subject to third-country law with extraterritorial reach, such as 18 U.S.C. 2713, and how a government request would be handled. EDPB Guidelines 05/2021 (Example 12) say that complying with such a request would be a transfer, so this exposure needs its own assessment before the contract is signed.

Supplementary measures and necessity findings

Write down the supplementary measures you rely on, such as encryption with keys you hold, access restricted to EU-based administrators and documented request handling procedures. Where a provider may need data in the clear and third-country powers go beyond what is necessary and proportionate, EDPB Recommendations 01/2020 say no effective technical supplementary measure can be envisioned. Record that conclusion openly so the decision to keep the identity store in your own infrastructure is traceable. Confirm the position with your data protection officer and legal counsel.

Configuration records and Keycloak metrics

Keep versioned exports of realm configuration, client registrations, authentication flows and identity provider settings, so each change can be traced to a date and an owner. Enable Keycloak metrics for login, token and failure counts, and retain them for your own retention period. Auditors will ask whether these records show who changed a client or a federation link. Confirm with your security team which log fields are kept and where they are stored.

Backup and restore test results

A realm export is not a full backup. The Keycloak documentation warns that export and import have limitations as a backup and restore mechanism, and that all nodes must be stopped while the export runs. Pair realm exports with database-level backups, and record dated restore tests that rebuild a realm in a separate environment and confirm that users can sign in. Keep the test logs with the recovery objectives your business has set, which you should confirm with your own continuity plan.

Operator update approval trail

If you run Keycloak on Kubernetes with the Operator, record each update as an approved change. The Operator documentation strongly recommends manual approval mode to avoid unintended automatic upgrades, so the approval record should name the reviewer, the target version, the test result and the rollback plan. Keep the upgrade notes from the Keycloak project with each change, since breaking changes in minor releases are opt-in. Confirm that the approval workflow is enforced by your change management tooling, not by convention.

Questions EU buyers ask before moving SSO off Entra ID

What drives the cost of a self-hosted Keycloak deployment?

The cost is the sum of several components, and each one has a different owner. Servers or cloud capacity are paid to your infrastructure provider and recur monthly or yearly. The database, usually PostgreSQL from the supported list, adds hosting, backup and patching work. High availability roughly multiplies the node count and needs a synchronously replicated database, so it is a design cost you pay once and run continuously. Support is paid to a vendor or partner if you want it, and app migration work (re-pointing SAML and OIDC clients, testing sign-in flows) is largely one-time. Keycloak itself is licensed under Apache 2.0, so there is no per-user license fee. When requesting a quote, ask each component to be priced separately, with one-time and recurring costs listed apart, and ask which items your own team already covers.

How long does moving application SSO to Keycloak take?

The duration depends on the number of applications, how many use SAML versus OIDC, how much Conditional Access logic has to be rebuilt, and how many user populations and directories are involved. Applications with custom claims, legacy protocols or unusual session rules take longer to test than standard OIDC clients. High availability design, environment separation and change windows also add time. Because no figure has been supplied for this page, ask for a timeline in the written scope instead of relying on a generic estimate. A sound scope lists each application, its protocol, its owner, its test plan and its cutover approach, which lets the timeline follow from the inventory.

Can an internal team move SSO to Keycloak without outside help?

Yes, many internal teams can run a Keycloak deployment, provided they have people who understand OIDC and SAML flows, database administration, container or Kubernetes operations and certificate management. The Keycloak Operator is an option for Kubernetes teams, and the documentation covers production configuration, metrics and high availability. The harder part is usually not the installation but the surrounding work: inventorying every enterprise app, rebuilding policies, testing failover and keeping upgrades current. Ask your team to confirm skills in each area and to list the staff hours they can commit. A fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backup and documentation, while your team keeps operational ownership.

Does moving SSO to Keycloak remove all third-country exposure?

No. Moving application SSO off Entra ID changes where the identity store for those apps lives, but it does not change every data flow. Microsoft 365 sign-in, Exchange, Teams and other Microsoft services can still depend on Entra ID, and their data may be processed in locations outside the EU. MFA providers, email delivery, monitoring tools, backup services and any support access by a vendor can also cross borders, including by remote access under the EDPB's Guidelines 05/2021. Map every service that touches identity data, record where it is stored and processed, and review each transfer with your data protection officer and counsel. Keep in mind that the EDPB Guidelines treat a request from a third-country authority as a separate exposure, which depends on the provider's legal obligations.

What does a fixed-scope Keycloak engagement include, and what does the quote need?

A fixed-scope engagement is agreed in writing before work starts and typically covers the deliverables you name: planning, implementation in your infrastructure, integration with your directory, hardening, backup and restore procedures, upgrade runbooks and documentation. DeployOpen does not publish a price list, so a quote follows from the written scope. To get a useful quote, supply an application inventory with protocol and owner, the directory sources and their sizes, the target hosting (cloud account, data center or air-gapped network), high availability requirements, database preference, the compliance evidence you need, and the ongoing support model. Ask whether testing, cutover support and knowledge transfer are included, and which items are excluded.

How should we run Keycloak upgrades safely?

Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in. Still, a safe process treats each upgrade as a change. Read the release notes and backwards compatibility notes for each version you skip, test the upgrade in a staging environment with a copy of production data, and decide whether to let the server migrate the database schema automatically at startup or to apply the SQL yourself, which the upgrading guide suggests for large deployments. For the Keycloak Operator, the documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Back up the database before each change, and schedule a rollback plan. Confirm with your team who approves each upgrade.

Why does a Keycloak realm export not work as a full backup?

A realm export through the kc.sh export command produces JSON files that describe realm configuration, but the Keycloak documentation warns that this process has limitations as a backup and restore mechanism. All nodes must be stopped while it runs, so it is not a live backup of a running cluster. Plan backups at the database level with tested restores, keep realm exports as configuration snapshots for reviews and migrations, and store copies within your own jurisdiction. Test a full restore into a separate environment at a set interval and record the result as evidence for your auditors. Confirm the restore procedure with your database team before go-live.

How DeployOpen deploys Keycloak under EU residency rules

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Keycloak, that means you decide where identity data, MFA secrets and session logs are stored before any configuration starts, and the written scope records those decisions.

How we scope

Map which applications, protocols and user populations move from Entra ID to Keycloak, in writing before work starts.
Record where the database, backups, logs and MFA data will sit, and which third-country access paths must be closed.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.

How we build

Deploy Keycloak on infrastructure you control, using a supported PostgreSQL version and a documented high availability design.
Federate existing LDAP or Active Directory sources and re-point SAML and OIDC applications, with tests for each application.
Configure production settings, metrics and operator update approval so upgrades happen on your schedule, not automatically.

How we hand over

Document the data flows, hosting locations and administrator access paths so your data protection team can review them.
Write tested backup and restore runbooks, since realm JSON export is not a complete backup method on its own.
Provide evidence of configuration and controls to support your compliance assessment. Auditors and certification bodies issue the actual opinions.

How we support

Apply Keycloak patches and minor and major upgrades under a retainer, following the release notes and a tested upgrade plan.
Run security testing of the deployed applications and APIs, and retest after material configuration changes.
Confirm with your legal counsel whether any remaining transfer, such as vendor support access, needs assessment under GDPR Chapter V.

Self-hosted Microsoft Entra ID alternative for EU data sovereignty