Sovereign Identity Management: Open-Source Azure AD Replacement

Sovereign identity management means operating an organisation’s authentication and access-control infrastructure entirely within its own legal and technical perimeter, without delegating the identity layer to a cloud provider whose legal domicile places it under foreign jurisdiction. For European government bodies, financial institutions, healthcare organisations and law firms, this distinction is not theoretical: the identity provider holds the keys to every application, every file share and every communication tool in the organisation.

The Jurisdictional Problem with US-Controlled Identity Providers

When an organisation’s identity provider is incorporated in the United States, every authentication event and every stored credential falls within the reach of US extraterritorial law, regardless of where the data physically resides.

Microsoft Entra ID (formerly Azure Active Directory) and Google Identity are both operated by US entities. Under the Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018, US federal authorities can compel these providers to hand over data stored anywhere in the world by serving a warrant or court order on the US parent company. The data does not need to cross borders for the obligation to arise: the legal compulsion reaches the provider, not the data centre.

Beyond the CLOUD Act, FISA Section 702 enables bulk collection from electronic communications service providers for foreign intelligence purposes, and the USA PATRIOT Act provides additional compelled-disclosure mechanisms. An organisation using Entra ID accepts that its directory, its authentication logs and its conditional-access configuration exist within the legal perimeter of all three instruments. For a public-sector body or a regulated financial institution, this is a structural compliance problem, not merely a theoretical risk.

Open-Source Platforms That Replace Microsoft Entra ID

Several mature, self-hostable platforms cover the full IAM feature set that organisations depend on in Entra ID, including SSO, multi-factor authentication, directory services, role-based access control and device policy enforcement.

Keycloak is the most widely adopted of the three in European public-sector deployments. It supports user federation against existing on-premises Active Directory or LDAP directories, meaning organisations can migrate their identity infrastructure incrementally rather than replacing everything at once. Its support for FIDO2 hardware security keys via the WebAuthn standard is native and does not require additional plugins: administrators can enforce hardware-token MFA as a mandatory authentication flow for privileged accounts or sensitive applications.

Integrating Self-Hosted SSO with a Sovereign Workspace

A self-hosted IAM platform becomes the authentication backbone for every other sovereign tool in the stack, connecting them through standard protocols without routing any authentication traffic through foreign infrastructure.

SAML 2.0 and OpenID Connect in practice

Nextcloud, the open-source collaboration platform used as a sovereign Microsoft 365 replacement, supports both SAML 2.0 and OpenID Connect (OIDC) natively. When Keycloak acts as the identity provider, a user who authenticates once gains access to Nextcloud files, the organisation’s sovereign email platform (such as Mailcow or Dovecot), internal wikis and private AI tools running on self-hosted models such as Mistral or Llama, all without a single authentication request leaving the organisation’s infrastructure.

The practical configuration involves registering each application as a client in Keycloak, mapping user attributes and group claims to the format each application expects, and configuring logout propagation so that a single sign-out terminates all active sessions. This is standard OIDC back-channel logout behaviour, well-documented in the Keycloak administration guide.

Device compliance without a cloud MDM

Entra ID’s conditional-access policies often incorporate device-compliance signals from Microsoft Intune. In a sovereign architecture, device compliance is handled by a self-hosted MDM platform such as Headscale (for network access) combined with a configuration management tool. Keycloak’s authentication flows can require a client certificate issued only to enrolled and compliant devices, replicating the enforcement logic of Intune without the dependency on Microsoft’s cloud infrastructure.

Migrating from Entra ID: A Structured Approach

Migration requires preserving three things simultaneously: user and group data, access policy logic, and the audit trail that regulators may inspect.

Exporting and transforming directory data

The starting point is a full export of the Entra ID directory using the Microsoft Graph API, which returns users, groups, application registrations and conditional-access policies in JSON format. User attributes, group memberships and nested group structures map directly to Keycloak’s user and group model. Automated import scripts using the Keycloak REST API can process tens of thousands of accounts reliably. Passwords cannot be migrated in plaintext: the standard approach is to force a password reset at first login to the new platform, communicated in advance to users with a clear timeline.

Replicating conditional-access policies

Entra ID conditional-access policies typically enforce combinations of user group, network location, device state and MFA requirement. Each of these maps to a Keycloak authentication flow or policy condition. IP-range restrictions use Keycloak’s condition-based authentication flows. Group-specific MFA requirements are implemented as per-client or per-realm authentication policies. The mapping is not always one-to-one but the functional outcome is equivalent.

