EU Sovereignty and Identity: Entra ID, External ID, and Keycloak Compared - Part 4

EU Sovereignty and Identity: Entra ID, External ID, and Keycloak - Part 4

In Part 1 I broke down the real risks — the CLOUD Act, Schrems II, the difference between legal jurisdiction and physical location. In Part 2 I covered the practical options: self-hosting, EU cloud providers, hybrid approaches, and the infrastructure patterns most organisations actually end up using. In Part 3 we looked at France's bet-everything-on-Linux announcement and asked whether the grand gesture matched the operational reality.

Now I want to get specific about something that runs through all of those posts but rarely gets addressed directly: identity.

Identity is the control plane for everything else. You can host your workloads in Frankfurt, encrypt data at rest, use an EU cloud provider — and then hand over the keys by routing authentication through a US-controlled identity service. If your users authenticate against a system you don't control, running on infrastructure outside your jurisdiction, the sovereignty question doesn't stop at compute and storage. It extends straight through to who gets to decide who can log in.

So this post is about the three credible options and what each one costs you from a sovereignty standpoint: Microsoft Entra ID (workforce identity), Microsoft Entra External ID (customer identity), and Keycloak — specifically the Red Hat build that enterprise teams should be running in production. What do you get with each? What gets harder? What disappears entirely?

Why Identity Is the Sovereignty Gap Nobody Talks About

When organisations think through the sovereignty problem, they usually start with storage and compute. Where does the data live? Who can subpoena the server? Those are real questions. But identity is the layer that authorises access to everything else, and it often gets treated as an afterthought.

Think about what happens in a typical authentication flow:

A user's browser sends a sign-in request to an identity provider (IdP)
That IdP validates credentials and issues a token
The token is used to access your application and APIs

If that identity provider is Microsoft Entra running in a US-controlled datacenter, then:

Authentication metadata logs live in Microsoft's infrastructure (even if your app is in an EU datacenter)
Sign-in flows, conditional access evaluations, and MFA challenges all transit through systems under US legal jurisdiction
Token issuance — the actual moment of access grant — happens on Microsoft's hardware
Tenant configuration data (policies, app registrations, user attributes) is stored in Entra's multi-tenant backend

For most European organisations, this is an acceptable trade-off. Microsoft offers EU Data Boundary commitments, strong security, and world-class reliability. But for regulated public sector entities, critical infrastructure operators, or organisations handling data under strict national security constraints, "acceptable trade-off" isn't the right frame. They need actual isolation. And that changes the conversation entirely.

Note: Microsoft's EU Data Boundary (available for commercial and public sector tenants) keeps most Entra core service data within the EU/EEA. However, it doesn't eliminate all cross-border data flows for operational telemetry, and the legal jurisdiction question (US CLOUD Act, FISA 702) remains regardless of where servers are physically located. The boundary is a real improvement — but it's not sovereignty.

The Three Options

Let's be clear about the scope of each option before comparing them side by side.

Microsoft Entra ID

Entra ID is Microsoft's workforce identity platform. It handles employee sign-ins, MFA, Conditional Access, app registrations, device management integration, Privileged Identity Management, and — if you're on E3/E5 — Entra ID Governance for JML lifecycle automation. It's the backbone of Microsoft 365 and Azure RBAC.

This is what most European enterprises are already running, whether they've thought explicitly about sovereignty or not. If your users log in to Teams, Outlook, SharePoint, or an Azure-hosted application with their corporate account, they're authenticating against Entra ID.

Microsoft Entra External ID

Entra External ID is Microsoft's customer identity and access management (CIAM) platform — the successor to Azure AD B2C. It handles external user sign-ups, social identity federation (Google, Facebook, Apple), custom sign-in flows built with user flows or custom policies, branded experiences, and consumer-facing MFA.

If you're building a B2C application, a customer portal, a partner extranet, or any public-facing service where people register and sign in with accounts they own (not accounts your IT team provisions), External ID is the managed cloud answer within the Microsoft stack.

Keycloak (Red Hat Build)

