Was It Worth It? The Real Cost of EU Sovereignty Architecture and Who Should Run It — Part 8

EU Data Sovereignty Architecture: Cost Reality and Decision Framework

This series has spent seven posts building something: an architecture where your users' identities are managed in an EU-controlled Keycloak instance, your Entra ID domain is federated to that Keycloak, user accounts are provisioned across both systems via SCIM, and the whole thing is operationally hardened with cert rotation procedures, health monitoring, and break-glass access. It works. I've shown the commands, the config, the code.

What I haven't done yet is ask the harder question: should you actually build this for your organisation? Not "can you" — you clearly can. But whether the operational cost is justified by the compliance benefit you're trying to achieve. The answer is genuinely different depending on what kind of organisation you are and why you care about EU data sovereignty in the first place.

So this post is the cost and reality check. I'll go through what running this architecture actually costs, compare it honestly to the alternatives, explain what problem it does and doesn't actually solve, and give you a framework for making the decision.

What you're signing up for

Running Keycloak in production for identity is not like running a stateless application. It's a stateful, security-critical service that needs to be available whenever a user tries to sign in. If Keycloak is down, federated users can't access M365 — not their email, not Teams, not SharePoint. The dependency is hard.

Beyond availability, there's the operational workload. Keycloak has historically had significant breaking changes between major versions. Version 17 dropped the legacy Wildfly distribution. Version 21 changed the Quarkus configuration format. Version 25 changed how realm export/import works. Each major version upgrade requires testing, migration work, and a maintenance window. These upgrades happen roughly every six months if you're tracking the supported release stream.

The certificate rotation procedure from Part 7 is manual and requires someone who understands the relationship between the Keycloak key store and the Entra ID federation configuration. If that person leaves your organisation and their replacement doesn't know the cert is expiring in 30 days, you get an outage. The SCIM sync service from Part 6 needs monitoring, drift detection runs, and someone to investigate when it stops syncing correctly. These are not one-time setup tasks.

Real cost numbers

Let's look at actual infrastructure costs for a production Keycloak HA deployment on Azure, then add the operational overhead.

Infrastructure

Component	Spec	Approx. monthly cost
Keycloak node ×2	Standard_D2s_v5 (2 vCPU, 8 GB)	~€120 × 2=€240
Azure Database for PostgreSQL Flexible HA	General Purpose, 2 vCores, zone-redundant standby	~€200
Azure Load Balancer (Standard)	Standard tier	~€20
Azure Key Vault (for secrets)	Standard tier	~€5
Log Analytics / monitoring	~2 GB/day ingest	~€30
Infrastructure total		~€495/month

These are rough West Europe region estimates from the Azure pricing calculator. Actual costs vary with reserved instance discounts, actual database size, and whether you're running containers instead of VMs. A container-based deployment on Azure Container Apps or AKS can be cheaper, but adds orchestration complexity.

Note: If you're placing Keycloak in a private vnet with a firewall, Application Gateway, or Private Endpoints for the database, add €100–200/month to the infrastructure figure. A production security posture for an internet-facing IdP warrants the investment.

Operational overhead (the real cost)

Infrastructure is the visible cost. The operational overhead is the one most teams underestimate. Based on running this in practice, here's a realistic assessment of ongoing staff time:

Activity	Frequency	Estimated hours/year
Routine health checks and log review	Weekly	26 h
Keycloak minor version patching	Monthly	12 h
Keycloak major version upgrade	Twice a year	20–40 h
SAML cert rotation	Annually	4 h
SCIM sync maintenance and drift review	Monthly	12 h
Auth incidents (diagnosis, fix, post-mortem)	2–4 per year	16–32 h
Break-glass account testing	Monthly	3 h
Staff time total		~100–130 h/year

At a conservative loaded engineer cost of €80/hour, that's €8,000–10,400 per year in operational overhead on top of the infrastructure. Annualised, the total cost of ownership is roughly:

Infrastructure: €5, 940/year (~€495 × 12)
Staff time: €8, 000–10, 400/year
Total: roughly €14, 000–16, 000/year

That number doesn't change much whether you have 100 users or 1,000 users. The infrastructure scales somewhat, but the operational overhead is mostly fixed — cert rotation takes the same time regardless of user count, and major version upgrades are the same regardless of how many users are in the realm.

