Secure Sensitive AI on Azure Confidential Computing with NVIDIA and Protopia
Your most valuable AI use cases often involve your most sensitive information: customer records, claims, clinical notes, and transaction histories. Dedicated infrastructure can offer control, but it can also limit access to flexible cloud capacity. The opportunity is to expand where that work can run without treating data protection as an afterthought. For a team exploring claims review or clinical-note analysis, the question is not simply whether a model can run in the cloud. It is where sensitive information could be exposed along the journey from application to model and back. Enterprises want to run their highest-value inference on the same scalable cloud they already run everything else on. The catch is that the highest-value inference is usually the most sensitive: customer records, claims and underwriting packets, clinical notes, transaction histories. Data policy keeps that work off shared, multi-tenant capacity and pins it to dedicated, single-tenant deployments. That is the isolation tax: the most valuable, most token-heavy workloads are exactly the ones kept off the infrastructure built to run them, so dedicated capacity sits underused and costs more than it should. Microsoft Foundry already gives this work an enterprise platform: a model catalog that now includes NVIDIA Nemotron, managed and serverless endpoints, and the governance regulated industries require. What has been missing is a way to run sensitive agentic workflows on that shared capacity while reducing the risk of data exposure. The trust dilemma on public cloud Azure Confidential Computing (ACC) addresses a fundamental trust challenge for AI workloads in multi-tenant cloud environments: the model, infrastructure, and data may each be owned or controlled by different parties. Model owners need to protect proprietary weights and intellectual property, and data owners need safeguards for sensitive information throughout processing. ACC provides the trusted foundation for addressing these requirements by helping protect models and their execution from unauthorized host access while enabling additional safeguards across the inference data path. The reference architecture brings together Azure Confidential Computing with NVIDIA H100 GPU capabilities and Protopia AI’s Stained Glass Transform to provide layered protection for sensitive AI workloads running at Azure scale. Confidential Computing: securing the model with NVIDIA Confidential Computing is designed to protect data and AI models while they are in use inside the enclave. The NVIDIA Hopper architecture introduced GPU-based confidential computing, extending the hardware trusted execution environment from the CPU to the GPU so that model weights, activations, and execution state remain within an attested boundary and are designed to be inaccessible to the host operating system, hypervisor, and infrastructure operator. NVIDIA device attestation provides cryptographic evidence about the GPU’s identity and security state before keys are released. For a model owner, these controls are designed to restrict access to model IP while the model runs. Enterprises should not have to choose between protecting their models and running them where compute is available and most convenient. NVIDIA has designed Confidential Computing to keep a model’s weights and execution within the GPU’s trusted execution environment, helping proprietary models run on shared infrastructure while limiting access to their IP. Combined with Protopia’s inference data protection on Azure, customers have a path designed to support sensitive AI workloads in the cloud they already trust. Bring confidential inference to Azure Azure brings confidential inference to production scale, surrounding the confidential GPU with the platform an enterprise needs to operate AI. The Azure NCCads H100 v5 series combines 4th-generation AMD EPYC confidential VMs with NVIDIA H100 Tensor Core GPUs to support confidential AI workloads. The trusted execution environment spans the AMD SEV-SNP CPU and the attached H100 in confidential mode, isolating GPU memory and the channel between CPU and GPU. When enabled and properly configured, Confidential Computing is designed to help limit access to unencrypted customer data within that boundary, including the cloud operator. Azure provides tools to help verify and operate the boundary: Microsoft Azure Attestation (MAA) can assess the confidential VM, while Azure Key Vault Managed HSM can be configured to release decryption keys after successful attestation. "Azure was the first cloud to bring Confidential Computing to NVIDIA H100 GPUs, so customers can protect their data in use, even from the cloud operator, while getting the performance they need for AI. Paired with Protopia’s Stained Glass Transform, this reference architecture protects data across the full inference path, helping regulated organizations bring their most sensitive agentic workloads to Azure.“ - Vikas Bhatia, Head of Product, Azure Confidential Computing, Microsoft Protecting the inference data path Confidential execution does not, by itself, cover every component of a managed inference service. Gateways, logs, traces, caches, and scheduler metadata can sit outside the trusted execution environment. Protopia AI’s Stained Glass Transform (SGT) converts sensitive inputs into protected representations inside the data owner’s trust boundary. The architecture is designed for downstream components to receive those representations, not the original inputs. An SGT-enabled model reasons over them directly, without a host-side decoder. Security teams should inspect the serving layer to verify that this pattern is implemented as intended. This distinction matters when reviewing a service: an attested GPU does not establish how a gateway or cache handles requests. Start with a map of the data flow, then check the controls at each boundary. “Sensitive AI should not automatically mean having to operate every part of the infrastructure yourself. Applying Stained Glass Transform inside the data owner's trust boundary, or within confidential execution on Azure, offers a way to securely deploy to the cloud without exposing sensitive data to the model hosting environment (other tenants or operator), and retaining the data owner's control over their sensitive enterprise data.” - Eiman Ebrahimi, Co-Founder and CEO, Protopia AI From customer boundary to confidential inference At the data owner’s trust boundary, the Stained Glass Proxy, an OpenAI-compatible sidecar, applies the Stained Glass Transform to the prompt and its context, with no changes to the upstream stack. In transit to Azure, the architecture sends the protected representation beyond the customer’s trust boundary rather than the original plaintext input, reducing the likelihood that sensitive plaintext is captured in downstream logs, caches, or interception points. In-transit encryption is used as standard. On Azure NCCads H100 v5 confidential VMs, the request reaches an SGT-enabled model endpoint. Configure and verify confidential execution, attestation, and key-release policies for the chosen serving stack. Across the serving path, verify that components outside the execution boundary handle protected representations rather than original sensitive inputs, including logs, caches, and traces. On return, the client receives a result intended to be interpretable within the data owner’s environment. Expand your options for sensitive AI For enterprises, the value comes down to expanding where sensitive AI workloads can run while maintaining strong protections for models and data. Azure Confidential Computing provides a trusted foundation for running sensitive AI workloads on Azure, helping protect models and data while in use and enabling organizations to take advantage of Azure’s scalable GPU infrastructure. Depending on the workload and deployment configuration, this approach may provide greater infrastructure flexibility and utilization while helping organizations manage performance, model quality, and cost. Learn more Azure Confidential GPU OptionsAnnouncing Live Migration for Confidential Computing
Today at Build, Microsoft showcased Live Migration for Confidential Computing, a new capability that helps move Intel® TDX Confidential VMs to updated infrastructure with limited-service interruption while helping protect VM memory and execution context during migration.Announcing general availability of Azure Intel® TDX confidential VMs
We’re excited to announce the general availability of Azure’s next generation of confidential virtual machines, powered by 5th Gen Intel® Xeon® processors with Intel® Trust Domain Extensions (Intel® TDX). These new confidential VMs make it easier than ever for organizations to move their most sensitive workloads to the cloud—without requiring any application code changes. Available today for production deployments across both general-purpose (DCesv6, DCedsv6) and memory-optimized (ECesv6, ECedsv6) VM series, this release delivers a powerful combination of performance, scalability, and hardware-enforced security, enabling customers to innovate with confidence on Azure. By combining hardware-enforced isolation, cryptographic attestation, and built-in support for Intel® Advanced Matrix Extensions (Intel® AMX), Intel® TDX confidential VMs allow Azure customers to accelerate confidential AI scenarios, protect models and weights, and even collaborate across organizations without exposing confidential data. For Azure customers, this generation of Intel-based confidential VMs provides additional assurance for one of the last major barriers to cloud adoption for sensitive and high-value workloads. It allows organizations to take advantage of Azure’s global scale, elasticity, and rich ecosystem while helping to prevent unauthorized access to data in-use, even from the cloud operator. By combining hardware-enforced isolation and cryptographic attestation, customers can deploy sensitive and/or regulated workloads, protect intellectual property, and run confidential AI pipelines with greater assurance and fewer architectural compromises. The result is faster cloud adoption, simpler compliance, and accelerated innovation —without sacrificing control or security. With Azure Intel® TDX confidential VMs, customers can: Protect data and models while in use with hardware-enforced isolation Achieve significantly lower latency and higher throughput with NVMe local storage Deploy existing applications without code changes Verify integrity and workload integrity through cryptographic attestation and open infrastructure components Run confidential AI workloads efficiently with Intel® AMX acceleration As a first for Azure’s confidential VM offerings, we are adding support for local NVMe SSDs for our DCedsv6-series and ECedsv6-series. These sizes are suited for storage workloads that need a balance of SSD capacity, compute, and memory. With NVMe we can achieve nearly 5× more throughput while reducing latency by about 16% compared to the previous SCSI generation. Overall, we see lower IO latency by ~27 microseconds across block size and thread count. This figure shows NVMe vs SCSI local disk performance ratio for IOPS to latency for random reads with 8K block size, queue depth of 1, and 1 thread. This figure shows NVMe vs SCSI local disk performance for random reads with 8K block size and queue depth of 8 across various thread counts. Additionally, these TDX confidential VMs are Azure confidential compute's first offering to utilize our open-source paravisor, OpenHCL. This innovation allows us to increase transparency and verifiability for our customers, reinforcing our commitment to the trust-but-verify principle for confidential computing. These VMs also support Azure Boost, enabling up to 205k IOPS and 4 GB/s throughput of remote storage along with 40 Gbps VM network bandwidth. Customers are excited to use TDX based Confidential VMs “At Bosch Trustworthy Collaboration Services, we’ve enrolled our collaboration platform on Azure’s latest Confidential VMs powered by Intel® 5th Generation Xeon® processors with TDX support. That means better transparency, stronger performance, and more robust verification: the foundation we need for cross-company teamwork. These improvements reinforce our capability to deliver best-in-class secure collaboration capabilities to our customers with our Trusted Collaboration Spaces.” - Dr. Sven Trieflinger, CTO Bosch Trustworthy Collaboration Services “Ensuring data security across its entire lifecycle has always been a key priority for me. Until recently, encryption for data-in-use was the missing link, preventing true end-to-end protection managed by the customer. Through collaboration with Microsoft and Intel®, we have established a comprehensive ecosystem, called End-to-End Data Encryption. This ecosystem seamlessly unites data protection at rest, in transit, and now in use, thanks to the integration of Intel® TDX technology. The root of trust remains Thales CipherTrust Data Security Platform, enabling us to manage and safeguard our data with confidence. Of course, leveraging that technology for our own use significantly strengthens our cyber defenses. I would like to thank Microsoft for bringing this innovation to fruition.” - Didier Espinet, Chief Information Security Officer for Thales Cyber & Digital Identity "In the public sector and other regulated industries, trust and fairness are paramount. By integrating Microsoft Azure confidential virtual machines with Intel® TDX and AMX technologies, Nuuday delivers a secure and compliant Confidential AI environment that upholds strict data sovereignty and privacy standards. These capabilities ensure sensitive information can be processed with verifiable confidentiality and integrity – while unlocking new opportunities for digital innovation." - John Henriksen, CEO, TDC Erhverv. “Arqit is delighted to partner with Microsoft and Intel® on the launch of Azure’s latest Intel® TDX-enabled Confidential VMs. Together we have demonstrated a combination of security-enhancing technologies to deliver provable protection of sensitive AI workloads processed across multi-region public cloud. This partnership underlines our shared commitment to giving customers full sovereign control over their data even outside of their own networks, in turn accelerating AI adoption and digital transformation.” - Jonathan Pope, VP Sales & Partnerships Offerings The DCesv6-series and DCedsv6-series VMs are designed to offer a balance of memory to vCPU ratio, with up to 128 vCPUs, and up to 512 GiB of memory. The ECesv6-series and ECedsv6-series VMs are designed to offer an even higher memory to vCPU ratio, with up to 64 vCPUs, and 512 GiB of memory. Availability The DCesv6, DCedsv6, ECesv6 and ECedsv6 VMs with Intel® TDX are now generally available in West US, West US 3, West Europe, East US and South Central US. Customers can access these VMs through Azure Portal, Azure CLI, or Azure Powershell. We support Windows Server 2025, Ubuntu 22.04, 24.04 and RedHat guest OS versions.Improve Campaign Reach and Measurement with Azure Confidential Clean Rooms
Why campaign performance now depends on trusted data collaboration For many years, third-party cookies helped advertisers, publishers, and measurement partners recognize users across parts of the open web. That model continues to evolve as browsers and mobile platforms introduce stronger privacy protections and limit access to certain cross-site and device-level identifiers. As a result, some advertisers and publishers are placing greater emphasis on the first-party data they collect directly to support audience activation and campaign measurement. Advertising partnerships may involve identifiers and behavioral data covered by privacy, data-protection, or industry rules. Data that has been altered to reduce direct identification—such as hashed email addresses or advertising identifiers—may still be linked to individuals and should not automatically be considered anonymous. Depending on the law and context, it may be treated as personally identifiable information (PII) or personal data under the European Union’s General Data Protection Regulation (GDPR). Organizations must have an appropriate legal basis and a clear purpose for using such data. The European Union’s Digital Markets Act (DMA) also affects how designated digital platforms combine certain personal data across services. In the United States, health information held by organizations covered by the Health Insurance Portability and Accountability Act (HIPAA) may be subject to additional restrictions, including for some marketing uses. The requirements for each collaboration depend on the parties, data, purpose, consent or authorization, and jurisdiction. Together, these changes create a practical challenge: campaign analysis increasingly depends on combining detailed records held by different organizations, but privacy, security, and governance obligations make unrestricted exchange of customer-level data difficult. Advertisers and publishers therefore need a controlled way to match audiences and measure outcomes using only authorized data—without exposing or freely sharing the underlying records. Azure Confidential Clean Rooms is designed to address this challenge. It allows each party’s detailed data to be used for an agreed analysis while helping protect raw data from access by other participants. This provides a controlled, verifiable environment for audience matching and campaign measurement without unrestricted file sharing. What campaign leaders should look for: the potential to broaden addressable audiences, strengthen evidence of campaign lift, reduce operational risk, and establish a repeatable model for trusted collaboration across media and measurement partners. Campaign decisions with secure multiparty analytics Azure Confidential Clean Rooms is a fully managed service that enables advertisers, publishers, agencies, and measurement partners to analyze sensitive datasets together while helping protect each participant’s raw data. The current preview supports analytics through Spark SQL queries agreed by the participants. These queries run in a hardware-protected environment called a Trusted Execution Environment (TEE), helping protect participants’ raw data from other collaborators and the Azure operator throughout its lifecycle. For a deeper explanation of the technology and architecture, see our earlier blog, Preview of multiparty analytics with Azure Confidential Clean Rooms. The following scenarios show how this model supports specific campaign decisions: Audience activation — Which high-value customers might this media partner reach? The advertiser contributes first-party customer data, such as securely transformed contact details, postal addresses, loyalty IDs, and purchase history. The publisher contributes its audience-matching data, on-site behavior, and consented interest or demographic segments. Azure Confidential Clean Rooms can compare identifiers that the participants have agreed to use for matching and release a reachable audience segment without exposing the underlying records. Campaign leaders can use the result to estimate potential reach and direct investment toward more relevant audiences. Identity enrichment — Can we improve match quality while protecting partner data? An agency or identity partner can contribute a third dataset to connect approved identifiers across email, mobile advertising IDs, devices, or households and add consented demographic or business attributes. Because the matching happens inside the confidential clean room, participants may improve match rates without exposing the identity partner’s underlying data or copying another party’s identifiers. Stronger matching can help expand reach and reduce media waste caused by fragmented customer identities. Measurement and attribution — Did the campaign contribute to additional business outcomes? The publisher contributes ad-exposure records, while the advertiser contributes outcomes such as purchases, order values, subscriptions, or app installs. Comparing these approved datasets can help measure unique reach and frequency, results across publishers, and the difference between groups that were and were not exposed to the campaign. For example, a retailer and a streaming publisher can compare exposure data with purchase outcomes to estimate campaign lift without revealing who saw a specific ad or made a purchase. This can give campaign leaders stronger evidence for campaign optimization and future budget allocation. These scenarios can help campaign leaders assess whether secure data collaboration may improve audience reach, matching quality, or confidence in campaign measurement. Why campaign leaders should consider Azure Confidential Clean Rooms The collaboration model is designed to give each participant greater control over how its data is accessed, used, and shared. Four capabilities are central to building trust among advertisers, publishers, agencies, and measurement partners: No centralized data pooling — Collaborators can keep source datasets in their own storage instead of copying them into a shared, permanent repository. The confidential environment verifies that expected code is running before it securely retrieves authorized data for temporary processing. This can reduce unnecessary data movement and exposure while supporting an approved analysis across partners. Controlled release of approved results — Before analysis begins, collaborators can agree which data may be used, approve the analysis, and specify who may receive the results. Safeguards can also prevent results for very small groups from being released, helping reduce the risk of identifying an individual. Verifiable governance and tamper-resistant audit trails — Participants can verify key properties of the environment instead of relying only on the clean-room provider’s claims. Open-source components and hardware-backed verification help participants confirm that the expected Microsoft-provided code is running. Tamper-resistant audit trails generated in the confidential environment can support compliance reviews. Data protection throughout the process — Each party can encrypt its data before it leaves its environment. Participants allow access to encryption keys only after the confidential environment verifies that expected code is running. Try Azure Confidential Clean Rooms Consider a campaign where better partner data could help improve audience reach, matching quality, or measurement confidence. Sign up to participate in a preview of multiparty analytics with Azure Confidential Clean Rooms. The Microsoft team will contact you to discuss the campaign scenario, participating datasets, and governance requirements. Learn more Sign-up: Preview of multiparty analytics with Azure Confidential Clean Rooms Preview blog: Multiparty analytics with Azure Confidential Clean Rooms Azure documentation: Confidential Clean RoomsAzure Confidential Computing for Digital Sovereignty and Regulated Workloads
This blog provides an update on that momentum: how Azure Confidential Computing (ACC) is expanding across infrastructure, services, hardware-rooted security, and operational maturity, and why that matters for customers with increasing requirements for control, assurance, privacy, and compliance. As digital sovereignty and regulated workload needs continue to grow, ACC is becoming an increasingly important part of how Azure helps customers move sensitive workloads to the cloud with hardware-backed protections designed to help protect data in use. The opportunity for ACC is especially clear in scenarios where customers are balancing innovation with heightened requirements for control, assurance, and compliance. That includes sovereign cloud strategies, national and regional regulatory obligations, privacy-sensitive AI scenarios, and workloads where reducing exposure to privileged infrastructure layers is increasingly important. Momentum over the last year September 2025: Microsoft announced general availability of AMD SEV-SNP DCasv6 and ECasv6 confidential VMs based on 4th Generation AMD EPYC processors. November 2025: At Ignite 2025, Microsoft highlighted continued momentum for Azure Intel TDX confidential VMs, alongside hardware-rooted advances such as ABCD and TDISP to strengthen protected device and I/O paths for sensitive workloads. February 2026: Microsoft launched general availability of AMD SEV-SNP DCasv6 and ECasv6 confidential VMs in Azure Government, extending sovereign cloud capabilities. February 2026: Microsoft announced general availability of Azure Intel TDX confidential VMs across the DCesv6, DCedsv6, ECesv6, and ECedsv6 series. September 2025: Microsoft announced Azure Confidential Computing support for Azure Database for PostgreSQL, extending confidential computing capabilities into a managed database service. May 2026: Microsoft announced general availability of Azure Integrated HSM (AIH), strengthening hardware-backed key protection for sensitive and regulated workloads. June 2026: Microsoft announced preview of multiparty analytics with Azure Confidential Clean Rooms. June 2026: At Microsoft Build 2026, Microsoft showcased Confidential Live Migration for Intel TDX confidential VMs. June 2026: Microsoft announced that DCasv6 and ECasv6 confidential VMs are now available in 57 regions worldwide, significantly expanding the global footprint for confidential workloads. June 2026: Microsoft Signing Transparency (MST) general availability which complements ACC by extending verifiable trust into the software supply chain, enabling customers to independently validate the integrity and provenance of software artifacts alongside hardware-rooted protections for data in use. Taken individually, each announcement is a product update. Taken together, they show Confidential Computing (CC) maturing across VM breadth, digital sovereignty and regulated cloud relevance, AI-oriented confidential computing, operational capabilities that make the platform more practical for real-world deployment, and a growing set of Azure services adopting CC patterns beyond infrastructure alone. The June 2026 expansion of AMD-based DCasv6 and ECasv6 confidential VMs to 57 regions is especially important because it brings low-latency deployment closer to where customers operate, supports data residency and sovereignty requirements, improves multi-region resiliency planning, and can reduce cross-region data movement costs for sensitive workloads. Why ACC matters Azure Confidential Computing (ACC) is Azure’s portfolio across confidential virtual machines, containers, GPUs, attestation, and related services. Its purpose is to let customers run selected workloads inside trusted execution environments so that sensitive data can remain protected during processing and workload integrity can be measured and verified. That makes Azure Confidential Computing (ACC) particularly relevant for customers with digital sovereignty requirements, regulated data environments, and privacy-sensitive AI use cases. It extends the Azure security model beyond encryption at rest and in transit by helping protect data in memory while it is actively being processed within supported confidential computing environments. Confidential Computing is a powerful technical control, but it is not a substitute for the broader set of governance, access control, auditability, and key management measures that regulated customers often require. It is one of the most important building blocks in a larger trust architecture. Security rooted in hardware What differentiates ACC is that its security foundation starts in hardware. The core isolation boundary is provided by hardware-based trusted execution environments (TEEs), rather than relying only on software controls in the hypervisor or operating system. That matters because sensitive workloads are actually running inside attested TEEs, which gives customers a stronger basis for helping protect data and code during execution and for verifying the integrity of the environment before releasing secrets or processing sensitive data. In Azure, that hardware-rooted model spans multiple technologies and product paths. Hardware TEEs provide the protected execution environment. Azure Boost helps move key virtualization and storage functions into purpose-built hardware and offload paths, reducing the attack surface on the host and improving performance isolation. Azure Integrated HSM (AIH) adds hardware-backed key protection and helps strengthen the cryptographic control plane for customers that need stronger assurance around key custody and use. Just as important, Azure brings these capabilities together across a broad ACC portfolio that includes confidential VMs, confidential containers, confidential GPUs, attestation, and related services, giving customers more consistent protection patterns across infrastructure, data, and AI scenarios. Taken together, these elements matter because they show that Azure’s trust story is not built on a single feature. It is built from a hardware-rooted approach that combines protected execution, workload verification through attestation, platform isolation, and stronger control over sensitive cryptographic material. Azure’s approach is also aligned with the broader industry direction reflected in the Confidential Computing Consortium (CCC), where the broader industry organizations, including Microsoft, AMD, Intel, ARM and NVIDIA are all active participants. That alignment matters for customers that care about open industry definitions, ecosystem interoperability, and the long-term evolution of CC across platforms and workloads. The underlying security model starts in hardware and then extends upward through confidential VMs, confidential containers, confidential GPUs, attestation, and related services. AI and confidential inferencing AI is also becoming an important part of the ACC story. Azure was the first cloud provider to bring confidential computing to NVIDIA H100 with NCC H100 v5 confidential VMs, and we are seeing growing interest from sovereign and regulated customers that want stronger protections for sensitive models, prompts, and inference data. We are also seeing small- to medium-sized models run inference on confidential CPU-based VMs, showing that confidential AI is not limited to GPU scenarios alone. Looking ahead, we will continue innovating with our hardware partners to expand confidential AI capabilities, including support for multi-GPU confidential computing. Microsoft first-party adoption of ACC One of the clearest signs of ACC’s importance is Microsoft’s own adoption of CC in first-party services. Inside Microsoft, we often talk about eating our own dogfood, or drinking our own champagne, by using the same platform capabilities we ask customers to trust. That also applies to ACC. Microsoft has publicly discussed the adoption of confidential computing technologies across selected first-party services. More broadly, Microsoft continues to evaluate and expand confidential computing technologies across selected services where stronger isolation and protection may be beneficial. That direction matters because these are among the most security-sensitive parts of the platform. ACC is becoming relevant not just for sovereign/regulated workloads, but for the services that underpin Azure cloud trust itself. ACC and the control model behind digital sovereignty For digital sovereignty and regulated workloads, CC matters most when it is combined with complementary controls. Those can include governed operator access, customer approval workflows where supported, stronger key control, regional oversight capabilities in specific offerings, and auditability measures that help customers understand how sensitive systems are operated. In that broader model, ACC can also help reduce certain circumstances in which cloud operator access to sensitive data may be needed by helping protect data in use within hardware-backed environments, while still fitting within a larger control framework rather than replacing it. That broader framing is important because it reflects reality. ACC helps reduce trust assumptions for data in use, but regulated customers still evaluate a larger system of controls that includes governance, approvals, operational restrictions, key management, and service-specific support boundaries. That is why ACC is increasingly relevant. It helps address one of the most complex challenges in cloud trust: how to protect sensitive data during execution. For customers pursuing digital sovereignty and regulated cloud adoption, that is a foundational capability. Why this matters for sovereign and regulated industries The value of ACC is becoming clearer as customers move more sensitive workloads to the cloud and to AI-enabled architectures. They are not only looking for infrastructure that performs well. They are also looking for infrastructure that can support stronger assurances for privacy, compliance, sovereignty, and operational control. ACC gives Azure a stronger foundation for those scenarios by combining hardware-rooted protection with an expanding platform portfolio across compute, containers, GPUs, attestation, and key protection. That combination helps Azure support the needs of customers that want to move forward on cloud and AI adoption without giving up on the control requirements that matter most to them. Looking ahead, this direction will matter even more as confidential AI workloads become a larger part of the market. For the sovereign and regulated segments targeted here, helping protect model weights, prompts, customer data, and inference or training data during processing will be increasingly important. ACC can help provide part of that foundation by extending hardware-rooted protection to the next generation of sensitive AI workloads. As Azure continues to expand ACC, the most important outcome is not simply more features. It is a stronger platform for digital sovereignty and regulated workloads.Preview of multiparty analytics with Azure Confidential Clean Rooms
Today, we are excited to announce the preview of multiparty analytics feature of Azure Confidential Clean Rooms, a fully managed service that allows customers and their partners to securely analyze privacy-sensitive datasets from multiple parties. It uses confidential compute enabled Apache Spark-based big-data analytics (Spark SQL) which helps protect their raw data from other collaborators and from the Azure operator by performing computations in a Trusted Execution Environment (TEE). Privacy-sensitive datasets include personally identifiable information (PII), protected health information (PHI) and cryptographic secrets. Organizations across industries are increasingly looking to supplement their data with data from business partners, to build a complete view of their business. For example, brands, publishers, and their partners need to collaborate using datasets containing Intellectual Property (IP) to improve the relevance of their campaigns. Confidential data clean rooms help solve this challenge by enabling organizations to share and analyze granular datasets in a secure environment that helps prevent raw data exfiltration—protecting intellectual property, preserving customer privacy, and addressing concerns around regulatory compliance. You can sign up for the preview here Key Features Fully Managed: Azure takes care of the infrastructure provisioning and scaling with no user intervention. This significantly reduces your onboarding effort allowing you to focus on the queries and insights, not on infra management. Confidential Spark SQL: Spark SQL allows you to query large datasets and run complex queries in a distributed computing environment. In the confidential computing enabled version, the Spark driver and executors are fully attested policy-governed enclaves running as virtual nodes on confidential Azure Container Instances (ACI) which helps prevent exfiltration of collaborators’ data during query execution. Governance: Helps manage membership to cleanrooms, enables and verifies approval for queries from relevant collaborators before executing them and verifies consent to access sensitive collaborator data. It also helps generate tamper-resistant audit trails containing salient clean room events. This is made possible with the help of an implementation of the Confidential Consortium Framework (CCF). Telemetry: Throughout every clean-room run, detailed logs are streamed out in real time to monitor performance, troubleshoot issues, and keep the analytics healthy — all without ever exposing the collaborators’ data at any time. Verifiable trust: Cryptographic remote attestation viz. full attestation based on confidential hardware reports allows independent verification of the TEE along with along with all components that are part of it, without just trusting the cloud provider, before sensitive data and decryption keys are made available to the TEE Open-source containers: All Microsoft provided cleanroom containers and sidecars are open-sourced here and can be verified for provenance and integrity guarantees using GitHub artifact attestation Use Cases Multi-party confidential big-data analytics unlocks value in scenarios where data sensitivity, regulatory pressure, or competitive concerns previously blocked collaboration. These are some early scenarios that can benefit from this. Media & Advertising Collaboration of advertiser CRM data with publisher data for audience targeting and segment activation. Collaboration of audience data with measurement partners for measurement and attribution. Banking & Finance Collaboration between banks and insurance firms to upsell relevant products to existing bank customers without sharing raw data from either side Collaboration with retailers to generate customized offers for bank customers, without exposing either party’s underlying data. Government & Public Sector Secure collaboration of data across government departments to deliver better citizen welfare outcomes. Secure collaboration between government and private enterprises on shared-interest workloads such as traffic monitoring and weather systems. Healthcare Enable healthcare firms — including biopharma organizations — to combine their data with third-party institutions to accelerate clinical development, like identifying eligible participants for a clinical trial, without exposing underlying patient data. Combine patient datasets across hospitals to study disease patterns or outcomes without exposing sensitive protected health information. "A higher standard for protecting user privacy and trust, the phase-out of third-party cookies, and global regulations demand more sophisticated data collaboration tools to support advertising marketplaces. Azure Confidential Cleanrooms (ACCR) provides a secure, feature-rich, and flexible foundation to implement privacy-preserving functions and enable insights without sharing privacy-sensitive data outside of organization boundaries. Built on the Azure Confidential Compute (ACC) platform and offering cohesion with Azure's diverse set of services, ACCR offers the attestation, audit, fine-grained access control, and verifiable trust tools required for secure and privacy-safe data collaboration in today's world." — Andrei Mackenzie, Engineering Manager, Microsoft AI "Azure Confidential Clean Rooms enabled our team to evaluate how clean room capabilities can support secure, governed data collaboration at scale. Through the Proof-of-Concept (PoC), we explored how privacy-preserving workflows, trusted access controls, and scalable compute can create a stronger foundation for responsibly leveraging first-party data. This helps reduce operational friction while supporting business growth, improving customer engagement, and enabling more relevant customer experiences." — Nic Dregne, Director, Microsoft AdTech Engineering Beyond Spark SQL Realizing other multi-party scenarios like custom analytics, ML training and inferencing on Azure Confidential Clean Rooms is in our roadmap. If you have such a scenario to be realized, you can fill in and submit the preview signup form with the details of your scenario and we’ll get back to you. Learn More · Signup for the preview of Azure Confidential Clean Rooms for Analytics · Confidential Consortium Framework (CCF) · Virtual Nodes on Azure Container InstancesGA: DCasv6 and ECasv6 confidential VMs based on 4th Generation AMD EPYC™ processors
Today, Azure has expanded its confidential computing offerings with the general availability of the DCasv6 and ECasv6 confidential VMs. Regional availability June 03 2026: Australia Central, Australia Central 2, Australia Southeast, Austria East, Belgium Central, Brazil South, Brazil Southeast, Central India, Central US, Chile Central, Denmark East, East Asia, East US, East US 2, France Central, India South Central, Indonesia Central, Israel Central, Japan East, Japan West, Korea South, Malaysia West, Mexico Central, New Zealand North, North Central US, North Europe, Poland Central, South Africa West, South Central US, South India, Southeast Asia, Spain Central, Sweden Central, Sweden South, Switzerland West, Taiwan North, UAE Central, UK West, West US 2 April 13 2026: West Europe Jan 30 2026: Canada Central, Canada East, Norway East, Norway West, Italy North, Germany North, France South, Australia East, West US, West US 3, Germany West Central Sep 16 2025: Korea Central, South Africa North, Switzerland North, UAE North, UK South, West Central US These VMs are powered by 4th generation AMD EPYC™ processors and feature advanced Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) technology. These confidential VMs offer: Hardware-rooted attestation Memory encryption in multi-tenant environments Enhanced data confidentiality Protection against cloud operators, administrators, and insider threats You can get started today by creating confidential VMs in the Azure portal as explained here. Highlights: 4th generation AMD EPYC processors with SEV-SNP 25% performance improvement over previous generation Ability to rotate keys online AES-256 memory encryption enabled by default Up to 96 vCPUs and 672 GiB RAM for demanding workloads Streamlined Security Organizations in certain regulated industries and sovereign customers migrating to Microsoft Azure need strict security and compliance across all layers of the stack. With Azure Confidential VMs, organizations can ensure the integrity of the boot sequence and the OS kernel while helping administrators safeguard sensitive data against advanced and persistent threats. The DCasv6 and ECasv6 family of confidential VMs support online key rotation to give organizations the ability to dynamically adapt their defenses to rapidly evolving threats. Additionally, these new VMs include AES-256 memory encryption as a default feature. Customers have the option to use Virtualization-Based Security (VBS) in Windows, which is currently in preview to protect private keys from exfiltration via the Guest OS or applications. With VBS enabled, keys are isolated within a secure process, allowing key operations to be carried out without exposing them outside this environment. Faster Performance In addition to the newly announced security upgrades, the new DCasv6 and ECasv6 family of confidential VMs have demonstrated up to 25% improvement in various benchmarks compared to our previous generation of confidential VMs powered by AMD. Organizations that need to run complex workflows like combining multiple private data sets to perform joint analysis, medical research or Confidential AI services can use these new VMs to accelerate their sensitive workload faster than ever before. "While we began our journey with v5 confidential VMs, now we’re seeing noticeable performance improvements with the new v6 confidential VMs based on 4th Gen AMD EPYC “Genoa” processors. These latest confidential VMs are being rolled out across many Azure regions worldwide, including the UAE. So as v6 becomes available in more regions, we can deploy AMD based confidential computing wherever we need, with the same consistency and higher performance." — Mohammed Retmi, Vice President - Sovereign Public Cloud, at Core42, a G42 company. "KT is leveraging Azure confidential computing to secure sensitive and regulated data from its telco business in the cloud. With new V6 CVM offerings in Korea Central Region, KT extends its use to help Korean customers with enhanced security requirements, including regulated industries, benefit from the highest data protection as well as the fastest performance by the latest AMD SEV-SNP technology through its Secure Public Cloud built with Azure confidential computing." — Woojin Jung, EVP, KT Corporation Kubernetes support Deploy resilient, globally available applications on confidential VMs with our managed Kubernetes experience - Azure Kubernetes Service (AKS). AKS now supports the new DCasv6 and ECasv6 family of confidential VMs, enabling organizations to easily deploy, scale and manage confidential Kubernetes clusters on Azure, streamlining developer workflows and reducing manual tasks with integrated continuous integration and continuous delivery (CI/CD) pipelines. AKS brings integrated monitoring and logging to confidential VM node pools with in-depth performance and health insights, the clusters and containerized applications. Azure Linux 3.0 and Ubuntu 24.04 support are now in preview. AKS integration in this generation of confidential VMs also brings support for Azure Linux 3.0, that contains the most essential packages to be resource efficient and contains a secure, hardened Linux kernel specifically tuned for Azure cloud deployments. Ubuntu 24.04 clusters are also supported in addition to Azure Linux 3.0. Organizations wanting to ease the orchestration issues associated with deploying, scaling and managing hundreds of confidential VM node pools can now choose from either of these two for their node pools. General purpose & Memory-intensive workloads Featuring general purpose optimized memory-to-vCPU ratios and support for up to 96 vCPUs and 384 GiB RAM, the DCasv6-series delivers enterprise-grade performance. The DCasv6-series enables organizations to run sensitive workloads with hardware-based security guarantees, making them ideal for applications processing regulated or confidential data. For more memory demanding workloads that exceed even the capabilities of the DCasv6 series, the new ECasv6-series offer high memory-to-vCPU ratios with increased scalability up to 96 vCPUs and 672 GiB of RAM, nearly doubling the memory capacity of DCasv6. You can get started today by creating confidential VMs in the Azure portal as explained here. Additional Resources: Quickstart: Create confidential VM with Azure portal Quickstart: Create confidential VM with ARM template Azure confidential virtual machines FAQKT accelerates cloud and AI adoption with Azure Confidential Computing
A leading South Korea telecom provider, KT Corporation, serves more than 20 million consumers and thousands of enterprise customers in finance, manufacturing, and the public sector. As businesses across the country undergo digital transformation, KT needed to expand its cloud offerings but faced hurdles from government regulations and customer expectations. Data security: Caution and compliance Expanding cloud applications presented several challenges. South Korea’s Personal Information Protection Act (PIPA) imposes strict requirements on how organizations handle personal data, placing limits on cross-border transfers without explicit consent. At the same time, many of KT’s customers remain wary of the public cloud and hesitant to share data due to security concerns. “In Korea, sovereignty and privacy aren’t merely government regulations,” says Sungkwon Kang, senior vice president and head of cloud at KT. “They are fundamental service requirements of key customers.” Many of the company’s applications store and process personally identifiable information - data that is both highly sensitive and tightly regulated. KT already used standard encryption for data at rest and in transit, but leaders still worried that data in use could be vulnerable to attack. To move forward, KT needed a way to assure business customers of end-to-end confidentiality, integrity, and compliance without sacrificing the scale and agility of public cloud. Secure Public Cloud service with Azure Confidential Computing In partnership with Microsoft and Advanced Micro Devices (AMD), KT built a next-generation Secure Public Cloud service powered by Azure Confidential Computing (ACC). ACC protects data in use, encrypting information in RAM and during computation. It also enforces strict hardware attestation, key management, and cryptographic guarantees. “Only the data owner can access the data,” explains Youngmin Kim, senior vice president and head of IT development at KT. KT has already migrated critical workloads to this secure public cloud, including its personal information management services. That migration took about six months, and the environment is now stable and running smoothly. The effort now serves as KT’s reference architecture as the company moves additional services onto the platform. Throughout the transition, KT prioritized customers’ sovereignty requirements. “We store customer data in-region, with transparency and sovereignty controls built into the Azure platform,” says Kang. The same foundation supports KT’s AI scenarios, enabling customers to adopt advanced capabilities with confidence. Performance increases and greater trust KT’s goal in adopting ACC was to give its public-sector and financial customers the confidence to embrace cloud services without hesitation. Strong, verifiable data protection helps build that trust. To support this vision, KT is working closely with manufacturing, financial, and public-sector organizations to increase transparency through service validations and ongoing technology briefings with Microsoft. “We’re building a cloud ecosystem where even the most sensitive organizations can confidently embrace digital and AI transformation with us,” says Kang. We want customers to trust Azure services as much as their own data centers, knowing they have the same level of security control, transparency, and compliance. To support its secure cloud architecture, KT has adopted ACC v6 Confidential Virtual Machines, which run on AMD’s fourth-generation EPYC Genoa processors. With the new VMs, KT is already seeing performance improvements of 15–60% over v5 in similar scenarios. KT is also expanding its software-as-a-service (SaaS) offerings, including AI-driven services for both business-to-business and business-to-consumer customers. Like other shared services, SaaS requires customers to store data in the public cloud, raising similar security concerns. To enhance security and build customer trust, KT is building its SaaS services on Azure, using ACC to protect sensitive data in use. “We’re delivering bolder innovations with stronger protections,” says Kang. Discover more about KT Corporation on Facebook, Instagram, LinkedIn, and YouTube.
Sovereignty in Azure Belgium Central: A Three-Layer Technical Deep Dive
When Belgium Central went live in November 2025, it marked the launch of a new Azure region for Belgian organizations operating in the EU. For many scenarios, it enables customers to run workloads in-country and apply technical controls that can support sovereignty requirements. But "sovereignty" is one of those words that means different things to different people. So, let's break it down into something more tangible. In this post, we'll walk through sovereignty in Azure Belgium Central using three standardized technical layers. Think of them as concentric rings of protection around your data: Layer 1: Data Residency & Locality. Where your data physically lives and how it behaves during failure. Layer 2: Encryption at Rest & In Transit. How data is protected and who holds the keys. Layer 3: Confidential Computing. How data is protected while being processed in memory. Each layer builds on the previous one. Together, they form a comprehensive sovereignty posture. Let's find out what that looks like in practice. Layer 1: Data Residency & Locality This layer answers the most fundamental sovereignty question: where is my data, and does it stay there? In-Country Storage For regionally deployed Azure services, customer data at rest is stored in the selected Azure region. In Belgium Central, this means data at rest for supported services is stored in Belgium. Microsoft indicates the region’s datacenters are located in the Brussels area. When you deploy a resource with location = "belgiumcentral" in Terraform or location: 'belgiumcentral' in Bicep, you’re selecting that Azure region for the resource. This matters for organizations bound by Belgian or EU data residency requirements, and it matters for public sector customers who need assurance that sensitive data doesn't cross national borders without explicit action. Source: Microsoft Digital AmBEtion (microsoft.com/en-be) Three Availability Zones Belgium Central supports Availability Zones. Availability Zones are physically separate locations within an Azure region and are designed with independent power, cooling, and networking. This lets you deploy zone-redundant architectures (for example, spreading VMs, databases, and storage across zones) for high availability while keeping resources in the same Azure region. Availability Zones within a region are connected by high-bandwidth, low-latency networking designed to support zone-redundant services and architectures. Actual latency depends on workload placement and architecture and should be validated for your scenario. Source: The ABC of Azure Belgium Central (Microsoft Community Hub) Non-Paired Region: A Sovereignty Feature, Not a Limitation Azure Belgium Central is a non-paired region. For services that rely on region pairing for automatic geo-replication, behavior and options can differ from non-paired regions. Customers can configure cross-region disaster recovery explicitly and choose a target region based on their requirements. From a sovereignty perspective, some customers may prefer this model because cross-region replication and secondary data locations are customer-selected when configured. Replication and failover capabilities are service-specific, and customers should confirm the data residency and replication behavior for the services they use. Depending on the service and redundancy option, some geo-redundant features (for example, Geo-Redundant Storage (GRS) for Azure Storage) may not be available in non-paired regions. Many designs use Zone-Redundant Storage (ZRS) for in-region redundancy across Availability Zones. For cross-region replication, options such as object replication may be used where supported, with the destination region selected by the customer. Source: Azure region pairs and nonpaired regions (learn.microsoft.com) What This Means Architecturally When designing for Belgium Central, customers may consider: Intra-region redundancy via Availability Zones (for example, ZRS and zone-redundant deployments), where supported. Cross-region disaster recovery when explicitly configured, with a customer-chosen secondary region. Replication behavior that is service-dependent; customers should validate which services replicate within a region, across zones, or across regions, and what configuration is required. Layer 2: Encryption at Rest & In Transit Layer 1 keeps your data in Belgium. Layer 2 makes sure that even if someone gained physical access to the underlying infrastructure, they'd find nothing readable. Encryption at Rest: Platform-Managed by Default By default, all data stored at rest in Azure is encrypted to ensure security and compliance. Storage accounts, managed disks, databases: all use AES-256 encryption with Microsoft-managed keys out of the box. You don't have to configure anything to get this baseline protection. But for sovereignty scenarios, "Microsoft holds the keys" might not be enough. Data at rest is encrypted by default with platform managed keys but double encryption is possible with an extra layer of encryption with customer managed keys (CMK). Source: Double encryption in Azure (learn.microsoft.com) Customer-Managed Keys (CMK): You Hold the Keys Azure services in Belgium Central support Customer-Managed Keys (CMK) through Azure Key Vault. This shifts key ownership from Microsoft to you. You generate, rotate, and revoke keys on your own schedule. Azure services reference your key in Key Vault for encrypt/decrypt operations, but the key itself is under your control. This applies to a broad range of services: VM disk encryption, storage account encryption, Azure SQL Transparent Data Encryption, and more. But not all key storage is created equal. Azure offers three tiers of key management in Belgium Central, and the differences matter for sovereignty: Source: Azure encryption overview (learn.microsoft.com) Key Vault Standard: Software-Protected Keys The entry-level option. Keys are stored encrypted in software, protected by Microsoft's infrastructure, but not in dedicated HSM hardware. This is the entry-level option: software-protected keys stored in a vault, without dedicated HSM hardware. For many general-purpose workloads where regulatory demands don't mandate hardware key protection, Standard is cost-effective and fully functional for CMK scenarios. Key Vault Premium: HSM-Backed Keys (Multi-Tenant) Premium includes everything in Standard plus support for HSM-protected keys. When you create an HSM-backed key in a Premium vault, the key material lives inside Microsoft-managed Hardware Security Modules rather than in software. The HSM hardware is shared (multi-tenant, logically isolated per customer), but the key material is processed and stored within certified HSM devices. Microsoft documentation describes the compliance and validation posture of Key Vault and HSM-backed keys, including FIPS validation details that may vary by hardware generation, region, and service configuration. Customers should refer to the current product documentation and compliance listings for the specific SKU and region in scope. For many scenarios, Key Vault Premium provides HSM-backed key options in a multi-tenant service model and is priced differently than Key Vault Standard and Managed HSM. The right choice depends on regulatory requirements, operational model, and cost considerations. Managed HSM: Single-Tenant, Maximum Isolation For the highest level of key sovereignty, Azure Key Vault Managed HSM provides a single-tenant key management service backed by FIPS 140-3 Level 3 validated hardware. Unlike Key Vault Premium (where HSM-backed keys share a multi-tenant HSM infrastructure), a Managed HSM pool gives you a dedicated, cryptographically isolated HSM environment with your own security domain. Key facts about Managed HSM that matter for sovereignty: Compliance / validation: Managed HSM uses dedicated hardware security modules. Refer to current Microsoft documentation for FIPS validation level and applicability for your region and SKU. Regional deployment: Managed HSM is deployed to an Azure region. Customers should validate data residency and any service-specific data handling behavior for their workload and compliance needs. Security domain: Customers download and control the security domain (a cryptographic backup of HSM credentials), protected using customer-controlled keys. See product documentation for the shared responsibility model and operational details. Access control: Managed HSM provides role-based access controls for key operations. Customers should review the authorization model and administrative boundaries described in the documentation. Managed HSM has a different pricing and operational model than Key Vault (for example, pool-based billing and additional operational steps). It is typically considered when requirements call for dedicated HSM resources, security domain control, or specific compliance needs beyond a shared HSM service model. Choosing the Right Tier Managed HSM is typically considered when requirements call for dedicated HSM resources, security domain control, or administrative separation beyond a shared HSM service model. Key Vault Standard can be a fit for development/test or scenarios where software-protected keys meet your requirements. Key Vault and Managed HSM capabilities are available in Azure Belgium Central, but customers should verify current product, SKU, and service availability by region and validate service-specific data residency behavior for their workload. Source: Azure Key Vault Managed HSM overview (learn.microsoft.com), Managed HSM technical details (learn.microsoft.com), About keys (learn.microsoft.com) Encryption in Transit: MACsec + TLS On the wire, Azure provides two layers of transit encryption: IEEE 802.1AE MACsec. our documentation describes the use of MACsec on portions of the Azure backbone for in-network encryption on supported links. Availability and coverage can vary by scenario; customers should refer to current documentation for details. TLS. Azure services support TLS for client-to-service connections. Supported TLS versions and configuration requirements vary by service; customers should validate the specific service and endpoint configuration they use. Together, these mechanisms help protect data in transit at different layers, depending on the service and network path used. Layer 2 Summary Concern Mechanism Key Detail Data at rest (default) AES-256, platform-managed keys Automatic, no config needed CMK: software keys Key Vault Standard FIPS 140-2 L1, multi-tenant, lowest cost CMK: HSM-backed keys Key Vault Premium FIPS 140-3 L3 (new hardware), multi-tenant CMK: dedicated HSM Managed HSM FIPS 140-3 L3, single-tenant, security domain Data in transit (infra) MACsec (IEEE 802.1AE) Coverage varies by link/scenario; refer to current documentation Data in transit (client) TLS 1.2+ Supported versions vary by service and configuration Trusted Launch and protection of data at rest Trusted Launch is a security feature available for Azure Virtual Machines that helps protect against advanced threats such as rootkits and bootkits. It enables secure boot and virtual Trusted Platform Module (vTPM) on supported VM sizes, ensuring that only signed and verified operating system binaries are loaded during startup. This provides enhanced integrity for the boot process and helps organizations meet compliance requirements for workloads running in the cloud. By leveraging Trusted Launch, customers can monitor and attest to the health of their VMs at boot time, making it easier to detect and respond to potential tampering or compromise. The combination of secure boot and vTPM strengthens the security posture of Azure VMs, offering greater protection for sensitive workloads. Additionally, Trusted Launch strengthens data‑at‑rest protection by isolating encryption keys in a platform‑managed vTPM, binding key release to verified boot integrity, and preventing offline or unauthorized reuse of encrypted disks, even by privileged administrators. Source: Trusted Launch for Azure virtual machines Layer 3: Confidential Computing Layers 1 and 2 protect data where it lives and while it moves. Layer 3 closes the final gap: protecting data while it's being processed in memory. This is the domain of Azure Confidential Computing, and it's where things get genuinely interesting from a sovereignty perspective. Azure Confidential Computing is designed to help reduce certain operator-access risks by using hardware-backed isolation for data while it is being processed in memory. Confidential Virtual Machines Azure Confidential VMs use specialized hardware to create a Trusted Execution Environment (TEE) at the VM level. Two technology families are available: AMD SEV-SNP (DCasv6 / DCadsv6 / ECasv6 / ECadsv6 series) These VMs use AMD's Secure Encrypted Virtualization with Secure Nested Paging. The key properties: The VM's memory is encrypted with keys generated by the AMD processor. These keys are designed to remain within the CPU boundary. The platform is designed to help protect VM memory and state from access by the hypervisor and host management code. Supports Confidential OS disk encryption with either platform-managed keys (PMK) or customer-managed keys (CMK), binding encryption to the VM's virtual TPM on supported configurations. Each VM uses a virtual TPM (vTPM) for key sealing and integrity measurement. Intel TDX (DCesv6 / DCedsv6 series) These VMs use Intel Trust Domain Extensions, which provides full VM memory encryption and integrity protection: The entire VM runs inside a hardware-isolated Trust Domain (TD), designed to help protect data in memory from the hypervisor and host management code. Memory encryption and integrity are enforced by the Intel CPU using dedicated encryption keys per TD. Supports Confidential OS disk encryption (PMK/CMK) and vTPM integration on supported configurations. Additional performance characteristics and hardware details vary by VM size and generation; refer to the current VM size documentation for specifics. The AMD SEV-SNP VM families are currently available in Preview in Azure Belgium Central, with GA planned. The Intel SKU is not currently available in Azure Belgium Central. Source: About Azure confidential VMs (learn.microsoft.com), DC family VM sizes (learn.microsoft.com), Intel TDX confidential VMs GA announcement (techcommunity.microsoft.com) Azure Attestation: Trust, but Verify Confidential computing isn't just about encryption. It's about verifiable trust. Azure Attestation is a free service that validates the integrity of the hardware and firmware environment before your workload runs. Here's how platform attestation works for AMD SEV-SNP and Intel TDX Confidential VMs: When a confidential VM boots, the hardware generates an attestation report containing firmware and platform measurements (an SNP report for AMD, a TDX quote for Intel). Azure Attestation evaluates this report against expected values. Only if the platform passes attestation are decryption keys released from your Key Vault or Managed HSM. These keys unlock the vTPM state and the encrypted OS disk, and the VM starts. If the platform does not meet the attestation policy, key release can be blocked and the VM may not start, depending on configuration. In addition to platform attestation, customers can perform guest-initiated attestation from within the CVM to independently verify the VM's measured hardware and runtime state. This allows applications running inside a confidential VM to obtain an attestation token at runtime, which they can present to relying parties (like a key vault or external service) to prove they are executing in a genuine TEE. This can help reduce reliance on implicit trust by providing cryptographic evidence about the environment at boot and, where implemented, at runtime. Azure Attestation availability is region-dependent; customers should verify current availability in Belgium Central and select the appropriate provider configuration for their scenario. Source: Azure Attestation overview (learn.microsoft.com), Attestation types and scenarios (learn.microsoft.com) Confidential Computing on AKS For containerized workloads, Azure Kubernetes Service supports confidential computing through confidential node pools. You can add node pools backed by confidential VMs alongside regular node pools in the same cluster. You can add AKS node pools using supported confidential VM sizes. In this model, the worker node runs as a confidential VM, so the node’s memory is hardware-protected from the host and hypervisor. Containers scheduled onto that node can run without application refactoring, but the added protection is at the VM/node level. Exact region and SKU availability should be validated for the sizes you plan to deploy. AKS support for confidential VM sizes today includes AMD SEV-SNP with Intel TDX on the roadmap; customers should validate region and SKU availability for the exact AKS node pool sizes they intend to use. Azure Attestation can be integrated into confidential computing architectures on AKS to verify the trust state of nodes or workloads before secrets are released. This is typically implemented at the workload or confidential container level and is not enforced automatically for all AKS pods. Source: Confidential VM node pools on AKS (learn.microsoft.com), Use CVM in AKS (learn.microsoft.com) The Full Data Protection Chain When you combine all three layers, the protection chain when using confidential VMs in Belgium Central looks like this: [Confidential VM boots] → Hardware TEE encrypts VM memory (SEV-SNP or TDX, CPU-generated keys) → Azure Attestation validates platform report (SNP report or TDX quote) → Key Vault (Premium) or Managed HSM conditionally releases disk decryption keys → vTPM state unlocked → OS disk decrypted → VM starts → Data in memory: encrypted and isolated by hardware TEE (Layer 3 – Confidential Compute) → Data at rest: encrypted by CMK from Key Vault / Managed HSM (Layer 2 – Encryption) → Data in transit: protected using TLS (and MACsec on selected Azure backbone links) (Layer 2 – Encryption) → Data stored and processed in Belgium Central where supported and as configured (Layer 1 – Data Residency) These controls are designed to reduce operator-access risk through hardware-backed isolation, attestation, and customer-controlled key options. The exact protection level depends on the selected service, SKU, region, and configuration Bringing It All Together Here's the sovereignty stack for Azure Belgium Central in one view: Layer What It Protects Key Technologies Availability in Belgium Central 1: Data Residency Where data lives 3 AZs, non-paired region, ZRS GA. No cross-border replication by default. 2: Encryption Data at rest + in transit CMK, Key Vault (Std/Premium), Managed HSM, MACsec, TLS GA. All three Key Vault tiers available in-region. 3: Confidential Computing Data in use (memory) SEV-SNP / TDX VMs, Attestation, AKS Availability varies by SKU and region. Confirm confidential VM options (AMD/Intel), attestation, and AKS confidential node support for Belgium Central for the exact sizes you plan to use. Each layer is independently valuable, but the combination can help customers implement stronger technical controls for data residency, encryption, and in-use protection—subject to the specific services, SKUs, regions, and configurations selected. A Few Honest Caveats Because I want to keep this honest and useful: Check regional availability for specific SKUs. Availability can vary by region and can change over time. Before finalizing an architecture, confirm that the exact services and SKUs you plan to use are available in Azure Belgium Central (for example, specific confidential VM sizes, Azure Attestation, Managed HSM, and AKS node pool sizes) using the Azure products-by-region information. Sovereignty is not just technical. The layers above cover technical sovereignty, where data is, who encrypts it, and who can access it in memory. Legal sovereignty (jurisdiction, government access requests, contractual commitments) is a separate conversation. Managed HSM has different pricing and operational characteristics. Managed HSM uses pool-based billing and may require additional operational steps compared to Key Vault. Key Vault Premium supports HSM-backed keys in a multi-tenant model, which may be sufficient for many CMK scenarios. Select the option that meets your compliance and operational requirements. Confidential VM capabilities and integrations vary by VM size, generation, and feature. Some scenarios and integrations (for example, certain backup/DR options, live migration behaviors, accelerated networking, or resize paths) may be limited for specific confidential VM offerings. Validate the current limitations and supported features for the exact confidential VM series and region you plan to use, and plan DR based on the services and mechanisms supported for your scenario. These limitations are being actively worked on. Disclosure: Disaster recovery (DR) design and configuration remain a customer responsibility, including selecting a secondary region and implementing replication, failover, testing, and operational runbooks. Azure service availability and specific features can vary by region, SKU, and deployment model, and may change over time. Replication scope and behavior (in-zone, zone-redundant, regional, or cross-region) are service-specific and depend on the redundancy option selected; validate the data residency and replication details for each service in your architecture. References Microsoft Digital AmBEtion (microsoft.com/en-be) The ABC of Azure Belgium Central (Microsoft Community Hub) Azure region pairs and nonpaired regions (learn.microsoft.com) Azure encryption overview (learn.microsoft.com) Double encryption in Azure (learn.microsoft.com) Azure Key Vault Managed HSM overview (learn.microsoft.com) Managed HSM technical details (learn.microsoft.com) About keys (learn.microsoft.com) About Azure confidential VMs (learn.microsoft.com) DC family VM sizes (learn.microsoft.com) Confidential VM FAQ (learn.microsoft.com) Intel TDX confidential VMs GA announcement (techcommunity.microsoft.com) Confidential VM node pools on AKS (learn.microsoft.com) Use CVM in AKS (learn.microsoft.com) Azure Attestation overview (learn.microsoft.com) Attestation types and scenarios (learn.microsoft.com) Azure products by region (azure.microsoft.com) Trusted Launch for Azure virtual machines (learn.microsoft.com)DCasv6 and ECasv6 confidential VMs in Azure Government Cloud
Today, we are announcing the launch of the DCasv6 and ECasv6 series of confidential virtual machines (CVMs) in Azure Government. Azure Government: Compliant, Hyperscale, Sovereign Cloud Azure Government was designed to remove the constraints that have historically limited federal cloud adoption by delivering hyperscale innovation without sacrificing regulatory certainty. Supporting over 180 services, Azure Government allows customers to consume advanced cloud capabilities without having to individually validate service availability or compliance. It is a complete end-to-end platform, delivering identity, DevOps, and services as commercial Azure, while operating entirely within accredited boundaries. Confidential virtual machines address one of the barriers to multi-tenant cloud adoption: When deployed on Azure Government, Confidential VMs combine physical isolation, sovereign operations, and hardware-enforced cryptographic isolation into a single execution environment. This enables customers to get additional protections from insider threats. At its core, Azure Government runs the same Azure codebase that powers Microsoft’s commercial cloud, providing access to compute, networking, storage, data, and AI services. DCasv6 and ECasv6: Confidential virtual machines in Azure government cloud The DCasv6 and ECasv6-series virtual machines built on 4th Generation AMD EPYC™ processors are the first in Azure Government to implement AMD SEV-SNP. This generation introduces several controls that change both security posture and operational readiness: Hardware-Enforced Memory Isolation: AMD SEV-SNP provides full, AES-256 encrypted memory with keys generated and managed by the onboard AMD Secure Processor. Online key rotation: Support for the online key rotation with the introduction of Virtual Machine Metablob disk (VMMD). Programmatic Attestation for Audit and Zero-Trust: Before provisioning any workload, customers can perform an attestation. This cryptographic procedure validates the integrity of the hardware and software, producing a signed report that proves the VM is a genuine confidential instance. Confidential OS Disk Encryption with Flexible Key Management: Cryptographic protection extends beyond runtime memory to the operating system disk itself. The disk's encryption keys are bound to the VM's virtual Trusted Platform Module (vTPM), which is protected within the TEE. Customers can choose between platform-managed keys (PMK) for simplicity and regulatory ease, or customer-managed keys (CKM) for full, sovereign control over the key lifecycle - a common requirement for the most stringent compliance regimes. Conclusion With the DCasv6 and ECasv6-series virtual machines now generally available in Azure government regions, customers can modernize their infrastructure deployments through confidential computing which replaces implicit trust with cryptographic isolation, and when deployed on Azure Government’s sovereign cloud within physically isolated data centers, it enables agencies to modernize at operational speed without compromising control. Azure Government is in a unique position to deliver the full operational depth of a hyperscale cloud, from identity and DevOps to monitoring and edge execution, inside an environment purpose-built for federal compliance. When combined with the latest Confidential VMs, customers gain secure infrastructure built on a platform where agility, visibility, and trust reinforce each other. Additional resources Azure Government documentation | Microsoft Learn Government Validation System