Keycloak is the open-source identity and access management platform originally created by Red Hat. It covers both workforce and customer identity scenarios — it doesn't draw a line between the two the way Microsoft does. You configure realms, identity providers, authentication flows, and user federation to handle whatever identity scenario you're building.

The upstream open-source project is available from keycloak.org. But I'd argue — and this point matters if you're deploying Keycloak in a sovereignty-conscious context — that Red Hat Build of Keycloak (previously Red Hat Single Sign-On / RH-SSO) is the version you should be running in production. It's commercially supported, receives timely security patches backed by Red Hat's security response process, is certified against FIPS 140-2 when deployed in FIPS mode, and is available from Red Hat's hardened container registry. For regulated environments, the difference between "open source project" and "Red Hat enterprise product" isn't academic — it matters for your compliance posture and your vendor contracts.

Important: If you're deploying Keycloak for a regulated European organisation or public sector entity, use Red Hat Build of Keycloak with an active Red Hat subscription. The upstream community build has no SLA for security patches, no commercial support escalation path, and no vendor certification. The Red Hat product version gives you all three — and it's the same code, just hardened, tested, and supported.

The Sovereignty Comparison

Let's go through the sovereignty dimensions from Part 1 — physical location, legal jurisdiction, admin access control, data residency, operational control — and see how each option actually holds up.

Sovereignty Dimension	Entra ID	Entra External ID	Keycloak (Red Hat)
Physical location	EU Data Boundary for core data; some telemetry may leave EU	EU Data Boundary commitment; tenant region selectable but not all data flows covered	Fully your choice — host anywhere you control
Legal jurisdiction	US company — CLOUD Act and FISA 702 apply	US company — same as Entra ID	Your jurisdiction — EU law governs if you host in EU with EU staff
Admin access control	Microsoft staff have operational access under MSFT policies; you don't control this	Same as Entra ID	You define all admin access — nobody else has it unless you give it
Data residency	EU Data Boundary covers core services; authentication logs, MFA signals may vary	Tenant region controls most data; social IdP federations route to external services	100% your control — no data leaves your infrastructure unless you configure it to
Operational control	Microsoft operates the service; you configure within the allowed surface	Same as Entra ID	You operate it entirely — total control, total responsibility
Root of trust	Microsoft controls token signing keys and cert management	Microsoft controls token signing keys	You own the realm's signing keys — full key control

The pattern is clear: Keycloak wins on every sovereignty axis. But that's not the whole picture. Sovereignty is only one dimension worth comparing.

The Customization Picture: Where Each Option Stands

Keycloak's architecture is built around extensibility. The Part 1 Keycloak vs External ID comparison goes into technical depth on this, but here's the sovereignty-relevant summary:

Keycloak: Full Control, Full Complexity

You can write Java Service Provider Interface (SPI) implementations for anything Keycloak does. Custom authenticators that implement your national eID scheme. Custom user storage providers that read from your existing LDAP or database without migrating users. Custom token mappers that embed arbitrary claims from your internal systems into JWTs. Custom event listeners that log authentication events to your SIEM in your format.

You can also theme every user-facing screen — login pages, registration forms, email templates, error pages — using FreeMarker templates. The branding is yours. The UX is yours. The HTML markup won't contain a single Microsoft design token unless you put it there.

Authentication flows are configured as directed graphs in the Keycloak admin console. Browser-based login, direct grant, device authorization (important for IoT scenarios), passwordless flows with WebAuthn — you assemble them from built-in providers or your own custom providers. The January 2026 GA of device authorization grant flow in Entra External ID matched something Keycloak has supported for years. That pattern repeats: Keycloak typically has features earlier, but you have to build and maintain the integration.

Entra ID: Rich, Integrated, Opinionated

Entra ID is incredibly capable for workforce identity. Conditional Access with named locations, device compliance signals, continuous access evaluation, Verified ID integration, Entra ID Governance with automated JML workflows, Privileged Identity Management with just-in-time elevations, and deep integration with the entire Microsoft 365 and Azure surface. These aren't features you build — they're features you configure. That's the appeal.

But the customization ceiling is real. You can't change how tokens are issued at a low level. You can write custom claims transformation using optional claims or a claims mapping policy, but you can't rewrite the token signing infrastructure. You can't modify how Conditional Access evaluates signals — you can pick from the signals Microsoft supports, and when Microsoft doesn't support a signal you need, you're stuck.

