AWS Cognito EU Alternative 2026: User Authentication Data Under US Jurisdiction and the CLOUD Act Risk

Post #693 in the sota.io EU Compliance Series

AWS Cognito is Amazon's managed identity platform: User Pools store and authenticate your application's end users, while Identity Pools federate identities from Cognito User Pools, social providers (Google, Facebook), and SAML/OIDC enterprise directories into temporary AWS credentials. Cognito has become a default choice for web and mobile applications because it handles the most tedious aspects of identity: registration flows, password reset, MFA enrollment, token issuance, and federation — all without maintaining identity infrastructure.

The GDPR problem with Cognito is structural, not incidental. Identity data is personal data by definition. Every email address in a Cognito User Pool is a GDPR-regulated data point. Every authentication event log — which user logged in, from what IP address, at what time, on what device, with what MFA method — is personal data under Article 4(1). Every password reset, every failed login attempt, every session token issued lives in AWS infrastructure operated by Amazon Web Services, Inc., a Delaware corporation subject to the US CLOUD Act.

This article examines what AWS Cognito stores and processes, the GDPR and regulatory implications of running user authentication under US-entity control, and the EU-native identity alternatives for organizations that need authentication sovereignty.

What AWS Cognito Stores and Processes

Cognito's data footprint is broad because identity systems touch every user interaction in an application. Understanding what Cognito holds requires looking at each component.

Cognito User Pools as the primary user directory. A User Pool is a fully managed user directory. For every registered user it stores:

