AWS IAM Identity Center EU Alternative 2026: Identity Federation, GDPR Controller Questions, and CLOUD Act Access to Your Identity Graph

Post #793 in the sota.io EU Compliance Series

AWS IAM Identity Center — formerly AWS Single Sign-On — is the central identity hub for AWS multi-account environments. It federates your corporate identity provider, manages permission sets across AWS accounts, and logs every authentication event your developers and administrators perform across your AWS estate.

It is not in the AWS European Sovereign Cloud service catalog.

That absence matters for a specific reason: IAM Identity Center sits at the intersection of two GDPR concerns that most compliance guides treat separately. First, it processes the identity data of your employees — names, email addresses, group memberships, authentication timestamps — making it subject to the standard employee data processing obligations under GDPR. Second, and less obviously, it builds a cross-service behavioral graph by recording which user accessed which AWS service at which time across every account in your AWS organization. That graph is not just authentication metadata. It is a detailed map of your employees' professional activities that AWS can be compelled to disclose.

This guide examines the five GDPR issues that IAM Identity Center raises, explains the ESC catalog gap, and identifies the EU-sovereign alternatives that provide federated identity without US-jurisdiction exposure.

What AWS IAM Identity Center Does

AWS IAM Identity Center provides centralized access management for AWS Organizations. Instead of managing IAM users in every AWS account separately, Identity Center lets you define permission sets once and assign them to users and groups from a central identity store — either AWS's built-in directory or a connected external identity provider.

Core functionality:

• Identity federation: Connect an external IdP (Okta, Azure AD, Google Workspace, or any SAML 2.0/OIDC-compatible provider) and sync users and groups into Identity Center
• Permission sets: Define role-like bundles of AWS IAM policies that can be assigned to accounts
• Multi-account access portal: Give users a single web portal to switch between AWS accounts without separate credentials
• SCIM provisioning: Automatically sync user and group changes from the external IdP via the SCIM 2.0 protocol
• CloudTrail integration: All Identity Center authentication events, permission set assignments, and access portal sessions are logged to CloudTrail

Scale context: In a typical large organization, Identity Center processes thousands of authentication events per day — every developer console login, every CLI credential refresh, every automated service-to-service authentication. At enterprise scale, it logs tens of millions of identity events per year.

ESC status: AWS IAM Identity Center is absent from the AWS European Sovereign Cloud service catalog. Organizations running AWS in the eu-central-1 or eu-west-1 regions with IAM Identity Center are not operating that service under ESC data residency and operator access control guarantees. The federated identity layer sits outside the sovereign boundary.

GDPR Issue 1 — The Art. 4(7) Controller Question: Is AWS a Processor or a Controller for Federated Identities?

The most fundamental question that IAM Identity Center raises is one that most DPAs and DPIAs skip: when AWS processes the identity data of your employees in IAM Identity Center, does AWS act as a data processor under Art. 4(8) GDPR — following your instructions — or does it exercise independent controller discretion under Art. 4(7)?

The distinction matters enormously for your Art. 28 obligations. If AWS is purely a processor, you need a Data Processing Agreement that gives you contractual control over how your employee identity data is handled. If AWS exercises any controller functions — deciding purposes or means of processing independently — you have a joint controller situation under Art. 26, with substantially different obligations and liability allocations.

Where the line blurs for IAM Identity Center:

AWS uses Identity Center data for service operation, abuse detection, billing, and its own security monitoring. The AWS Customer Agreement and DPA assign processor status to AWS for your data, but identity data has a peculiarity: AWS needs to resolve identities to enforce its own service quotas, detect account abuse, and comply with its own legal obligations including US government requests. In those contexts, AWS is acting on the identity data for purposes you did not specify and cannot override.

The practical GDPR implication: your DPIA for IAM Identity Center should document the processor/controller boundary explicitly and acknowledge that certain AWS-initiated processing of your employee identity data falls outside your instructional control. Most organizations do not do this. Most DPIA templates for SSO solutions assume a clean processor relationship that does not fully describe how hyperscale identity infrastructure works.

Art. 26 risk: If a supervisory authority reviews your IAM Identity Center implementation and finds undocumented controller-mode processing by AWS of your employee data, you face potential Art. 26 joint controller compliance failures — documented agreements between controllers are mandatory, not optional.

