"Put the servers in Europe and we are done." If your product lives on one continent, sure. Mine serves healthcare users on both sides of the Atlantic.
TL;DR: I work on a multi-region EU/US SSO architecture, with fallback, for a healthcare platform serving more than 25 million users. The rule that holds everything: health data stays in its region, authentication works everywhere. The pattern has a name, selective residency. Here is how to build it, and where it bites.
This article is for teams serving both the EU and the US under residency constraints: healthcare, finance, public sector.
The setup
An authentication platform for healthcare. More than 25 million users, more than 1,000 integrated sites, two regions: Europe and the United States.
Health data comes with strict residency rules. Data residency is the obligation to store and process a piece of data inside a defined geographic zone.
And yet the SSO must remain one system. SSO, single sign-on, lets you log in once and access several services.
That is the whole tension. A global service, sitting on top of data that is not allowed to move.
The wrong question: "where do we host?"
The usual reflex: pick one region and put everything there. For an international product, that question has no good answer.
The right question: what is allowed to cross?
Answer it data by data, not server by server. It is a classification exercise, not a hosting one.
Classify your data before drawing the architecture
Three piles are enough.
First pile: sensitive business data. In my case, health data. It does not cross. Ever.
Second pile: minimal identity. What you need to authenticate someone: identifier, secrets, login methods. It is small, and it is what must work everywhere.
Third pile: everything else. Logs, metrics, telemetry. That is the pile everyone forgets, and PII loves hiding in it. PII is the information that identifies a person.
The boundary does not run between servers. It runs through the user: their record stays, their identity travels.
Selective residency: the pattern the big players own up to
Look at how Slack documents its data residency. Messages and files are stored in the chosen region, Frankfurt for example. And the docs say it plainly: login requests are sent to the United States.
Content stays local, authentication is global. That is a deliberate engineering choice, not a dirty secret.
The logic is sound. Authentication is a data-poor, availability-hungry flow. A medical record is the exact opposite.
GDPR does not forbid that flow. It frames it: a transfer is still a transfer, Chapter V. Minimize what crosses, encrypt it, document it.
Fallback: one region going down must not log out the world
In a multi-region platform, authentication is the worst possible place for an outage. If one region's auth goes down, millions of people stop logging in.
Hence the cross-region fallback, for authentication only.
Three conditions make it possible. Tokens must be verifiable everywhere: public signing keys replicate without risk. The state strictly needed for login must stay minimal and available. And the fallback must never drag business data along.
The rule fits on one line: replicate keys, not records.
And a fallback that never fired does not exist. Test it as a real scenario, not as a checkbox in a document.
The traps that only show up in production
First trap: knowing which region a user belongs to. The question looks trivial. It decides routing, latency and compliance. Answer it with an explicit rule: by organization, by site, or by a choice at signup. Never by fragile inference.
Second trap: redirect latency. An OIDC login chains several round trips between services. Put the entry point close to the user, or the most basic login becomes painful.
Third trap: asynchronous processing. A global worker reading a regional database performs a transfer nobody signed off on. Jobs have a region, just like data.
Last trap: humans. A support agent opening an account from the other region moves data across a border. Admin tools have a residency too.
The horizon: healthcare identity becomes public infrastructure
Europe is standardizing exactly this ground. The EHDS, the European Health Data Space, entered into force in March 2025. Its obligations apply in stages from 2027.
The European identity wallet, the EUDI wallet, must be offered by every Member State by late 2026. Healthcare will get dedicated attestations for its professionals.
Translation for your backend: cross-border healthcare identity will not stay a private hack. Build your SSO to talk to these building blocks, not against them.
The checklist before your multi-region architecture
Before drawing a single diagram, walk through these questions.
- [ ] Classify every piece of data: strictly regional, mobile identity, or telemetry to audit
- [ ] Write the exact list of what crosses regions, and why
- [ ] Check that PII does not leak through global logs and metrics
- [ ] Make tokens verifiable everywhere: replicate keys, not records
- [ ] Build the auth-only cross-region fallback, and test it as a real scenario
- [ ] Give every user and every async job an explicit region
- [ ] Treat admin and support tools as cross-border flows
What to remember
A multi-region SSO fits in one sentence: data stays, auth travels.
The rest is discipline. Data classification, minimizing what crosses, a tested fallback, and suspicion for the invisible flows: logs, jobs, admin.
European standards push in the same direction. You might as well build with the current.
Need to make an SSO hold on top of residency constraints? Let's talk.
Sources: Slack, what data residency covers · GDPR, Chapter V, transfers (EUR-Lex) · Regulation (EU) 2025/327, European Health Data Space (EHDS) · Regulation (EU) 2024/1183, European Digital Identity framework (EUDI wallet)
Top comments (0)