Microsoft Entra ID EU Alternative 2026: GDPR, CLOUD Act, and Why Your Identity Layer Carries the Highest Compelled-Disclosure Risk

Post #1 in the sota.io EU Identity Management Series

Identity data is the most sensitive category in your SaaS stack. It is not customer order history or analytics events — it is who your users are, how they authenticate, where they work, what devices they use, and which resources they access. When a US federal agency issues a CLOUD Act warrant against Microsoft, your entire user base is exposed: usernames, credential hashes, MFA secrets, session tokens, device compliance states, and every login event your system has ever recorded.

Microsoft Entra ID (formerly Azure Active Directory, rebranded July 2023) is the world's most widely deployed enterprise identity platform. It handles authentication for hundreds of millions of users across Microsoft 365, Azure workloads, and third-party SaaS integrations. For EU organisations operating under GDPR, NIS2, and DORA, that market dominance comes with a structural compliance problem: Microsoft Corporation is a Washington State corporation with its legal headquarters in Redmond, WA — incorporated under Delaware law — and has no legal mechanism to resist a validly issued US CLOUD Act warrant.

This guide explains the CLOUD Act exposure, analyses GDPR risks under Art.28/46, examines Microsoft's EU Data Boundary commitments and their limits, and presents every credible EU-native identity provider alternative.

1. What Is Microsoft Entra ID?

Microsoft Entra ID (product ID: Azure Active Directory P1/P2, API namespace: microsoft.graph/identity) is Microsoft's cloud-based Identity and Access Management (IAM) platform. It provides:

• SSO (Single Sign-On) via SAML 2.0, OIDC/OAuth 2.0, WS-Federation
• MFA (Microsoft Authenticator app, FIDO2, OATH hardware tokens, SMS/TOTP)
• Conditional Access policies (device compliance, location, sign-in risk)
• Privileged Identity Management (PIM) for just-in-time admin access
• B2B/B2C external identity federation
• Directory Services (user, group, device object management)
• Application Proxy (reverse-proxy for on-premises apps)
• Microsoft Entra Permissions Management (CIEM/cloud permissions)

Formerly called "Azure AD", the July 2023 rebrand to "Microsoft Entra ID" unified several products under the Entra brand (Entra ID Governance, Entra External ID, Entra Permissions Management, Entra Verified ID). The underlying architecture and legal structure are unchanged — it is still Microsoft's authentication cloud.

Pricing tiers:

• Free — included with Microsoft 365 / Azure subscriptions. 500k directory objects, basic SSO for 10 apps.
• P1 (€5.90/user/month) — Conditional Access, hybrid identity, self-service password reset, group-based access.
• P2 (€8.90/user/month) — Identity Protection (sign-in risk), Privileged Identity Management, Access Reviews.

2. Microsoft's Legal Structure and US CLOUD Act Exposure

Corporate Jurisdiction

Microsoft Corporation is incorporated in Washington State under Delaware law. The US CLOUD Act (18 U.S.C. § 2523, enacted 2018) requires US-incorporated entities to provide data held anywhere in the world upon receipt of a qualifying warrant — without any obligation to notify the data subject or controller.

The landmark Microsoft v. United States (2018) case demonstrated the issue: US DOJ subpoenaed emails stored on Microsoft's Dublin, Ireland servers. The Second Circuit ruled in Microsoft's favour before the case became moot (Clarifying Lawful Overseas Use of Data Act passed the same day). But the CLOUD Act codified the government's ability to compel production of data stored abroad — Microsoft could not resist a CLOUD Act order even for data in its EU Data Centers.

Data Categories with Maximum CLOUD Act Sensitivity

Authentication data processed by Microsoft Entra ID includes:

Category                          Sensitivity  CLOUD Act Value
──────────────────────────────────────────────────────────────
User Principal Names (UPNs)       HIGH         ★★★★★ — full user list
Credential hashes (bcrypt/scrypt) HIGH         ★★★★★ — offline cracking risk
TOTP secrets (MFA seeds)          CRITICAL     ★★★★★ — MFA bypass risk
Session tokens / refresh tokens   CRITICAL     ★★★★★ — live session takeover
Sign-in log (IP, device, time)    HIGH         ★★★★★ — geo-location/correlation
Device compliance states          MEDIUM       ★★★★☆ — organisational topology
Group memberships / role assigns  HIGH         ★★★★★ — privilege mapping
App registration secrets          CRITICAL     ★★★★★ — service account access

