An identity system holds names, email addresses, credentials and a log of everything each person did. That makes it one of the first systems a regulator, an auditor or a large customer asks about when the question is "where is our data kept". Answering "in the cloud" is no longer enough, and answering precisely requires an architecture that was designed for the question.
What counts as identity data
Residency discussions often go wrong because the scope is too narrow. The user table is only the start. An identity platform holds at least five kinds of data.
- Profile data. Names, email addresses, phone numbers, group memberships, custom attributes.
- Credentials. Password hashes, passkey public keys, authenticator secrets, recovery codes.
- Sessions and tokens. Who is signed in now, from which device and address, and the refresh tokens that keep them there.
- The audit record. Every sign-in, grant and refusal, with an identifier for the person and usually an IP address.
- Keys and secrets. The private keys that sign tokens, and stored credentials for connected systems.
The audit record deserves attention. It is personal data in its own right, it grows without limit and it is the part most often shipped to a central logging system in another country without anyone deciding that it should be.
Signing keys are not personal data, but they belong on the list. A key held outside the region can mint tokens for accounts inside it, so where keys live is part of any honest residency answer.
Regional planes and a global control plane
The common architecture for residency splits a platform in two.
The regional data plane
A regional plane is a complete, self-contained installation in one place. It has its own databases, its own key store and its own copy of the services that handle sign-in, tokens, directory and audit. A tenant is created in exactly one region, and every request that touches that tenant's data is processed there.
The global control plane
Some things are global by nature: the product's own sign-up, billing, the list of which tenant lives in which region, and the routing that sends a request to the right place. These live in a control plane that every region shares.
The rule that makes the design defensible is that the control plane holds nothing about a tenant's end users. It knows that a tenant exists, who pays for it and where it lives. It does not know who that tenant's users are.
The direction of the connection
How the two planes talk matters as much as what each holds. There are two options.
- Push. The control plane reaches into each region to configure it. This needs an inbound path into every region and credentials for it stored centrally.
- Pull. Each region calls out to the control plane, authenticates itself and fetches what it needs, such as plan entitlements. Nothing reaches in.
Pull is the better default for residency. A region with no inbound administrative path is easier to reason about and far easier to run inside a customer's own network.
What may cross a border
No useful system keeps every byte in one country. The aim is to be able to list exactly what leaves and why. A reasonable allow-list looks like this.
- Account and billing records for the company that bought the product. These describe your customer as a business, not their users.
- Routing metadata. The mapping from a hostname or tenant id to a region.
- Usage counts. Aggregates for billing, such as the number of active users, with no identifiers.
- Entitlements. What the plan allows, flowing from the control plane to the region.
- Traffic in transit. A request may pass through a network edge location in another country on its way to the region. That is transit, and it should be transit only: terminated, forwarded, not stored.
What should not cross without an explicit decision by the customer: profiles, credentials, sessions, the audit record and private keys.
The places residency leaks
A sound architecture can still be undone at the edges. Check these.
- Log and trace pipelines. Application logs that include email addresses, sent to a central observability service.
- Support tooling. A support engineer in another country reading tenant data through an admin console is a transfer, whatever the database location says.
- Email and SMS providers. A one-time code sent by a provider elsewhere carries the recipient's address or number with it.
- Backups. Cross-region backup replication is often switched on by default.
Running in your own cloud
For some organisations a vendor's region in the right country is still not enough. The requirement is that the data sits in an account they control, under their own network rules and their own cloud contract.
The regional plane model extends to this naturally. If a region is a self-contained installation, it can be installed in a customer's cloud account or data centre as well as in the vendor's. The questions to settle are practical ones.
- Who operates it? Somebody has to apply upgrades, and it should be the same software as the hosted service, not a fork.
- What connects out? Ideally only the region's own calls to the control plane.
- Where are the keys? In the installation, so tokens are signed inside your boundary.
When you compare vendors on these points, ask about each kind of data by name. The wider checklist is in how to evaluate an identity provider.
How AuthFI does it
AuthFI is built as two planes. The global plane runs on Cloudflare and holds control APIs and the web apps. It holds no end-user data. The regional plane is a set of services on Kubernetes that hold the data.
A project is created in one region and stays there for life. The people, sessions, keys and audit record of that project are stored in that region only. AuthFI's own regions are US East on Amazon Web Services and Mumbai on Google Cloud. On the Enterprise plan the regional plane can run in your own AWS, Google Cloud, Azure or Oracle account, or in your own data centre, with the same console and the same updates as everyone else.
What the control plane holds is account and billing records and the routing that sends a request to the right region. Requests pass through the network provider's edge locations on the way to a region, and those locations do not store customer data. A project's data is not moved between regions unless the customer asks.
A region joins the control plane by enrolling for its own client certificate, and it calls out over mutual TLS to push usage and pull entitlements. The direction is region to global.
Each project signs with its own keys, kept in its region, as described in why every secret key lives in one place. More detail is on the identity inside your own cloud page and in the privacy notice.
Key takeaways
- Identity data includes credentials, sessions, the audit record and signing keys, not only the user table.
- A regional plane should hold all of it. A global control plane should hold accounts, billing and routing, and nothing about end users.
- Prefer regions that call out to the control plane over a control plane that reaches in.
- Write down exactly what crosses a border, and check logs, support access, messaging providers and backups.
- If a vendor's region is not enough, the same regional plane should be installable in your own cloud.
