Selective data residency leaves authentication outside the region

At a glance

What this is: This analysis explains why selective data residency is becoming the default SaaS pattern and shows that authentication is increasingly treated as a global control-plane exception.

Why it matters: IAM teams now have to govern identity flows as part of residency design, because cross-border authentication can be acceptable for some programmes but a blocker for regulated or sovereignty-bound environments.

By the numbers:

• OpenAI expanded EU residency to include in-region GPU inference for Europe in an update published January 16, 2026.
• Slack’s data residency model dates back to December 2019, showing that selective residency is not a new pattern.
• GitHub’s EU data residency launch in October 2024 reflects the same split between local content and global control-plane operations.

👉 Read WorkOS’s analysis of selective data residency and authentication routing

Context

Selective data residency is the practice of keeping some data and processing in-region while allowing control-plane functions such as authentication to route elsewhere. In this article, the primary issue is not storage alone but how identity, inference, and application control are being separated to balance compliance, cost, and operational reality in enterprise SaaS.

That matters for identity governance because authentication is no longer just a login concern. It is part of a residency decision, which means IAM, SSO, and federation design now affect whether a platform can meet regional constraints without duplicating its entire control plane.

For teams evaluating SaaS, the question has shifted from whether a vendor supports residency to which parts of the identity and processing stack actually remain local. The split can be workable, but only when the exception is explicit and aligned to the organisation’s risk posture.

Key questions

Q: How should security teams evaluate SaaS residency claims when authentication crosses borders?

A: Security teams should separate storage claims from identity-path claims. Ask where login, SSO, session, and directory sync traffic terminate, then decide whether those flows are acceptable for the data classification in question. If authentication crosses borders, the residency posture is partial, not absolute, and that may be fine only for programmes that explicitly allow it.

Q: Why do residency programmes often exempt authentication and control-plane functions?

A: They are usually exempted because they are low-volume, operationally central, and difficult to regionalise without duplicating identity infrastructure. The trade-off is convenience versus sovereignty. If the business accepts global control-plane routing, the exception should be explicit, documented, and reviewed against regulatory and contractual obligations.

Q: What do teams get wrong about data residency in AI-enabled SaaS?

A: Many teams focus only on stored data and miss where inference happens. In AI systems, prompts and responses can be as sensitive as content at rest, so residency reviews must include compute locality. If inference is global, the application may still create a cross-border exposure even when the database is local.

Q: When is a split residency model not acceptable for identity governance?

A: It is not acceptable when the organisation cannot tolerate cross-border identity traffic, such as in some public-sector, defence, or tightly regulated financial contexts. In those cases, even a small authentication exception can undermine the residency commitment. The decision is less about technical elegance and more about whether the control-plane exception matches the risk posture.

Technical breakdown

Selective data residency splits content, processing, and control planes

Modern SaaS architectures increasingly separate customer content from the systems that process and control it. The content plane holds messages, prompts, files, and other user-generated material. The processing plane runs searches, inference, and similar compute-intensive tasks. The control plane covers authentication, billing, telemetry, and identity metadata. This split lets vendors keep sensitive workloads local while centralising low-volume operations that are harder to regionalise. The architectural trade-off is that residency no longer means one simple yes or no answer. Practitioners need to ask which plane is local, which is global, and where identity data sits in that model.

Practical implication: map each SaaS control to a residency plane before approving it for regulated or sovereignty-sensitive use.

Why authentication is often carved out of residency guarantees

Authentication is frequently treated as an exception because it is operationally central and relatively low in volume compared with application content. Identity flows depend on SAML, OAuth, session handling, and third-party directory integrations that are expensive to duplicate region by region. That makes global routing attractive for reliability and supportability. The risk is that personal identity data, timestamps, and session artefacts may cross borders even when the underlying content does not. In practice, residency claims can be technically true while still leaving a non-trivial cross-border identity path in place.

Practical implication: validate where login, SSO, and session traffic terminate, not just where files or prompts are stored.

AI inference in-region changes the residency discussion

For AI products, residency now extends beyond storage into model execution. Keeping prompts and responses in-region matters because inference itself can expose sensitive context, not just the stored input. OpenAI’s move to in-region GPU inference for Europe reflects a broader architectural shift: processing is becoming part of the residency boundary. That complicates older assumptions that only resting data needs location control. It also means residency reviews now need to cover compute locality, not just database geography, because inference can be as sensitive as storage in practice.

Practical implication: include inference locality in procurement and data protection reviews for AI-enabled SaaS.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Selective residency is really a control-plane exception model, not a full sovereignty model. Vendors are no longer promising that every byte stays local. They are promising that customer content stays in-region while identity, routing, and support functions may travel globally. That makes the real governance question whether the organisation accepts a split boundary or needs a stricter one. Practitioners should treat the exception as a formal design choice, not a vague implementation detail.

