Topic starter
07/06/2026 8:15 pm
TL;DR: Modern SaaS is splitting residency by plane, keeping customer content and, increasingly, inference in-region while routing authentication and other control-plane functions globally, according to WorkOS’s analysis of OpenAI, Slack, and GitHub. The trade-off is now structural: identity teams must decide which cross-border flows are tolerable and which trigger sovereignty exceptions.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Why authentication doesn't need to stay local: The new data residency pattern”.
Key questions
Q: How should security teams govern authentication when data residency is selective?
A: Security teams should govern authentication as a separate residency scope, not as an automatic extension of content locality.
Q: Why do SaaS platforms keep authentication global even when customer content stays local?
A: They do it because authentication is lower-volume, operationally central, and hard to regionalize across many identity providers and SSO configurations.
Q: What breaks when residency controls ignore control-plane traffic?
A: The residency promise becomes incomplete, because the organisation may localize content while still sending login, metadata, or session events across borders.
Practitioner guidance
- Map residency by service plane Break each SaaS dependency into content, processing, and control-plane functions, then record which of those functions are permitted to leave the region.
- Separate authentication from content review Review SSO, login, session routing, and identity metadata as a distinct residency scope instead of assuming they follow the same rule as storage.
- Classify cross-border identity flows as exceptions Document which identity events may cross borders, why they are acceptable, and which regulatory or contractual conditions apply to each exception.
Bottom line: Selective residency is replacing binary residency thinking, but it introduces a new governance burden around the control plane.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
07/06/2026 10:05 pm
Selective residency is an identity governance problem disguised as a data architecture choice. The real control question is not whether a vendor stores content in-region, but whether identity and session handling are allowed to cross borders without being treated as an exception. That matters because authentication is often the control path that defines who can reach the localized data in the first place. Practitioners should treat the residency boundary as a governance object, not a marketing label.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do buyers compare selective residency with full regional isolation?
A: Selective residency localizes the sensitive payload while allowing some identity and operational services to remain global, whereas full regional isolation tries to keep the entire service stack within one jurisdiction. The right choice depends on regulatory expectations, risk tolerance, and whether cross-border identity processing is acceptable.
👉 Read our full editorial: Selective data residency leaves authentication outside the region
This post was modified 4 days ago by NHI Mgmt Group