GDPR Issue 2 — Art. 28: SSO as a Sub-Processor Chain You Did Not Audit

When you connect an external identity provider to IAM Identity Center, you create a processor chain that most Art. 28 compliance programs do not trace fully.

A typical enterprise setup: Azure AD (Microsoft, US) → IAM Identity Center (AWS, US) → permission sets in ten AWS accounts. Each link in this chain is a data processor relationship that requires a valid DPA. The SCIM provisioning endpoint that syncs your user directory to IAM Identity Center sends employee names, email addresses, job titles, department memberships, and group assignments from Microsoft's infrastructure to AWS's infrastructure. That sync happens continuously — every user creation, modification, and deletion propagates across.

The sub-processor audit requirement under Art. 28(2): Your DPA with the initial processor (typically your cloud vendor or HR system) must either authorize the specific sub-processors or require prior written consent for sub-processor changes. For SCIM-synced identity data flowing from an HR system through Azure AD into IAM Identity Center, you need a documented chain of DPAs.

The gap in practice: Most organizations have a DPA with Microsoft for Azure AD and a DPA with AWS for general cloud services, but they do not have explicit sub-processor authorization documented in each DPA for the SCIM sync from Microsoft to AWS. The flow of employee personal data through the SCIM provisioning pipeline crosses a controller-processor boundary that is frequently undocumented in the Art. 28 DPA chain.

Practical exposure: Under Art. 28(3)(d), your processor (Microsoft) must ensure that sub-processors (AWS) are bound by the same data protection obligations as the main processor agreement. When the IAM Identity Center SCIM endpoint receives employee data from Azure AD, the sub-processor relationship between Microsoft and AWS for that specific data flow needs to be explicitly covered — not just assumed from the general AWS DPA your organization holds separately.

GDPR Issue 3 — CLOUD Act: AWS Has Access to Every Federated Identity Event

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US law enforcement to compel US companies to produce stored data regardless of where the data physically resides. AWS is a US company. AWS stores IAM Identity Center authentication logs in CloudTrail.

What this means for your identity events: Every authentication event your employees generate through IAM Identity Center — when they logged in, what account they accessed, from what IP address, using what method, for how long — is stored in AWS-controlled infrastructure and subject to potential CLOUD Act production orders.

The intelligence value of identity event logs: Authentication metadata is not neutral technical data. A complete log of when your developers accessed specific AWS accounts and services tells an observer what your team was working on, when, at what scale, and with what permissions. For organizations handling trade secrets, M&A activity, regulated financial data, or government contracts, the intelligence value of your AWS CloudTrail logs — especially identity events — is substantial.

The ESC catalog gap: ESC-catalog services come with operator access controls that restrict AWS personnel access and provide enhanced compliance guarantees. IAM Identity Center is not in the ESC catalog. The identity event logs for your entire AWS organization are stored without ESC-level protections.

Schrems II residual risk: Post-Schrems II, transfers of personal data from EU organizations to US processors require either Standard Contractual Clauses with a Transfer Impact Assessment or another Art. 46 transfer mechanism. Your CloudTrail identity logs flow to AWS's infrastructure for IAM Identity Center. The CLOUD Act creates a "specific circumstances" risk factor that many TIAs for AWS services underestimate: US government access capability exists and has been exercised.

GDPR Issue 4 — Art. 5(1)(c): The Cross-Service Identity Graph

IAM Identity Center's logging integration goes deeper than most organizations realize. Every CloudTrail event across your entire AWS organization records the IAM Identity Center identity context — which user, from which Identity Center instance, authenticated with which permission set.

This means AWS's infrastructure contains a cross-service identity graph: for every S3 access, RDS query, Lambda invocation, and EC2 action across all your AWS accounts, there is a corresponding Identity Center identity record. At scale, this graph reveals not just authentication events but behavioral patterns: which developers access which production systems, at what hours, with what frequency, in response to what incidents.

Art. 5(1)(c) — data minimization: The cross-service identity graph that emerges from IAM Identity Center's CloudTrail integration is a byproduct of AWS's logging architecture, not a deliberate data collection choice your organization made. But GDPR data minimization applies to the totality of personal data processing — including data that accumulates as an architectural side effect. The behavioral profile that emerges from identity-linked CloudTrail logs may exceed what is necessary for your stated purposes (access control and security monitoring).