Preserving audit continuity

Audit continuity is the element most often underestimated during IAM migrations. Before decommissioning Entra ID, the full sign-in and audit log archive must be exported and retained in its original structured format, because GDPR accountability obligations and NIS-2 incident-investigation requirements may require access to historical authentication records. The new sovereign IAM must write structured logs to an immutable SIEM from day one, so that there is no gap in the timeline that an auditor or supervisory authority might question.

Satisfying GDPR Article 25, NIS-2 and DORA with a Single Architecture

A self-hosted IAM architecture addresses the identity-related obligations of all three regulatory frameworks through a single set of technical controls.

GDPR Article 25, which requires data protection by design and by default, obliges controllers to implement technical measures that ensure only the personal data necessary for each processing purpose is accessible by default. A sovereign IAM enforces this at the protocol level: OIDC scopes limit which attributes are released to each application, role-based access control ensures users receive only the permissions their function requires, and the absence of a US-jurisdiction provider eliminates the structural exposure described above.

NIS-2 (Directive (EU) 2022/2555) requires essential and important entities to implement access-control measures as part of their baseline security obligations under Article 21. ENISA’s implementation guidance specifies that access control should be reviewed regularly and that privileged access should be protected by strong authentication. A self-hosted Keycloak deployment with enforced FIDO2 hardware security keys for administrators directly satisfies this requirement, and the audit logs produced are the evidence needed to demonstrate compliance during an inspection.

DORA (Regulation (EU) 2022/2554), which applies to financial entities and their critical ICT providers from January 2025, requires entities to manage concentration risk in their ICT third-party dependencies and to maintain resilience in critical functions. Placing identity and access management with a US hyperscaler creates a single point of foreign-jurisdiction dependency for every system in the organisation. A self-hosted IAM removes this dependency and supports the ICT resilience testing and third-party risk management requirements that DORA mandates.

According to the IBM Cost of a Data Breach Report 2023, the average cost of a data breach globally reached USD 4.45 million, the highest figure in the report’s history. For regulated European organisations, enforcement actions under GDPR add a separate financial exposure on top of breach costs, making preventive architectural investment economically justified as well as legally necessary.

Practical Considerations Before Starting the Migration

Organisations should conduct a dependency audit before touching the Entra ID configuration. Every application that uses Entra ID for authentication must be catalogued, along with the protocol it uses and the specific claims it requires. Applications that rely on legacy authentication protocols such as NTLM or Kerberos require additional federation work and should be scheduled later in the migration timeline. The sovereign IAM platform should run in parallel with Entra ID during a transition period of at least four to eight weeks, with users migrated in cohorts by department or risk profile rather than all at once. This approach maintains a fallback path and allows the help desk to manage support volume without disruption to operations.

FAQ

Does Keycloak support multi-factor authentication and FIDO2 hardware security keys?

Yes. Keycloak natively supports WebAuthn, which covers FIDO2 hardware security keys such as YubiKey. Administrators can enforce hardware-token MFA as a required authentication flow for specific clients, user groups or risk levels, without any third-party plugin.

Can a self-hosted IAM platform enforce conditional access policies comparable to those in Microsoft Entra ID?

Platforms such as Keycloak and Authentik support context-aware authentication flows based on IP range, device registration, group membership and time-of-day conditions. These cover the most common Entra ID conditional-access scenarios. Very advanced device-compliance integrations may require additional tooling such as a self-hosted MDM solution.

What happens to audit logs when migrating from Entra ID to a self-hosted IAM?

Audit continuity requires exporting the full Entra ID audit and sign-in log archive before decommissioning. Logs must be retained in their original format to satisfy GDPR accountability requirements and potential regulatory inspection. The new sovereign IAM must be configured to write structured logs to an immutable SIEM from day one, so there is no gap in the audit trail.

Is Keycloak suitable for organisations with thousands of user accounts?

Keycloak is designed for enterprise scale and is deployed by public-sector and financial organisations across Europe with tens of thousands of accounts. It supports clustered deployments, external LDAP or Active Directory user federation, and horizontal scaling through its Quarkus-based distribution.

How does sovereign IAM relate to DORA compliance for financial entities?

DORA Regulation (EU) 2022/2554 requires financial entities to manage ICT third-party risk and to ensure that critical functions are not wholly dependent on a single provider subject to foreign jurisdiction. A self-hosted IAM removes the identity layer from US-provider dependency, directly supporting DORA requirements on concentration risk and ICT resilience.