Microsoft Entra ID and data residency

  • Article

Microsoft Entra ID is an Identity as a Service (IDaaS) solution that stores and manages identity and access data in the cloud. You can use the data to enable and manage access to cloud services, achieve mobility scenarios, and secure your organization. An instance of the Microsoft Entra service, called a tenant, is an isolated set of directory object data that the customer provisions and owns.

Note

Microsoft Entra External ID is a customer identity and access management (CIAM) solution that stores and manages data in a separate tenant created for your customer-facing apps and customer directory data. This tenant is called the external tenant. When you create an external tenant, you have the option to select the geographic location for data storage. It’s important to note that the data locations and region availability may differ from those of Microsoft Entra ID, as indicated in this article.

Core Store

The Core Store is made up of tenants stored in scale units, each of which contains multiple tenants. Update or retrieval data operations in the Microsoft Entra Core Store relate to a single tenant, based on the user's security token, which achieves tenant isolation. Scale units are assigned to a geo-location. Each geo-location uses two or more Azure regions to store the data. In each Azure region, a scale unit data is replicated in the physical datacenters for resiliency and performance.

Microsoft Entra ID is available in the following clouds:

  • Public
  • China*
  • US government*

* Not currently available for external tenants.

In the public cloud, you're prompted to select a location at the time of tenant creation (for example, signing up for Office 365 or Azure, or creating more Microsoft Entra instances through the Azure portal). Microsoft Entra ID maps the selection to a geo-location and a single scale unit in it. Tenant location can't be changed after it's set.

The location selected during tenant creation will map to one of the following geo-locations:

  • Australia*
  • Asia/Pacific
  • Europe, Middle East, and Africa (EMEA)
  • Japan*
  • North America
  • Worldwide

* Not currently available for external tenants.

Microsoft Entra ID handles Core Store data based on usability, performance, residency or other requirements based on geo-location. Microsoft Entra ID replicates each tenant through its scale unit, across datacenters, based on the following criteria:

  • Microsoft Entra Core Store data, stored in datacenters closest to the tenant-residency location, to reduce latency and provide fast user sign-in times
  • Microsoft Entra Core Store data stored in geographically isolated datacenters to assure availability during unforeseen single-datacenter, catastrophic events
  • Compliance with data residency, or other requirements, for specific customers and geo-locations

Microsoft Entra cloud solution models

Use the following table to see Microsoft Entra cloud solution models based on infrastructure, data location, and operational sovereignty.

Model Locations Data location Operations personnel Put a tenant in this model
Public geo located Australia*, North America, EMEA, Japan*, Asia/Pacific At rest, in the target location. Exceptions by service or feature Operated by Microsoft. Microsoft datacenter personnel must pass a background check. Create the tenant in the sign-up experience. Choose the location for data residency.
Public worldwide Worldwide All locations Operated by Microsoft. Microsoft datacenter personnel must pass a background check. Tenant creation available via official support channel and subject to Microsoft discretion.
Sovereign or national clouds US government*, China* At rest, in the target location. No exceptions. Operated by a data custodian (1). Personnel are screened according to requirements. Each national cloud instance has a sign-up experience.

* Not currently available for external tenants.

Table references:

(1) Data custodians: datacenters in the US government cloud are operated by Microsoft. In China, Microsoft Entra ID is operated through a partnership with 21Vianet.

Learn more:

Data residency across Microsoft Entra components

Learn more: Microsoft Entra product overview

Note

To understand service data location, such as Exchange Online, or Skype for Business, refer to the corresponding service documentation.

Microsoft Entra components and data storage location

Microsoft Entra component Description Data storage location
Microsoft Entra authentication Service This service is stateless. The data for authentication is in the Microsoft Entra Core Store. It has no directory data. Microsoft Entra authentication Service generates log data in Azure Storage, and in the datacenter where the service instance runs. When users attempt to authenticate using Microsoft Entra ID, they're routed to an instance in the geographically nearest datacenter that is part of its Microsoft Entra logical region. In geo location
Microsoft Entra identity and Access Management (IAM) Services User and management experiences: The Microsoft Entra management experience is stateless and has no directory data. It generates log and usage data stored in Azure Tables storage. The user experience is like the Azure portal.
Identity management business logic and reporting services: These services have locally cached data storage for groups and users. The services generate log and usage data that goes to Azure Tables storage, Azure SQL, and in Microsoft Elastic Search reporting services.		 In geo location
Microsoft Entra Domain Services See regions where Microsoft Entra Domain Services is published on Products available by region. The service holds system metadata globally in Azure Tables, and it contains no personal data. In geo location
Microsoft Entra dynamic membership groups, Microsoft Entra self-service group management Azure Tables storage holds rule definitions for dynamic membership groups. In geo location
Microsoft Entra application proxy Microsoft Entra application proxy stores metadata about the tenant, connector machines, and configuration data in Azure SQL. In geo location
Microsoft Entra password writeback in Microsoft Entra Connect During initial configuration, Microsoft Entra Connect generates an asymmetric keypair, using the Rivest-Shamir-Adleman (RSA) cryptosystem. It then sends the public key to the self-service password reset (SSPR) cloud service, which performs two operations:

1. Creates two Azure Service Bus relays for the Microsoft Entra Connect on-premises service to communicate securely with the SSPR service
2. Generates an Advanced Encryption Standard (AES) key, K1

The Azure Service Bus relay locations, corresponding listener keys, and a copy of the AES key (K1) goes to Microsoft Entra Connect in the response. Future communications between SSPR and Microsoft Entra Connect occur over the new ServiceBus channel and are encrypted using SSL.
New password resets, submitted during operation, are encrypted with the RSA public key generated by the client during onboarding. The private key on the Microsoft Entra Connect machine decrypts them, which prevents pipeline subsystems from accessing the plaintext password.
The AES key encrypts the message payload (encrypted passwords, more data, and metadata), which prevents malicious ServiceBus attackers from tampering with the payload, even with full access to the internal ServiceBus channel.
For password writeback, Microsoft Entra Connect need keys and data:

- The AES key (K1) that encrypts the reset payload, or change requests from the SSPR service to Microsoft Entra Connect, via the ServiceBus pipeline
- The private key, from the asymmetric key pair that decrypts the passwords, in reset or change request payloads
- The ServiceBus listener keys

The AES key (K1) and the asymmetric keypair rotate a minimum of every 180 days, a duration you can change during certain onboarding or offboarding configuration events. An example is a customer disables and reenables password writeback, which might occur during component upgrade during service and maintenance.
The writeback keys and data stored in the Microsoft Entra Connect database are encrypted by data protection application programming interfaces (DPAPI) (CALG_AES_256). The result is the master ADSync encryption key stored in the Windows Credential Vault in the context of the ADSync on-premises service account. The Windows Credential Vault supplies automatic secret reencryption as the password for the service account changes. To reset the service account password invalidates secrets in the Windows Credential Vault for the service account. Manual changes to a new service account might invalidate the stored secrets.
By default, the ADSync service runs in the context of a virtual service account. The account might be customized during installation to a least-privileged domain service account, a managed service account (Microsoft account), or a group managed service account (gMSA). While virtual and managed service accounts have automatic password rotation, customers manage password rotation for a custom provisioned domain account. As noted, to reset the password causes loss of stored secrets.		 In geo location
Microsoft Entra Device Registration Service Microsoft Entra Device Registration Service has computer and device lifecycle management in the directory, which enable scenarios such as device-state Conditional Access, and mobile device management. In geo location
Microsoft Entra business-to-business (B2B) collaboration Microsoft Entra B2B collaboration has no directory data. Users and other directory objects in a B2B relationship, with another tenant, result in user data copied in other tenants, which might have data residency implications. In geo location
Managed identities for Azure resources Managed identities for Azure resources with managed identities systems can authenticate to Azure services, without storing credentials. Rather than use username and password, managed identities authenticate to Azure services with certificates. The service writes certificates it issues in Azure Cosmos DB in the China North region, which fail over to another region, as needed. Azure Cosmos DB geo-redundancy occurs by global data replication. Database replication puts a read-only copy in each region that Microsoft Entra managed identities runs. To learn more, see Azure services that can use managed identities to access other services. Microsoft isolates each Azure Cosmos DB instance in a Microsoft Entra cloud solution model.
The resource provider, such as the virtual machine (VM) host, stores the certificate for authentication, and identity flows, with other Azure services. The service stores its master key to access Azure Cosmos DB in a datacenter secrets management service. Azure Key Vault stores the master encryption keys.		 In geo location

For more information on data residency in Microsoft Cloud offerings, see the following articles:

Next steps