Auth0 / Okta EU Alternative 2026: GDPR, CLOUD Act, and Why Identity Providers Carry the Highest Compelled-Disclosure Risk

Post #901 in the sota.io EU Cyber Compliance Series

Identity providers occupy a unique position in your threat model. They are not just another SaaS tool that processes some metadata about your users. They hold the keys: password hashes, multi-factor authentication (MFA) secrets, OAuth tokens, session identifiers, and the complete audit log of every authentication event your users have ever generated. If a government compels disclosure from your identity provider, it does not get a list of who bought what. It gets everything needed to access every account, impersonate every user, and reconstruct every session.

Auth0 was acquired by Okta in May 2021 for US$6.5 billion. It continues to operate as a brand, but the legal entity that runs it is Okta, Inc., incorporated in Delaware and traded on the NASDAQ as OKTA. Delaware incorporation is not a technical footnote. It makes Okta subject to the US Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 18 U.S.C. § 2713), which requires US companies to produce data held anywhere in the world when compelled by a US court order — including data stored on servers in Frankfurt, Dublin, or Amsterdam.

Before addressing that legal structure, it is worth reviewing what happened to Okta's security posture between 2022 and 2023, because the combination of compelled-disclosure risk and demonstrated breach vulnerability defines the full picture.

Okta's Three Security Incidents in Twenty-Four Months

January 2022 — Lapsus$ Access via Third-Party Support Contractor

In March 2022, the Lapsus$ threat group published screenshots of Okta's internal systems. Okta confirmed that the attackers had accessed the laptop of a Sitel employee (a third-party customer support contractor) for approximately twenty-five minutes in late January 2022. Okta's initial disclosure delayed by two months between when Okta learned of the incident and when it notified customers.

Roughly 2.5 percent of Okta customers — approximately 366 organisations — were affected. Affected data included customer names, email addresses, and support ticket contents. Okta's CISO acknowledged that the delayed disclosure process was inadequate.

October 2023 — Customer Support System Breach

In October 2023, Okta disclosed that attackers had accessed its customer support case management system using a stolen credential. The attackers uploaded files to support tickets and used the access to steal HTTP Archive (HAR) files that Okta support agents had requested from customers for debugging purposes. HAR files can contain session cookies, authentication tokens, and API keys.

Okta initially said 134 customers were affected. It later revised the number upward: by November 2023, Okta confirmed the attacker had accessed a report containing the names and email addresses of all Okta customer support system users. That is, every organisation that had ever filed a support ticket with Okta had contact-level data exposed.

BeyondTrust, Cloudflare, and 1Password were among the publicly confirmed affected organisations — all of them identity-adjacent tools that were themselves investigating their own Okta-related exposure.

September–October 2023 — GitHub Source Code Repository Leak

In the same period, Okta confirmed that its GitHub source code repositories had been accessed without authorisation. Although Okta stated that the exposed code did not include customer data or credentials, the event underlined that Okta's own internal systems had been repeatedly compromised within a single year.

The CLOUD Act Exposure — What It Means for Your EU Users' Auth Data

What Data Okta / Auth0 Holds

When you run your application on Auth0 or Okta, the data processed includes:

• User identities: Email addresses, usernames, names, phone numbers, profile attributes you pass to Auth0.
• Credentials: Hashed passwords (bcrypt, argon2) stored in Okta's Universal Directory. Even a hash reveals which users have accounts.
• MFA secrets: TOTP seeds, WebAuthn credential IDs, push notification device tokens.
• Session tokens and refresh tokens: The credentials that keep users logged in between authentication events.
• Login history: Timestamps, IP addresses, user-agent strings, geolocation data for every login event.
• Social connection tokens: OAuth tokens from Google, GitHub, Microsoft login flows that Okta brokers.
• Application metadata: Which of your applications each user can access, their roles, their permissions.

Under GDPR Article 4, all of this is personal data. IP addresses and login timestamps are personal data. TOTP seeds linked to a user identity are personal data. The combination of email address + login frequency + geolocation profile of authentication events constitutes detailed behavioural profiling.

The CLOUD Act Mechanism

The CLOUD Act amended the Stored Communications Act (18 U.S.C. § 2703) to require US providers to comply with lawful domestic orders for data regardless of where the data is physically stored. Okta is a US provider. If a US federal agency (FBI, NSA, DEA, CBP) obtains a lawful order for user data held by Okta, Okta is required to produce it — from its EU data centres, from its AWS Frankfurt deployment, from wherever it happens to be stored.

The order can come with a gag provision: Okta may be prohibited from notifying the affected user, the affected organisation, or any third party. This creates a scenario where your EU users' authentication data has been compelled and disclosed, and neither you nor your users can be told.

Standard Contractual Clauses (SCCs) do not resolve this. SCCs govern data transfer legality under GDPR Chapter V. They create contractual obligations between Okta and you as the controller. They do not change US law. An Okta employee who discloses data pursuant to a CLOUD Act order is complying with US law and not violating the SCC — the SCC carves out legally required disclosures.

The GDPR Art. 44–49 Transfer Analysis

Auth0 and Okta rely on SCCs as the transfer mechanism for EU user data flowing to or through US infrastructure. Post-Schrems II (Case C-311/18, July 2020), the Court of Justice of the EU held that US national security law — specifically FISA Section 702 and EO 12333, both of which enable access to data on US providers — fundamentally compromises the protection SCCs are meant to provide.

The Data Privacy Framework (DPF, successor to Privacy Shield) provides a new basis for transfers where the recipient is DPF-certified. Okta is DPF-certified. However, DPF certification does not remove CLOUD Act compelled-disclosure risk. The DPF covers US intelligence collection under FISA 702 and EO 12333 via the Redress Mechanism, but the CLOUD Act is a separate statutory authority. DPF does not limit CLOUD Act production obligations.

The practical GDPR position for EU controllers: you are relying on SCCs + DPF for Auth0/Okta transfers, but neither mechanism prevents compelled disclosure of your EU users' authentication data under CLOUD Act orders. Your GDPR Art. 32 obligation to implement appropriate technical and organisational security measures is harder to satisfy when the entity holding credentials can be compelled by a foreign government.

What the GDPR Specifically Requires for Authentication Data

Authentication data is not a special category under GDPR Article 9 (which covers health, biometrics, race, sexual orientation, etc.), but it carries elevated sensitivity under Art. 32's risk-proportionate security requirement.

Art. 32 — Security of processing: Controllers and processors must implement measures appropriate to the risk, including confidentiality, integrity, and availability. For authentication data, the risk of compelled disclosure by a state actor without user notification is an identifiable risk that should appear in your DPIA.

Art. 35 DPIA — High-risk processing: Authentication processing at scale — particularly when combined with behavioural profiling (login timestamps, geolocation, device fingerprints) — is likely to constitute high-risk processing requiring a Data Protection Impact Assessment. Your DPIA should explicitly address jurisdiction risk.

Art. 28 — Controller-processor relationship: Your DPA with Okta/Auth0 must meet Art. 28(3) requirements. Check specifically whether it addresses government access and notification obligations. Okta's standard DPA carves out legally compelled disclosures.

EDPB Recommendations 01/2020 on supplementary measures: The European Data Protection Board recommends that when SCCs alone cannot provide adequate protection (as post-Schrems II analysis suggests for US providers with national security exposure), controllers should consider technical supplementary measures such as end-to-end encryption where the cloud provider cannot access the data in plain text. For an identity provider, this is structurally impossible — the provider must be able to verify credentials, which requires access to credential data.

The logical conclusion of the EDPB guidance applied to identity providers: if you cannot achieve adequate protection through SCCs + supplementary measures, you should consider switching to a provider not subject to CLOUD Act jurisdiction.

EU-Native Identity Provider Alternatives

Zitadel — Swiss Open-Source Identity, Hosted in the EU

Zitadel is developed by CAOS AG, incorporated in Rapperswil-Jona, Switzerland. Zitadel Cloud is hosted in Google Cloud regions in Europe (Frankfurt). The source code is open source (Apache 2.0) and available for self-hosting.

Switzerland is not an EU member, but the Swiss Federal Act on Data Protection (revFADP, effective September 2023) aligns substantially with GDPR. Crucially, Switzerland is not subject to US CLOUD Act jurisdiction. CAOS AG has no US parent, no US subsidiary, no US investment structure that would bring it within US law.

Feature coverage against Auth0/Okta:

• OIDC and OAuth 2.0 compliant
• SAML 2.0 support
• Multi-tenancy (organisations within a single instance)
• Passkey / WebAuthn support (passwordless)
• Machine-to-machine (M2M) with client credentials flow
• Actions / event hooks for custom logic
• Admin UI and management API
• SCIM provisioning

Pricing comparison: Zitadel Cloud free tier (up to 25,000 monthly active users); paid plans from €250/month. Auth0 free tier (7,500 active users); paid from $240/month. Zitadel self-hosted is free with enterprise support contracts available.

Migration path from Auth0: Zitadel supports Auth0-compatible import flows. User data (excluding credential hashes, which cannot be migrated without a password reset cycle) can be imported via Zitadel's management API.

Keycloak — Red Hat Open-Source Identity, Self-Hosted

Keycloak is an open-source identity and access management solution maintained by Red Hat (IBM). Keycloak itself is open-source (Apache 2.0). When you self-host Keycloak on EU infrastructure, there is no US entity involved in the data flow.

The important distinction: Red Hat / IBM are US companies. Using Red Hat Keycloak (the open-source project) while hosting it yourself on Hetzner, Scaleway, or OVHcloud means no US entity touches your authentication data. Using a managed Keycloak hosting service run by a US company reintroduces the jurisdiction problem.

Feature coverage:

• Mature, battle-tested since 2013
• Full OIDC, OAuth 2.0, SAML 2.0
• Social login federation
• LDAP and Active Directory federation
• Fine-grained authorisation
• User-managed access (UMA 2.0)
• Multi-tenancy via Keycloak Realms
• Extensive extension ecosystem

Operational complexity: Keycloak requires more operational expertise than Auth0. It runs on JVM (Quarkus-based since Keycloak 17). High-availability configuration requires clustering. For teams without dedicated infrastructure experience, managed Keycloak hosting from an EU provider (such as Inventage in Switzerland, or self-hosted on sota.io with a preconfigured Keycloak deployment) reduces this burden.

When Keycloak is the right choice: Enterprise teams with LDAP/AD federation requirements, teams that need fine-grained authorisation policies, organisations that want zero external SaaS dependency in their auth stack.

Authentik — Open-Source, Python/Go, Self-Hosted

Authentik is developed by Authentik Security Inc. (US entity), but the product is open-source (MIT/proprietary enterprise) and designed for self-hosting. When self-hosted on EU infrastructure, no US entity is involved in authentication data processing.

Authentik's architecture is modern: Python/Django backend with a Go proxy, containerised deployment (Docker Compose or Kubernetes). Its UI is more polished than Keycloak's default admin interface.

Notable features:

• Flows engine: fully customisable authentication flows via UI (no code required for most customisations)
• Built-in reverse proxy that can protect non-OIDC applications
• LDAP outpost for legacy application support
• Extensive source and provider coverage
• SCIM provisioning support
• Enterprise edition adds dedicated support

Consideration: Authentik Security Inc. is a US company. If you use their cloud offering (forthcoming as of 2026), that reintroduces CLOUD Act exposure. Self-hosted on EU infrastructure is the compliant path.

Hanko.io — German Startup, Passkey-First

Hanko is developed by Teamwörk GmbH, incorporated in Hamburg, Germany. Hanko Cloud is hosted in AWS EU regions (Frankfurt). Hanko focuses specifically on passkey-first authentication — passwordless login using WebAuthn/FIDO2.

Feature coverage:

• WebAuthn / Passkey authentication (primary design goal)
• OAuth social login
• Email-based login (magic link, passcode)
• Pre-built UI components (React, Vue, Angular, Web Components)
• Multi-tenancy

Trade-off: Hanko has a narrower feature set than Auth0 or Zitadel in 2026. It does not offer SAML, complex enterprise federation, or fine-grained RBAC out of the box. If your auth requirements are primarily consumer-facing passwordless login, Hanko is an excellent fit. For enterprise B2B with complex federation, Keycloak or Zitadel is more appropriate.

CLOUD Act risk: Hanko Cloud runs on AWS. Amazon Web Services, Inc. is a Delaware corporation and subject to CLOUD Act. The difference from Auth0 is that Hanko itself is not CLOUD Act subject — but its hosting provider is. Self-hosting Hanko on EU-owned infrastructure (Hetzner, OVHcloud) resolves this entirely.

SuperTokens — Open-Source, US Company, Self-Hostable

SuperTokens is developed by SuperTokens Inc., incorporated in Delaware. It is open-source (Apache 2.0) and primarily designed for self-hosting. SuperTokens managed service is US-hosted.

For EU compliance: self-hosted SuperTokens on EU infrastructure avoids CLOUD Act exposure. The open-source codebase can be audited. SuperTokens does not have the same breach history as Okta.

Feature coverage:

• Email/password authentication
• Social login
• Passwordless (magic link, OTP)
• Session management (one of SuperTokens' strongest points — fine-grained session control)
• Multi-tenancy (Enterprise)
• User roles and permissions

Best fit: Startups and scale-ups that want developer-friendly self-hosted auth with lower operational complexity than Keycloak.

Comparison: Auth0 / Okta vs. EU Alternatives

Making the Switch: Technical Migration Considerations

Phase 1 — Parallel Deployment

The standard migration pattern for identity providers is parallel deployment: run Auth0 and your EU alternative simultaneously, federate your EU IdP into Auth0 (or vice versa) for a transition period, then migrate users.

Most modern identity providers support OIDC federation. You can configure Zitadel or Keycloak as an external identity source in Auth0 temporarily while you migrate application-by-application.

Phase 2 — User Migration and the Credential Hash Problem

This is the hard part. Auth0 stores user passwords as bcrypt hashes. You can export these hashes via Auth0's Management API (GET /api/v2/users with password_hash field access, requiring a specific connection export from Auth0 support for bulk migrations). Keycloak and Zitadel can import bcrypt hashes directly — users log in without needing to reset their passwords.

For Auth0 database connections, request an export via the Auth0 Dashboard → User Management → Export Users (includes password hashes for database connections). This export is only available for Auth0 database connections — social login users (Google, GitHub) do not have password hashes because they authenticate via the social provider.

For social login users, the migration is simpler: re-register the social connection on the new IdP. Users log in with their existing Google/GitHub account. No credential disruption.

Phase 3 — MFA Device Migration

TOTP devices (Google Authenticator, Authy) are registered to TOTP secrets stored in Auth0. These cannot be exported — Auth0 does not expose TOTP seeds via the Management API for security reasons. Users will need to re-enrol their TOTP devices after migration.

WebAuthn (hardware keys, platform authenticators) credentials are bound to the origin domain and cannot be migrated between providers. Users will re-enrol their hardware keys.

SMS and email OTP flows: these are re-registerable automatically on first login to the new provider.

Migration communication: plan a user-facing "please re-enrol your two-factor device" flow. For consumer applications with high MFA adoption, this requires careful UX planning.

Phase 4 — Application Integration

Auth0 and OIDC-compatible EU IdPs share the same protocol. Your applications' OIDC integration code changes are minimal:

• Update the issuer URL (from your-tenant.eu.auth0.com to your Zitadel/Keycloak endpoint)
• Update client IDs and client secrets
• Update callback URLs in the new IdP
• Verify JWKS endpoint for token validation

Most OAuth/OIDC libraries (passport.js, Spring Security, django-allauth, Python's authlib) are provider-agnostic — swapping the configuration is a config change, not a code rewrite.

Deploying EU Auth Infrastructure on sota.io

Each of these self-hosted options — Keycloak, Authentik, Hanko, SuperTokens — can be deployed as a containerised application. sota.io runs any Docker-compatible workload.

A minimal Keycloak deployment on sota.io:

# Set your domain and Keycloak admin credentials
sota env set KEYCLOAK_ADMIN=admin
sota env set KEYCLOAK_ADMIN_PASSWORD=<strong-password>
sota env set KC_HOSTNAME=auth.yourdomain.com

# Deploy from Docker Hub (or use a custom image)
sota deploy --image quay.io/keycloak/keycloak:latest \
  --port 8080 \
  --env KC_PROXY=edge \
  --env KC_HOSTNAME=$KC_HOSTNAME

sota.io handles TLS termination, EU-region deployment, and automatic HTTPS. Your Keycloak instance is reachable at auth.yourdomain.com within minutes, running on infrastructure that is not subject to CLOUD Act jurisdiction.

For Zitadel:

sota deploy --image ghcr.io/zitadel/zitadel:latest \
  --port 8080 \
  --env ZITADEL_EXTERNALDOMAIN=auth.yourdomain.com \
  --env ZITADEL_TLS_ENABLED=false

Both deployments need a PostgreSQL database. sota.io can host Postgres alongside your IdP in the same project, keeping all authentication data within the same EU-jurisdiction boundary.

The GDPR Risk Summary

EU SaaS teams using Auth0 / Okta should document and address the following in their ROPA and DPIA:

1. Data controller / processor relationship: You are the controller; Okta is the processor. Your DPA with Okta must meet GDPR Art. 28(3). Review whether the DPA adequately addresses government access requests.

2. Transfer mechanism: SCCs + DPF. Document this in your ROPA under Art. 30(1)(e). Note that DPF does not cover CLOUD Act production obligations.

3. DPIA requirement: Authentication at scale with login history, geolocation, and device profiling likely triggers DPIA under Art. 35. The DPIA should include jurisdiction risk as an identified risk item.

4. Incident notification implication: If Okta discloses your users' authentication data pursuant to a CLOUD Act order, this may constitute a personal data breach under Art. 4(12) — even though Okta is technically complying with law. Whether you have an Art. 33/34 notification obligation depends on whether the breach "results in risk to the rights and freedoms of natural persons." Authentication data compelled disclosure almost certainly meets this threshold.

5. Art. 32 proportionality: Given the sensitivity of credential data and Okta's demonstrated breach history, an updated Art. 32 assessment should consider whether the current security measures are proportionate to the risk. Switching to EU-native self-hosted auth is a structural risk reduction, not a cosmetic compliance measure.

Summary

Auth0 is Okta. Okta is a Delaware corporation. Delaware means CLOUD Act. CLOUD Act means your EU users' passwords, MFA secrets, session tokens, and login histories can be compelled by US authorities without a court order visible to you or your users.

After three significant security incidents between January 2022 and November 2023 — Lapsus$, the customer support breach that exposed all support users' contact data, and the GitHub source code leak — the combination of demonstrated vulnerability and compelled-disclosure jurisdiction risk represents the highest-risk data processor position in a typical SaaS stack.

The EU alternatives exist and are mature. Zitadel provides a managed EU-hosted option with no US-jurisdiction exposure. Keycloak remains the enterprise standard for self-hosted IdM. Authentik offers the best balance of modern UX and self-hosted flexibility. Hanko leads for passkey-first consumer applications.

None of them have had three security incidents in two years. And none of them are Delaware corporations.

sota.io is an EU-native PaaS for developers who need genuine data sovereignty — not US-company EU regions. Deploy Keycloak, Zitadel, Authentik, or any Docker-compatible auth stack on infrastructure that is structurally outside US CLOUD Act jurisdiction. Start your EU-sovereign deployment.