For most enterprise use cases, this isn't a problem. The built-in capabilities are extensive. Where it becomes a problem is niche scenarios: integrating with a national identity scheme that isn't SAML or OIDC, handling deeply custom session management logic, or building a consumer application with radically non-standard authentication UX requirements.

Entra External ID: Configured, Not Coded

External ID sits between the two. You can build user journeys through User Flows (the simpler option) or Custom Policies using Identity Experience Framework, which is actually quite powerful — you can build complex multi-step sign-up flows, integrate with REST APIs during the journey, and handle custom claims transformations.

But it's still configuration, not code. The system gives you building blocks and you assemble them. You can't write a custom authenticator at the Java level the way you can in Keycloak. What you can do is call an external REST API at any point in a user journey, which is a useful escape hatch — but it means your custom logic runs somewhere else (often on Azure Functions or a small API), and that's another service to secure, monitor, and maintain.

The Isolation Options with Keycloak

If isolation is the requirement — and I mean genuine, verifiable, legally defensible isolation — Keycloak is the only option in this comparison that delivers it. Let's be concrete about what that looks like in practice.

Azure Container Apps (Isolated Workload Profile)

Azure Container Apps with the Dedicated or Isolated workload profile gives you a single-tenant compute environment within Azure's EU infrastructure. Combine this with a dedicated PostgreSQL Flexible Server (with customer-managed keys via Azure Key Vault), a private endpoint for all backend services, and a Keycloak (Red Hat build) container deployed from your own Azure Container Registry — and you have a defensible isolation posture.

# Deploy Keycloak on Azure Container Apps with private networking
# First: Create a dedicated Container Apps Environment with custom VNET

az containerapp env create \
  --name keycloak-env \
  --resource-group rg-identity-eu \
  --location westeurope \
  --infrastructure-subnet-resource-id /subscriptions/.../subnets/aca-subnet \
  --internal-only true  # No public endpoint — all traffic via private network

# Create the Keycloak container app
az containerapp create \
  --name keycloak \
  --resource-group rg-identity-eu \
  --environment keycloak-env \
  --image your-acr.azurecr.io/redhat-keycloak:24 \
  --target-port 8080 \
  --ingress internal \  # Internal only — exposed via Application Gateway with WAF
  --min-replicas 2 \
  --max-replicas 5 \
  --env-vars \
    KC_DB=postgres \
    KC_DB_URL=jdbc:postgresql://your-db.postgres.database.azure.com:5432/keycloak \
    KC_DB_USERNAME=keycloak \
    KC_HOSTNAME=identity.your-domain.eu \
    KC_PROXY=edge \
    KC_HTTP_ENABLED=true

Note: The --ingress internal flag means Keycloak is not reachable from the public internet. Expose it via an Application Gateway with WAF_v2 tier in front, with your own TLS certificate from your PKI. This keeps token signing traffic inside your Azure Virtual Network.

Hosting at a European Provider: Two Worked Examples

This is the point that doesn't get made clearly enough in sovereignty discussions: Keycloak runs on any infrastructure that can run a container. That's not a footnote — it's the whole advantage. You're not negotiating an EU Data Boundary addendum with a US hyperscaler, not waiting for a regional datacenter to open, not accepting a contractual commitment as a substitute for actual control. You pick the EU-based provider you trust, deploy Red Hat Keycloak on their infrastructure, and the identity stack is under your jurisdiction from the hardware up.

Two concrete examples of how organisations actually do this in production:

OVHcloud Managed Kubernetes

OVHcloud is a French company headquartered in Roubaix, with datacenters across the EU: Gravelines and Roubaix (France), Strasbourg (France/Germany border), Warsaw (Poland), Frankfurt (Germany). Their Managed Kubernetes Service gives you a managed control plane with worker nodes on OVH hardware. Combine it with OVH Public Cloud Databases (managed PostgreSQL) and you get a Keycloak backend where no data leaves French-company-operated EU infrastructure — and no US CLOUD Act exposure at the infrastructure layer.