• Core PII: Email address or phone number (used as username), and optionally a display name, given name, family name, address, birthdate, gender, locale, website, and profile picture URL. These are standard OIDC claims that Cognito pre-defines. Every piece of information your registration flow collects is stored in the User Pool — under AWS, in AWS's infrastructure, in the jurisdiction of an AWS-controlled AWS region. For EU-based applications, this is typically eu-west-1 (Ireland) or eu-central-1 (Frankfurt). The region is physically in the EU, but the legal entity operating the infrastructure is Amazon Web Services EMEA SARL (a Luxembourg entity that is a wholly owned subsidiary of Amazon Web Services, Inc.). The data remains subject to US CLOUD Act jurisdiction because the parent company is a US corporation.
• Hashed credentials: Cognito stores Secure Remote Password (SRP) verifiers for password-based authentication. The raw password is never stored, but the SRP verifier combined with the salt is stored in AWS infrastructure. Under CLOUD Act compulsion, AWS could provide this data to US law enforcement.
• Custom attributes: Cognito supports custom user attributes — arbitrary key-value pairs your application adds to the user schema. These frequently contain internal user IDs, subscription tiers, tenant identifiers, and feature flags. Custom attributes that correlate to external systems (your application's database user ID) become linkable data under AWS control.
• Multi-factor authentication (MFA) data: Cognito tracks enrolled MFA methods per user. For TOTP (Time-based One-Time Password), Cognito stores the TOTP secret — the cryptographic seed that generates authentication codes — in the User Pool. This is particularly sensitive: knowledge of a TOTP secret allows generating valid authentication codes for that user indefinitely. For SMS MFA, Cognito stores the verified phone number. MFA configuration is personal data (phone number) combined with security-sensitive data (TOTP secrets).
• User status and account state: Whether an account is confirmed, unconfirmed, force-password-change required, disabled, or deleted is stored in the User Pool. Account creation timestamp, last modified timestamp, and the complete attribute history are maintained by Cognito.

Authentication event logs — the most sensitive Cognito data. Cognito Advanced Security features log every authentication event with a risk assessment. Even without Advanced Security, standard Cognito generates authentication event records:

Every successful login is recorded with the user identifier, the client application ID, the source IP address, the timestamp, and the authentication method (SRP password, TOTP, SMS OTP, federation assertion). Source IP correlated with user identity and timestamp is personal data under GDPR — it reveals when your users are active, from where, and on which devices. For applications with sensitive user bases (healthcare, legal, financial), this behavioral data is highly sensitive.

Cognito Advanced Security (an additional paid feature) adds risk assessment to every authentication event — classifying events as low, medium, or high risk based on IP reputation, device fingerprint, geolocation, and behavioral analysis. AWS stores these risk assessments and the underlying signals that generated them. Device fingerprinting data — browser user agents, screen resolution, installed fonts used for fingerprinting — is stored by AWS as part of the device tracking feature.

Cognito Identity Pools and federation. Identity Pools broker credentials from multiple identity sources (User Pools, Google, Facebook, Apple, SAML enterprise IdPs, OIDC providers) into temporary AWS IAM credentials. The Identity Pool stores the mapping between external identity claims and IAM roles. Federation through Cognito means that SAML assertions from your enterprise IdP — which may contain employee role claims, department codes, and email addresses — transit through and are processed by AWS-controlled infrastructure.

Lambda triggers — where application logic runs inside Cognito. Cognito supports Lambda triggers that fire at specific points in authentication flows: pre-signup validation, post-confirmation actions, pre-token generation (to add custom claims), user migration (to migrate users from an existing system on first login), and more. These Lambda functions run on AWS Lambda — a separate service — but they are invoked by Cognito and receive the full user record as input. User migration triggers in particular receive the username and plaintext password that a migrating user supplies on first login, so your migration Lambda can validate against the legacy system. This plaintext password handling in AWS Lambda is a notable data processing point that GDPR controllers need to document in their Records of Processing Activities (Article 30).

Amazon Pinpoint integration for user analytics. Cognito optionally integrates with Amazon Pinpoint for user activity analytics — tracking which users open your app, complete registration, or drop off during onboarding. Pinpoint stores this behavioral data under AWS jurisdiction. Organizations using this integration are sending application engagement analytics — tied to individual Cognito user identities — to an additional AWS service.

The GDPR and CLOUD Act Analysis

Cognito as a Data Processor under Article 28 GDPR. AWS acts as a Data Processor for Cognito User Pool data. The AWS GDPR Data Processing Addendum (available through the AWS Customer Agreement) establishes the legal basis for this processing. AWS commits to processing data only on documented instructions (your application's API calls) and to appropriate technical and organizational security measures.

The CLOUD Act gap in this arrangement is well-documented and not resolved by the AWS DPA: the CLOUD Act (18 U.S.C. § 2713) requires US communications service providers to produce data stored anywhere in the world in response to US law enforcement orders. The DPA's commitments operate under normal circumstances. The CLOUD Act overrides normal circumstances by making disclosure a legal obligation for the US parent entity.

For Cognito specifically, the CLOUD Act risk profile is higher than many AWS services because:

1. Cognito holds PII for your entire user base by design. Unlike S3 (where you control what you store) or CloudWatch (where you configure what gets logged), Cognito's value proposition is that it manages your users. Your entire user directory is, by design, the data Cognito holds.

2. Authentication events are behavioral data. Login timestamps, IP addresses, and device fingerprints build a behavioral profile of every user. In investigations, authentication logs are precisely the kind of data that law enforcement seeks under CLOUD Act orders — they establish presence, activity patterns, and account access.

3. MFA TOTP secrets are security-critical. Cognito stores TOTP secrets for enrolled MFA methods. Access to these secrets grants the ability to generate valid second-factor codes. This is categorically more sensitive than most application data.

NIS2 and DORA implications. For organizations in scope for NIS2 (Network and Information Security Directive 2, enforceable October 2024) or DORA (Digital Operational Resilience Act, January 2025 for EU financial entities), the identity system is critical infrastructure. NIS2 requires that essential and important entities manage supply chain risks — using a US-controlled identity provider is a documented third-party dependency risk that needs formal treatment. DORA explicitly requires ICT third-party risk management with documented exit strategies. For financial entities, dependency on Cognito for authentication without a migration plan would be a DORA finding.

The "AWS EU Region" misconception. AWS launched the AWS European Sovereign Cloud in January 2026, a new isolated cloud region operated by a German legal entity with German managing directors. The European Sovereign Cloud is a distinct product — it is not the same as running Cognito in eu-west-1 or eu-central-1. Standard Cognito in EU regions runs under Amazon Web Services EMEA SARL (Luxembourg subsidiary of US parent). The European Sovereign Cloud product, if it offers Cognito, would represent a different legal arrangement — but as of early 2026, Cognito availability in the European Sovereign Cloud is not confirmed, and the product is priced at enterprise contract level, not self-service.

EU-Native Alternatives to AWS Cognito

The EU-native identity market has matured significantly. Several open-source options are production-ready and deployable on EU-sovereign infrastructure.

Keycloak (Red Hat/CNCF) — the enterprise standard. Keycloak is the most widely deployed open-source identity platform. It provides:

• User federation (sync from LDAP/Active Directory)
• OIDC and SAML 2.0 support
• Social login (Google, GitHub, etc.) via external identity providers
• Fine-grained authorization policies
• Full MFA support (TOTP, WebAuthn/passkeys, SMS via external provider)
• Admin UI and theme customization for branded login flows
• Extensive Java-based SPI for custom authentication flows

Keycloak deployed on sota.io runs on Hetzner-owned infrastructure in EU data centers. Your User Pool equivalent — every user account, every credential hash, every session — stays under EU jurisdiction. Keycloak is backed by Red Hat (IBM subsidiary, but the open-source project is CNCF-hosted), and enterprise support is available through Red Hat Single Sign-On. The GDPR controller-processor relationship shifts: you are the controller and processor simultaneously for self-hosted Keycloak, with no third-party data processing to document under Article 28.

Authentik — the modern developer-first alternative. Authentik is a newer open-source identity provider (Python/Django, approximately 2020 origin) that has gained significant adoption for its clean UI and simpler configuration model compared to Keycloak. Authentik supports OIDC, SAML, LDAP, RADIUS, and SCIM. Its Flow-based authentication configuration — where login, enrollment, MFA enrollment, and account recovery are defined as configurable flows — is more accessible than Keycloak's authentication flow configuration. Authentik is particularly popular in homelab and SMB deployments and has growing enterprise adoption.

Zitadel — the cloud-native EU option. Zitadel is a Swiss company (Zitadel AG, founded 2021) that provides an open-source identity platform designed for cloud-native deployment. Zitadel's key differentiators are its multi-tenant architecture (designed for B2B SaaS where each customer organization is a separate tenant), its event-sourced data model (full audit log of every state change), and its Go-based implementation (lower resource footprint than Keycloak). Zitadel AG is a Swiss entity — Switzerland has an EU adequacy decision under GDPR (SCCs not required). For organizations that need a managed Zitadel service with Swiss/EU data residency, Zitadel AG offers Zitadel Cloud.

Casdoor — the lightweight option for embedded use cases. Casdoor is an open-source identity platform (Go, Apache 2.0) from Casbin that embeds cleanly into existing applications. It supports OAuth 2.0, OIDC, SAML, and CAS protocols. Casdoor is well-suited for applications that need an embeddable identity service rather than a full-featured standalone identity platform. Resource requirements are significantly lower than Keycloak.

Ory — the microservice identity stack. Ory is a CNCF project providing identity microservices: Hydra (OAuth 2.0/OIDC server), Kratos (self-service user management — registration, login, MFA, account recovery), and Keto (permission/access control). Ory Kratos maps most directly to Cognito User Pools. Ory GmbH is a German company (Munich). Ory Network — the managed offering — runs in EU data centers. For organizations that want managed identity without self-hosting, Ory Network with EU data residency is a genuine EU-native Cognito alternative at the SaaS level.

Deploying Keycloak on sota.io

sota.io provides Docker-based deployments on Hetzner infrastructure in Nuremberg (NBG1) and Falkenstein (FSN1) data centers — both in Germany, EU jurisdiction, no US-entity involvement in the infrastructure stack.

A production Keycloak deployment on sota.io:

# docker-compose.yml for Keycloak on sota.io
services:
  keycloak:
    image: quay.io/keycloak/keycloak:24.0
    command: start
    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: ${KC_DB_PASSWORD}
      KC_HOSTNAME: auth.yourdomain.eu
      KC_PROXY: edge
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}
      KC_HEALTH_ENABLED: "true"
    depends_on:
      - postgres
    ports:
      - "8080:8080"

  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: ${KC_DB_PASSWORD}
    volumes:
      - keycloak_db:/var/lib/postgresql/data

volumes:
  keycloak_db:

Migrating from Cognito to Keycloak involves:

1. User export from Cognito: Use the Cognito ListUsers API to export user records. Passwords cannot be exported (only SRP verifiers are stored, not cleartext), so a migration Lambda approach — where users are migrated on first post-migration login — is typically used.
2. Cognito User Migration trigger equivalent: Keycloak supports a "User Storage SPI" that federates against an external source on first login. The same pattern applies: on first login to Keycloak, if the user doesn't exist locally, query the legacy Cognito export, validate credentials, and create the Keycloak user. Over time, all active users migrate.
3. OIDC client updates: Update your application's OIDC issuer URL, client ID, and client secret from Cognito endpoints to your Keycloak realm endpoints. The OIDC protocol is identical — the change is configuration, not application code.
4. Token claim mapping: Cognito's JWT claims structure differs from Keycloak's defaults. Review the claims your application reads from ID tokens and configure Keycloak's protocol mappers to produce matching claims.

Risk Assessment: When Does Cognito's Jurisdiction Actually Matter?

Not every application has the same risk profile. A structured assessment:

High risk — migrate or avoid Cognito:

• Healthcare applications where user identity combined with access patterns reveals sensitive relationships (patient-provider)
• Legal, financial, or HR applications where user behavioral data (login timestamps, session duration, access patterns) is sensitive
• Applications where the user base includes EU data subjects whose data is subject to regulatory sector-specific rules beyond GDPR (DORA for financial entities, specific health data regulations)
• Organizations in NIS2 scope (essential/important entities) where third-party risk management requires documented mitigation for US-jurisdiction dependencies

Medium risk — acceptable with documented mitigation:

• B2C consumer applications where the data in Cognito is limited to email address and hashed credentials, behavioral data risks are accepted and documented in the ROPA, and a migration plan exists
• Internal applications where users are employees, the employment relationship provides legal basis for processing, and the behavioral data risk is lower
• Applications where Cognito is used only for federated identity (Cognito Identity Pools federating from your self-hosted IdP) — limiting what Cognito directly holds

Lower risk — Cognito may be pragmatic:

• Early-stage products where the user base is small, the data processed is minimal, and the development velocity benefit outweighs the compliance overhead
• Applications where the user base is exclusively non-EU (outside GDPR scope), though this requires affirmative verification rather than assumption

Conclusion

AWS Cognito stores the most personal data of any AWS service by design: your complete user directory, authentication behavioral logs, MFA secrets, and device fingerprints — all under the jurisdiction of an Amazon Web Services entity subject to the US CLOUD Act.

For EU-based applications handling GDPR-regulated user data, the choice between Cognito and an EU-native identity platform is not primarily a technical decision — it's a data sovereignty decision. The technical alternatives are mature: Keycloak, Authentik, Zitadel, Ory, and Casdoor each provide the core capabilities of Cognito User Pools. The operational overhead of self-hosting is real but well-understood.

sota.io provides the EU-native infrastructure layer: managed Postgres for identity data, Hetzner-owned data centers in Germany, no US-entity involvement in the infrastructure stack. Keycloak or Authentik running on sota.io replaces Cognito's managed service model with an EU-sovereign equivalent where you remain the controller and processor of your user data under Article 28 GDPR — with no third-party data processing to document, no CLOUD Act exposure, and no dependency on a US corporation for your application's authentication infrastructure.

Part of the sota.io EU Compliance Series: AWS service-by-service GDPR and CLOUD Act analysis for European developers and engineering teams.