sota.io
2026-05-01·14 min read·
AWS Cognito is Amazon's managed Customer Identity and Access Management (CIAM) platform, built around two core constructs: User Pools and Identity Pools. User Pools handle authentication — they store your customer accounts, manage passwords and MFA, issue JWTs, and integrate with social identity providers (Google, Facebook, Apple). Identity Pools broker temporary AWS credentials to authenticated or unauthenticated users, enabling direct access to S3, DynamoDB, and other AWS services from client applications. For European software companies, Cognito is an operationally attractive default: it removes the complexity of running an authentication service, scales automatically, and integrates natively with AWS Lambda, API Gateway, AppSync, and ALB. The GDPR problem is structural. Every customer account, every authentication event, every token operation, every device fingerprint — all of it resides on US-controlled infrastructure and falls under CLOUD Act jurisdiction. Your customers never consented to Amazon holding their login history. Most never know it happens. This post analyses what AWS Cognito actually processes, why the CLOUD Act exposure is broader than most application teams realise, and which EU-native CIAM alternatives deliver the same capabilities without routing your customer identity layer through US infrastructure. --- ## What AWS Cognito Actually Holds Cognito is frequently described as a "login service," but its data surface extends well beyond credential storage. **User Pool records:** Each User Pool stores a complete customer identity record per registered user: - Core attributes: email, phone number, username, name, address, birthdate, gender, locale, zoneinfo, preferred username, website, profile - Custom attributes: application-defined fields added to the user schema — subscription tier, organisation ID, onboarding flags, feature toggles, consent records, account creation timestamp - Password verifier: hashed credential derived from SRP protocol — not the plaintext password, but sufficient for Cognito to authenticate the user - MFA configuration: which MFA methods the user has configured (SMS, TOTP, email OTP), phone numbers or TOTP secrets associated with each **Authentication event logs:** Cognito emits a detailed event log for every authentication operation: - `SignIn`: timestamp, user identity, source IP address, user agent string, device fingerprint, authentication result (success, failure, challenge required) - `SignUp`: registration event with registration source attributes - `TokenRefresh`: every silent token renewal — reveals when users are active even without explicit logins - `ForgotPassword`, `ChangePassword`, `UpdateUserAttributes`: lifecycle events showing when users change their credentials or profile data - Device tracking: Cognito's "remembered devices" feature stores a device fingerprint for each user, enabling device-based authentication without MFA **Advanced Security features (Cognito Fraud Detection):** When Advanced Security features are enabled, Cognito processes additional signals: - **Risk scoring**: Cognito analyses IP address, device fingerprint, user location, and behavioural patterns to compute a risk score for each authentication event - **Adaptive authentication**: high-risk sign-ins trigger MFA challenges — this means Cognito holds a behavioural profile sufficient to distinguish "normal" from "anomalous" logins for each user - **Compromised credential checks**: Cognito checks passwords against known breach datasets — the check itself generates an additional processing record **Identity Pool (Federated Identity) records:** Identity Pools associate authenticated users with temporary AWS IAM credentials: - Identity mappings: links between Cognito User Pool sub-identifiers, social provider tokens (Google `sub`, Facebook UID, Apple user identifier), and Cognito Identity IDs - Unauthenticated identity records: if your application allows guest access, Cognito creates anonymous identity records with device-persistent identifiers - Credential vend logs: each call to `GetCredentialsForIdentity` is logged — revealing when users directly accessed AWS services (S3 pre-signed URL requests, AppSync queries, DynamoDB direct access) --- ## CLOUD Act Exposure: The Authentication Database Your Customers Don't Know About The CLOUD Act (18 U.S.C. § 2713) requires US providers to produce data in response to a US government order regardless of where the data is stored physically. AWS is a US entity. A CLOUD Act order targeting a User Pool yields: **The complete customer roster:** Every registered user, their email or phone number, their custom attributes, and their account status. For a B2C application with 100,000 European users, this is a complete export of your customer base — names, emails, profile data, subscription tiers — produced without the data subjects' knowledge or notification rights under European law. **The complete authentication history:** Every login event for every user for the retention period of Cognito event logs. Authentication logs reveal not just that a user exists but when they were active, from which cities, on which devices, with what regularity. For healthcare or financial applications, authentication frequency alone can reveal sensitive facts: a spike in late-night logins, activity from a hospital IP range, inactivity consistent with hospitalisation or life events. **The behavioural profile:** If Advanced Security features are enabled, Cognito has computed a risk profile from the behavioural signals of each user. This profile encodes enough about "normal" behaviour to detect anomalies. Produced under a CLOUD Act order, it constitutes a behavioural dossier on your customer derived without their consent for that purpose. **The device map:** If device tracking is enabled, Cognito holds a persistent device fingerprint per user per trusted device. This maps the hardware used by each individual to access your application — potentially linkable to other services using the same device identifier. The critical structural problem is that the data controller (the European company using Cognito) has no ability to resist or even know about a CLOUD Act order targeting their User Pool. AWS will comply with valid legal orders; your customers will not be notified under European law; you as data controller cannot discharge your Art.5(2) accountability obligations for processing you do not control. --- ## Six GDPR Compliance Vectors for AWS Cognito ### 1. Art.6 Legal Basis: Cognito Attributes Exceed Consent Scope **The problem:** Many Cognito User Pools collect custom attributes that go beyond what customers explicitly consented to when registering. Standard onboarding flows capture email and password; the Cognito schema may additionally store device fingerprints, login timestamps, behavioural risk scores, geographic location from IP, and application-specific flags — none of which appear in the privacy policy or consent notice shown to the user. When a customer creates an account in your application, they consent to providing their email address and a password to access the service. They do not typically consent to Amazon computing a behavioural risk profile from their authentication patterns, storing a device fingerprint, or enriching their record with geolocation derived from their IP. Each category of additional processing requires its own legal basis under Art.6, and Schrems II invalidated the legal basis for transferring this data to a US processor. **The consequence:** A data subject rights request (Art.15 right of access) that reveals Cognito attributes the user never knowingly provided is prima facie evidence of Art.6 non-compliance. Supervisory authorities have found Art.6 violations on this basis in authentication contexts. ### 2. CLOUD Act as Art.5(1)(f) Security Obligation Paradox **The problem:** Art.5(1)(f) requires that personal data be processed with appropriate security, including protection against unauthorised access. CLOUD Act government access constitutes authorised (under US law) access that is simultaneously unauthorised (under EU law) — there is no Art.49 derogation that legalises systematic, prospective law-enforcement access to authentication data. The EDPB has confirmed that standard contractual clauses cannot overcome structural CLOUD Act exposure. Controllers that use Cognito cannot comply with Art.5(1)(f) for the processing operations Cognito performs, because they cannot prevent or even detect CLOUD Act access to their User Pools. ### 3. Art.17 Right to Erasure: Cognito Deletion Is Not GDPR Erasure **The problem:** Cognito offers `AdminDeleteUser` and allows users to delete their own accounts. Deleting a Cognito user removes them from the User Pool — but deletion propagates to AWS CloudTrail and Cognito event logs differently depending on retention configuration. By default, CloudTrail logs are retained for 90 days in CloudTrail event history and indefinitely if configured to write to S3. Authentication events referencing the deleted user identity (by `sub` or `username`) persist in these logs. For a Cognito User Pool linked to DynamoDB, S3, or other downstream systems via Lambda triggers, the deletion of the Cognito record does not cascade to data stored in those services by trigger functions. GDPR Art.17 erasure requires deletion of all personal data — the Cognito `AdminDeleteUser` satisfies the identity record deletion but leaves authentication event logs containing the user's identifier in place. Controllers must implement a separate erasure workflow covering: Cognito User Pool record, CloudTrail events (not deletable on demand), Cognito advanced security event logs, downstream records written by Lambda triggers, and any analytics events that captured the Cognito `sub` as a user identifier. Most Cognito deployments have no such workflow. ### 4. Art.9 Sensitive Data in Custom Attributes **The problem:** Healthcare and financial applications commonly store Art.9-qualifying attributes in Cognito custom attributes: disability accommodation flags, medical condition identifiers used for feature gating, HIV status identifiers in patient applications, treatment programme codes, and similar fields. Cognito's custom attribute schema makes it trivially easy to add these fields to the user record. Art.9 requires explicit consent for sensitive data processing and explicit identification of the legal basis. Custom attributes in a Cognito User Pool are not distinguished by sensitivity — they are stored, logged, and exported identically to non-sensitive attributes. A CLOUD Act order would produce Art.9 data without any additional filter or restriction, since Cognito does not implement data classification at the attribute level. ### 5. Art.13/14 Transparency: Customers Unaware of Amazon as Sub-Processor **The problem:** Art.13/1(e) and Art.14/1(f) require controllers to inform data subjects about the recipients or categories of recipients of personal data, including processors acting on their behalf. Most consumer-facing applications that use Cognito do not name Amazon Web Services as a processor of authentication data in their privacy notices. Users registering for a European SaaS product typically have no visibility into the fact that their login credentials, authentication events, and device fingerprints are held by Amazon in the United States. Privacy notices that list "cloud infrastructure providers" generically without identifying that authentication data — including credentials, login history, and behavioural profiles — is specifically held by a US provider under CLOUD Act jurisdiction are not compliant with Art.13/14. Supervisory authorities in France (CNIL), Germany (DSK), and the Netherlands (AP) have found this level of disclosure insufficient in enforcement actions. ### 6. Art.35 DPIA for Large-Scale Authentication Processing **The problem:** Art.35 DPIA is mandatory for "large-scale processing of personal data," systematic monitoring of data subjects' behaviour, and processing of special categories of data. Cognito User Pools for consumer applications frequently meet multiple DPIA triggers simultaneously: large-scale (tens of thousands or millions of user records), systematic behavioural monitoring (authentication event logging and risk scoring), and Art.9 data in custom attributes. Most organisations that adopt Cognito for a new application do not conduct a DPIA because Cognito is selected before the application reaches scale and the DPIA trigger criteria are not re-evaluated as user numbers grow. The Advanced Security risk-scoring feature — which performs exactly the "systematic monitoring of behaviour" DPIA trigger — is often enabled as a security best practice without triggering a DPIA review. A Cognito deployment with Advanced Security features and a User Pool exceeding approximately 25,000 users almost certainly requires a mandatory DPIA under Art.35(3)(b). --- ## Identity Pool CLOUD Act Risk: The Temporary Credential Problem Identity Pools are often overlooked in Cognito GDPR analysis because they do not store persistent user data in the same way User Pools do. The CLOUD Act exposure is nonetheless significant. Every call to `GetCredentialsForIdentity` is logged in CloudTrail with the Cognito Identity ID, the identity pool ID, the timestamp, the source IP, and the IAM role assumed. For applications that grant users direct access to AWS resources (S3 objects, DynamoDB items, AppSync operations), this log reveals exactly which user accessed which AWS resource at which time — a complete access log for user-generated content, documents, media, and communications stored in S3. For an application where users upload documents to S3 via Identity Pool credentials, the CloudTrail log of credential vending events combined with S3 access logs constitutes a complete record of who accessed which document when. If those documents include health records, legal correspondence, or financial statements, the CloudTrail Identity Pool logs are Art.9 or Art.9-adjacent sensitive processing records. --- ## EU-Native CIAM Alternatives ### Keycloak Keycloak is the CNCF-graduated identity and access management platform originally developed by Red Hat, now a standalone open source project. It provides a complete CIAM feature set: User Federation (LDAP, Active Directory), social login (Google, Facebook, GitHub, Apple), SAML 2.0 and OIDC IdP/SP, MFA (TOTP, WebAuthn, SMS), client scopes, protocol mappers, and a full admin and account console. For Cognito User Pool replacement, Keycloak's realm concept maps directly: one realm per application or tenant, with configurable password policies, registration flows, email verification, and account recovery. Keycloak does not include Cognito's machine learning risk scoring — risk scoring can be added via the IP-Restrictor and Device-Authenticator plugins or via upstream WAF integration. Keycloak runs on any JVM-compatible infrastructure. Deployed on EU-hosted cloud (Hetzner, OVH, IONOS, sota.io), it processes all customer identity data within EU jurisdiction without CLOUD Act exposure. ### Authentik Authentik is a German-founded open source identity platform focused on ease of deployment and a modern UI experience. It provides OIDC/OAuth2, SAML, LDAP, RADIUS, proxy authentication, and SCIM 2.0 provisioning in a single deployable package. Authentik's flow engine allows building custom authentication and registration flows visually — the equivalent of Cognito's Lambda trigger customisation, but without code. For consumer-facing CIAM, Authentik's self-service flows (password reset, email verification, profile editing, MFA enrollment) are production-grade and customisable via the branding and policy engine. The application portal provides users with a centralised view of all their connected applications — comparable to the Cognito Hosted UI but fully self-hosted. Authentik's Docker Compose deployment works well on a single EU-hosted VM with a PostgreSQL backend; for high-availability deployments, Kubernetes manifests and a Helm chart are maintained. ### Zitadel Zitadel is a Swiss-developed, cloud-native identity platform designed for multi-tenant SaaS applications. Its architecture natively separates the identity provider (Zitadel instance) from the consuming organisations — each organisation has an isolated tenant with its own user base, branding, and authentication policies. This makes Zitadel well-suited for B2B SaaS products that need to offer their customers branded SSO and custom authentication policies. Zitadel offers a managed cloud option with EU data residency (hosted in Frankfurt) for teams that want the operational simplicity of a managed service without the CLOUD Act exposure of Cognito. For teams requiring on-premises or fully self-managed deployments, Zitadel's single binary and Kubernetes operator make it straightforward to deploy on EU infrastructure. Zitadel's OIDC implementation is particularly thorough, with full device flow, token introspection, and rich action support for customising token claims — the functional equivalent of Cognito User Pool Lambda triggers for Pre-Token Generation. ### Ory (Kratos + Hydra) The Ory ecosystem provides composable identity primitives: Ory Kratos handles identity management (user registration, login, profile management, credential recovery) and Ory Hydra provides the OAuth2/OIDC authorisation server. Together they replicate the Cognito User Pool and application authorisation flow as separate, independently deployable services. The composable architecture is appropriate for teams building complex authorisation models or needing fine-grained control over the identity flow — at the cost of higher integration complexity compared to Keycloak or Authentik. Ory also offers a managed cloud product (Ory Network) with EU data residency. ### FusionAuth FusionAuth is a commercially-supported CIAM platform available as self-hosted or managed cloud. Its feature set is explicitly designed for Cognito replacement: User Registration, Login, MFA, Social Login, Passwordless, Email Templates, Webhooks, and a Lambda-equivalent (FusionAuth Lambdas for JWT customisation). FusionAuth offers a free self-hosted tier with commercial support contracts. For European teams requiring vendor support without US data residency risk, FusionAuth's self-hosted model on EU infrastructure combines commercial-grade support with full jurisdictional control. --- ## Hosting EU-Native CIAM on sota.io Running Keycloak, Authentik, Zitadel, or Ory on EU-native PaaS delivers equivalent operational simplicity to Cognito without routing authentication through US-controlled infrastructure. A managed EU PaaS handles container orchestration, TLS termination, persistent volume management, and availability — the operational work that makes teams reach for Cognito by default. [sota.io](https://sota.io) is EU-native PaaS (Germany-hosted, no US parent company, no CLOUD Act jurisdiction) built for exactly this use case. Deploying Keycloak or Authentik on sota.io takes the same operational work as configuring a Cognito User Pool, with full control over where your customer identity data lives. The architecture: deploy your CIAM service on sota.io with a managed PostgreSQL backend, configure your application to use the EU-hosted OIDC endpoint instead of the Cognito User Pool endpoint, and add custom domain routing. Authentication data stays in the EU. Device fingerprints stay in the EU. Behavioural risk scoring — if you implement it — stays in the EU. CLOUD Act jurisdiction does not apply. --- ## Decision Framework: When to Migrate from Cognito **Migrate now if:** - Your application handles health, financial, or other Art.9-adjacent data and uses Cognito custom attributes - You have conducted a Schrems II transfer impact assessment and cannot achieve adequacy for Cognito - A customer or enterprise prospect has contractually required EU data residency for authentication data - You have Art.35 DPIA obligations and cannot document adequate safeguards for Cognito **Assess carefully if:** - You have fewer than 10,000 users and low-risk data — migration cost may exceed near-term compliance risk - You are mid-development and can architect around CIAM abstraction from the start - Your application already abstracts the auth layer (auth service interface) — migration will be a backend swap **Cognito remains acceptable if:** - Your users are outside the EU and GDPR does not apply - You are a US-market-only company with no European customers --- ## Summary AWS Cognito processes your entire customer identity layer — registration records, authentication events, device fingerprints, behavioural profiles — on US-controlled infrastructure subject to the CLOUD Act. A single government order yields a complete export of your customer base and their authentication history without your knowledge or your customers' notification rights. The GDPR compliance gaps compound: Art.6 legal basis for Cognito's attribute collection frequently exceeds the consent scope of registration flows; Art.17 erasure workflows must extend beyond User Pool deletion to cover CloudTrail logs; Art.13/14 privacy notices must name Amazon as processor of authentication data; Art.35 DPIAs are mandatory for large-scale deployments with Advanced Security features. EU-native CIAM alternatives — Keycloak, Authentik, Zitadel, Ory, FusionAuth — deliver equivalent functionality at equivalent operational cost when deployed on EU-hosted infrastructure. The migration path from Cognito is well-documented: OIDC abstraction in your application layer, User Pool export and import, and a DNS cutover. What changes is jurisdiction: your customer identity layer processes data in Europe, under European law, without CLOUD Act exposure.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing