Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
Hello Descopers! Descope projects can now be created in three additional regions: Singapore, Brazil, and the United Kingdom. They join the United States, European Union, Canada, and Australia, bringing multi-region data residency to seven regions across four continents.
Data residency impacts organizations of all sizes. For a team selling upmarket to enterprises, it arrives as a line on the enterprise buyer's security questionnaire, with the answer deciding whether the evaluation moves forward. For a company that already serves customers worldwide, it arrives from its own regulators, each with a view on where the records of their residents belong. In both cases the question has been getting harder to answer well, because buyers and regulators have started asking follow-ups about who operates the infrastructure and which jurisdiction governs it.
This post covers why the identity layer attracts residency scrutiny, Descope’s list of supported regions, and how to structure an application that serves users in several regions at once.
Why residency questions land hardest on the identity layer
The identity store holds the densest collection of personal data in a typical application. Email addresses, phone numbers, names, authentication factors, session records, and audit logs all sit in one place, tied to a real person by design. A security reviewer who is triaging where to focus tends to arrive there quickly.
This creates a gap that is easy to miss: while residency is scoped to an application’s own database, the identity provider is a second store of the same people’s personal data that isn’t scoped. If an application stores its primary customer content in-region while authentication runs through infrastructure somewhere else, the residency claim stays technically accurate, but the user directory, the personal data attached to each account, and the audit trail still cross borders on every login. Teams discover this during a customer's security review rather than during architecture planning, which is a difficult time to discover it.
Data residency questions are also sharpening. In April 2026, the European Commission awarded sovereign cloud contracts worth up to EUR 180 million using a Cloud Sovereignty Framework that scores providers on Sovereignty Effectiveness Assurance Levels. The lower levels ask where data is processed, while the higher levels ask about supply chain independence and control by parties outside the EU. The Commission has invited all organizations to adopt the same method, which means storage location is becoming the opening question in a longer conversation.
Descope’s supported data residency regions
Descope supports the following regions:
Region | Location |
|---|---|
US | Northern Virginia, United States |
EU | Frankfurt, Germany |
UK | London, United Kingdom |
CA | Montreal, Canada |
SG | Singapore |
AP | Sydney, Australia |
SA | Brazil |
When a Descope project is created in a region, user data and all project configuration are stored and maintained only within that region. That covers the user and tenant records, flows, connectors, tenant settings, and authentication configuration.
Each project lives in exactly one region, and once the region is selected, user and tenant data cannot be moved between regions. There is no background replication to a primary region and no cross-region user store, so a Frankfurt project has no mechanism by which its data leaves Frankfurt.
Regional deployment sits alongside the rest of Descope's compliance posture, which includes SOC 2 Type 2, ISO 27001, GDPR, HIPAA, and CSA STAR Level 2, along with FedRAMP High authorization for workloads that require it.
Building an application across several regions
Because a project maps to a single region, a multi-region application uses one Descope project per region. Each project has its own Project ID, base URL, and data store.
Most teams pair this with regional authentication domains. A custom domain such as auth.eu.yourapp.com points at the regional CNAME target for that region, and the equivalent US or Singapore domain points at its own. The application determines a user's region from geolocation, an explicit user preference, or a business rule such as which tenant the user belongs to, then initializes the Descope SDK with the matching project configuration.
Not just for large enterprises
The value of multi-region data residency to existing global conglomerates is evident. A company with users in London, São Paulo, and Sydney answers to three sets of regulators, and a single global identity store makes each of those relationships harder to defend. Separate regional projects keep each population under the rules that apply to it.
However, a Series A startup with no regulatory exposure of its own still needs to meet the same requirement from the other side of the table—where their enterprise buyer's compliance team sets terms the startup does not get to negotiate. As we covered in Enterprise Identity Features That Unlock Upmarket Deals, residency is one of the enterprise requirements that can stop a deal outright, and retrofitting it once a contract is in motion is slow and expensive.
Descope’s multi-region data residency coverage is included in our Growth and Enterprise licenses. Book a demo with our auth experts to talk through a multi-region deployment.