A CLOUD Act warrant for Microsoft Entra ID tenant data effectively gives the requesting agency a complete user roster, credential store, and access-pattern history for your organisation.

3. GDPR Risk Analysis

Art.28 — Processor Agreement

Microsoft's Data Processing Agreement (DPA) and Online Services Terms (OST) serve as the Art.28 processor agreement. Microsoft commits to:

• Processing data only on documented instructions
• Engaging sub-processors (listed at microsoft.com/en-us/trust-center)
• Assisting with Art.32 technical/organisational security measures
• Supporting Art.33/34 breach notifications (72-hour window)

Critical limitation: Microsoft's DPA explicitly states that Microsoft may comply with a valid legal process (government warrant) even if this conflicts with the controller's instructions. From the OST:

"Microsoft will notify Customer of a government request for Customer Data unless legally prohibited from doing so."

When legally prohibited — which CLOUD Act warrants frequently are (gag orders) — you receive no notification. Your users' identity data has been handed over; you may never know.

Art.46 — Transfers to Third Countries

Microsoft relies on Standard Contractual Clauses (SCCs, 2021 revision) for transfers of EU personal data to the US. Since Schrems II (C-311/18, July 2020), SCCs alone are insufficient if the third country's surveillance laws undermine their effectiveness.

The CJEU Schrems II ruling found that US FISA 702 and EO 12333 surveillance programmes do not provide equivalent protection to EU fundamental rights. Microsoft is a PRISM provider — confirmed in the Snowden documents. Authentication data processed through Entra ID's global authentication endpoints (including login.microsoftonline.com) transits Microsoft's global network regardless of EU Data Boundary commitments.

EU Data Boundary (EDB) commitment — Microsoft announced in January 2023 that all EU/EEA customer data for core commercial services (including Entra ID) would be stored and processed within the EU. EDB Phase 1 (Dec 2022) covered identity authentication data. However:

1. EDB is a contractual commitment, not a legal shield against CLOUD Act warrants
2. Telemetry, diagnostics, and support data may still be transferred outside the EU under "limited exceptions"
3. Microsoft's global backbone routing means some authentication requests may still transit US infrastructure
4. EDB does not prevent US law enforcement from issuing CLOUD Act orders against Microsoft Corporation

The EDPB's Opinion 07/2025 (March 2025) confirmed that voluntary data localisation commitments by US providers do not eliminate the legal basis for CLOUD Act compelled disclosure.

Art.32 — Security of Processing

Microsoft Entra ID's security posture is generally strong (SOC 2 Type II, ISO 27001, FedRAMP High). However, three major security incidents raise Art.32 concerns:

1. Storm-0558 (July 2023): Chinese state-sponsored actors forged Microsoft authentication tokens using a stolen MSA signing key. Affected US government email accounts. Root cause: cryptographic key management failure in Microsoft's production environment.

2. Midnight Blizzard (January 2024): Russian SVR gained access to Microsoft senior leadership email via a legacy OAuth test tenant. Password spray → MFA bypass on non-MFA account → OAuth application with high privileges.

3. Entra ID Tenant Misconfiguration Cascade (2024-2025): Multiple enterprise customers found their Entra ID tenants had legacy authentication protocols (Basic Auth) still enabled — exploited in credential-stuffing campaigns despite Microsoft's published deprecation timeline.

All three incidents demonstrate that your identity data security is only as strong as Microsoft's global infrastructure security — which is a target of every sophisticated threat actor on the planet.

4. GDPR Risk Score — Microsoft Entra ID vs EU-native Alternatives

For comparison: CrowdStrike scored 18/25 (endpoint), Zscaler 23/25 (inline proxy). Microsoft Entra ID at 20/25 reflects the highest possible data sensitivity combined with incomplete jurisdictional isolation.

5. NIS2 and DORA Implications

NIS2 Directive (EU) 2022/2555 — Art.21 Security Measures

Authentication infrastructure falls under NIS2 Art.21(2)(b) "incident handling" and Art.21(2)(e) "supply chain security." For NIS2 essential entities:

• Dependency on a CLOUD Act-exposed identity provider creates a supply chain risk that must be documented in your NIS2 risk assessment
• A Storm-0558-type incident affecting your Entra ID tenant could constitute a reportable NIS2 incident within 24 hours (early warning) under Art.23
• CLOUD Act warrant execution = potential NIS2 Art.23 incident — disclosure of user identity data without controller notification may constitute a personal data breach under Art.33 GDPR (linked Art.26 NIS2 joint responsibility)

DORA (EU) 2022/2554 — Art.28-30 ICT Third-Party Risk

For financial sector entities, Microsoft Corporation is designated a Critical ICT Third-Party Provider (CTPP) under DORA Art.31 (Commission Delegated Regulation 2024/2886). If your financial entity uses Microsoft Entra ID:

• Contract must include all DORA Art.30 mandatory provisions
• Microsoft's CTPP designation means your ICT contract is subject to EBA/ESMA/EIOPA oversight review
• Concentration risk: Microsoft Entra ID and Microsoft 365 together may create prohibited ICT concentration per DORA Art.28(4)
• Sub-outsourcing of Entra ID authentication to Microsoft's global backbone requires DORA Art.28(6) notification

6. EU-native Identity Provider Alternatives

Tier 1 — Full EU-native, No CLOUD Act

Note on Authentik: Authentik Security Inc. is a US LLC (Delaware) but Authentik is open source and self-hosted — the software itself has no CLOUD Act exposure when self-deployed. The company sells a hosted Enterprise tier. For self-hosted deployments within EU infrastructure: CLOUD Act risk = 0.

Tier 2 — EU-based SaaS with Acceptable Data Residency

7. Deep Dive: Keycloak vs Microsoft Entra ID

Keycloak is the most widely deployed EU-sovereign identity platform. Originally developed by JBoss (Red Hat), now a CNCF-incubating project hosted under the Keycloak GitHub organisation. When self-deployed on EU infrastructure, it has zero CLOUD Act exposure.

Feature Parity

Keycloak Deployment Architecture

┌─────────────────────────────────────────────────────────────────┐
│                    EU Data Center (e.g., sota.io)               │
│  ┌─────────────────────┐   ┌─────────────────────────────────┐  │
│  │   Keycloak Cluster  │   │        PostgreSQL (EU)          │  │
│  │  (2x Active-Active) │◄──│  (realm config, credentials)   │  │
│  │  Port: 8443 (HTTPS) │   └─────────────────────────────────┘  │
│  └──────────┬──────────┘                                        │
│             │ SAML/OIDC                                         │
│  ┌──────────▼──────────────────────────────────────────────┐   │
│  │            Your Applications                            │   │
│  │  web-app (OIDC client) │ api (JWT bearer) │ legacy SAML │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
          ↑ ZERO data leaves EU, ZERO CLOUD Act exposure

Keycloak Kubernetes Deployment (Helm)

# keycloak-values.yaml — sota.io standard config
auth:
  adminUser: admin
  adminPassword: "${KEYCLOAK_ADMIN_PASSWORD}"

postgresql:
  enabled: true
  auth:
    postgresPassword: "${KC_DB_PASSWORD}"
    database: keycloak

ingress:
  enabled: true
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  rules:
    - host: auth.your-eu-domain.eu
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: keycloak-tls
      hosts:
        - auth.your-eu-domain.eu

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 2000m
    memory: 2Gi

# Enable production mode with HTTPS
extraEnvVars:
  - name: KC_HOSTNAME
    value: auth.your-eu-domain.eu
  - name: KC_PROXY
    value: edge
  - name: KC_DB
    value: postgres

8. Deep Dive: Zitadel — Cloud-native EU Alternative

Zitadel (CAOS AG, Zürich, Switzerland) is a modern, cloud-native IAM platform built as a microservices architecture. It offers a SaaS option hosted in Swiss/EU data centres, or self-hosted on Kubernetes.

Key GDPR advantages:

• Swiss company (CAOS AG) — EU adequacy decision (Swiss-EU Data Protection Framework, 2000, renewed 2024)
• Cloud instance hosted exclusively on Google Cloud Europe (Zürich, Frankfurt)
• No US corporate parent → no CLOUD Act exposure
• Full audit log export capability (Art.5(2) accountability)
• GDPR-native data deletion APIs (Art.17 right to erasure)

Architecture strengths vs Keycloak:

• Event-sourced state machine → complete audit trail without additional tooling
• gRPC API + REST API for all operations
• Multi-tenancy built-in (organizations/projects concept matches SaaS needs)
• Human tasks engine for lifecycle management (invitation, verification flows)
• Passwordless-first (FIDO2, passkeys) by design

