Skip to content

What is new in Sovereign Public Cloud

To identify which sovereign cloud solution may fit your organization’s needs, take the Microsoft Sovereign Cloud assessment


 


New and upcoming controls, where they apply, and how they fit into sovereign Azure architecture. At the October Frontier Tour, we are announcing new and expanded capabilities for Microsoft Sovereign Public Cloud. This post explains what each capability does, where it applies, and how customers can combine controls within an Azure architecture. 


It is written for the platform engineer responsible for the landing zone, the security engineer answering operator-access questions, the compliance professional translating requirements into controls and evidence, and the architect deciding where and how an AI workload can run. The One Microsoft Blog provides the broader business framing. 


Why the control surface changed


For years, residency addressed many sovereignty questions: select the appropriate region, understand commitments such as the EU Data Boundary and in-country processing, and design the workload accordingly. Those commitments continue to provide an important foundation. 


AI makes the choice of controls increasingly important. An AI workload can help organizations create and process sensitive information across prompts, retrieved context, model responses, embeddings, model artifacts, and operational data. Each can have its own residency, protection, and access considerations. Sovereignty therefore needs to extend across the workload architecture, not only the location in which the workload runs. Sovereignty is not one-size-fits-all. With Microsoft Sovereign Public Cloud, organizations can select and combine sovereign controls based on the requirements of each workload while benefiting from the innovation and scale of the public cloud. Data residency controls, including the choice of more than 80 Azure regions and the EU Data Boundary, help customers address where data is stored and processed.  


Customer-managed keys with Azure Key Vault Managed HSM strengthen customer control over data at rest; Private Link and TLS protect data in transit; and Azure Confidential Computing helps extend protection to data while it is being processed. Customer Lockbox provides additional control over Microsoft access to customer data, while Sovereign Landing Zone uses policy-based guardrails to help organizations apply sovereignty requirements at scale. Together, these complementary controls allow customers to tailor architectures to specific sovereignty, regulatory, and workload requirements while benefiting from Azure’s hyperscale infrastructure and advanced cloud and AI capabilities. 


Prompts, retrieved context, and model responses are processed in memory. For supported workloads, Azure confidential computing helps protect this data during processing using hardware-based, attested trusted execution environments. For supported workloads configured for secure key release, Microsoft Azure Attestation provides claims about the execution environment’s identity and security state. Azure Key Vault Managed HSM evaluates those claims against the configured release policy before releasing a key. Residency and encryption protections for stored embeddings, vector indexes, and model artifacts depend on the services and configurations used. Operational telemetry should be assessed separately against the applicable service’s data handling and residency commitments. 


We are now expanding this portfolio with new and enhanced capabilities that give customers additional choices across sovereignty posture, encryption-key control, the protection of data in use, policy enforcement, operator-access transparency, and business continuity. 


Start with the workload


Consider an AI-powered application that uses sensitive organizational information to answer questions. Information moves from the source records to a search index, then to an AI model that generates a response. Instead of using every available sovereignty control, the organization first reviews the requirements and risks for this workload. It then chooses the controls that best address those needs. 


Each stage of that pipeline raises a different question. Source records raise residency and encryption-at-rest questions. Embedding and indexing determine where vector representations of sensitive data live. Inference determines where prompts and retrieved context are processed, and whether that processing is hardware-isolated. Responses and operational telemetry raise retention, logging, and access questions. The sections that follow introduce each new capability against these stages, and the table at the end consolidates the mapping. 


Sovereign Control Panel Public Preview at Microsoft Ignite


Organizations increasingly need to demonstrate not only where their data resides, but also how sovereignty controls are applied, monitored, and evidenced. Answering questions from executives, auditors, regulators, and risk teams can require information spread across policy, security, monitoring, and operational processes. This fragmentation can make sovereignty posture difficult for organizations to assess and demonstrate consistently. Sovereign Control Panel, currently in private preview, will enter public preview at Microsoft Ignite. Delivery timelines are subject to change. 


Just as Microsoft Defender for Cloud helps organizations understand and improve their security posture, and Microsoft Purview brings visibility and governance to data, Sovereign Control Panel is designed to bring organizations greater clarity and operational focus to sovereignty. 


Sovereign Control Panel is an Azure-based posture and evidence experience designed to help organizations assess, monitor, and demonstrate their sovereignty posture from a centralized position. Instead of manually assembling information across tools and teams for every assessment, customers can gain a more continuous and actionable understanding of their posture across their existing Azure estate. 


The experience is organized around a continuous Discover, Control, Act model. Discover helps organizations understand where they stand and why by establishing their actual sovereignty posture, surfacing evidence, identifying gaps and risks, and explaining the underlying drivers. It also supports business continuity readiness by helping organizations assess dependencies and readiness for portability across operating environments, if required. Control helps organizations define what should be true and how it should be maintained by selecting and configuring controls, assigning ownership, applying guardrails, and detecting deviations. Act helps organizations address identified gaps through guided remediation and verify the resulting posture. 



By connecting posture assessment, control management, remediation, and verification, Sovereign Control Panel is designed to help customers move from manually assembling sovereignty information toward a continuous, insight-driven approach to managing sovereignty. It complements the policy-based guardrails provided by Sovereign Landing Zone and provides a foundation for progressively bringing sovereignty posture and operator-access visibility together in one experience. 


Data Guardian and Production Touch Ledger


Customers increasingly expect cloud-provider access to be governed, monitored, and evidenced. Existing controls already govern access before it begins. Just-in-Time Access reviews time-bound Microsoft engineer access, while Customer Lockbox adds customer approval when customer data is in scope. 


We are rolling out two complementary additions to these operator-access controls for customers in the EU and EFTA: Data Guardian and Production Touch Ledger. 


Data Guardian strengthens operational oversight by enabling European-resident oversight by a trusted EU partner to monitor qualifying Microsoft engineer remote access to in-scope production systems in EU and EFTA regions. This oversight spans Azure, Microsoft 365, and Dynamics 365 workloads. 


Production Touch Ledger, also launched with phased rollout, complements this oversight with tamper-evident records of the actions performed during qualifying remote Microsoft engineer access to in-scope production systems in EU and EFTA regions.  


Together, these capabilities extend the operator-access lifecycle from access governance to oversight and evidence: 



  • Govern: Just-in-Time Access and Customer Lockbox govern access before it begins. 



  • Monitor: Data Guardian provides EU-resident oversight by a trusted EU partner during qualifying Microsoft engineer access to in-scope production environments. 



  • Record: Production Touch Ledger preserves tamper-evident records of access and the actions performed for validation reconstruction. 


External Key Management with Azure Managed HSM, generally available


Azure Managed HSM already provides customers with dedicated, single-tenant protection and control over the encryption keys used by supported Azure services. We are now announcing the general availability of External Key Management with Azure Managed HSM, allowing customers to keep the root encryption key in hardware they own and operate on-premises or through a trusted third party. 


With External Key Management, the key-encryption key remains in a customer-owned and customer-operated HSM, either on-premises or hosted by a trusted third party. When a supported Azure service needs to wrap or unwrap a data-encryption key, Azure Managed HSM delegates the cryptographic operation to the external HSM through an External Key Management proxy. 


Azure Managed HSM remains the Azure-facing service for authorization and key management, while External Key Management allows the key-encryption key to remain in an HSM physically controlled by the customer or a third-party provider. 


Because the external HSM, proxy, and connectivity become part of the workload’s critical path, organizations should design and test availability, failover, key rotation, rewrapping, and recovery procedures before production deployment. External Key Management is available to customers globally.  


Azure Confidential Clean Rooms: In Limited Preview


 Some of the most valuable insights require organizations to bring data together, but sensitive data often can’t simply be shared. Azure Confidential Clean Rooms, currently in Limited Preview, is designed to help organizations collaborate on sensitive data while keeping the underlying data protected. Participants can analyze approved datasets together using Spark SQL within a hardware-protected environment, helping enable scenarios such as advertising measurement, customer matching, joint risk analysis, and other multiparty analytics without broadly exposing each participant’s raw data.


Built on Azure confidential computing, Azure Confidential Clean Rooms brings a verifiable trust model to these collaborations. Participants encrypt their data, agree to the analysis being performed, and can use attestation to verify the expected environment and code before encryption keys are released. Only approved results leave the protected environment, while tamper-resistant audit trails help record important activity. Azure Confidential Clean Rooms is moving toward making confidential, multiparty data collaboration available to a broader set of customers and scenarios. 


Sovereign Landing Zone with Bicep, Terraform, and Azure Verified Modules, now available


Sovereign Landing Zone provides a policy-based foundation for implementing sovereign controls across Azure environments, using a management group hierarchy and Azure Policy definitions, initiatives, and assignments to help organizations apply sovereignty requirements consistently. 
 
We’re announcing an updated Sovereign Landing Zone implementation supporting both Bicep and Terraform, using Azure Verified Modules to provide reusable infrastructure-as-code building blocks that platform teams can integrate into their existing deployment practices– 
 
In the current geopolitical environment, organizations are revisiting how they maintain control, continuity, and resilience for critical workloads. Azure Local can support these requirements by providing an option to run workloads in a customer-controlled environment, including disconnected operations when needed. 


The new Local management group in the Sovereign landing zone hierarchy gives customers a clear place to govern Azure Local clusters and the workloads running on them. It also helps teams design workloads in Azure public cloud today with a potential exit path to Azure Local later, so business continuity planning is built into the architecture rather than addressed only during a disruption.



Business Continuity and Portability


Sovereign business continuity extends beyond traditional high availability and disaster recovery. It starts with understanding what should remain operational when disruptions affect access, connectivity or cloud-platform assumptions.


Sovereign Control Panel introduces portability evaluations that help customers assess continuity risks and measure readiness for portability across operating environments, if required. These evaluations help identify baseline considerations such as service availability and compatibility, while recognizing that porting the applications may require additional architectural work.


We are also publishing a new Sovereign Business Continuity guidance and architecture patterns starting with an initial set, with more to follow in the coming months. The library provides prescriptive architecture guidance in the form of flexibly composable patterns for designing continuity paths across Azure, Azure Local, and Azure Local disconnected operations. Combined with governance capabilities in Sovereign Landing Zone for Azure Local, these resources can help customers inform risk-based continuity planning and establish recovery ready architectures.



Putting them together


Sovereignty requirement category

Sovereign Public Cloud

Sovereign Private Cloud

National Partner Cloud

Foundational

Controls: Azure landing zone
Enforcement: Azure Policy, Microsoft Defender, Microsoft Entra, Microsoft Purview

Controls: Azure landing zone, Security defaults
Enforcement: Azure Policy for connected and disconnected

Partner-specific

Data residency

Controls: Region selection and Microsoft Entra ID
EU control: EU Data Boundary
Enforcement: Azure Policy, Go-Local

Controls: Customer-controlled infrastructure placement
Enforcement: Configuration

Partner-specific

Data confidentiality at rest

Control: Encryption at rest
Enforcement: Azure default setting

Controls: Encryption at rest for connected and disconnected
Enforcement: Manual configuration

Partner-specific

Data confidentiality in transit

Controls: Encryption in transit (TLS 1.2+), Private Link, Virtual Network integration
Enforcement: Azure Policy for HTTPS, TLS version, Private Link

Controls: Encryption in transit for connected and disconnected
Enforcement: Manual configuration

Partner-specific

Data confidentiality in use

Control: Azure confidential computing
Enforcement: Azure Policy

Controls: Confidential VMs, Trusted Launch
Enforcement: SKU selection for confidential VMs, Azure Policy for Trusted Launch

Partner-specific

Data confidentiality with key control

Controls: Customer-managed keys (CMK), managed HSM, and/or External Key Management
Enforcement: Azure Policy for CMK and HSM

Controls: Customer-controlled keys
Enforcement: Azure Policy for CMK and HSM

Partner-specific

Operator access

Control: Customer Lockbox
EU and EFTA control: Data Guardian
Enforcement: Enable Customer Lockbox

Controls: Customer operator, identity access for connected and disconnected
Enforcement: Manual

Partner-specific

Operator validation

Control: Production Touch Ledger
Enforcement: Manual

Controls: Customer operator
Enforcement: Manual

Partner-specific

Infrastructure control

Microsoft-operated

Controls: Customer-owned hardware
Enforcement: Manual

Partner-specific

Policy management

Control: Sovereign Control Panel, Azure Policy
Enforcement: Manual

Controls: Azure Policy
Enforcement: Manual

Partner-specific


 


Choosing between these controls is usually a small number of concrete decisions. If a customer requires the root encryption key to remain in hardware outside Microsoft infrastructure, External Key Management applies, and the external HSM, proxy, and connectivity become part of the workload’s critical path. If the requirement is strong customer control of keys without external custody, customer-managed keys in Managed HSM may be sufficient. If prompts, retrieved context, or model weights must be protected while in use, the workload needs confidential computing SKUs and attestation-gated key release rather than encryption at rest alone. If the requirement is record of who accessed the environment, the operator-access controls apply. And if the requirement is the ability to keep operating through disruption, continuity and portability planning belongs in the architecture from the start rather than at the point of failure.


 


The result is not a single prescribed sovereign architecture. It is a tailored sovereignty architecture in which organizations combine the controls that meet the requirements and risk profile of each workload while continuing to benefit from the innovation and scale of the public cloud. Service, region, SKU, and workload support vary by capability, so validate availability before making any control an architectural dependency.


Resources



  • Microsoft Sovereign Cloud overview: https://learn.microsoft.com/azure/azure-sovereign-clouds/

  • Capabilities of Sovereign Public Cloud: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/sovereign-public-cloud-capabilities

  • Confidential Computing: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/confidential-computing

  • Data Guardian: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/data-guardian

  • External Key Management: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/external-key-management

  • Sovereign Control Panel: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/sovereign-control-panel

  • Sovereign Landing Zone: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/overview-sovereign-landing-zone

  • Sovereign Landing Zone implementation options: https://learn.microsoft.com/azure/azure-sovereign-clouds/public/implementation-options

  • New Local Management Group for ALZ https://techcommunity.microsoft.com/blog/azuregovernanceandmanagementblog/new-local-management-group-for-alz–updated-sovereign-policies-for-slz/4515156

  • Sovereign Private Cloud Tech Community blog


 


 


 


 


 


 

Microsoft Tech Community originally posted this article on 20 October 2026 at 9:30 AM.

Leave a Reply