# OVHcloud: provision Managed Kubernetes cluster in Gravelines, France (GRA region)
# Provision via OVH Control Panel (https://www.ovhcloud.com/en/public-cloud/kubernetes/)
# Then download kubeconfig from your cluster's dashboard

export KUBECONFIG=~/.kube/ovh-keycloak-cluster.yaml

# Namespace and secrets
kubectl create namespace identity
kubectl create secret generic keycloak-admin \
  --namespace identity \
  --from-literal=admin-password='your-strong-password'

# PostgreSQL connection from OVH Public Cloud Databases (same GRA region)
kubectl create secret generic keycloak-db \
  --namespace identity \
  --from-literal=password='db-password' \
  --from-literal=connection-url='jdbc:postgresql://your-instance.database.cloud.ovh.net:5432/keycloak'

# Deploy Red Hat Build of Keycloak using Bitnami Helm chart with RHBK image override
# (requires active Red Hat subscription for registry.redhat.io pull access)
helm repo add bitnami https://charts.bitnami.com/bitnami
kubectl create secret docker-registry redhat-pull-secret \
  --namespace identity \
  --docker-server=registry.redhat.io \
  --docker-username=your-rh-username \
  --docker-password=your-rh-token

helm install keycloak bitnami/keycloak \
  --namespace identity \
  --set image.registry=registry.redhat.io \
  --set image.repository=rhbk/keycloak-rhel9 \
  --set image.tag="24.0" \
  --set image.pullSecrets[0]=redhat-pull-secret \
  --set auth.existingSecret=keycloak-admin \
  --set externalDatabase.host=your-instance.database.cloud.ovh.net \
  --set externalDatabase.database=keycloak \
  --set externalDatabase.existingSecret=keycloak-db \
  --set replicaCount=3 \
  --set resources.requests.memory=1Gi \
  --set resources.limits.memory=2Gi \
  --set tls.enabled=true \
  --set tls.existingSecret=keycloak-tls

Hetzner Cloud + k3s

Hetzner is a German company founded in 1997, with datacenters in Nuremberg and Falkenstein (Germany) and Helsinki (Finland). Entirely German-owned, EU-jurisdicted, and substantially cheaper than hyperscalers — their CX32 instances (4 vCPU, 8 GB RAM) run at around €13/month, so a 3-node k3s cluster with dedicated PostgreSQL on a separate volume comes to roughly €50–70/month all in. That's a relevant data point for Finnish municipalities, German Mittelstand companies, or Polish public sector entities that need real sovereignty without a hyperscaler budget.

# Hetzner Cloud: provision a 3-node k3s cluster using the hcloud CLI

# Private network for intra-cluster traffic
hcloud network create --name keycloak-net --ip-range 10.20.0.0/16
hcloud network add-subnet keycloak-net \
  --type cloud --network-zone eu-central --ip-range 10.20.1.0/24

# Three nodes in Nuremberg (nbg1) — CX32: 4 vCPU / 8 GB RAM
hcloud server create \
  --name kc-node-1 --type cx32 --location nbg1 \
  --image ubuntu-24.04 --network keycloak-net --ssh-key your-key-name
hcloud server create \
  --name kc-node-2 --type cx32 --location nbg1 \
  --image ubuntu-24.04 --network keycloak-net --ssh-key your-key-name
hcloud server create \
  --name kc-node-3 --type cx32 --location nbg1 \
  --image ubuntu-24.04 --network keycloak-net --ssh-key your-key-name

# Install k3s on the control-plane node
ssh root@$(hcloud server ip kc-node-1) \
  'curl -sfL https://get.k3s.io | sh -s - server --cluster-init'

# Get the join token, then add worker nodes
K3S_TOKEN=$(ssh root@$(hcloud server ip kc-node-1) 'cat /var/lib/rancher/k3s/server/node-token')
CTRL_IP=$(hcloud server ip kc-node-1)
for NODE in kc-node-2 kc-node-3; do
  ssh root@$(hcloud server ip $NODE) \
    "curl -sfL https://get.k3s.io | K3S_URL=https://${CTRL_IP}:6443 K3S_TOKEN=${K3S_TOKEN} sh -"
done

# Persistent volume for PostgreSQL (stays in nbg1, Hetzner-managed)
hcloud volume create --name keycloak-pg-data --size 30 --location nbg1

# Copy kubeconfig from control-plane node
ssh root@$(hcloud server ip kc-node-1) 'cat /etc/rancher/k3s/k3s.yaml' \
  | sed "s/127.0.0.1/${CTRL_IP}/" > ~/.kube/hetzner-keycloak.yaml
export KUBECONFIG=~/.kube/hetzner-keycloak.yaml

# Deploy RHBK — same Helm approach as OVHcloud, just pointing at Hetzner DB
helm install keycloak bitnami/keycloak \
  --namespace identity --create-namespace \
  --set image.registry=registry.redhat.io \
  --set image.repository=rhbk/keycloak-rhel9 \
  --set image.tag="24.0" \
  --set image.pullSecrets[0]=redhat-pull-secret \
  --set auth.existingSecret=keycloak-admin \
  --set postgresql.enabled=true \
  --set replicaCount=3

Note: OVHcloud and Hetzner are two examples, not an exhaustive list. Deutsche Telekom T-Systems Open Telekom Cloud, IONOS Cloud (Germany), Scaleway (France), and Exoscale (Switzerland/EU) all support the same pattern: provision a Kubernetes cluster in an EU region, deploy Red Hat Keycloak via Helm, point it at a PostgreSQL instance in the same datacenter. The provider changes; the deployment does not. The sovereignty properties — physical location, legal jurisdiction, admin access control — follow from your provider selection, not from Keycloak itself.

The Isolation Spectrum

Deployment Option	Sovereignty Level	Operational Overhead	Realistic For
Entra ID / External ID (managed)	EU Data Boundary commitments — not full sovereignty	Very low — Microsoft operates it	Most enterprises, commercial apps
Keycloak on Azure Container Apps (private)	High isolation at identity layer; Azure infrastructure still US-company-operated	Medium — you manage Keycloak, Azure manages the platform	Orgs needing identity control without leaving Azure
Red Hat Keycloak on EU IaaS (e.g., OVHcloud, Hetzner)	Full — every layer under EU jurisdiction and your admin control	High — you manage the platform, Keycloak, DB, TLS, updates	Critical infrastructure, national security, defence, regulated public sector
Red Hat Keycloak on-premises	Maximum — physical and legal control	Very high — full stack ownership	Defence, intelligence, strict government requirements

What You Give Up With Keycloak

This is the part that gets glossed over in sovereignty conversations, where people get so focused on what they gain (control) that they undercount what they lose. Let me be honest about the gaps.

1. The Microsoft 365 and Azure RBAC tie-in is gone

Entra ID isn't just your identity provider. For organisations using Microsoft 365, it's the identity backbone for Teams, SharePoint, Exchange, Intune device management, and Azure RBAC. Keycloak doesn't replace that. If you're shifting workforce identity to Keycloak, you'd still need Entra ID (or Entra ID external identities federation) for your M365 surface. Running both adds complexity — Keycloak as your primary IdP, with Entra ID as a downstream app or using Keycloak as a SAML/OIDC IdP that federates into Entra.

This is solvable, but it's not free. I've seen teams set it up where Keycloak is the authoritative source and Entra ID trusts SAML assertions from it. It works. But there's an operational cost, and app registrations that previously just worked in Entra now need to handle the federation hop.

2. Conditional Access depth

Entra ID's Conditional Access is genuinely mature. Device compliance signals from Entra-joined or Intune-managed devices, continuous access evaluation that revokes tokens within minutes of a policy change, named locations with detailed IP/country controls, sign-in risk signals from Microsoft's threat intelligence, and hardware-bound passkey support via FIDO2. Keycloak has Conditional Access-style authentication flows — you can build context-aware authentication — but you're assembling that logic yourself from custom authenticators and whatever signals you can pull in.

If you need device compliance signals, you'd typically deploy an MDM that can push claims into Keycloak tokens. That's achievable, but it's a build, not a configuration.

3. The updatability gap