# Zitadel self-hosted quick start (Docker)
docker run \
  --rm \
  -p 8080:8080 \
  -e ZITADEL_MASTERKEY="$(openssl rand -base64 32)" \
  -e ZITADEL_DATABASE_POSTGRES_HOST=localhost \
  -e ZITADEL_DATABASE_POSTGRES_PORT=5432 \
  -e ZITADEL_DATABASE_POSTGRES_DATABASE=zitadel \
  -e ZITADEL_DATABASE_POSTGRES_USER_USERNAME=zitadel \
  -e ZITADEL_DATABASE_POSTGRES_USER_PASSWORD=zitadel_pass \
  -e ZITADEL_DATABASE_POSTGRES_USER_SSL_MODE=disable \
  -e ZITADEL_DATABASE_POSTGRES_ADMIN_USERNAME=postgres \
  -e ZITADEL_DATABASE_POSTGRES_ADMIN_PASSWORD=postgres_pass \
  -e ZITADEL_EXTERNALPORT=8080 \
  -e ZITADEL_EXTERNALSECURE=false \
  ghcr.io/zitadel/zitadel:latest start-from-init

Zitadel vs Keycloak decision:

9. Migration Strategy: Entra ID → Keycloak/Zitadel

A full Entra ID migration involves three phases:

Phase 1: Shadow Identity Provider (4-8 weeks)

Deploy Keycloak/Zitadel alongside existing Entra ID. Configure your applications to accept tokens from both identity providers simultaneously:

# FastAPI dual-IdP JWT validation example
from fastapi import Depends, HTTPException
from fastapi.security import HTTPBearer
import jwt
from jwt import PyJWKClient

ENTRA_JWKS_URL = "https://login.microsoftonline.com/{tenant_id}/discovery/v2.0/keys"
KEYCLOAK_JWKS_URL = "https://auth.your-eu-domain.eu/realms/your-realm/protocol/openid-connect/certs"

def get_entra_jwks():
    return PyJWKClient(ENTRA_JWKS_URL.format(tenant_id=ENTRA_TENANT_ID))

def get_keycloak_jwks():
    return PyJWKClient(KEYCLOAK_JWKS_URL)

async def verify_token(credentials = Depends(HTTPBearer())):
    token = credentials.credentials
    # Try Keycloak first (preferred EU-native path)
    for jwks_client, issuer in [
        (get_keycloak_jwks(), "https://auth.your-eu-domain.eu/realms/your-realm"),
        (get_entra_jwks(), f"https://login.microsoftonline.com/{ENTRA_TENANT_ID}/v2.0"),
    ]:
        try:
            signing_key = jwks_client.get_signing_key_from_jwt(token)
            payload = jwt.decode(
                token,
                signing_key.key,
                algorithms=["RS256"],
                audience=YOUR_CLIENT_ID,
            )
            return payload
        except Exception:
            continue
    raise HTTPException(status_code=401, detail="Invalid or expired token")

Phase 2: User Migration (2-4 weeks)

Users cannot be migrated with passwords intact (bcrypt hashes are not exportable from Entra ID). Use Just-In-Time (JIT) migration:

# JIT migration: first login against Entra ID → create Keycloak account
# Keycloak User Storage SPI (Java) or via API
import requests

def migrate_user_on_first_login(username: str, password: str, keycloak_admin_token: str):
    """
    Validate credentials against Entra ID ROPC flow,
    then create user in Keycloak if valid.
    Note: ROPC is deprecated for AAD — use only for migration, not ongoing auth.
    """
    # 1. Validate against Entra ID (ROPC — migration only)
    entra_resp = requests.post(
        f"https://login.microsoftonline.com/{ENTRA_TENANT_ID}/oauth2/v2.0/token",
        data={
            "grant_type": "password",
            "client_id": MIGRATION_CLIENT_ID,
            "client_secret": MIGRATION_CLIENT_SECRET,
            "scope": "openid profile",
            "username": username,
            "password": password,
        }
    )
    if entra_resp.status_code != 200:
        return None

    # 2. Create user in Keycloak
    user_data = {
        "username": username,
        "email": username,
        "enabled": True,
        "credentials": [{"type": "password", "value": password, "temporary": False}],
        "attributes": {"migrated_from": ["entra_id"], "migration_date": ["2026-05-16"]},
    }
    kc_resp = requests.post(
        f"{KEYCLOAK_URL}/admin/realms/{REALM}/users",
        json=user_data,
        headers={"Authorization": f"Bearer {keycloak_admin_token}"},
    )
    return kc_resp.status_code == 201

Phase 3: Cutover (1 day)

1. Disable Entra ID SAML/OIDC applications (block new logins)
2. Force-reset remaining unmigrated users (send password-reset emails from Keycloak)
3. Remove Entra ID as identity provider from all applications
4. Verify all applications return valid tokens from Keycloak only
5. Retain Entra ID read-only for 90 days (audit log access)

10. GDPR Compliance Checker (Python)

#!/usr/bin/env python3
"""
Microsoft Entra ID GDPR/CLOUD Act Compliance Checker
Assesses whether your Entra ID configuration exposes you to unmitigated CLOUD Act risk.
"""

from dataclasses import dataclass, field
from typing import Optional
import json

@dataclass
class EntraIDComplianceAssessment:
    # Identity provider details
    provider: str = "Microsoft Entra ID (Azure AD)"
    provider_jurisdiction: str = "USA (Washington State / Delaware)"
    cloud_act_subject: bool = True
    prism_provider: bool = True  # NSA PRISM confirmed

    # EU Data Boundary assessment
    eu_data_boundary_enrolled: bool = False
    eu_data_boundary_scope: str = ""  # "core services only" or "all services"

    # Authentication data categories present
    mfa_secrets_stored: bool = True
    session_tokens_stored: bool = True
    credential_hashes_stored: bool = True
    sign_in_logs_retained_days: int = 90

    # Third-country transfer safeguards
    sccs_in_place: bool = True
    tia_completed: bool = False  # Transfer Impact Assessment
    supplementary_measures: list = field(default_factory=list)

    # NIS2/DORA context
    nis2_essential_entity: bool = False
    dora_financial_entity: bool = False

    # Alternatives assessed
    eu_native_alternatives_assessed: bool = False
    migration_plan_exists: bool = False

    def compute_risk_score(self) -> int:
        score = 0
        if self.cloud_act_subject:
            score += 5
        if self.prism_provider:
            score += 3
        if not self.eu_data_boundary_enrolled:
            score += 2
        if self.mfa_secrets_stored and self.credential_hashes_stored:
            score += 5
        if self.sign_in_logs_retained_days > 30:
            score += 2
        if not self.tia_completed:
            score += 2
        if len(self.supplementary_measures) == 0:
            score += 2
        if self.nis2_essential_entity:
            score += 2
        if self.dora_financial_entity:
            score += 2
        return min(score, 25)

    def generate_report(self) -> dict:
        score = self.compute_risk_score()
        risk_level = "CRITICAL" if score >= 20 else "HIGH" if score >= 15 else "MEDIUM" if score >= 8 else "LOW"

        required_actions = []
        if not self.tia_completed:
            required_actions.append("Complete Transfer Impact Assessment per EDPB Rec 01/2020")
        if not self.eu_data_boundary_enrolled:
            required_actions.append("Enroll in Microsoft EU Data Boundary (commercial commitment, not legal shield)")
        if self.sign_in_logs_retained_days > 30:
            required_actions.append(f"Reduce sign-in log retention from {self.sign_in_logs_retained_days}d to ≤30d (Art.5(1)(e) storage limitation)")
        if not self.eu_native_alternatives_assessed:
            required_actions.append("Assess EU-native alternatives: Keycloak (self-hosted), Zitadel (CAOS AG, CH)")
        if self.nis2_essential_entity and not self.migration_plan_exists:
            required_actions.append("NIS2 Art.21 supply chain risk: document Entra ID dependency in risk register")
        if self.dora_financial_entity:
            required_actions.append("Verify Entra ID in DORA Art.28 ICT register + check CTPP concentration limits")

        return {
            "provider": self.provider,
            "jurisdiction": self.provider_jurisdiction,
            "gdpr_risk_score": f"{score}/25",
            "risk_level": risk_level,
            "cloud_act_exposure": "YES — Microsoft Corp, Washington State",
            "schrems_ii_status": "Unresolved — SCCs insufficient without supplementary measures (PRISM provider)",
            "required_actions": required_actions,
            "recommended_migration": "Keycloak (self-hosted EU) or Zitadel (CAOS AG, Zürich)",
        }


def assess_entra_id_configuration(config: dict) -> None:
    assessment = EntraIDComplianceAssessment(**config)
    report = assessment.generate_report()
    print(json.dumps(report, indent=2))


# Example: typical EU SaaS startup using Entra ID for SSO
example_config = {
    "eu_data_boundary_enrolled": True,
    "eu_data_boundary_scope": "core services only",
    "tia_completed": False,
    "sign_in_logs_retained_days": 90,
    "nis2_essential_entity": False,
    "eu_native_alternatives_assessed": False,
    "migration_plan_exists": False,
}