Art. 5(1)(b) — purpose limitation: Identity data collected for access control purposes (who can access what) is different from behavioral monitoring data (who accessed what when and how often). The cross-service identity graph created by linking Identity Center records to CloudTrail events across your organization represents a secondary use of identity data that goes beyond the access control purpose for which it was originally collected.

DPIA obligation: If your AWS estate is large enough that the identity behavioral graph represents systematic profiling of employees, Art. 35 DPIA requirements may be triggered — not just for your AWS deployment generally, but specifically for the cross-service identity monitoring that IAM Identity Center enables.

GDPR Issue 5 — Art. 17: The Identity Removal Challenge When Offboarding Employees

GDPR Art. 17 (right to erasure) and the related Art. 5(1)(e) storage limitation principle create a specific challenge for federated identity systems: when an employee leaves your organization, removing them from your corporate IdP does not automatically and completely erase their identity data from IAM Identity Center or the CloudTrail records linked to that identity.

The offboarding sequence problem:

1. Employee departs. HR disables their account in your HR system.
2. SCIM sync propagates the deletion to the corporate IdP (Azure AD or similar).
3. SCIM sync propagates the deletion to IAM Identity Center — the user is deprovision from the Identity Center user store.
4. But CloudTrail logs containing that user's identity context (their IAM Identity Center userId, email, and group memberships at time of access) persist in CloudTrail for the configured retention period — typically 90 days to 7 years.
5. If you used AWS Config or Security Hub with identity context, those records also persist.

The erasure gap: GDPR Art. 17 right to erasure requires that upon request (or upon loss of the legal basis for processing, e.g., employment relationship end), personal data be erased. CloudTrail logs linked to a former employee's identity are personal data under Art. 4(1) — they identify a specific individual's actions at specific times. Erasing them retroactively from CloudTrail is architecturally difficult and may conflict with security audit retention requirements under other laws (NIS2 Art. 21 incident logging, financial sector regulations, etc.).

Practical implication: Your identity governance program should document the tension between Art. 17 erasure requests from former employees and your CloudTrail retention policy. Most organizations resolve this by relying on Art. 17(3)(e) — erasure is not required when processing is necessary for establishing, exercising, or defending legal claims — but this exemption must be documented and cannot be applied reflexively to all former-employee identity data.

The ESC Catalog Gap: Why IAM Identity Center Is Missing

The AWS European Sovereign Cloud catalog lists services that AWS operates with enhanced data residency guarantees, restricted operator access, and alignment with EU regulatory requirements. IAM Identity Center is not in that catalog.

This creates a structural gap: organizations that deploy AWS in the EU, using ESC-catalog compute and storage services, still route all identity authentication through a non-ESC service. Every developer login, permission set assignment, and access portal session flows through infrastructure without ESC-level protections.

The gap is not accidental. Identity services are architecturally complex to sovereign-tier because they require tight integration with AWS's global control plane. Providing ESC-compliant IAM Identity Center would require AWS to operate a fully isolated identity control plane for EU sovereign customers — a significant infrastructure investment that AWS has not yet made.

For organizations with strict data sovereignty requirements, the practical implication is that AWS-managed identity federation is incompatible with full ESC compliance. The identity layer cannot be moved into the ESC boundary while using IAM Identity Center.

EU-Sovereign Alternatives to AWS IAM Identity Center

authentik (DE) — Best EU-Sovereign Option

Provider: Authentik Security GmbH, Germany
Deployment: Self-hosted (Kubernetes, Docker Compose) or authentik Cloud (EU-hosted)
Licensing: BSL 1.1 for cloud, AGPLv3 for self-hosted

authentik provides SAML 2.0, OIDC/OAuth 2.0, LDAP, and SCIM support. It replaces IAM Identity Center's federation capability with a self-hosted IdP you control completely — no US parent company, no hyperscale control plane dependency.

Key GDPR advantage: Deployed on EU infrastructure (Hetzner, Scaleway, or your own servers), authentik stores all identity and authentication event data on infrastructure subject to EU jurisdiction. CLOUD Act does not reach your authentication logs. You control retention, erasure, and access entirely.

AWS integration: authentik can act as an external SAML IdP for IAM Identity Center — you keep Identity Center for permission set management but move the identity store and authentication events to authentik on EU infrastructure. This hybrid approach reduces the GDPR surface significantly.