Entra ID gets Microsoft's full product team releasing features continuously. The January 2026 client credentials GA, the February 2026 device authorization flow GA, per-app branding themes — those shipped without you doing anything. With Keycloak, you decide when to upgrade and you're responsible for testing the upgrade. Red Hat Build of Keycloak has a predictable support lifecycle (18 months per major version), but you still own the upgrade schedule.

For a fast-moving CIAM product where consumer sign-in flows need to evolve frequently, this matters. For a stable enterprise identity deployment where you're not changing flows every quarter, it's fine.

4. CIAM features at scale

External ID has built-in handling for things like progressive profiling, social identity linking, JIT password migration (public preview as of December 2025), custom branding themes per application, and Microsoft's bot protection integration. Keycloak can do most of these — social IdP federation works well, progressive profiling is achievable with custom authentication flows — but you build it rather than configure it.

At large scale (millions of MAUs), External ID's managed infrastructure means you don't think about load balancing, DB connection pooling, or horizontal scaling. With Keycloak at millions of users, you're managing a PostgreSQL cluster, tuning JVM heap, handling Infinispan cache cluster coordination, and designing your session store for HA. That's a real ops team or a managed Kubernetes platform covering those concerns.

5. Entra ID Governance and PIM have no equivalent

Entra ID Governance — automated joiner/mover/leaver workflows, access reviews, entitlement management — is genuinely difficult to replicate. Keycloak handles authentication and authorization. It doesn't have a built-in entitlement management engine with automated access reviews and audit trails for compliance reporting. If your organisation needs that, either you build a separate system, integrate with a third-party IGA product, or you keep Entra ID Governance in the mix.

Full Comparison Table

Dimension	Entra ID	Entra External ID	Red Hat Keycloak
Primary use case	Workforce / employee identity	Customer / consumer identity (CIAM)	Both — realm-per-purpose
EU data sovereignty	EU Data Boundary; not full sovereignty	EU Data Boundary; not full sovereignty	Full — governed by your deployment and jurisdiction
Operational model	SaaS — Microsoft operates it	SaaS — Microsoft operates it	Self-managed — you operate it
Token signing key control	Microsoft	Microsoft	You
Custom authentication logic	Limited — configuration only	Medium — Custom Policies + API calls	Full — Java SPIs, custom flows
UI / theme control	Limited company branding	Per-app branding themes (GA Jan 2026)	Full FreeMarker templates — complete UI control
M365 / Azure RBAC integration	Native	Partial (external users)	Via SAML/OIDC federation — not native
Conditional Access depth	Very mature — device compliance, risk, CAE	Session controls, sign-in frequency (GA Jan 2026)	Build yourself — context-aware via custom authenticators
Entra ID Governance / PIM	Built-in (licensed)	Not applicable	Not built-in — requires separate IGA product
FIPS 140-2 compliance	Microsoft-managed compliance	Microsoft-managed compliance	FIPS mode supported in Red Hat build with FIPS OS
Protocol support	OIDC, SAML 2.0, WS-Federation	OIDC, SAML 2.0	OIDC, SAML 2.0, Kerberos, LDAP proxy
Cost model	Per-user licensing (P1/P2 for advanced features)	Per-MAU (50K free, then tiered)	Red Hat subscription + your infrastructure costs
Vendor dependency	High — Microsoft product	High — Microsoft product	Open standard code; Red Hat subscription for enterprise support

So When Does Each Option Make Sense?

I've seen organisations get tangled up trying to build the perfect sovereignty-compliant identity architecture when their actual risk exposure doesn't warrant it. And I've also seen organisations casually expose authentication workflows to US legal jurisdiction when their compliance requirements explicitly prohibit it. Neither extreme is good. Here's how I'd think about the decision.

Use Entra ID (and External ID if needed) if:

You're a commercial enterprise with no specific national security or critical infrastructure classification
You're already on Microsoft 365 and Azure — the integration depth is real and adding a separate IdP creates complexity without proportionate benefit
Your compliance framework accepts EU Data Boundary commitments as sufficient (most GDPR interpretations do)
Your team has M365 / Azure expertise rather than Keycloak/Java/OpenShift expertise
You need Entra ID Governance, PIM, or deep Intune device signal integration — these don't have good equivalents elsewhere