Comparison to native Entra ID options

Entra ID has its own licensing tiers, and the feature comparison matters when deciding whether the federation architecture buys you anything beyond sovereignty. The Entra figures below use Microsoft's public P1/P2 list pricing as a rough planning number; your actual EUR price depends on region, agreement, and whether the license is already bundled in Microsoft 365.

Option	Monthly cost	100 users/year	500 users/year	1, 000 users/year
Entra ID Free (included with M365)	€0	€0	€0	€0
Entra ID P1 (add-on)	~€6/user	€7, 200	€36, 000	€72, 000
Entra ID P2 (add-on)	~€9/user	€10, 800	€54, 000	€108, 000
Keycloak federation (this series)	~€1, 250/mo fixed	€15, 000	€15, 000	€15, 000

The crossover point compared to Entra ID P1 is roughly 200 users. Below that, Entra ID P1 costs less than running Keycloak. Above 200 users, the fixed cost of Keycloak becomes competitive. Above 500 users, it's substantially cheaper — but only if the operational cost is manageable, which it is if you have an engineer who already owns it as part of their role.

Compared to Entra ID P2 specifically, Keycloak federation is cheaper at any scale beyond about 120 users. But Entra ID P2 includes features this architecture replaces poorly or not at all: Privileged Identity Management, Identity Protection with ML-based risk scoring, and access reviews with attestation workflows. If you need those specific features and are replacing Entra ID P2 with Keycloak, check what you're actually dropping before doing the arithmetic.

What this architecture does and doesn't give you

This is where the honest part matters most. There's a meaningful difference between data residency (where bytes are stored), legal jurisdiction(which courts can compel access), and operational control(who can actually read the data right now). The Keycloak federation architecture addresses one of these three, partially.

What it actually gives you

Your identity data — user accounts, credentials, authentication events — is stored and processed in infrastructure you control, in EU jurisdictions you choose. Keycloak's database lives in Azure West Europe (or whichever EU region you pick), and it runs on your Azure subscription. The authentication decisions happen in your infrastructure, not Microsoft's. You can audit every authentication event, see every login attempt, and control exactly which claims are asserted in SAML responses.

If a government authority in a non-EU jurisdiction issues a legal order for your identity data, that order goes to your organisation — not to Microsoft. That's a real distinction. It's the core of what Schrems II was about: the concern that US-owned infrastructure means US authorities can reach the data via the CLOUD Act or FISA 702, regardless of where it's physically stored.

What it doesn't give you

Your M365 data — email, files, Teams messages — still lives in Microsoft's infrastructure. Microsoft is a US company. The CLOUD Act still applies to Microsoft as an entity, regardless of where the data is physically located. The Keycloak federation changes who controls authentication; it doesn't change the legal status of your content data in SharePoint and Exchange.

If you're running the SCIM sync on Azure VMs (as this series shows), your provisioning service also runs on Microsoft infrastructure. The user data being synced passes through Microsoft's network, even if it's in your subscription. True sovereignty throughout the entire stack requires running Keycloak and all supporting services on genuinely EU-owned infrastructure — OVHcloud, IONOS, Hetzner, Deutsche Telekom's T-Systems, or similar. Azure West Europe is geographically in Europe and subject to EU data protection regulation, but Microsoft remains a US company subject to US law.

That isn't a reason not to build this architecture. It is a reason to be clear about what compliance requirement you're satisfying and whether this satisfies it. "We don't want our user identities in Microsoft's control" is satisfied by this. "We need complete legal immunity from US jurisdiction" is not, because M365 itself is Microsoft's product.

Who should actually build this

Rather than a single recommendation, here's a tiered assessment based on what I've seen work and not work in practice.

You almost certainly should — regulated and critical infrastructure

Organisations with a genuine legal requirement for identity sovereignty. This includes:

EU public sector bodies handling sensitive government data, especially where national security clearance is involved
Operators of essential services under NIS2, particularly in the energy, water, and transport sectors where authentication infrastructure is considered part of critical systems
Defence contractors and suppliers with classified information handling requirements that explicitly mandate EU-controlled identity
Financial institutions subject to DORA that have assessed authentication infrastructure as a critical ICT dependency and need to demonstrate operational resilience and control over it
Organisations under contractual obligation from EU government clients that explicitly require non-US identity providers