Authentication has become the most politically sensitive low-volume data flow in SaaS residency design. It is low-frequency compared with content traffic, but it carries trust, identity, and compliance significance that basic volume-based reasoning can miss. This is why residency reviews increasingly intersect with IAM, federation, and cross-border transfer assessments. The implication is that identity teams now influence market access, not just access control.

Selective residency validates a pragmatic middle path, but it also exposes where governance assumptions were too binary. The old model assumed either full localisation or full global operation. That assumption breaks when content, inference, and control-plane functions are separated. For identity programmes, the lesson is to stop asking whether residency is supported and start asking which identity functions are exempted and why.

Cross-border authentication creates a named governance pattern: residency split trust. This is the point where organisations trust local content handling but accept a global identity path because the control plane is operationally harder to localise. The concept matters because it changes how programmes document exceptions, risk acceptances, and regulatory posture. Teams should make that split explicit in policy and architecture reviews.

Identity governance, not just data governance, now determines whether selective residency is usable. If SSO, session control, and directory integrations cannot be explained clearly, the residency claim is incomplete. That pushes IAM teams into architecture review earlier than before. Practitioners should expect residency decisions to appear in security architecture, legal review, and identity design at the same time.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many identity exceptions are still being governed without end-to-end observability.
• Selective residency only works when the control plane is documented, which is why 52 NHI Breaches Analysis is useful for understanding how hidden identity paths expand attack surface.

What this signals

Residency programmes are becoming identity programmes by another name. If SSO, federation, and session handling are not included in the policy boundary, the organisation is only governing data storage and missing the actual trust path. Teams should expect more legal, privacy, and architecture questions to land in IAM reviews as vendors formalise split residency models.

Cross-border identity handling creates a measurable governance gap, especially when visibility is weak. Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs. If that is the baseline for machine identities, it is unlikely that most teams can confidently explain every control-plane route involved in residency decisions.

Documentation now matters as much as topology. A selective residency model is only defensible when the exception list is precise, current, and owned by both identity and privacy stakeholders. For teams using external identity services, the practical next step is to align access governance with regional data obligations before the first audit question arrives.

For practitioners

• Inventory identity flows alongside data flows Document where SSO, session handling, directory sync, and federation requests terminate for each SaaS application. Compare those paths against the region where content is stored so you can see whether the residency claim is actually local or only partly local.
• Classify residency exceptions by control-plane function Separate authentication, telemetry, billing, and support operations into distinct exception categories. That lets security, privacy, and legal teams review the same service with a shared understanding of which identity operations cross borders and why.
• Add compute locality to AI procurement reviews For AI-enabled platforms, ask where inference occurs as well as where prompts are stored. If the model executes outside the target region, the residency posture is incomplete even when the storage layer is local.
• Set a separate approval path for sovereignty-bound deployments Use a stricter review for government, defense, and highly regulated financial use cases that cannot tolerate cross-border identity traffic. In those cases, require evidence of local control-plane handling or a documented alternative deployment model.

Key takeaways

• Selective data residency is no longer a storage-only question. It now includes where identity, inference, and control-plane functions are allowed to operate.
• Authentication is increasingly treated as an acceptable global exception, but that decision changes the governance burden for IAM, privacy, and compliance teams.
• Practitioners should evaluate residency claims by control plane, not by marketing label, because the real risk sits in the identity path.

Key terms

• Selective Data Residency: Selective data residency is an architecture pattern where an organisation keeps some customer content and processing in a chosen region while allowing other service functions to operate elsewhere. The split is usually applied to reduce compliance friction without duplicating the entire platform. In identity-heavy systems, the key question is which control-plane functions remain global.
• Control Plane: The control plane is the part of a service that manages identities, sessions, configuration, telemetry, and operational coordination. It does not usually contain the user content itself, but it decides how the service behaves. For residency decisions, the control plane often becomes the exception path that crosses borders.
• Authentication Routing: Authentication routing is the path an identity request takes when a user signs in, renews a session, or completes federation. It matters because login data can cross regions even when content does not. In a residency model, routing is an identity governance issue as much as a technical one.
• Inference Locality: Inference locality means the model execution that produces AI output happens in the same region as the protected data. It goes beyond storage because the compute step itself can process sensitive prompts and responses. For AI-enabled SaaS, inference locality is now part of the residency boundary.

Deepen your knowledge

Selective data residency and cross-border authentication are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is reviewing SaaS residency claims or identity paths, it is a relevant starting point.

This post draws on content published by WorkOS: Why authentication doesn't need to stay local: the new data residency pattern. Read the original.