sota.io
2026-05-01·14 min read·
AWS IAM Identity Centre (formerly AWS SSO) is Amazon's managed single sign-on service that bridges your AWS multi-account organisation with external applications. Employees log in once and gain access to AWS Management Console accounts, SAML 2.0 business applications (Microsoft 365, Salesforce, Slack, Okta-connected apps), and OIDC-compatible services — all through a single authentication hub. For European organisations managing dozens of AWS accounts or needing centralised access control across cloud applications, IAM Identity Centre looks operationally ideal: centralised access management, automatic SCIM provisioning, built-in MFA, and deep integration with AWS Organizations. The GDPR problem is structural. AWS IAM Identity Centre is not peripheral infrastructure — it is the federation hub through which every user authentication event for every connected application must pass. Everything that flows through that hub is logged on US-controlled infrastructure and is reachable under the US CLOUD Act. This post analyses what AWS IAM Identity Centre holds, why the CLOUD Act scope is broader than most controllers realise, and what EU-native SSO alternatives provide equivalent federation without routing enterprise authentication through US-controlled infrastructure. --- ## What AWS IAM Identity Centre Actually Processes AWS IAM Identity Centre is positioned as a convenience layer, but it is an active processor of substantial personal data. **Identity store data (built-in or synced):** IAM Identity Centre includes an integrated identity store. When organisations use the built-in store rather than federating with an external IdP, all user and group data is held directly by AWS: - User objects: username, email address, first name, last name, display name - Group objects: group names and complete membership lists - SCIM-provisioned attributes: department, title, manager, employee number, locale, phone numbers, addresses - Custom SCIM attributes: organisations commonly sync HR attributes beyond the standard SCIM schema, including cost centre codes, contract types, and organisational tier **SAML assertion content:** When IAM Identity Centre acts as an IdP for SAML-connected applications, it processes the assertion attributes sent to the service provider. These assertions may include: - `NameID`: typically the user's email address or employee identifier - `groups`: group memberships passed to the application for role mapping - Custom attribute mappings: HR system attributes propagated into application permissions, including manager chain, department, team affiliation, and project assignments - Session duration: how long the federated session is valid — revealing working hours patterns **Permission set assignments:** IAM Identity Centre maps users and groups to permission sets, which correspond to IAM roles in specific AWS accounts. This mapping reveals: - Which employees have access to which AWS accounts (production, staging, data, security) - What IAM role — and therefore what cloud permissions — each employee holds - When access was granted and by whom (via CloudTrail) - Which accounts an employee accessed and when (authentication events per account per role) **Access logs (CloudTrail + Identity Centre logs):** Every AWS console sign-in, every SAML federation to an external application, and every permission set use is logged. IAM Identity Centre emits events including: - `UserAuthentication`: timestamp, user identity, source IP, user agent, authentication result - `Federate`: when IAM Identity Centre issues a SAML assertion to an external application - `CreateAccountAssignment` / `DeleteAccountAssignment`: access grant and revocation events - SCIM provisioning events: user/group create, update, delete from the external IdP --- ## GDPR Vector 1 — The Federation Hub: All Application Authentication Through US Infrastructure The defining GDPR risk of AWS IAM Identity Centre is its role as a federation hub. Unlike a directory service that holds identity data but delegates authentication to applications, IAM Identity Centre sits in-path on every authentication event. **The hub architecture creates universal surveillance:** When IAM Identity Centre is configured as the SSO provider for an organisation's SaaS portfolio — Microsoft 365, Salesforce, Slack, Jira, GitHub Enterprise, Okta — every login to every application generates a log entry in AWS CloudTrail. A user who logs into Slack via SSO does not just generate a Slack log entry: they also generate an IAM Identity Centre `Federate` event logged in AWS. This means the complete application access behaviour of every employee — what applications they use, at what times, how frequently — is captured in a single US-controlled service. The CLOUD Act scope covers all of this: not just the identity record, but the complete time-series behavioural log of enterprise application usage. **The blast radius of a single CLOUD Act order:** A CLOUD Act order directed at Amazon Web Services for an IAM Identity Centre tenant can yield: 1. All user and group objects in the identity store 2. All SCIM-provisioned HR attributes associated with each user 3. Complete authentication logs for every AWS console login over the retention period 4. Complete federation logs for every SAML application login 5. Permission set assignments revealing the entire access topology 6. Temporal access patterns revealing who worked when, from where, using which applications This is the fullest possible picture of enterprise behaviour — more comprehensive than email metadata, more revealing than HR records alone. The authentication hub is the highest-value surveillance target in the enterprise stack, and placing it in US-controlled infrastructure transfers this surveillance potential to US jurisdiction. --- ## GDPR Vector 2 — Permission Sets as Corporate Power Structure AWS IAM Identity Centre's permission sets do not merely control cloud access — they encode the power structure of the organisation. **What permission sets reveal:** Permission sets map to IAM roles with specific AWS service access rights. An organisation's permission set architecture reveals: - **Administrative access levels**: which employees have `AdministratorAccess` (full account control) versus read-only access versus no access - **Production access**: which employees can access production AWS accounts containing customer data - **Security access**: which employees have access to security tooling, GuardDuty findings, CloudTrail logs, Secrets Manager - **Data access**: which employees have access to S3 buckets, RDS databases, and data pipelines - **Financial visibility**: which employees have access to billing and cost management tools This mapping reveals organisational hierarchy, role sensitivity classification, and staffing patterns. New permission set assignments reveal hiring; deleted assignments reveal terminations or role changes. The timing of permission set grants and revocations can reveal organisational restructuring before it is publicly disclosed. **Art.4(1) personal data scope:** Permission set assignment data is personal data under GDPR Art.4(1) because it is information relating to an identified natural person (the employee). The access topology — which individual has which access level to which production system — is employee-specific and therefore personal data. This data, in aggregate, constitutes a comprehensive profile of individual authority and responsibility within the organisation. A CLOUD Act order yielding permission set assignments for all users provides not just a list of employees but a ranked organisational chart by access privilege — mapping who the organisation considers trusted, skilled, and authorised to act on its most sensitive infrastructure. --- ## GDPR Vector 3 — Art.9 Data in SAML Assertions and SCIM Attributes Article 9 GDPR restricts processing of special category data. AWS IAM Identity Centre processes Art.9-adjacent data through two mechanisms: SCIM provisioning and SAML assertion attribute mapping. **SCIM provisioning of HR attributes:** When organisations federate IAM Identity Centre with an external IdP (Azure AD, Okta, Google Workspace) and enable SCIM provisioning, HR attributes flow from the IdP into the AWS identity store. The SCIM schema supports `department`, `title`, `manager`, `employeeNumber`, `costCenter` — but many HR systems extend this with custom attributes that are not neutral. Common examples: - Accessibility accommodation flags (screen reader requirements, ergonomic equipment flags) — health data under Art.9(1) - Work restriction attributes for occupational health reasons — health data under Art.9(1) - Union representative role flags — union membership under Art.9(1) - Religious holiday calendar preferences — religious/philosophical beliefs under Art.9(1) - Pregnancy leave status codes — health data under Art.9(1) Once these attributes are in the SCIM sync scope, they are written to and stored in the AWS-managed identity store and are processed by IAM Identity Centre on every authentication event. **SAML assertion attribute mapping:** When IAM Identity Centre acts as an IdP for downstream SAML applications, it maps identity store attributes to SAML assertion attributes. If HR attributes containing Art.9 data are in the identity store, they may be included in assertions sent to SAML applications — transiting through AWS's federation infrastructure on every login. The assertion is logged in CloudTrail as part of the `Federate` event, meaning Art.9 data is potentially written to authentication logs. --- ## GDPR Vector 4 — CLOUD Act SSO Log Completeness: Structured Surveillance Standard AWS CloudTrail logging for IAM Identity Centre creates a structured, complete record of enterprise application usage. Unlike ad hoc monitoring, this is systematic, automated, and covers all users in the IAM Identity Centre tenant. **The authentication log content:** Each IAM Identity Centre authentication event includes: - `eventTime`: exact timestamp of the authentication - `userIdentity`: the user's identifier in the identity store - `sourceIPAddress`: the IP address from which the user authenticated - `userAgent`: browser and OS fingerprint - `requestParameters.applicationArn`: which application the user was accessing - `requestParameters.instanceArn`: which IAM Identity Centre instance (maps to the organisation) - `responseElements`: whether the authentication succeeded or failed **Why this constitutes surveillance:** The combination of user identity + timestamp + source IP + application creates a complete behavioural record. From these logs, it is possible to derive: - Working hours patterns (when each employee starts and ends work) - Remote working behaviour (whether source IPs are home networks or office subnets) - Application usage patterns (which tools each employee uses most) - Authentication anomalies (logins from unusual locations — potential security incidents or personal travel) - Attendance patterns (absent days visible as authentication gaps) This is behavioural monitoring of employees — data that Art.88 GDPR identifies as requiring special care and that national implementing laws (notably Germany's §26 BDSG) regulate strictly. Placing this monitoring data in US-controlled infrastructure means it is subject to CLOUD Act disclosure without notice to the monitored employees or their employer. --- ## GDPR Vector 5 — Art.28 Processor Chain: The External IdP Sub-Processor Web Many organisations federate IAM Identity Centre with an external corporate IdP rather than using the built-in identity store. This creates a layered processor chain that multiplies CLOUD Act exposure. **Typical enterprise federation chain:** 1. **HR system** (Workday, SAP SuccessFactors) → pushes employee data to 2. **External IdP** (Azure AD / Entra ID, Google Workspace, Okta) → federates via SAML/OIDC to 3. **AWS IAM Identity Centre** → issues SAML assertions to 4. **SAML applications** (Salesforce, Slack, GitHub Enterprise, etc.) In this chain: - Azure AD is a Microsoft service (US parent company, CLOUD Act jurisdiction) - Google Workspace is a Google service (US parent company, CLOUD Act jurisdiction) - Okta is a US company (CLOUD Act jurisdiction) - AWS IAM Identity Centre is an Amazon service (CLOUD Act jurisdiction) For organisations using Azure AD federated to IAM Identity Centre: the CLOUD Act jurisdiction applies at step 2 (Entra ID) and step 3 (IAM Identity Centre) — double CLOUD Act exposure before the assertion even reaches the target application. **Art.28 documentation obligation:** Under Art.28 GDPR, the data controller must have a Data Processing Agreement with each processor in the chain. The controller must document all sub-processors. The IAM Identity Centre DPA references AWS's sub-processors — but the Art.28(2) obligation requires the controller to actually authorise this sub-processor chain. Few DPOs maintain a complete, current sub-processor map for an SSO federation chain spanning four US cloud providers. --- ## GDPR Vector 6 — Art.13/14 Transparency: The Invisible Authentication Hub Article 13 requires informing data subjects about processing at the point of collection. Article 14 requires informing data subjects about processing of data not directly collected from them. AWS IAM Identity Centre creates systematic Art.13/14 gaps. **The transparency gap at login:** When an employee clicks "Sign in with SSO" to access their project management tool, they are not informed that: 1. Their authentication is being processed by Amazon Web Services 2. A log entry is being created in AWS CloudTrail 3. Their source IP, browser fingerprint, and timestamp are being retained in a US-controlled system 4. This log entry may be accessible to the US government under the CLOUD Act without prior notice to the employee or employer Employee privacy notices typically describe that access to systems is managed and monitored by IT — but they do not specify that the authentication infrastructure processing this data is Amazon Web Services operating in US jurisdiction. **The SCIM provisioning disclosure gap:** When IAM Identity Centre is synced with an external IdP via SCIM, employees are not notified that their HR attributes are being replicated into Amazon's identity store. The SCIM sync is an automated background process — there is no visible disclosure event that would trigger Art.13 compliance. **Art.35 DPIA obligation:** Systematic monitoring of employee behaviour in the workplace may trigger the Art.35 DPIA requirement under the "systematic monitoring" criterion in Art.35(3)(c). If authentication logs constitute systematic monitoring — which the German DPA (BfDI) and the French CNIL have indicated they may — then deploying AWS IAM Identity Centre requires a DPIA before deployment. The DPIA must assess the CLOUD Act risk, and controllers cannot document adequate mitigation while using a US cloud provider for their authentication hub. --- ## EU-Native Alternatives to AWS IAM Identity Centre European organisations need SSO federation that handles SAML, OIDC, multi-account access control, and SCIM provisioning — without routing every enterprise authentication event through US infrastructure. ### Keycloak — Enterprise SSO and Identity Broker [Keycloak](https://www.keycloak.org/) is the most mature open-source identity and access management platform, supporting SAML 2.0, OpenID Connect, OAuth 2.0, LDAP, and Kerberos. Maintained by Red Hat and the CNCF community, it provides: - Identity brokering: federate with upstream IdPs (LDAP, SAML, OIDC) and issue SAML/OIDC assertions to downstream applications - Role mapping: RBAC with composite roles, group-to-role mappings, and fine-grained permission policies - SCIM support: via extensions and SCIM 2.0 compatibility layer - Admin console: web UI for user management, client configuration, and session management Deployed on EU infrastructure (Hetzner, OVHcloud, Ionos), Keycloak provides CLOUD-Act-free SSO federation with full protocol compatibility. The authentication hub is under the controller's control, on the controller's infrastructure, in EU jurisdiction. **Strengths:** Largest community, extensive protocol support, mature enterprise features. Multiple EU-based managed Keycloak providers (cloud-iam.com, phase two). Active Red Hat support path. **Considerations:** Higher operational complexity than a managed service. Requires PostgreSQL, infra maintenance, and Keycloak version upgrades. **Best for:** Enterprises needing full enterprise SSO capabilities with the broadest protocol support and the most active community. ### Authentik — Self-Hosted Identity Provider with Proxy Support [Authentik](https://goauthentik.io/) is an open-source identity provider built in Germany, self-hostable on any EU infrastructure. It supports SAML 2.0, OIDC, OAuth 2.0, LDAP outpost, SCIM, and forward authentication (proxy auth for Nginx/Traefik/Caddy). **Distinguishing features for IAM Identity Centre replacement:** - **SCIM 2.0 server**: acts as a SCIM endpoint for HR system provisioning — equivalent to IAM Identity Centre's SCIM sync - **Outpost architecture**: deploy authentication proxies close to the applications being protected - **Application portal**: customisable user-facing application launcher — equivalent to IAM Identity Centre's user portal - **Group-based access control**: map groups to application access and SAML/OIDC attribute claims - **Policy engine**: expression-based access policies supporting time-of-day, IP range, and MFA enforcement **Strengths:** German-founded, GDPR-native design philosophy, active community, user-friendly admin UI. Forward auth support covers applications that do not natively support SAML/OIDC. **Considerations:** Smaller community than Keycloak. PostgreSQL + Redis required. Multi-tenant support less mature. **Best for:** Self-hosted environments needing a modern IdP with good UX and proxy authentication support for mixed application portfolios. ### Zitadel — EU-Native Cloud Identity Platform [Zitadel](https://zitadel.com/) is a Swiss-founded open-source identity infrastructure platform with OIDC, OAuth 2.0, SAML 2.0, and SCIM support. Available as a managed service hosted in EU (Switzerland, adequate country under GDPR Art.45) or self-hosted. **Strengths for SSO federation:** - Multi-tenancy built-in: manage multiple organisations within a single Zitadel instance — equivalent to IAM Identity Centre's multi-account model - SAML SP and IdP: federate upstream corporate directories and issue assertions to downstream applications - Fine-grained roles and permissions: action-based access control with custom claims and role mappings - EU company: Swiss jurisdiction, no US parent, not subject to CLOUD Act - Zero-trust architecture: machine user accounts for service-to-service authentication **Best for:** Cloud-native organisations and SaaS companies needing multi-tenant identity management with EU-native managed service option. ### Dex — OIDC Connector Hub [Dex](https://dexidp.io/) (CNCF project) is a lightweight OIDC identity broker that aggregates upstream identity providers — LDAP, SAML, GitHub, OIDC — and exposes them as a single OIDC endpoint. It is simpler than Keycloak or Authentik, optimised for Kubernetes-native environments and microservice authentication. **Strengths:** Minimal footprint, CNCF-governed, strong Kubernetes integration, excellent for service mesh authentication scenarios. **Considerations:** Limited admin UI, no SAML SP support, not suitable as a full enterprise SSO replacement without additional components. **Best for:** Cloud-native engineering organisations using Kubernetes who need OIDC federation for developer tooling and internal services. --- ## Migration Strategy: From AWS IAM Identity Centre to EU-Native SSO **Phase 1 — Inventory connected applications and permission mappings.** Export all SAML application configurations, permission set definitions, and user-group-permission assignments from IAM Identity Centre. This defines the scope of the migration and identifies which protocols each application requires. **Phase 2 — Assess the identity store source.** Determine whether your organisation uses the built-in IAM Identity Centre identity store or federates with an external IdP. If federating with Azure AD or Google Workspace, the migration may focus on repositioning the EU-hosted SSO (Keycloak/Authentik/Zitadel) as the new federation hub while maintaining the external IdP as an upstream source. **Phase 3 — Deploy EU-hosted SSO.** Provision Keycloak or Authentik on EU infrastructure. Configure SAML 2.0 and OIDC clients for each application currently connected to IAM Identity Centre. Configure upstream identity federation from your existing corporate directory. **Phase 4 — Migrate application configurations.** For SAML applications, update the IdP metadata URL and certificate to point to the EU-hosted SSO. For OIDC applications, update the issuer URL and client credentials. AWS console access requires a different approach: configure AWS IAM to trust SAML assertions from your EU-hosted Keycloak/Authentik as an external IdP. **Phase 5 — Migrate AWS multi-account access.** For IAM Identity Centre's core function of granting AWS account access, replace permission sets with IAM roles that trust the EU-hosted SAML IdP. This requires creating SAML-based IAM roles in each AWS account with trust policies pointing to the EU IdP's metadata. More complex than permission sets but eliminates the US-controlled authentication hub from the AWS console access path. **Phase 6 — Update Art.28 DPAs and Art.30 records.** Document the new processor chain: controller → EU infrastructure provider → no US sub-processor for authentication. Update the Art.30 register, remove IAM Identity Centre from the processor list, and document the CLOUD Act risk elimination in the updated DPIA. --- ## The SSO Federation Paradox: Centralisation Creates Surveillance Risk AWS IAM Identity Centre's value proposition is centralisation — one place to manage all access, one log to audit all authentication, one service to rule all applications. This centralisation is also its GDPR liability. The same architectural property that makes IAM Identity Centre operationally attractive makes it a maximum-value surveillance target. A decentralised authentication architecture — separate IdPs per application silo — is operationally harder but distributes the CLOUD Act risk across multiple jurisdictions and service providers. IAM Identity Centre concentrates it. For European organisations that have built centralised SSO around IAM Identity Centre, the GDPR exposure scales with the scope of the federation: the more applications connected, the more valuable the centralised log, and the greater the CLOUD Act surveillance risk. Every new SAML application added to IAM Identity Centre increases the blast radius of a CLOUD Act order. --- ## Practical Decision Matrix | Requirement | AWS IAM Identity Centre | Keycloak | Authentik | Zitadel | Dex | |---|---|---|---|---|---| | SAML 2.0 IdP | ✅ | ✅ | ✅ | ✅ | ❌ | | OIDC IdP | ✅ | ✅ | ✅ | ✅ | ✅ | | SCIM provisioning | ✅ | ✅ Extension | ✅ | ✅ | ❌ | | Multi-account AWS access | ✅ Native | ⚠️ SAML roles | ⚠️ SAML roles | ⚠️ SAML roles | ❌ | | CLOUD Act exposure | ❌ Yes | ✅ None | ✅ None | ✅ None | ✅ None | | EU managed service | ❌ | ✅ Providers | ✅ Self-hosted | ✅ Cloud option | ✅ Self-hosted | | Application portal | ✅ | ✅ | ✅ | ✅ | ❌ | | Forward auth / proxy | ❌ | ❌ | ✅ | ❌ | ❌ | | Licensing cost | 💰 Per user | Free | Free | Free/paid | Free | --- ## Why the SSO Hub Is the Highest-Risk GDPR Decision Organisations that place a database or an application on AWS accept a bounded CLOUD Act risk — that specific data in that specific service. Organisations that place their SSO hub on AWS accept an unbounded risk: every authentication event for every application, every permission assignment, every SCIM-provisioned HR attribute, every session duration log — for every employee, indefinitely. The authentication hub is not a peripheral GDPR decision. It is the decision that determines whether every other privacy control in the stack is meaningful. Encryption at rest in your applications does not help if the authentication log proves when each employee accessed those applications. Data minimisation in your HR system does not help if SCIM sync replicates HR attributes to the AWS identity store. Art.17 erasure from your databases does not help if IAM Identity Centre retains the authentication history showing the data subject accessed those records. Placing the SSO hub in EU jurisdiction is the architectural decision that makes all other GDPR controls coherent. Without it, CLOUD Act jurisdiction over the authentication hub undermines every downstream privacy measure. [sota.io](/) provides EU-native platform infrastructure for deploying SSO services — Keycloak, Authentik, Zitadel — without routing enterprise authentication through US-controlled platform layers. Deployed on sota.io, your identity federation hub operates in EU jurisdiction, with no US parent company in the processor chain for authentication events.

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