Cost: Self-hosted authentik is free (AGPLv3). authentik Cloud enterprise pricing starts around €5/user/month.

Zitadel (CH) — EU-Sovereign with Managed Option

Provider: ZITADEL (Caos AG), Switzerland
Deployment: Self-hosted or ZITADEL Cloud (EU-hosted, Swiss company)
Licensing: Apache 2.0

Zitadel provides OIDC/OAuth 2.0, SAML 2.0, and SCIM 2.0. It is the most feature-complete open-source IdP for organizations replacing Okta or similar enterprise identity services. Switzerland is not an EU member but has an EU adequacy decision under GDPR (Commission Implementing Decision 2000/518/EC, adequacy confirmed 2021 for post-Privacy Shield alignment), making Swiss-hosted data transfers lawful without SCCs.

Key differentiation: Zitadel has native multi-tenancy and multi-organization support — important for MSPs or organizations with complex B2B identity requirements. Its permission model is more granular than authentik for cross-organizational access scenarios.

AWS integration: Same hybrid approach as authentik — use Zitadel as the SAML IdP for IAM Identity Center.

Cost: Self-hosted free (Apache 2.0). ZITADEL Cloud pricing from ~€10/month for small deployments.

Keycloak — Caveats Apply

Provider: Red Hat (IBM subsidiary, US) — community project
Deployment: Self-hosted only (Red Hat does not offer Keycloak-as-a-service)
Licensing: Apache 2.0

Keycloak is the most widely deployed open-source IdP in enterprise environments. It provides SAML 2.0, OIDC, LDAP, and Kerberos support with extensive customization.

GDPR caveat: Keycloak the software is open source and EU-deployable. But Red Hat (the steward of Keycloak development) is a US company (IBM subsidiary). If you self-host Keycloak on EU infrastructure, the GDPR exposure is limited to the software supply chain — Red Hat does not have access to your identity data. This is a substantially better position than AWS IAM Identity Center, where AWS actively operates the infrastructure.

Practical recommendation: Self-hosted Keycloak on EU infrastructure (Hetzner, OVH, Scaleway) is a legitimate EU-sovereign alternative. The Red Hat parent company relationship creates a theoretical supply chain consideration but no operational data access. For organizations that need the extensive enterprise features and community support of Keycloak, it is preferable to AWS IAM Identity Center from a GDPR perspective, with the proviso that "open source from US-parent company" is different from "built and operated by EU company" — which is what authentik and Zitadel provide.

Migration Path: From IAM Identity Center to EU-Sovereign Identity

Phase 1 — Inventory: Export your IAM Identity Center permission set assignments, user group mappings, and account assignments. Identify which accounts use which permission sets and which users/groups have access.

Phase 2 — Deploy EU IdP: Stand up authentik or Zitadel on EU infrastructure. Migrate your user directory (either import from existing LDAP/AD or configure SCIM sync from your HR system to the EU IdP directly, bypassing Azure AD if possible).

Phase 3 — Federate IAM Identity Center to EU IdP: Configure IAM Identity Center to use your new EU IdP as the external SAML identity source. IAM Identity Center handles permission set management; your EU IdP handles authentication and identity storage. Authentication events now originate from EU infrastructure.

Phase 4 — Evaluate full replacement: For organizations that want to eliminate IAM Identity Center entirely, the permission set management functionality can be replaced by direct IAM role federation in each AWS account — more operational overhead but removes the IAM Identity Center dependency entirely.

Phase 5 — Audit trail migration: Decide on CloudTrail retention for historical identity events. Document the erasure approach for former-employee CloudTrail data (retention policy, legal basis, or pseudonymization approach).

Summary: IAM Identity Center GDPR Checklist

AWS IAM Identity Center solves a real operational problem — centralized multi-account access management at scale. But it does so through US-jurisdiction infrastructure that is absent from the AWS European Sovereign Cloud catalog and raises five distinct GDPR obligations that most identity governance programs do not address. The EU-sovereign alternatives — authentik and Zitadel, both built by European companies, both self-hostable on EU infrastructure — provide the core federation functionality without the US-jurisdiction identity event exposure.

sota.io helps European development teams run PaaS workloads on EU-sovereign infrastructure. See how sota.io handles identity and access management for your deployments.