Why most CIAM and B2B platforms fail at data residency, and what Ory does differently

Global companies face a straightforward but painful compliance problem: regulations require user data to stay within specific geographic boundaries, but users move, teams make mistakes, and rigid identity architectures make fixing either situation nearly impossible.

Ory Network solves this with per-identity data homing, which is the ability to easily move an individual user's personal data to a different region, without deleting and recreating their account.

Note: Data residency, localization, sovereignty, domiciling, and homing are related but not identical concepts. Data localization usually refers to legal or contractual requirements that certain data remain within a specific jurisdiction. Data residency describes where that data is stored and processed. Data sovereignty adds the question of which jurisdiction’s laws govern the data. Data domiciling and homing are emerging industry terms for where data is permanently based.

In this article, data homing refers to the region where an individual identity’s personal data lives inside Ory Network. Re-homing means moving that identity’s personal data from one supported region to another without deleting and recreating the account.

Compliance pressure continues to grow and evolve

The regulatory map for user data keeps getting more complex. GDPR, Brazil’s LGPD, Japan’s APPI, India’s DPDP Act, China’s PIPL, and enterprise contract requirements all create pressure to control where personal data is stored, processed, and governed.

For CIAM platforms, which sit directly in the path of user personal data, this creates an architectural question: can your identity system put specific users’ data in specific regions, and keep it there?

For most vendors, the answer is no.

Why most CIAM vendors struggle with data residency

The typical approach to multi-region identity is to run completely separate deployments: one instance in the US, one in the EU, perhaps one in Asia. Each is siloed. Each has its own configuration, its own user base, its own management surface.

This architecture creates several problems that most enterprises underestimate until they hit them:

• Data duplication and drift: When a user exists in two regions whether from a VPN-caused misassignment or a legitimate relocation. You now have two records to keep in sync. Most vendors have no mechanism to reconcile them.
• No migration path: If a user moves from the United States to Germany, the only option with a siloed vendor is to delete the account in the US instance and recreate it in the EU instance. Any history, preferences, or linked data is lost.
• Operational overhead: Separate deployments mean separate configuration, separate monitoring, separate access controls. Compliance audits become more painful with every region you add.
• No per-identity control: The entire user base is tied to a region at the project level. Generally, you cannot move one user without moving all users which is not an option in production, or if you can use one user, it requires multiple tenants in different regions. This is no longer a per-identity control but a multiple tenant architecture.

The underlying cause is architectural. These vendors built single-region systems first and bolted on regional deployments as an afterthought. The isolation that makes the deployments "separate" for compliance purposes is the same isolation that makes per-user data portability impossible.

How Ory approaches data residency differently

Ory Network was built as a multi-region platform from the start. Enterprise-tier projects can be homed in a super-region, making multiple geographic regions available within a single project. That single project can serve users across regions while still allowing each identity’s personal data to live in the appropriate place.

This is where Ory’s data homing model differs from traditional CIAM architectures. Instead of treating data residency as a static project-level setting, Ory treats the data home as a property of the individual identity. Each identity has a specific region where its personal data resides, and that region can be changed when business, regulatory, or user circumstances change.

Because the architecture is unified rather than siloed, re-homing an identity does not require duplicating records, deleting and recreating the account, or moving every other user in the project. The change is scoped to the individual identity.

Today, Ory Network supports the following data regions:

• European Union (GDPR-compliant)
• Japan
• United States (East)
• United States (West)

The available regions for a given identity depend on the super-region your project is homed in. Single-region projects are not affected. The selector is read-only for those projects, which keeps the experience clean for teams that do not need per-identity control.

Data region control in the Ory Console

Ory Network exposes data homing directly in the console. On the identity details page, a data region selector sits above the organization field. Selecting a new region shows the current and target region, then asks for confirmation before the re-homing process begins.

The change is scoped to the individual identity. Other users in the project are unaffected. The re-homing process moves the personal data associated with that identity which means no account deletion, no data loss, and no downstream disruption.

Built for enterprise global deployments

Per-identity data homing requires a multi-region project and is available on the Enterprise tier of Ory Network. The Console is the most direct way to re-home an identity. You can also set or update an identity's data region programmatically via the Ory REST API, through the create, patch, and update identity operations — as well as through B2B SSO JIT and SCIM provisioning using data mapping with Jsonnet. This makes data region management automatable at scale, not just a manual admin operation.

Note: The data region selector is read-only for single-region projects. To access per-identity data homing, your project must be homed in a super-region (US or Global) on the Enterprise tier.

Examples of where this matters in practice

A user relocates to a regulated jurisdiction

A customer who signed up while living in the United States moves to Germany. Under GDPR, their personal data must now be processed in compliance with EU law, and storing it in a US data center may no longer be appropriate. Rather than deleting and recreating the account, an administrator can re-home the identity to the EU region in a few clicks. The user's history, credentials, and linked data follow.

A VPN creates a misassignment

A user in Japan connects through a US VPN when they first register. Their identity is homed in a US region. Your compliance team flags the mismatch. Correcting it used to mean opening a support ticket with your identity vendor and hoping they had a migration path. With Ory Network, you find the identity in the console and re-home it to Japan.

A customer invokes their right to data localization

Enterprise customers increasingly ask where their user data lives. Some contracts now require that data for customers in specific jurisdictions be stored in those jurisdictions. Per-identity data homing lets you satisfy those requirements granularly, without restructuring your entire deployment.

Data residency is a product decision, not just a compliance checkbox

Most identity vendors treat data residency as a deployment configuration where you choose a region when you set up the project, and that is that. That model works for companies with a single, stable user geography. It breaks down the moment your users span borders, regulations change, or individual circumstances require individual handling.

Ory's approach treats data residency as a first-class property of each identity, not a static setting for the project. That distinction changes what compliance looks like in practice, from a one-time configuration decision to an ongoing operational capability your team can actually exercise.

If you are running a global CIAM deployment or planning one, reach out to the Ory team to discuss your data residency requirements and whether Ory is the right fit.