Use Keycloak (Red Hat build) if:

Your organisation is classified as critical infrastructure, national security, or defence — legal jurisdiction genuinely can't be US
You're in a EU public sector entity with explicit data localisation requirements that go beyond EU Data Boundary commitments
You need custom identity flows that Microsoft's platforms don't support — national eID schemes, custom MFA integrations, deep LDAP federation
You want ownership of token signing keys as an explicit security requirement
Your organisation already runs on OpenShift or has Red Hat agreements — Keycloak fits naturally
You need to combine workforce and consumer identity under one managed platform (Keycloak handles both in separate realms)

Consider a hybrid if:

You need M365 but want Keycloak as the authoritative workforce IdP — federate Entra ID to trust assertions from Keycloak
Your workforce uses Entra ID but your customer-facing application requires sovereignty-compliant CIAM — deploy Keycloak for External ID use cases, keep Entra ID for employee access
You're migrating from a legacy on-premises identity system — Keycloak as an intermediate platform while you evaluate a longer-term direction

Red Hat Keycloak: Why the Enterprise Build Matters

I've mentioned this already, but it's worth being direct: if you're deploying Keycloak in a context where you're citing sovereignty as a reason to avoid US-operated cloud services, and you then run the community build from an unofficial container image pulled from Docker Hub, you've undermined your own argument.

The Red Hat Build of Keycloak (product name: RHBK) is available from Red Hat's authenticated registry at registry.redhat.io/rhbk/keycloak-rhel9. It requires a Red Hat subscription — either a standalone Keycloak subscription or as part of a broader Red Hat Enterprise Linux or OpenShift agreement. What that gets you:

CVE response with SLA: Red Hat Product Security triages and patches CVEs in Keycloak with defined response times. The upstream community project has no SLA for security fixes.
FIPS 140-2 validated cryptography: The Red Hat build uses RHEL's certified cryptographic modules when deployed on a FIPS-enabled OS, which is a specific requirement for many EU public sector and defence certifications.
Hardened container image: Scanned and signed by Red Hat. Your compliance team can verify the provenance of what you're running.
Extended support lifecycle: Predictable long-term support with migration paths between major versions — important when you're managing an identity platform that everything else depends on.
Commercial vendor relationship: When something goes badly wrong at 2am, you have a support contract to call, not just a community forum thread.

For regulated European organisations deploying an identity platform as a sovereignty argument for avoiding US-jurisdiction services, the Red Hat subscription is effectively non-optional. It's what makes the sovereignty story coherent end to end.

The Bottom Line

The sovereignty argument for identity comes down to one question: who controls the moment of authentication? With Entra ID and External ID, Microsoft does — within the contractual guarantees of the EU Data Boundary, which are genuinely meaningful but not full sovereignty. With Keycloak, you do.

Isolation is possible. Full, legally defensible, key-owning, EU-jurisdiction authentication is achievable with Red Hat Keycloak deployed on infrastructure you control. It's not theater sovereignty. It's real.

But it costs something. You lose native M365 integration, Conditional Access depth, Entra ID Governance automation, and the zero-maintenance experience of a managed SaaS platform. You gain operational control and the responsibility that comes with it.

The right answer depends entirely on what you're protecting and who's asking you to protect it. A commercial SaaS company's EU data residency policy is not the same problem as a national defense agency's authentication infrastructure. For the former, Entra ID with EU Data Boundary is entirely reasonable. For the latter, Red Hat Keycloak on EU-only infrastructure isn't optional — it's the baseline.

The mistake I see most often isn't choosing the wrong option — it's not being clear about which category you're in before you choose. The EU sovereignty conversation sometimes leads organisations to adopt costly self-managed identity stacks when their actual threat model doesn't require it, or to deploy SaaS identity platforms in contexts where the legal exposure is genuinely unacceptable. Get the threat model right first. The technology choice follows from that.

Next in this series: we'll look at what federating Keycloak with Entra ID actually looks like in practice — how to use Keycloak as your primary IdP while keeping M365 functional, and what breaks along the way.