assess_entra_id_configuration(example_config)
# Output:
# {
#   "gdpr_risk_score": "20/25",
#   "risk_level": "CRITICAL",
#   "cloud_act_exposure": "YES — Microsoft Corp, Washington State",
#   "required_actions": [
#     "Complete Transfer Impact Assessment per EDPB Rec 01/2020",
#     "Reduce sign-in log retention from 90d to ≤30d",
#     "Assess EU-native alternatives: Keycloak, Zitadel"
#   ]
# }

11. Microsoft Entra ID vs EU-native IdPs — Decision Matrix

Recommendation:

• Microsoft 365-heavy organisations: Entra ID remains the path of least resistance for Microsoft ecosystem integration. Mitigate with EU Data Boundary + TIA + supplementary measures.
• Cloud-native EU SaaS startups: Keycloak (self-hosted on EU PaaS) or Zitadel Cloud eliminate CLOUD Act exposure at near-zero cost.
• Financial sector (DORA): CLOUD Act-exposed IdPs require documented concentration risk analysis per DORA Art.28(4). Keycloak or Zitadel provide the cleanest compliance posture.
• NIS2 essential entities: Identity is a tier-1 dependency — CLOUD Act-exposed IdPs must appear in the Art.21 supply chain risk register.

12. Twenty-Item GDPR/NIS2 Compliance Checklist

GDPR / CLOUD Act
─────────────────────────────────────────────────────────
☐ 1.  Document Entra ID as US-jurisdiction processor in ROPA (Art.30)
☐ 2.  Review Microsoft DPA for Art.28 completeness (CLOUD Act carve-out clause)
☐ 3.  Complete Transfer Impact Assessment per EDPB Rec 01/2020
☐ 4.  Update SCCs to 2021 version if still using 2010 version
☐ 5.  Enroll in Microsoft EU Data Boundary (core services scope)
☐ 6.  Verify sub-processors list (Microsoft Trust Center) for non-EU entities
☐ 7.  Set sign-in log retention to ≤30 days (Art.5 storage limitation)
☐ 8.  Enable Azure AD Audit Log streaming to EU-only SIEM
☐ 9.  Document MFA secret storage location (cloud vs. hardware token)
☐ 10. Assess GDPR Art.9 data in directory attributes (disability, religion etc.)

NIS2 / DORA
─────────────────────────────────────────────────────────
☐ 11. Add Entra ID to NIS2 Art.21 supply chain risk register (if essential entity)
☐ 12. Document SLA 99.99% + RPO/RTO for authentication outage (NIS2 Art.21(2)(e))
☐ 13. Test Entra ID outage response plan: can users authenticate without cloud IdP?
☐ 14. Verify DORA Art.30 contract clauses in Microsoft OST/DPA (financial entities)
☐ 15. Check Entra ID in DORA ICT third-party service register + concentration limits

Migration Planning
─────────────────────────────────────────────────────────
☐ 16. Assess Keycloak or Zitadel as EU-sovereign alternatives
☐ 17. Map all SAML/OIDC applications dependent on Entra ID
☐ 18. Design JIT migration strategy for existing user credentials
☐ 19. Test dual-IdP operation (Entra ID + Keycloak in parallel)
☐ 20. Define 12-month migration roadmap with quarterly milestones

Summary

Microsoft Entra ID is a technically excellent identity platform with enterprise-grade SLA and deep Microsoft 365 integration. For EU organisations with strict GDPR compliance requirements, its fundamental limitation is structural: Microsoft Corporation is subject to US CLOUD Act jurisdiction, and no contractual commitment — including the EU Data Boundary — can shield your identity data from a valid US federal warrant.

With a GDPR risk score of 20/25, Entra ID carries the highest risk classification in our EU-sovereignty series. The data it holds (credentials, MFA secrets, session tokens, login event logs) represents your entire user base's authentication identity — the keys to every door in your infrastructure.

EU-native alternatives exist and are production-ready:

• Keycloak (open source, self-hosted, 0/25 CLOUD Act score) for organisations with operational capacity
• Zitadel (CAOS AG, Zürich, 2/25) for managed cloud with EU-sovereign hosting
• WALLIX Trustelem (Paris, 1/25) for enterprise SSO with French sovereignty credentials

Next in this series: Ping Identity EU Alternative → — Delaware Corp since 2002 Thoma Bravo LBO. How PingFederate's on-premises option changes the CLOUD Act calculus.

sota.io is a European PaaS built for GDPR-native deployments. Every workload stays within EU jurisdiction — no CLOUD Act exposure, no data sovereignty compromises. Start your EU-sovereign deployment →