Where Does My Microsoft Entra ID Data Reside? Understanding Azure Regions and Data Residency
Hello everyone! Zoheb Shaikh here again. I’m a Senior Cloud Solution Architect with Microsoft, based in Doha, Qatar. It’s been almost three years since my last blog, and I’m happy to be back sharing another interesting customer conversation. This time, we’ll explore what the new Saudi Azure region really means for Microsoft Entra ID and data residency. I was recently having a conversation with a customer about Microsoft’s announcement of the Saudi Arabia East Azure region, which is expected to become available in November 2026. Naturally, there was a lot of excitement around it. We started discussing what this means for workloads, applications, data, resiliency and, of course, data residency. And then came a very simple question. “Great. So once the Saudi Azure region is available, our Microsoft Entra ID will also be in Saudi, right?” It is actually a very good question. And I think this is something we are going to hear more often as local Azure regions become available across different countries. My answer was: “Not exactly. Azure region availability and Microsoft Entra ID data residency are two different things.” And that started an interesting conversation. “But Entra runs on Azure, right?” Yes, But this is where we need to understand the difference between a workload that we deploy into Azure and a cloud service that Microsoft operates for us. Think about a normal Azure workload, you want to deploy a VM > Azure asks you: Where do you want to deploy it? Saudi Arabia East, UAE North, UK South, West Europe. You select the region based on your requirements. The same concept applies to many other supported Azure services. With the new Saudi Arabia East region, customers will be able to access supported Microsoft cloud and AI services and host eligible workloads and data locally in the Kingdom. Microsoft has announced that the region will also include three Availability Zones. That is the Azure region conversation But Microsoft Entra ID is different. You don’t create your Microsoft Entra tenant and then say: “Deploy my Entra tenant into Saudi Arabia East.” That is not how the service is designed. So how does Microsoft Entra actually work? This is where the architecture becomes interesting. Microsoft Entra ID is designed as a geographically distributed identity service. When an Entra tenant is created in the public cloud, the country or region selected during tenant creation is mapped by Microsoft Entra to a geo-location and a scale unit. Microsoft’s documentation currently lists geo-locations such as EMEA, North America, Asia/Pacific, Japan, Australia and Worldwide. The tenant location isn’t simply determined by where you later deploy your Azure VMs or applications. I explained it to the customer like this. If you deploy an application into Azure, you are largely deciding: “Where should my workload run?” For Microsoft Entra, Microsoft is managing a global identity platform and deciding: “How do we keep identity available, resilient and responsive while respecting the service’s data-residency architecture?” They are two very different design problems. Then the customer asked the next obvious question “Why does Entra need to work this way?” And this is probably my favourite part of the discussion. Imagine your company’s entire authentication service was dependent on one datacenter. Your users are signing in, Your applications are authenticating, Microsoft 365 depends on identity, Azure depends on identity. Thousands of applications may depend on the same identity platform and now imagine that datacenter has a problem. Identity is one of those services where availability really matters, this is one of reasons Microsoft Entra uses a distributed architecture. Microsoft’s published architecture describes a directory partition as having a primary replica and multiple secondary replicas. The primary replica handles writes, Before a write is acknowledged as successful, Microsoft Entra replicates that write to a secondary replica in another datacenter. Reads work differently, Directory reads, including authentication requests, can be serviced by secondary replicas that are geographically distributed. Microsoft routes these requests so that they can be serviced from datacenters close to customers. Now the architecture starts making more sense. It isn’t distributed randomly, It is distributed because the identity platform needs to provide things such as: availability, resiliency, performance and data durability. “So when I authenticate, am I always talking to where my directory data is stored?” Not necessarily in the way we traditionally think about it. This was another useful part of our conversation. Microsoft documents the Microsoft Entra authentication service itself as stateless. The directory data required for authentication resides in the Microsoft Entra Core Store. When users authenticate, Microsoft can route them to an authentication service instance in the geographically nearest datacenter that forms part of the applicable Microsoft Entra logical region. This is an important concept. The place from which a service responds to you and the place where the underlying authoritative data is managed do not always have to be the same thing. That is quite normal in large cloud services. And then came the real question: “Where is my data?” This is where I normally slow the conversation down a little. Because there are actually a few different questions hiding inside that one question. The customer might be asking: Where does my application data reside? Or Where does my Microsoft Entra directory data reside? Or Where is my authentication request being processed? Or perhaps the actual concern is Do I meet a specific regulatory requirement? These questions sound similar. But technically, they are not the same. For Microsoft Entra ID, Microsoft’s public documentation says the country/region selected during tenant creation is mapped to a Microsoft Entra geo-location and a scale unit. Microsoft Entra Core Store data is then managed according to that geo-location, considering areas such as performance, usability, residency and other requirements. That is why simply saying: “I have an Azure datacenter in my country, therefore every Microsoft cloud service must now store its data there” would be an oversimplification. There is actually an interesting Saudi-specific detail here At this point the conversation usually gets a little more interesting. Microsoft’s public documentation explains that Microsoft Entra directory location is determined when the tenant is originally created. Changing the country code later doesn’t move the directory data location. There is also some historical behaviour worth understanding. Microsoft documents that several country codes — including Saudi Arabia, UAE, Qatar, Bahrain, Kuwait and Oman — were mapped to the Asia region until 2013 and later mapped to Europe. As a result, tenants from those countries created before July 2013 can be provisioned differently from tenants created afterward. Why do I like this example? Because it makes one thing very clear: You shouldn’t determine your Microsoft Entra data location simply by looking at where your Azure workloads are deployed today but tenant provisioning history matters as well. “Okay, but is distributed data less secure?” This is another place where two conversations sometimes get mixed together. Data residency and security are related, but they are not the same thing. Data residency generally talks about where data is geographically stored. Security talks about how that data and the service around it are protected. Microsoft documents several protections around the Entra service. For example, Microsoft Entra directory data is signed and encrypted while it is being transferred between datacenters within a scale unit, and customer-facing web services use TLS. Microsoft also documents tenant-isolation controls around the Entra Core Store. Microsoft Entra also uses geographically distributed replicas, automated routing, monitoring and failover as part of its service architecture. So I wouldn’t look at a distributed architecture and conclude: “The data isn’t sitting in my local Azure region, therefore it is less secure.” That isn’t the right comparison. But I also wouldn’t say: “The service is secure, therefore data residency doesn’t matter.” That isn’t correct either. Security and regulatory residency are two different conversations This is probably the most important takeaway from the whole discussion. Imagine a customer tells me: “Our concern is security.” Then we should discuss the security architecture, tenant isolation, encryption, authentication controls, privileged access, service resilience and the controls Microsoft has put around the service. But imagine the customer says: “Our regulator specifically requires this category of data to be stored within Saudi Arabia.” That becomes a data-residency and compliance conversation. The right thing to do in that situation is not to make an assumption based on the availability of a local Azure region. Instead, check the official Microsoft documentation for the specific service and the specific data type involved. Microsoft’s Trust Center provides service-specific information for Microsoft Azure, Microsoft 365, Microsoft Entra ID, Intune, Defender and other cloud services. This is important because not every Microsoft cloud service follows exactly the same data-storage architecture. Back to the Saudi Azure region, So after all of this, we came back to where our conversation started. What does Saudi Arabia East actually change? A lot. Microsoft has announced that Saudi Arabia East will allow government and private-sector organizations to access supported Microsoft cloud and AI services and host eligible workloads and data locally in the Kingdom. The region will contain three Availability Zones, providing another important building block for organizations designing resilient local architectures. For customers running Azure applications, data platforms, infrastructure and AI workloads, this is a very significant development. But does that automatically mean an existing Microsoft Entra tenant moves into the Saudi Arabia East Azure region? No, And that shouldn’t really be surprising once we understand how Microsoft Entra is designed. The easiest way I explain it By the end of the conversation, I normally reduce everything into two simple questions. Azure Region is “Where do I want to deploy my workload?” For eligible Azure services, Saudi Arabia East gives customers another local option. Microsoft Entra ID “How does Microsoft’s identity service manage and protect my directory data?” That involves Microsoft Entra geo-locations, scale units, replicas and a geographically distributed service architecture. And then there is a third question which is equally important: Data residency “What does Microsoft commit to regarding the storage of my specific data for this specific cloud service?” That answer should always come from the relevant service documentation rather than from assumptions about where the nearest Azure datacenter happens to be. One last thought I actually think conversations like this are healthy. When customers ask “Where is my data?”, we shouldn’t try to answer the question with one sentence. Because modern cloud architecture doesn’t always work like the datacenter architecture we grew up with. An Azure region. A Microsoft Entra geography. A scale unit. A service endpoint. A replica. A data-residency commitment. They can all be part of the same cloud architecture, but they don’t necessarily mean the same thing. The Saudi Arabia East region is a major step forward for customers wanting to run Azure workloads locally in the Kingdom. And at the same time, it gives us a great opportunity to have a deeper conversation about how global cloud services such as Microsoft Entra ID are actually built. My conversation with the customer started with: “So Entra will now also be in Saudi, right?” By the end, the question had changed to something much better: “What is our actual data-residency requirement, and how does Microsoft Entra meet it?” And I think that is the right conversation to have. References Microsoft announces Saudi Arabia East datacenter region https://news.microsoft.com/source/emea/2026/08/microsoft-announces-saudi-arabia-east-datacenter-region-will-be-available-in-november-2026/ Microsoft Entra ID and data residency https://learn.microsoft.com/en-us/entra/fundamentals/data-residency Microsoft Entra architecture https://learn.microsoft.com/en-us/entra/architecture/architecture Customer data storage and processing for European customers in Microsoft Entra ID https://learn.microsoft.com/en-us/entra/fundamentals/data-storage-eu Microsoft Entra data protection considerations https://learn.microsoft.com/en-us/entra/fundamentals/data-protection-considerations Microsoft Trust Center – Data location https://www.microsoft.com/en-us/trust-center/privacy/data-location I hope this blog helped clarify the difference between Azure regions and Microsoft Entra ID data residency. These are the kinds of interesting customer conversations that I enjoy sharing, and I hope to continue writing more regularly. As always, feel free to share your thoughts, questions or experiences in the comments. I'd love to hear your views! Thanks for reading, and until next time! Zoheb Shaikh Senior Cloud Solution Architect | Microsoft Doha, QatarWindows 11, version 26H2 security baseline
Update: The Windows 11, version 26H2 security baseline has been updated to reflect the general availability of Administrator protection. An updated v2 package is now available, and organizations should review and test the existing Administrator protection configuration as appropriate for their environment. You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Summary of Changes This release includes several changes since the Security baseline for Windows 11, version 25H2 to further strengthen enterprise security and align the baseline with current platform capabilities and industry standards. Security Policy Change Summary Printer\Configure Windows Ready Print driver ranking Configured as “Enabled” to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Internet Explorer\Internet Control Panel\Advanced Page\Turn off encryption support Updated from TLS 1.1 and TLS 1.2 to TLS 1.2 and TLS 1.3 to align with current security standards. User Account Control: Configure type of Admin Approval Mode (updated) Configured as “Admin Approval Mode with Administrator protection” to enable Administrator protection. User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection (updated) Configured as “Prompt for credentials on the secure desktop” to require credential verification for administrative elevation. Windows Ready Print driver ranking Configure Windows Ready Print driver ranking" is the newly added setting under Administrative Templates\Printers to control whether Windows prefers the modern inbox IPP class driver over third-party OEM drivers when installing new printers. We recommend enabling this policy to reduce reliance on third-party print drivers in the stack, narrowing the overall print driver attack surface. Note that driver ranking applies when printers are installed via a connection method that supports IPP, such as USB or network multicast discovery. In those cases, if the printer supports IPP, Windows will install using the class driver even if a vendor V3/V4 driver is available. If the printer doesn't support IPP, or is installed directly as a TCP/IP printer, there's no change in behavior. Encryption Support We have updated the policy "Turn off encryption support" to allow only TLS 1.2 and TLS 1.3. Previous baseline releases permitted TLS 1.1 and TLS 1.2; however, TLS 1.1 is now considered obsolete and is no longer recommended for enterprise environments. This change aligns the security baseline with modern cryptographic standards while maintaining compatibility with widely deployed services that support current TLS versions. Administrator Protection (update) Administrator protection is now generally available. Organizations can enable it through Microsoft Intune or Group Policy. Important: Organizations should review and test their existing configuration and adjust these settings as appropriate for their environment. The security baselines for Windows 11, versions 24H2, 25H2, and 26H2 include settings that enable Administrator protection. The following policies are part of the security baseline: User Account Control: Configure type of Admin Approval Mode User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection An updated v2 package has been published for Windows 11, version 26H2, to reflect this change. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.
CSP Program enrollment was DEACTIVATED
We are an active Microsoft reseller in the AI Cloud Partner Program. We were also enrolled in the CSP Indirect Reseller Program. Last year, our CSP enrollment was DEACTIVATED (not SUSPENDED and not TERMINATED). Of course, we got the typical response on our tickets when asking WHY we were deactivated stating that MS can walk away with no explanation. We BELIEVE it is because we had not sold at least $1000 in the previous 12 month period. Everything I read states that we can re-enroll 12 months after our "onboarding date" which I am not sure what that date is. We were deactivated around October 2025. The "Learn More" link doesn't really help, and focuses mostly on SUSPENSIONS which I believe is different. Even using that link, none of the reasons for a suspension apply to us other than the "program requirements" which is where the $1000 minimum comes from. Can anyone offer some additional guidance here? Thanks!
Poor Partner Center Support
I'm trying to register for the Hardware Program and it shows account suspended (we have not subscribed before), because we simply need a driver to be signed. But after many frustrating weeks this is the final answer we got (8+ weeks, TrackingID#2609140040004120): "Thank you so much for your patience while we reviewed the account. During the reinstatement review, it was confirmed that the account was never registered in the Hardware Program and therefore was never active. Because of this, the existing account cannot be reinstated. To move forward, you will need to start a new Hardware Program enrollment using a new tenant. I understand this may not be the outcome you were expecting, but this will allow you to proceed with a new registration rather than continuing with the previous account. As we have now received the final outcome of the reinstatement review and the required next step has been provided, I will proceed with closing this support ticket." How it the world is this a possible solution since it did not work in the first place. We have a our whole company tied to this tenant, and now I have to register a new one, most likely incur some costs again, just because of some buggy software that cannot resolve the issue??
M365 Admin Center Global Administrator Lockout
Hello Microsoft Community, I am seeking urgent assistance and guidance regarding a critical Microsoft 365 tenant lockout that has been ongoing for several days without a resolution or proper communication from the support team. Our organization manages Microsoft 365 services for a business with more than 200 active users who depend on Microsoft 365 for their daily operations. Issue Description We have been locked out of our Microsoft 365 tenant's administrator account. This prevents us from properly managing our Microsoft 365 environment and restoring normal access to essential business services. Our business-critical data, including important documents and operational information, is stored in SharePoint. The inability to access and manage these services has significantly disrupted our business operations. Microsoft Support Ticket References We have raised multiple support tickets and followed up repeatedly, but the issue remains unresolved. Tracking ID: 2610050040001149 Tracking ID: 2610090010001066 Tracking ID: 2610050040001222 Despite these support cases and repeated follow-ups, we have not received a satisfactory resolution or a clear recovery timeline. Support Experience So Far Following a discussion with the support team, we were expecting a call to assist with unlocking the administrator account and providing a temporary password through the appropriate recovery process. However, we have not received the expected call or a meaningful update. Our main concerns are: Complete loss of access to the Microsoft 365 tenant administrator account. More than 200 users affected by the ongoing incident. Critical business data and documents stored in SharePoint. Multiple support tickets without a concrete resolution. Lack of clear communication regarding the root cause and recovery timeline. No clear escalation path or confirmation of the next recovery steps. Our Concerns We understand that technical issues can occur, but leaving a business-critical environment inaccessible for an extended period without meaningful updates is extremely concerning. We purchase Microsoft 365 licenses through a partner and expect appropriate technical support and escalation assistance when critical incidents occur. Our organization previously used Google Workspace and recommended migrating to Microsoft 365 because of its enterprise capabilities. This incident has seriously affected user confidence and business continuity. If access cannot be restored promptly, we may have to consider alternative email hosting arrangements to minimize further disruption. Request for Assistance I would appreciate guidance from Microsoft engineers, Microsoft 365 administrators, and community members who have experienced similar situations. What is the appropriate escalation process when all available tenant administrator accounts are inaccessible? How can we expedite tenant ownership verification and administrator account recovery? Is there a dedicated Microsoft team that handles critical tenant lockout incidents affecting business operations? What is the recommended recovery process when the administrator cannot access the Microsoft 365 Admin Center? How can we obtain urgent assistance when multiple support tickets and repeated follow-ups have not resulted in a clear resolution? Can the three referenced support tickets be escalated for urgent review by the appropriate Microsoft support team? We are not looking for workarounds that compromise tenant security. We need Microsoft's official recovery process to restore authorized administrative access safely. Microsoft Support Team: If any Microsoft support representatives are monitoring this community, we would appreciate your guidance on the appropriate escalation channel for this incident. We can provide additional information privately through the appropriate official channels. Thank you for your time and assistance. Any guidance that helps us restore our services and protect business continuity would be greatly appreciated. Best regards, Microsoft 365 Tenant Administrator
Store company account: employment verification closed after appeal limit
I’m the sole owner of a single-member US LLC (Clumsy’s Lab LLC, Missouri) and I’m trying to open a company account through the new Microsoft Store developer onboarding at storedeveloper.microsoft.com. Status: Email verification: ✅ Verified (on our company domain.) Business verification: ✅ Verified via D-U-N-S Employment verification: ❌ “Verification could not be completed. You’ve reached the limit for verification appeals.” The vetting team’s note says our organization “does not currently meet the requirements to pass verification” and the request is closed. No specific reason was given. What I’ve done since: Updated our Dun & Bradstreet record to list me as owner and contact, with the company email Updated the domain registration so the registrant organization is the LLC, with the company email and business address Emailed mailto:email address removed for privacy reasons with documentation The problem: every “Contact support” and “create a ticket” link sends me to partner.microsoft.com, which requires an existing Partner Center account, so I can’t open a ticket. I’m stuck in a loop. I can provide Articles of Organization (naming me as organizer), our IRS EIN letter, and domain ownership records going back to 2024. Could a moderator help reopen the employment verification, or point me to the right team? For a one-person company, I’m not sure what more “employment” proof is possible. I am the company. Thank you!WHY is microsoft support so useless???
I give up at this point. How is it possible for one of the biggest companies in the world to have the worst and most useless support system ever. I'm just trying to get my account back after it got hacked so I can play minecraft. So how is in after sending a paragraph of information about the account and screenshots of receipts and email I received of someone changes the email of the account, it's still not enough information??? The selfhelp system is somehow the worst one I've ever seen and the AI chatbot doesn't even work.Security Review for Microsoft Edge version 152
We have reviewed the new settings in Microsoft Edge version 152 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 151 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 152 introduced 4 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. Starting with version 152 Microsoft Edge is moving to a more frequent release cycle. To better align with the needs of the enterprise customers, the Microsoft Edge security baseline is expected to align with the Extended Stable Channel, which provides major feature updates on an eight-week cadence while continuing to receive security and quality updates between releases. This approach provides organizations with additional time to evaluate and deploy feature changes while ensuring security protections remain current. Why the change? Security baselines are intended to provide guidance for managing security relevant configuration settings, not to track every feature introduced in a browser release. With the move to a two-week release cadence, publishing baseline updates for every release would increase operational overhead while providing limited security benefit. The Extended Stable cadence offers a more practical balance for enterprise customers by allowing additional time for testing and evaluation, while continuing to receive security and critical fixes between major feature releases. By aligning with Extended Stable, we can update the baselines less frequently and focus on publishing them earlier in the release cycle, giving IT administrators more time to review and plan for upcoming changes. Our goal is to make security baseline adoption more predictable and easier to manage while continuing to provide timely security guidance. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.Verification "Authorized" but Partner Center remains deactivated. No support channel reachable.
We are a company seeking help with a Partner Center account state inconsistency (Seller ID available by direct message to a Community Manager or Microsoft employee). Timeline: - Our Windows Hardware Developer Program enrollment was rejected at the Employment Verification stage. - Microsoft Vetting Operations instructed us in writing to update our profile to a company-owned domain and provide domain registration documentation. We complied fully and same-day: registered and verified a company domain on the enrolling tenant, updated the seller contact and company approver to an address on that domain, and supplied registrar documentation. - The verification pipeline re-ran: Email, Identity, and ultimately all stages completed. Legal Info now shows Verification Status: AUTHORIZED. - However, the Partner Center account itself returns "your Partner Center account has been deactivated" on every workspace — Hardware, Programs, and the support wizard — so we cannot file an in-portal support case from the deactivated account. - Email follow-ups to the Vetting Operations thread and to an assigned Dev Center support engineer have gone unanswered for over a week. We hold multiple correlation IDs (most recent: f4fd02fd-d21f-462f-8765-1ea3d6132ad2, 02 Oct 2026). Our read: the account object was deactivated when the earlier application was closed, and was never re-activated when the verification subsequently authorized — a state inconsistency between the vetting record and the account. Ask: could a Community Manager or Microsoft employee escalate this to the team that can re-activate a verified account? The verification work is complete; only the deactivation flag remains, and it is blocking a driver-signing deliverable. We can provide the Seller ID, case numbers, correlation IDs, and full documentation through any private channel indicated. Thank you. Access restricted We're sorry, you don't have permission to access this page because your Partner Center account has been deactivated. For assistance, please contact your Partner Center administrator or support. Correlation ID: f4fd02fd-d21f-462f-8765-1ea3d6132ad2 Correlation vector: leO3sWI4S0K2fExK.4 Time: 02 Oct 2026 22:36:07 +00:00
