Self-hosted SSO for EU data sovereignty

A transfer impact assessment starts from a map of where identity data flows, who can reach it, and which third-country laws could reach it. For a self-hosted Keycloak, authentik or ZITADEL deployment on EU infrastructure, the inputs are the hosting location of the database and backups, the list of administrators and support vendors with remote access, and any external services the identity provider calls, such as email, SMS or social login brokers. The EDPB Guidelines 05/2021 treat remote access from a third country, even screen display for support, as a transfer, so support paths belong in the assessment. Ask your implementation partner to document each path in writing and to confirm which of your own contracts with cloud or support providers carry third-country exposure. The assessor will also look at the GDPR text on Chapter V conditions that apply to each identified flow.

The record of processing should name the identity data categories (account identifiers, credentials, MFA enrollment data, login logs, session metadata), the purposes, the retention periods and the physical and logical location of each store. For a self-hosted deployment, the producing components are the identity provider's database (PostgreSQL in the supported authentik architecture, or one of the Keycloak supported production databases), the backup target, log shipping destinations and any directory federation source such as LDAP or Active Directory. Keep the data location table current after each upgrade or infrastructure change, because a new sidecar or log exporter can move personal data outside the intended region. Confirm the retention settings for sessions and events in your own environment rather than relying on defaults.

Assessors usually want an export of the authentication flow, required actions, MFA policy, password rules, lockout and session timeouts, taken from the running system and dated. In Keycloak, the realm export and the authentication flow definitions show these settings; in authentik, the blueprints and flow and stage bindings serve the same purpose; in ZITADEL, the login policy and organization settings do. Store these exports in version control so changes appear as reviewed diffs. Pair them with a sample of login attempts that show the policy applied, since an export alone does not prove the policy was active during a given period. The Keycloak database guide and configuration production documentation list the settings to capture for your version.

Assessors look for a log of every administrative session, including which account made each change, from which network, and what was changed. The producing components are the identity provider's admin event and audit logging, the operating system and database audit logs, and the bastion or privileged access tool used for vendor sessions. Note that enhanced audit logging is listed as an enterprise-only feature on the authentik pricing page, so confirm which audit capabilities your chosen edition includes. Retain these logs in a location the vendor cannot silently alter, and record every remote session that a support engineer opens from a third country, because that access is itself a transfer.

The assessor needs a current bill of materials that lists each component, its exact version, its license, and its patch status. For a typical stack this includes the identity provider, its database, the operating system, the container runtime, and any connectors or themes. License differences matter: Keycloak is under Apache-2.0, authentik's core is under MIT with a separate enterprise license for its enterprise directory, and ZITADEL is under AGPL-3.0, which carries network-use obligations if you modify the code and expose it to users. Record the version and release date from the project's release page at the time of each review. Ask your partner to confirm which license applies to any extension or paid edition you add, because the paid edition terms are separate documents.

Assessors commonly ask for a written upgrade procedure, test results from a non-production copy, and a record of the versions in use over time. For Keycloak, the operator documentation recommends manual approval mode for operator updates, and schema migration can run automatically at startup or be applied manually, so record which method you chose. For authentik, the security policy lists which versions receive security fixes and announces security releases at least 24 hours ahead, which should be reflected in your patch calendar. Keep the change record for each upgrade, including the database backup taken before it, the rollback plan, and the sign-off.

Assessors will expect a documented response procedure that covers how requests are logged, reviewed by legal counsel, and limited to what is necessary. The CLOUD Act provision at 18 U.S.C. 2713 applies to US-headquartered providers regardless of data location, and GDPR Article 48 limits recognition of third-country disclosure orders to those based on an international agreement. Because the EDPB Recommendations 01/2020 say no effective technical supplementary measure exists where a provider must access data in the clear under overbroad powers, the procedure should also cover contractual and architectural choices, such as keeping keys and data under EU control. Ask your legal team to confirm how these rules apply to your specific supplier chain, since DeployOpen does not issue legal opinions or audit reports.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. In practice, the engagement produces the configuration exports, architecture and data location documentation, license and version records, and runbooks described above, scoped in writing before work starts. Ask any implementation partner to list the evidence artifacts they will deliver, who maintains each one after handover, and which items remain your responsibility, such as legal review of transfer risk and the final assessor selection.

The cost is driven mainly by who runs the identity provider, how many applications must be integrated, and how much legal and data mapping work precedes the build. The open-source software itself carries no license fee for Keycloak, which is Apache 2.0, but you pay for infrastructure, a supported database, application integration effort, MFA rollout, testing, and ongoing operations. Ask any partner for a written scope that lists each cost line separately: infrastructure and database (one-time setup plus recurring hosting), integration per application (one-time), MFA enrollment support (one-time plus help desk load), legal review of data flows (one-time), and operations and upgrades (recurring). Each line should name who is paid for what.

Usually not for core single sign-on. Keycloak is Apache-2.0 licensed and authentik's repository puts most code under MIT, with enterprise features in a separately licensed directory. Paid editions are worth pricing only when you need a specific feature they gate. For authentik, the pricing page places Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging in its Enterprise tier. Enterprise Plus adds dedicated support with SLAs and FIPS compliance for FedRAMP requirements. Before you commit, confirm with the vendor which features your design depends on, and include subscription costs as a recurring line item in your quote.

Yes, if your team has the skills to operate a production identity system, but the work is larger than the software installation. The hard parts are the directory and application inventory, data mapping for GDPR and transfer analysis, high availability design, upgrade testing and MFA enrollment for staff. Keycloak documents three high availability architectures, and each supported design needs a synchronously replicated database, which is a design decision your team must own. Keycloak also documents that its Operator should use manual approval for updates. A partner can deliver a fixed-scope project with written deliverables, while your team keeps operating the platform. Decide which of these tasks you will carry in-house before requesting quotes.

Your team must supply access, decisions and sign-off. Expect to provide read access to the source directories (such as Active Directory, LDAP or an existing identity provider), a list of applications with their owners and protocols (SAML, OpenID Connect or none), and a named business owner for each application who can approve testing. Data protection and legal staff must sign off the data mapping: which personal attributes flow to which systems, where the database and backups sit, and whether any remote administration or support access comes from outside the EEA. Ask the partner to list these inputs in the written scope so that delays are visible before work begins.

The duration depends on the number of applications, the state of the directory, and how many applications lack SAML or OpenID Connect support. No timeline for this project is supplied here, so treat any figure from a vendor as a claim to verify. The schedule is usually driven by application owner availability, testing cycles for each integration, and the staged cutover of users from the old provider. Ask for a phased plan with a named pilot group, a list of applications per phase, and exit criteria for each phase. Ask how the plan handles applications that cannot use single sign-on, since those often extend the timeline.

A retainer makes sense when the identity provider becomes a critical dependency and your team cannot absorb upgrades, security fixes and monitoring on its own. Keycloak plans four minor releases a year and a major release every two to three years, and authentik publishes security releases with at least 24 hours of advance notice, so someone must track and test each release. Ask for a retainer scope that covers patch testing, upgrade windows, incident response hours and periodic security testing. Compare that scope against your internal staffing. Retainer prices should come from a written quote, not a published rate card.

No. Hosting in an EU data center reduces exposure, but it does not settle the legal analysis by itself. EDPB Guidelines 05/2021 treat remote access from a third country, even just displaying data for support, as a transfer. Vendor support sessions, cloud backups, and telemetry sent outside the EEA can each create a transfer. Ask your counsel to review every support path, backup location and log destination. Keep the written scope explicit about which systems and personnel can access identity data, and where each one is located.