For these organisations, the €15, 000/year operational cost isn't really the question — the alternative is a compliance failure that carries potentially much larger consequences.

Worth evaluating seriously

EU-based software companies selling to regulated industries where their clients require data sovereignty assurances in contracts
Healthcare organisations processing sensitive health data and operating under national health data laws that go beyond basic GDPR
Large EU enterprises (500+ employees) that are cost-conscious about Entra ID P1/P2 licensing and have an in-house IT team that can absorb the operational overhead
Organisations already running Keycloak for application-level authentication — the M365 federation becomes an extension of an existing investment rather than a new operational burden

Probably not worth it for most

SMBs and startups without specific regulatory requirements — the operational overhead of running Keycloak in production is disproportionate to the benefit
EU organisations whose primary sovereignty concern is GDPR compliance — GDPR compliance is achievable with properly configured Microsoft 365 with a DPA in place; it doesn't require EU-controlled identity
Organisations that lack an engineer who can own Keycloak long-term — the architecture becomes a liability when the person who built it leaves
Teams using M365 primarily as a collaboration tool rather than a critical business system — the architecture is over-engineered for this use case

Alternatives worth knowing about

If you want EU identity control but the full Keycloak federation is more than you need, there are lighter options:

Microsoft 365 Advanced Data Residency and Entra regional residency — Microsoft has data residency controls for defined Microsoft 365 workloads and Entra ID stores directory data based on tenant geography and service requirements. This is useful if your requirement is about where Microsoft stores customer data at rest, but it is not the same as moving identity control out of Microsoft or pinning every Entra object and log to a single EU country. Read the product terms and workload coverage carefully before treating this as a sovereignty control.

EU sovereign-cloud alternatives and regional operating models — evaluate provider-specific offerings carefully, because legal model, operator responsibility, and service scope vary by product and contract. Some models emphasize EU operations, but they are not equivalent across all Microsoft 365 capabilities. If legal jurisdiction is your main concern, validate the exact operating and contractual model for your tenant before deciding.

Keycloak as IdP for applications only, not M365 — You can run Keycloak as the identity provider for your own applications (internal tools, SaaS products you build) without federating M365. This gives you sovereignty over application-level identities without taking on the operational complexity of M365 federation. Many organisations find this a reasonable middle ground.

Making the decision

If you're still not sure which tier you fall into, these questions usually clarify it:

Is there a specific legal or regulatory requirement that names identity infrastructure as needing EU control? If yes, you're probably in Tier 1. If no, continue.
Do your contracts with clients or partners require a non-US identity provider? If yes, Tier 1 or 2. If no, continue.
Do you already run Keycloak for application authentication and have an engineer who owns it? If yes, the marginal cost of adding M365 federation is lower than it looks — you're already paying the operational overhead. If no, continue.
Do you have 200+ M365 users and genuine concern about identity sovereignty? If yes, the economics work and it's worth evaluating seriously. If no, the overhead likely outweighs the benefit.
Can you name the engineer who will own this long-term? If you can't answer this question clearly, don't build it. The architecture requires ongoing ownership — it's not a deploy-and-forget solution.

The honest summary: This architecture is right for organisations with a genuine sovereignty requirement and the operational maturity to run it. For most EU organisations using M365 without specific sector regulations, properly configured Microsoft 365 with a Data Processing Agreement satisfies GDPR. The Keycloak federation adds real sovereign control over identity — but it's a choice that comes with real ongoing costs. Know which one you need before you build it.

Wrapping up the series

This series started in Part 1 by looking at whether the fear around EU data sovereignty was real or overblown — the answer was: real, but concentrated in specific sectors and use cases. Parts 2 and 3 looked at self-hosting economics and the political context. Parts 4 through 7 built the actual architecture step by step: domain federation, Keycloak as a SAML IdP, SCIM provisioning, and operational hardening. This post is the reality check. The series then continues with the Microsoft Sovereignty 2026 track in Parts 9 and 10, where I break down technical control models first and deployment reality next.

The architecture works. I've run through all of it in detail — the commands, the config, the edge cases, the failure modes. If you need it, you now have a complete reference. If you're not sure you need it, this should make the decision easier.

The complete series: