Verification closed, appeals exhausted, duplicate seller account. Need reopen.
We're a Delaware C corp ISV (Evident Systems Inc.) running an AI SaaS platform on Azure, trying to complete AI Cloud Partner Program and Commercial Marketplace verification for ISV Success. Our Partner and Developer verifications are both closed as Rejected with no appeals left. The trouble came from our address. We used a virtual office first, then switched to our Delaware registered agent address to match our incorporation documents. Neither met the requirement that the business exist at the stated address. Our real principal office is in South Carolina, where we hold a municipal business license and a state Certificate of Authority. Re-enrolling in Commercial Marketplace also created a duplicate seller account and extra business locations by mistake. Identity, email, and contact verification all passed. We have a support ticket open #2611040040007807. Could someone from Partner Vetting reopen our case, confirm we should update the legal address to our principal office, and merge the duplicate seller accounts? We will hold all changes until a reviewer confirms, so we don't trigger another automated rejection. Global Partner ID: 7176457 Thank you.The CISO Cheat Sheet to Microsoft Digital Defense Report 2026
I know we’re all busy, so I’ve pulled the most important data from this year’s Microsoft Digital Defense Report into one short read. The full report is well worth exploring, but this article focuses on the numbers and trends most relevant to security leaders. This year’s edition shows that AI is lowering the time, expertise and cost required to discover and exploit weaknesses, enabling attackers to operate with greater speed, scale and autonomy. The report describes this as AI “changing the physics of cybersecurity”: attack timelines are compressing and agentic systems are beginning to automate more of the attack lifecycle. Trend 1: Time has collapsed The clearest finding is about speed. Vulnerability discovery is increasingly running ahead of remediation, while the time from discovery to weaponisation is shrinking. In the AI era, weaponisation can follow in hours. Vulnerability discovery and weaponisation now often needs only a well-written prompt. The median time from discovery in the wild to weaponisation is below 24 hours. Vulnerabilities were on track for a record estimated 72,000 CVEs in 2026. The report expects a multi-year period in which the number of known but unpatched vulnerabilities rises sharply before eventually declining. The median time from container start to first exploit attempt is 5.3 hours. The ransomware actor Storm-1175 moved from web-facing exploitation to deploying Medusa ransomware in as little as 24 hours. CISA added over 110 CVEs to its Known Exploited Vulnerabilities catalogue between November 2025 and May 2026, most within a week of disclosure. The mismatch with enterprise reality is the uncomfortable part. The report says the disclosure-to-exploitation window has shrunk to single-digit days. Between November 2025 and May 2026, CISA added more than 110 vulnerabilities to its Known Exploited Vulnerabilities catalogue, most within a week of disclosure. In one example, Storm-1175 moved from exploiting a web-facing vulnerability to deploying Medusa ransomware in as little as 24 hours. Microsoft’s Red Team makes an important point: a patch is also a disclosure. Every fix points attackers towards the flaw it closes. As AI-assisted analysis makes reversing patches faster and more reliable, the report argues that patch velocity, not simply patch availability, becomes the control that matters. Trend 2: Attack chains are gaining autonomy The report charts a clear progression: September–November 2025: AI assists in orchestrating a campaign, as in the Anthropic-reported espionage case. April–June 2026: Full-chain autonomy is demonstrated in labs. July 2026: Real-world autonomous attacks of increasing complexity appear. Two frontier models, Mythos and GPT-5.5, completed a 32-step attack chain against an emulated enterprise with no human help. The test environment had no defenders. The UK AI Security Institute reached a similar finding independently. GPT-5.5 was the second model to solve its end-to-end corporate network attack simulation, a task AISI estimates would take a human about 20 hours. Open-weight models lag closed models at orchestrating attacks by about seven months. In the wild, early July 2026 saw the first documented automated ransomware extortion attack, named JADEPUFFER by Sysdig. Microsoft has seen AI-orchestrated intrusions that share elements with it. Initial access consistently came from internet-exposed services running known-vulnerable software. The report is measured on this point. Volumes of AI-orchestrated activity remain low. In most observed real-world operations, complex end-to-end intrusions still retain meaningful human direction. The Red Team's framing is the most useful one: AI doesn't create a new class of attack, it collapses the effort needed to find and exploit existing attack paths. Trend 3: AI has become an attack surface The report's second takeaway is that attackers are already targeting AI itself. The adoption numbers explain why. 88% of enterprises are experimenting with agents, and 82% of leaders plan broader rollouts within 12–18 months. The report cites industry projections of roughly 1.3 billion agents in production by 2028. What attackers are doing to AI systems: Four techniques accounted for roughly 90% of observed attack activity in telemetry from Azure AI workloads: malicious link injection (52%), jailbreaks (16%), tool and agent abuse (12%), and identity and credential abuse (10%). Memory poisoning: An attacker who can place content anywhere an agent reads can often place it where the agent remembers. Email is the dominant pathway the Red Team has observed. Human-in-the-loop isn't a complete control: Red team testing saw approval prompts ignored, or bypassed by a policy stored in poisoned memory. Developer tools turned against their owners: The "s1ngularity" malware hijacked locally installed AI command-line tools to hunt for secrets. It leaked about 2,000 secrets and 20,000 files across 225 victims. AI browsers: In daily use at more than 40% of organisations in Microsoft's dataset, they were the initial infection vector in incidents involving 57 malware families in a May 2026 analysis. Chat histories as a target: Malicious AI-assistant extensions reached nearly 900,000 installs and more than 20,000 enterprise tenants, harvesting AI chat histories that often contain code, architecture and credentials. The identity implications are direct. Each agent needs its own identity, not one borrowed from an employee, and a named human sponsor. The report also treats revocation latency, the time to cut off a compromised agent, as a measured outcome. Trend 4: The front door is still identity AI changes the speed and personalisation of social engineering. It hasn't changed where attacks start. Initial access in Defender Experts data: User execution: 30% Valid accounts: 20% Malicious copy-and-paste: 13% Phishing: 11% Together, user execution and valid accounts account for over half of observed activity. In incident response engagements, phishing as an initial access vector jumped from 7% to 23% year on year. The standout numbers: ClickFix: Defender saw user-pasted malicious commands on more than 1.1 million unique devices between February and early May 2026, roughly an 8x increase. AiTM: URLs accounted for 45% of the identified phishing techniques in the report’s breakdown. Separately, the share of AiTM phishing and token-theft attacks more than doubled during the first six months of 2026, although the report notes that their overall share remained comparatively small. Teams vishing: Weekly confirmed malicious volume increased 502% year on year. Per attempt, 48% of vishing calls kept the victim engaged for more than 20 seconds, and 30% lasted more than one minute. When a call succeeds, attackers can persuade the victim to install a remote-management tool and complete reconnaissance in two minutes or less. Business contact impersonation (BCI): The report introduces this term for conversations that start with a trusted-looking contact. Microsoft detected more than 46 million attacks in 12 months, with a 121% spike in April 2026. The share of first-contact messages that explicitly asked for money or documents fell from 17% to 3%. The first message is deliberately bland, like "Are you at your desk?" Password attacks declined 26% year on year, which the report describes as strong evidence that MFA and passkeys are forcing attackers to pivot. That pivot includes techniques such as fatigue attacks, AiTM phishing and token theft designed to circumvent conventional MFA. Trend 5: Attackers are inheriting trust rather than breaking in The report's headline theme is that risk is increasingly interconnected. Threats travel through the trusted relationships between identities, software supply chains, partners and cloud platforms. The numbers: Supply chain: Major open-source ecosystems saw attacks roughly every ten days, accelerating through Q2 2026. Shai-Hulud 2.0 affected 25,000 repositories. Megalodon backdoored 5,561 GitHub repositories in under six hours. Trusted signing: In May 2026, Microsoft disrupted Fox Tempest, a "malware-signing-as-a-service" operation that obtained genuine certificates for ransomware loaders and infostealers. Microsoft revoked over a thousand fraudulent code-signing certificates. Legitimate access: An unsanctioned remote monitoring tool is now one of the most reliable mid-stage indicators of a human-operated intrusion. Cloud identity: Cloud identity abuse was the most observed technique against critical infrastructure, representing 78% of the technique mix in Microsoft’s data for March to June 2026. Hybrid intrusions: The Storm-2885 case showed an attacker using a privileged cloud identity to close and downgrade security alerts. The report says identity governance and alert-handling workflows deserve Tier 0 treatment. Dwell time: DART data shows a statistically significant increase in dwell time year on year, meaning organisations took longer to detect intrusions. Ransomware shows the same ecosystem pattern. Qilin led leak-site data with 16.4% of victims, up 386%. Defender detections tell a different story, with Akira at 22%. Trend 6: Defence works best when it's connected The report is not only a catalogue of threats. The strongest defensive evidence: Disruption works. Following the March 2026 disruption, Tycoon2FA activity had fallen 95% from its November 2025 peak by June. Its share of CAPTCHA-gated phishing declined from 76% in December 2025 to 12% in June 2026. Correlation is the highest-leverage variable. The report argues that how well defenders share and correlate signals across endpoint, identity, cloud, email and network is one of the highest-leverage strategic variables under their control. AI is also changing defensive operations. The report describes AI-assisted triage, incident summarisation, hunting-query generation and detection engineering as ways to accelerate investigations and allow analysts to concentrate on higher-value work. Automated disruption can compress response time. The report says that when a correlated incident reaches a defined confidence threshold, defensive systems can automatically isolate devices, disable compromised accounts, revoke sessions or quarantine affected cloud resources. It also stresses the importance of appropriate governance and human oversight for high-risk AI actions. The report also recommends changing what leaders measure. It suggests moving from patches deployed to exposure reduced, detection coverage increased and time-to-mitigate compressed. What the MDDR recommends: ten security priorities The report starts its recommendations with the foundations: Secure by Design, Secure by Default and Secure Operations, applied through identity-centric Zero Trust. Microsoft says these keep the priorities below durable as AI adds more identities, applications, agents and dependencies to govern. Govern cyber risk at leadership level. Report identity exposure, patch latency, agent permissions, critical dependencies, dwell time and recovery readiness to the board. Defend identity as the primary control plane. Deploy passkeys and phishing-resistant MFA, reduce privilege and govern human and non-human identities. Invalidate and rotate tokens and session credentials quickly. Establish governance, visibility and data controls for AI. Keep visibility of approved AI tools, services and agents, and monitor for unauthorised or unmanaged use. Apply sensitivity-aware access and data protection to the data those systems can reach. Reduce exposure and edge risk. Continuously discover internet-facing assets and patch edge devices quickly. Centralise high-fidelity logging, enforce strong authentication and combine network visibility with threat intelligence. Focus on cross-signal correlation. Correlate endpoint, identity, cloud, application, email and network signals to detect intrusions earlier. Correlation also helps defenders anticipate attack paths and likely targets. Enact a continuous threat and vulnerability management model. Combine asset visibility, vulnerability identification, threat detection and AI-accelerated insight into a single continuous programme. Validate exposure through proactive testing. Run assume-breach exercises on cloud services, SaaS platforms, APIs and workflow automation. Prioritise them by where your highest-value data is stored, accessed or aggregated. Secure software dependencies. Harden software installation, keep a software inventory and validate provenance. Monitor packages and prepare for rapid containment. Participate in collective defence. Share actionable threat indicators and victim-informed intelligence with trusted partners and law enforcement. This supports coordinated tracking, investigation and disruption. Prepare for long-horizon technology transitions. Build a cryptographic inventory and advance post-quantum planning alongside AI governance. Read together, the numbers tell one story: the attacker’s workflow is becoming faster and less expensive. AI can shorten vulnerability discovery, exploitation, secret discovery and lateral movement, while organisations still face the slower operational work of testing, coordinating and deploying safe changes across complex environments. At the same time, agent identities can proliferate faster than organisations can inventory, govern and revoke them The defining question for boards today is not whether disruption will occur, but whether the organization can continue operating, contain harm, recover quickly, and maintain trust when it does. Source: Microsoft Digital Defense Report 2026, Version 1.1. Reporting period: July 2025–June 2026.
MAICPP Partner roaster synchronization Issue - Technofocus Levelup Campaign Eligibility
Hello Community Team and Moderators, I am posting to seek guidance and visibility regarding an active Partner Operations support request (Case #2610290050004098) regarding campaign roster synchronization for our organization, Belvit Hub (Partner ID: 7157172). Context & Status: Partner Status: Belvit Hub’s Microsoft AI Cloud Partner Program (MAICPP) enrollment is active, and legal entity vetting was authorized on September 24, 2026. Issue: 500+ candidates from our organization participating in the Technofocus LevelUp / Certification Week campaign are receiving an "Ineligible Domain" block when attempting to register for exam vouchers. Vendor Feedback: Technofocus (LevelUp) support confirmed in writing that their portal cannot manually override domain eligibility and that they are waiting for an updated partner eligibility roster refresh from Microsoft Skilling Operations. Partner Support engineer Hesham Ali has initiated an internal consultation to route this to the relevant internal team. We are posting here to ask if community moderators can assist in ensuring this roster update reaches the Skilling Operations team so our candidates can access their exam vouchers. Thank you for your assistance. Reference Details: Partner Name: Belvit Hub Partner ID (MPN): 7157172 Support Ticket: #2610290050004098Identity verification rejected, no Fix now option – ticket 2610230010000294
We’re an Australian MSP enrolling in the CSP Reseller program. Our current verification status is: Contact verification: Verified Identity verification: Not Verified (no Resolve or Fix now button, so we can’t appeal) Business verification: In Progress – Microsoft Action (ETA was 28 Oct, still pending) I opened ticket 2610230010000294 on 23 Oct but haven’t been contacted yet. Could someone please review the ticket and re-trigger identity verification? We’re happy to provide ID and business registration documents that match our account details. We’d also like to know why identity verification failed, so we can fix the cause and avoid another rejection. Thanks in advance.Establish a macOS security baseline with mSCP and Microsoft Intune custom compliance
By: Iris Yuning Ye, Product Manager | Microsoft Intune Organizations that manage Mac devices need a reliable way to evaluate their security posture against a recognized baseline. Microsoft Intune custom compliance provides the device compliance evaluation policy, and the National Institute of Standards and Technology’s (NIST) macOS Security Compliance Project (mSCP) provides macOS security rules and checks mapped to compliance requirements. Earlier this year we released Intune custom compliance for macOS devices. The feature uses a discovery script and JSON file to define compliance settings. With the mSCP command-line tool, you can select and tailor a security baseline, generate a macOS discovery script, and pair the discovered identifiers with an Intune rules JSON file. Intune then evaluates each device against the chosen baseline and uses the result in compliance reporting and Conditional Access decisions. In this blog, we’re introducing a JSON conversion script (mscp_to_intune_json_conversion.sh). The script converts the mSCP’s generated vendor manifest into the JSON format required for Intune custom compliance. Prerequisite Before you begin, set up the mSCP locally by following the NIST guidance: Getting started with the macOS Security Compliance Project. Create a security baseline Next, we’ll establish and configure the security baseline on the device. Select your security baseline: Choose a security baseline your organization intends to evaluate devices against by looking through frameworks supported by mSCP (for the example in this blog we’ll use CIS Level 1) Configure your baseline: When creating the baseline for the first time, you'll follow a guided process to specify the name of the custom baseline, your name and organization, choose what specific rules to include or exclude. Once the customization process is completed, a new baseline file containing all the rules you specified is generated under the custom/baselines/ directory as a YAML file. ./mscp.py baseline –k cis_lvl1 –t Note: The command uses the following flags: -k Specifies the keyword. In this example, we're using cis_lvl1 . -t Enables tailoring, allowing you to select specific rules to include and define organization-specific values. Once the baseline YAML file is generated, run the command below to generate mSCP documents. These files will be saved into a build/[your specified project name] directory. ./mscp.py guidance –s –M [yaml file location] The yaml file location should be the relative location on top of your mSCP folder. Note: The command uses the following flags: -s Generates the compliance script. -M Generates the JSON vendor manifest file. Once the JSON Vendor Manifest and compliance script are successfully generated, we highly recommend running a test check to verify that all rules and values are defined as expected. Note: If you're using the container method, exit the container to proceed to run the check. (Exit container: NIST macOS Security Getting Started) The key is to locate where you build folder is and where the .sh file was saved in: sudo ./[base folder]/cis_lvl1_macos_27.0/cis_lvl1_macos_27.0_compliance.sh --check Create mobileconfig file Create a mobileconfig file by creating a plain text file, then copy and paste the example in GitHub into it. Configure the .mobileconfig profile Update the PayloadType key to match the audit file name. This ensures the compliance script uses the correct managed arguments when running. Example: In our demo, the value is updated to: org.intune_compliance_lv1_macOS_26.0.audit Customize the following keys based on your organization's requirements and preferences: PayloadDescription PayloadOrganization PayloadDisplayName Test the .mobileconfig profile To verify the configuration, install the .mobileconfig profile locally on a test MacOS device. Open System Settings > General > Device Management. Select the + button to add a configuration profile. Navigate to the saved .mobileconfig file, select it, and click Open. Follow the prompts to Continue and Install the profile. Note: Administrator privileges are required to install the device profile. Validating the Results: Once the profile is installed, run the generated compliance script. If the script runs successfully and outputs JSON, the managed arguments are correctly set. Run the generated compliance script with no arguments specified to make sure it uses the managed arguments from the installed mobileconfig file. sudo ./[base folder]/cis_lvl1_macos_27.0/cis_lvl1_macos_27.0_compliance.sh Once testing is complete, remove the test profile for your local Mac. It’s critical to ensure all testing profiles are removed from target devices before deploying from Intune to avoid conflicts. You can deploy the custom mobileconfig profile for the managed arguments using Intune to the desired set of macOS devices. Important: Deploy the .mobileconfig file to target devices before deploying the custom compliance policy. Otherwise, the custom compliance policy may not run correctly. Use JSON conversion script Next, use the mscp_to_intune_json_conversion.sh script from GitHub to convert the mSCP JSON Vendor Manifest file into the specific JSON format required for Intune’s custom compliance policy. The command line is comprised of three parts: Locate where you saved the conversion script. Specify the JSON file from security baseline you intend to convert from. Specify the name of the custom compliance JSON file you intend to convert to. ~/ mscp_to_intune_json_conversion.sh [base folder]/cis_lvl1_macos_27.0/cis_lvl1_macos_27.0_compliance.json > intune_custom_compliance.json You can now upload the compliance script built by the mSCP that can be found in the build directory as your Discovery Script within Intune’s custom compliance policy. You can also upload the converted JSON file as the JSON for custom settings. Devices with the mobileconfig profile installed will run the compliance script using the managed arguments and output the JSON required for the custom discovery script. Keep in mind Start with a small pilot group and a focused baseline of your choice. Validate every identifier, returned data type, and expected value before broad deployment. Deploy mobileconfig file and make sure the file is already successfully deployed on target devices before custom compliance policy. Review the per-setting results in the Intune admin center > Reports > Device compliance -> Noncompliant devices and settings. Make sure the JSON file generated is aligned with other discovery scripts’ output to avoid misalignment errors. The recommended first step is to pilot one baseline on a small Mac device group, document the source version and rule mapping, and expand only after the discovery script output and Intune results have been validated. Conclusion The steps and scripts provided simplifies the flow to connect the mSCP with Intune’s custom compliance feature. By leveraging mSCP, organizations can efficiently translate recognized macOS security guidance into actionable, measurable compliance signals. While Intune provides the mechanism to capture identifiers and current device values, the rules JSON define the precise evaluation criteria. Together, these tools create a transparent, automated path from a high-level security baseline to detailed, device-level compliance reporting. A special thank you to Robert Gendler from NIST for authoring the mscp_to_intune_json_conversion.sh script and collaborating on this project. Disclaimer Collaboration on this post does not imply NIST endorsement of the products or services offered by Microsoft. Any mention of specific tools or software is for informational purposes and does not constitute a recommendation by NIST.Cybersecurity in 2026: Is Zero Trust Enough to Defend Against AI-Powered Threats?
As cyber threats become more sophisticated, organizations are increasingly adopting Zero Trust architectures, identity-based security, and AI-powered threat detection. But an important question remains: Are our existing security strategies evolving fast enough to address the next generation of cyberattacks? Microsoft has developed a comprehensive security ecosystem through Microsoft Defender XDR, Microsoft Sentinel, Microsoft Entra ID, and Microsoft Intune. These technologies provide powerful capabilities for identity protection, endpoint security, threat detection, and incident response. However, attackers are also leveraging automation, generative AI, and increasingly sophisticated social engineering techniques. I'd like to open a discussion around five important questions: 1. Zero Trust implementation: Are organizations genuinely implementing Zero Trust principles, or are many simply deploying security products without changing their underlying security architecture? 2. AI-powered threats: How prepared are Microsoft security environments to detect AI-assisted phishing, identity attacks, and automated intrusion attempts? 3. Microsoft Defender and Sentinel: What practical improvements have security teams experienced by integrating Microsoft Defender XDR with Microsoft Sentinel? 4. Identity as the new perimeter: With hybrid workforces and cloud-based infrastructure, should identity security now take priority over traditional network perimeter protection? 5. Autonomous security operations: How much authority should AI-powered security agents have to investigate threats, isolate devices, disable accounts, or initiate incident response actions without human approval? One of my biggest concerns is that organizations may invest heavily in cybersecurity tools while overlooking the fundamentals: visibility, configuration management, access governance, employee awareness, and incident response readiness. Security is no longer just about preventing unauthorized access. It's about building resilient systems that can detect, contain, recover from, and continuously adapt to emerging threats. I'd be interested to hear from security architects, SOC analysts, Microsoft MVPs, and IT administrators: What do you consider the biggest cybersecurity challenge facing Microsoft-based enterprise environments today, and what practical steps should organizations prioritize in 2026? Looking forward to your insights and real-world experiences.Security Review for Microsoft Edge version 156
We have reviewed the new settings in Microsoft Edge version 156 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 151 security baseline remains our recommended configuration and can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge versions 153 through 156 introduced 8 new Computer and User settings. To make these settings easier to review, we have included a spreadsheet listing each of the new settings. As a reminder, the Microsoft Edge security baseline now aligns 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 provides organizations with additional time to evaluate and deploy feature changes while keeping security protections current. As always, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to share your feedback through the Security Baselines Discussion site or this post.
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, Qatar
