Azure Confidential Computing Blog articles

Sovereignty in Azure Belgium Central: A Three-Layer Technical Deep Dive

wesback — Thu, 09 Apr 2026 16:00:00 GMT

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

Announcing general availability of Azure Intel® TDX confidential VMs

simranparkhe — Thu, 26 Feb 2026 18:56:19 GMT

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 and West US 3 regions. Customers can access these VMs through Azure Portal, Azure CLI, or Azure Powershell. We support Windows Server 2025, Ubuntu 22.04 and 24.04 guest OS versions.

We will continue to receive requests for preview in other available regions and intend to bring them to general availability soon.

DCasv6 and ECasv6 confidential VMs in Azure Government Cloud

Rakeshginjupalli — Tue, 17 Feb 2026 00:27:19 GMT

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

Securing Confidential VM Backups with Azure Recovery Services Vault and Private Endpoints

PramodPalukuru — Sat, 29 Nov 2025 08:26:10 GMT

When working with Confidential VMs (CVMs) in Azure, ensuring secure backups is just as important as protecting workloads in use. Confidential VMs use hardware-based Trusted Execution Environments (TEEs) such as AMD SEV-SNP or Intel TDX to keep your data safe. But how do you securely back up this data without exposing it to the public internet? The answer lies in combining Azure Recovery Services Vault (RSV) with Private Endpoints.

In this blog, we’ll walk through why this setup matters, how to configure it, and what challenges you should watch out for.

Note: This blog specifically deals with CVMs encrypted with Confidential OS Encryption on the OS Disk. As of now, Azure Backup for CVMs is in Private Preview, so make sure to engage with your Microsoft Account Team or Product Team for access.

Why Use Private Endpoints for RSV?

By default, the Recovery Services vault communicates over public endpoints. With private endpoints, all traffic between your Confidential VM and RSV flows over the secure Microsoft backbone instead of the public internet. This adds an extra layer of isolation and protection — a perfect match for sensitive workloads.

What You’ll Need (Prerequisites)

Before jumping in, make sure you have:

An Azure Subscription and appropriate permissions (Owner/Contributor for RSV, DNS Zone Contributor for DNS).
A Confidential VM on supported SKUs.
A Recovery Services Vault in the same or a peered region.
A Virtual Network and Subnet:
- Use a dedicated subnet for private endpoints.
- A private endpoint connection for Backup uses 11 private IPs (including Azure Backup storage). This may be higher in certain regions.
- Recommended subnet size: /25 to /27 to ensure sufficient private IP availability.
Private DNS Zones:
- privatelink.backup.windowsazure.com (for the vault itself)
- privatelink.blob.core.windows.net (staging and recovery data)
- privatelink.queue.core.windows.net (backup operations queue)
- privatelink.table.core.windows.net (metadata storage)
Azure Backup for CVMs supports only the 3-blob layout, which is now generally available. As a result, all new deployments on versions v5 and v6 SKUs will have 3-blob configuration by default instead of the previous 2-blob setup. Older deployments that did not enable the Preview Feature may need to be redeployed to align with this change.
Azure Backup Private Preview Feature enabled on the subscription-level in collaboration with the Azure Product Team.
Up-to-date Backup Extension on the VM.

Step-by-Step: Configuring Backup with Private Endpoints

Request Product Team Enablement:
- Work with Microsoft support/product team to enable the Azure Backup Private Preview Feature for your subscription.
Create the Recovery Services Vault in the desired region.
Add a Private Endpoint:
- Go to RSV → Networking → Private Endpoint connections.
- Select your VNet and subnet (ensure enough private IPs: /25 to /27 recommended).
- Link to the required private DNS zones.
Enable Backup on the Confidential VM:
- Open the VM → Backup.
- Select the RSV.
- Choose or create an Enhanced policy (required for CVMs).
- Trigger the initial backup.

Key Considerations for Confidential VM Backup

Enhanced Policies Only: CVM backup supports only Enhanced policies. Backup support for CVM with confidential OS disk encryption using CMK is only available with Enhanced policies.
Zone-Redundant Recovery Services Vault (ZRS): Consider deploying RSV as ZRS if you want to restore CVMs across zones. Restores from other zones are possible only via vault; snapshot restores are not supported across zones.
CVM Backup with CMK Support: Currently available only under Private Preview on an enrollment basis.
Key Vault and Managed HSM Permissions:
- When configuring via Azure Portal, access to Key Vault/Managed HSM is granted automatically.
- When using PowerShell, CLI, or REST API, access issues occur because Azure Backup requires explicit permissions.
- Fix: Assign Permissions to Azure Backup:
  - For Key Vault: Grant Get, List, Backup key permissions (no secret permissions needed).
  - For Managed HSM:
    - Go to Managed HSM → Local RBAC → Add Role Assignment.
    - Assign one of the following:
      - Built-in Role: Managed HSM Crypto User
      - Custom Role: Ensure dataActions include:
        
        Microsoft.KeyVault/managedHsm/keys/read/action
        
        Microsoft.KeyVault/managedHsm/keys/backup/action
    - Set scope to the specific key (or All Keys).
    - Assign role to Backup Management Service.
  - Once permissions are configured, proceed with CVM backup setup as usual.

Restore Options and Limitations

When restoring a Confidential VM, Azure Backup provides several restore paths — each with certain caveats due to the confidential computing model:

Restore to Original Location
- You can restore the CVM directly to the same subscription, resource group, and network configuration.
- Ideal for operational recovery after accidental deletion or corruption.
Restore to Alternate Location
- You can restore the backup to a different resource group, virtual network, or availability zone.
- Limitations: Only supported when RSV is deployed as Zone-Redundant (ZRS). Snapshot restore is not supported when restoring to other zones.
Disk-Level Restore
- Allows restoring specific managed disks (OS or data disks) from the backup vault.
- Restored disks can be used to recreate CVMs manually.
- Limitations: Replacement of OS Disk on the existing VM is not supported.
Point-in-Time Restore (Enhanced Policy Only)
- Available for Enhanced Backup Policies with configurable retention settings.

Restore Limitations

Encryption Constraints: Restores for CVMs with CMK require the same Key Vault access and permissions to be valid at restore time.
Private DNS Dependency: Incorrect or missing DNS resolution for blob or backup endpoints can cause restore failures.
Feature Availability: All restore capabilities mentioned above are still evolving under the Azure Backup Private Preview program.

Security Benefits

Network Isolation: All communication between CVMs, the Recovery Services Vault, and backup storage occurs over private IPs using private endpoints — no exposure to the public internet.
End-to-End Encryption: Backup data is encrypted both at rest and in transit. Use Customer-Managed Keys (CMK) in Azure Key Vault or Managed HSM for greater control over encryption.
Role-Based Access Control (RBAC): Fine-grained access management ensures only authorized users and services can trigger or restore backups.
Managed Identities for Authentication: Reduces key management complexity and enhances security posture.

Known Issues and Limitations

DNS Misconfiguration: Missing or misconfigured private DNS zones for backup, blob, queue, or table endpoints often lead to failed backups or restores.
Limited Regional Support: Confidential VM backups with private endpoints are currently available in selected Azure regions only.
Extension Compatibility: Ensure that the latest Azure Backup extension version is installed on the CVM. Older versions may not support CVM encryption.
Feature Dependencies: Azure Backup for CVMs (Private Preview) must be manually enabled at the subscription level by the Azure Product Team.
Performance Overhead: Due to attestation and encryption validation, backup operations may experience slight latency.

Best Practices

Test Restore Scenarios Regularly: Validate both backup and restore processes to ensure end-to-end functionality.
Subnet Planning: Reserve adequate IP addresses in your subnet (/25 or /27) to accommodate private endpoints.
ZRS Deployment: Use Zone-Redundant Recovery Services Vault (ZRS) for better resiliency and zone-to-zone restore capability.
Use Enhanced Backup Policies: Enhanced policies ensure point-in-time recovery and support for CMK-based encryption.
DNS Hygiene: Keep private DNS zones properly configured and linked to ensure uninterrupted connectivity.
Permission Management: Verify Key Vault and Managed HSM permissions before initiating backup/restore through PowerShell or REST API.
Network Segmentation: Use dedicated subnets for private endpoints to avoid IP conflicts and simplify network management.
Automate with IaC: Use Bicep or Terraform templates for repeatable, auditable deployments of RSVs, private endpoints, and DNS configurations.
Monitor Health and Alerts: Enable Azure Monitor and Backup Center to track job statuses, failures, and performance.
Engage Product Team Early: Contact the Microsoft Product Team early in your project to ensure required preview feature (Azure Backup for CVMs) is enabled in time.

Final Thoughts

Backing up Confidential VMs with Azure Recovery Services vault over private endpoints gives you the best of both worlds: confidential computing protections for your workloads and secure, compliant backups that never leave the private network. By carefully planning DNS, subnet sizing, enabling subscription features with product team help, and configuring permissions properly, you can avoid common pitfalls and strengthen your data protection strategy.

Note: This blog specifically deals with CVMs encrypted with Confidential OS Encryption on the OS Disk.

Tip: If you’re just getting started, reach out to the Azure Product Team to enable the required features, deploy a test CVM, link it to an RSV with private endpoints, and run a backup/restore cycle to validate your configuration end-to-end.

Azure Intel® TDX confidential VMs momentum

simranparkhe — Fri, 05 Dec 2025 16:16:04 GMT

Azure’s next generation of Confidential Virtual Machines powered by 5th Gen Intel® Xeon® processors (code-named Emerald Rapids) with Intel® Trust Domain Extensions (Intel® TDX) is out in preview now. This will help to enable organizations to bring confidential workloads to the cloud without code changes to applications. These instances also enable Intel® Advanced Matrix Extensions (Intel® AMX) to accelerate confidential AI scenarios. Supported SKUs include the general-purpose DCesv6-series, as well as the memory-optimized ECesv6-series.

Confidential VMs are designed for tenants with high security and confidentiality requirements, providing a strong, attestable, hardware-enforced boundary. They ensure that your data and applications stay private and encrypted even while in use, keeping your sensitive code and other data encrypted in memory during processing.

Improvements for next milestone

As a first for Azure’s Confidential VM offerings, we are soon 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’s first offering to utilize our open-source paravisor, OpenHCL. This innovation allows us to enhance transparency with our customers, reinforcing our commitment to the "trust but verify" model. 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’s 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

“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

Availability

We expect the DCesv6, DCedsv6, ECesv6 and ECedsv6 VMs with Intel® TDX to be generally available in the first quarter of 2026 in select US regions and Europe regions. In the meantime, please sign up for our DCesv6 and ECesv6 VM preview at aka.ms/acc/v6preview and we will contact you with further instructions.

Generational Performance Leap for Azure Confidential Computing

Rakeshginjupalli — Thu, 13 Nov 2025 20:47:39 GMT

At Microsoft, protecting customer data is a foundational commitment. Organizations moving their most sensitive workloads to the cloud require assurances beyond just encryption of data-at-rest and data-in-transit. They need robust protection while the data is in use, and they need it without sacrificing the performance of their business-critical applications. Confidential Computing emerged as a technology to address this need for data-in-use protection.

For years, a key consideration for adopting confidential computing has been the perceived trade-off between stronger security and application performance. To provide our customers with transparent, third-party validation, Microsoft and AMD commissioned a technical analysis from Prowess Consulting, an independent research firm specializing in hands-on performance validation for the enterprise IT industry. Their report provides an assessment of our latest generation confidential VMs.

Azure confidential VMs, powered by the latest 4th generation AMD EPYC™ processors, deliver both next-generation performance and hardware-enforced security, fundamentally shifting the conversation from a security trade-off to a performance dividend. Enterprises are required to handle sensitive information or personal data like transactions, analytics or intellectual property (IP) while operating under strict compliance regimes like GDPR or HIPAA can now seamlessly transition to the cloud, running their high performance, mission-critical applications on Azure’s latest confidential VMs.

A Generational Leap in Performance

While uncertainty surrounding the performance overhead of enabling confidential computing features and performance gaps, confidential computing has broadened its appeal as processors leap forward in both performance and capabilities with each successive generation.

The motivation of the study was to identify a clear performance uplift by comparing the latest Azure DCasv6 confidential VMs, powered by 4th generation AMD EPYC™ processors, against the previous generation. The data confirms that upgrading delivers a significant and measurable performance uplift across the stack.

A 77% gain in memory bandwidth, driven by architectural enhancements including the adoption of DDR5 memory, directly benefiting data-intensive applications.

A 34% increase in Redis throughput, demonstrating substantial real-world gains for in-memory databases and caching workloads where latency is critical.

A 30% rise in CPU throughput, confirming faster execution for compute-bound workloads on the latest generation of Azure confidential VMs.

Quantifying the Overhead of SEV-SNP

Beyond generational gains, the Prowess report sought to answer the critical question: What is the real performance overhead of enabling AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP)? This hardware-level security feature isolates VMs by encrypting memory in use, protecting it even from the host hypervisor. The study compared confidential VMs (DCasv6) against general-purpose counterparts (Dasv6) running on identical 4th Gen AMD EPYC processors. The overhead introduced by these advanced protections was found to be minimal and predictable.

An 8% overhead for CPU-intensive and Redis workloads.

A mere 2% overhead for memory-intensive workloads.

These results affirm that a robust security posture with a minimum impact on performance or latency, making it a practical choice for a broad spectrum of production workloads.

From Technical Validation to Business Value

For IT leaders and developers, these findings mean you no longer need to architect around performance limitations to achieve stronger security. The implications are clear:

Confidentiality is a mainstream capability. With such minimal overhead, confidential computing is no longer a niche solution for only the most sensitive data, but a viable option for securing a diverse array of enterprise applications.
Modernize with confidence. Organizations can now confidently migrate and modernize applications on Azure confidential VMs, gaining both hardware-enforced data protection and a significant performance boost.
Unlock new possibilities. This validated performance enables the processing of sensitive data from financial analytics to healthcare insights in the cloud, scenarios that were previously constrained by security and performance concerns.

This report validates our commitment to delivering a confidential cloud without compromise.

Next Steps

We encourage you to review the detailed report and explore how Azure confidential computing can fit into your security strategy.

Read the full Prowess Consulting Technical Report for a deep dive into the methodology and results.
Visit the confidential computing homepage to learn more about our comprehensive portfolio.
Explore the DCasv6 and ECasv6-series VMs today.

GA: DCasv6 and ECasv6 confidential VMs based on 4th Generation AMD EPYC™ processors

Rakeshginjupalli — Fri, 30 Jan 2026 20:26:08 GMT

Today, Azure has expanded its confidential computing offerings with the general availability of the DCasv6 and ECasv6 confidential VMs.

Regional availability

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:

Announcing: Microsoft transforms Licensing with Cloud Security and Confidential Computing

Sumithra_Shekhar — Mon, 07 Jul 2025 21:58:11 GMT

Microsoft is proud to announce the successful migration of its Windows Licensing Service to Azure, leveraging cutting-edge Confidential Computing and Managed Hardware Security Modules (mHSM) technology. This marks a significant breakthrough in the cloud adoption journey for workloads operating in highly secure environments, reshaping the way Microsoft’s licensing services operate securely at scale.

But what did it really take to move one of Microsoft’s most security-critical services to the cloud? Read on to uncover how the team enabled the largest cryptographic workload ever run in Azure—built on high-assurance infrastructure designed for secure, high-throughput operations.

Migrating highly secure workloads is made possible with the help of Confidential computing and Managed HSM empowering organizations handling highly secure, high-throughput, and confidential workloads to operate with greater confidence, flexibility, and value.

Advancing Security and Throughput

The Microsoft Windows Key Management Licensing Service (MKMS) is built around the protection and management of high-value cryptographic keys, which are central to its security model. This service processes billions of licensing requests and related cryptographic operations each day, using these keys to ensure that only authorized individuals have access to their Windows operating systems, desktop applications, and games. Through its focus on secure key management, MKMS supports the authenticity of software licenses and the protection of sensitive data, making secure Windows licensing possible on a global scale.

With the integration of Confidential Virtual Machines (CVM) and Managed Hardware Security Modules, the service now meets modern high-security requirements by extending this rigorous protection into the cloud environment. This evolution not only reinforces Microsoft's dedication to safeguarding sensitive cryptographic operations but also ensures that customers can trust the reliability and security of their licensing experience.

Building Trust by Moving to Azure

Transitioning from multiple highly secure on-prem datacenters to strategically selected Azure regions has enabled greater reliability, stronger security, and a seamless customer experience for the service. This migration not only aligns with Microsoft’s Secure Future Initiative and delivers CAPEX savings by eliminating the need for hardware refreshes but also unlocks the benefits of cloud-native solutions powered by Confidential Computing and Azure Key Vault Managed HSM.

Migrating MKMS licensing service from on-premises infrastructure to Azure has delivered significant operational benefits. Azure’s elastic cloud resources allow us to scale efficiently, adapting to changing workload demands and supporting future growth while optimizing costs by paying only for the resources we use.

Distributing services across multiple geographic regions in Azure has substantially improved our service availability, minimizing downtime and maintaining consistent delivery even during unexpected events. This geographic redundancy ensures our customers experience fewer disruptions.

By utilizing Azure’s performance-driven infrastructure, we have reduced upfront hardware investments and ongoing maintenance costs, while still meeting the high throughput, speed, and reliability necessary for large-scale cryptographic operations—achieving results on par with or better than our previous on-premises environment.

Enabling Security with Azure Confidential Computing

At the heart of this transformation lies Azure Confidential Computing based on 4th generation AMD EPYC™ CPUs with SEV-SNP, which safeguards sensitive data during processing through hardware-based Trusted Execution Environments (TEEs). This technology prevents unauthorized access, including by cloud administrators and datacenter operators, ensuring robust confidentiality for cryptographic operations that are central to the authenticity of software licenses.

Azure encrypts data at rest and in transit, while confidential computing further secures data in use. This added layer of protection addressed essential security requirements for migrating secure workloads to Azure, supporting the safety and integrity of customer data.

The migration also incorporated Azure Managed HSM to provide enhanced security and tighter control over cryptographic keys. Complemented by Confidential Virtual Machines and securely attested OS images, the service now operates in a trusted and isolated environment, delivering a resilient and scalable cryptographic foundation —crucial for managing high value cryptographic keys required for Windows licensing.

Setting a Benchmark for High-Scale Cryptographic Services

Microsoft’s Key Management Licensing Service, leveraging Azure Confidential Computing and the specially engineered high-throughput Managed HSM capabilities, delivers advanced performance for securely hosting confidential, high-scale workloads in the cloud. These enhanced MHSM features were designed and built to meet the immense demand of this service, enabling it to support the highest throughput cryptographic workload ever run on Azure to date.

MKMS is deployed on Azure using a purpose-built, internally attested secure image to ensure a trusted baseline. The deployment leverages Azure confidential VMs, and managed hardware security modules to protect data: all data at rest and in transit is encrypted, with encryption keys secured by FIPS-validated HSMs. In addition, CVM guarantees our service that all data in-use is encrypted and secure as an additional layer of security. Comprehensive logging and monitoring are enabled across the stack: control-plane operations, host OS events, and network traffic are all recorded and analyzed for auditing and threat detection. This defense-in-depth design layers protection from the hardware and hypervisor up through network firewalls and application-level safeguards, ensuring comprehensive resilience against both volumetric and application-targeted attacks.

Summary

In summary, migration of Windows Licensing to Azure signifies Microsoft’s commitment to driving innovation and security in the cloud. By leveraging Confidential Computing and Managed HSMs, Microsoft is delivering value to billions of users worldwide while reinforcing the trust placed in its services.

This achievement highlights the potential of cloud-native technologies to transform traditional mission-critical systems, offering a glimpse into the future of secure and scalable computing.

Confidential agentic AI on Azure helps ServiceNow respond to sales commission inquiries in seconds

Krishnaprasad_Hande — Thu, 19 Jun 2025 00:18:28 GMT

Introduction

AI is transforming how businesses operate and innovate, unlocking opportunities across industries to pioneer new business models, solve previously intractable challenges, and create breakthrough experiences. ServiceNow is at the forefront, deploying powerful, confidential AI agents leveraging confidential computing. Their sales commission help desk faced mounting challenges, supporting their sales force. With thousands of commission inquiries annually requiring access to sales compensation plan information, the help desk needed a solution to accelerate response times while maintaining strict data privacy and security standards.

Applications

ServiceNow Digital Technology leverages cutting-edge AI to streamline business operations, increase operational efficacy, and enhance employee experiences. The sales commission help desk handles inquiries ranging from policy questions to payout explanations, requiring aggregation and analysis of sensitive data from multiple systems. The manual process of responding to these inquiries—which involves gathering, anonymizing, and analyzing sensitive employee data, sales quotas, and commission structures—created bottlenecks, with resolution times stretching to days for the most complex cases.

Use Cases

To address ongoing commission management challenges, ServiceNow’s Digital Technology team partnered with Opaque Systems and Azure confidential computing team to design, build, and implement Confidential Agents that enable secure, autonomous AI systems with cryptographic privacy guarantees and auditability. The solution provides their help desk team with instantaneous access to encrypted personal commission data across multiple systems, while AI agents automatically analyze requests and generate custom responses.

By integrating securely with various data sources, the system maintains strict privacy controls and compliance while delivering rapid, trusted insights. Every action taken by the AI agents is cryptographically verified, creating an immutable record of data access and usage. This generates detailed audit trails that meet compliance and strengthen governance protocols. Through hardware-based encryption on Azure NCCads H100 v5 confidential virtual machines augmented by NVIDIA H100 Tensor Core GPUs for accelerated computing running on their Microsoft Azure subscription service, the services built by ServiceNow can now harness the full power of AI technology without compromising on capabilities. Opaque’s Confidential AI Platform unlocks new performance potential of AI models that demand high-performing computational resources for all the commission requests, while maintaining robust protection of compensation data, setting a new standard for secure, efficient commission management.

Accelerate, Reclaim, and Save

Opaque's Confidential AI Agents architecture was uniquely built with NVIDIA H100s to help ServiceNow’s transformation. Once AI agents are connected to sensitive data, every aspect of agent operation maintains verifiable privacy and security, including real-time attestation that verifies agent authenticity and integrity, comprehensive audit trails of all agent actions and data interactions, cryptographic enforcement of data access and usage policies, and protection of valuable agent models and intellectual property. This combination of autonomous capability and verifiable privacy and security makes it ideal for ServiceNow to leverage for sensitive sales commission data while maintaining the highest standards of privacy and trust.

The implementation of Opaque's Confidential AI Agents delivered strong results across ServiceNow's sales operations. Average response times decreased from 4 days to just 8 seconds, dramatically improving service delivery. Sellers can find quick summaries of Sales Success Center material and links to learn more. They also reported a 74% accuracy rate of agent responses, demonstrating high relevancy. Beyond operational improvements, ServiceNow improved operating costs while simultaneously strengthening their security posture through confidential computing. Most importantly, this has freed up the help desk team to focus on more strategic, high-value work while delivering faster, more accurate support to the sales force, creating a virtuous cycle of improved efficiency and satisfaction.

Learn more

Azure Confidential VMs help keep BMW Group’s identities and passwords protected while in use

Rakeshginjupalli — Tue, 27 May 2025 15:00:00 GMT

Evolving identity and access management for the cloud

Security, performance, and reliability are the guiding principles behind Microsoft's identity and access management solutions. These solutions empower organizations to maintain their competitive edge by leveraging technology effectively. With Microsoft's robust cloud infrastructure, customer business teams, plant workers, and external vendors can manage huge workloads independently and around the clock. Collaborative success is facilitated, ensuring timely results and efficient release cycles, helping businesses like the BMW Group stay at the forefront of their markets.

Before it can achieve results or make a measurable impact, the BMW Group must give every employee, including independent workers, highly safe and secure access to company systems and devices. It’s for that reason the whole company couldn’t function without identity management authentication. If employees can’t securely sign in to their systems and workstations, all work comes to a halt.

Microsoft's identity and access management solutions play a crucial role in enhancing security, efficiency, and user experience across various industries. For the BMW Group specifically, conversations about identity systems are occurring against a backdrop of organization-wide modernization. The company chose to move to the cloud early on so it could unlock more opportunities for on-demand flexibility, scalability, and fast access to technological innovations, especially new and advanced security features.

As the BMW Group started to migrate its IT estate to Microsoft Azure, it also wanted a more secure platform for its on-premises Microsoft Active Directory environment and domain controllers. The group has some older applications that require Active Directory identification and access services but aren’t yet compatible with next-generation, cloud-native Microsoft Entra ID protection. Some of these IT systems, servers, and applications are also old, difficult, and expensive to replace but essential to support onsite business or are standard in the automotive industry, such as the hardware and software components built into plant machinery used for car production. Use of this machinery can extend beyond 30 years. Given the dependencies, the BMW Group focuses more on building a foundation to boost reliability and stability for its production processes than integrating them with a modern authentication system.

In response, the BMW Group wanted to use its on-premises Active Directory licenses to migrate existing Active Directory servers and domain controllers to Azure while actively protecting data and storage resources, the privacy of data in server memory, and its overall operations.

Maintaining critical infrastructure with confidential virtual machines on Azure

Considering the criticality and sensitivity of its services, the BMW Group was interested in evaluating confidential computing, a technology that helps protect highly sensitive data that is in use in server memory. When the BMW Group started to look at confidential computing, Microsoft was the only vendor offering a generally available confidential computing platform for the BMW Group to bring their Active Directory domain controllers to the cloud: the Azure DCasv5 confidential virtual machines (VMs) using 3rd generation AMD EPYC™ processors. This technology allowed them to do the migration without changing any code.

BMW Group IT specialists decided to start with confidential VMs running Active Directory services as a tier 0 workload in Azure to tighten security and put those servers on a future-proven track for how to continue operating Active Directory for the next 5–10 years. As it started using confidential VMs, the BMW Group appreciated being able to eliminate several potential attack paths as it used domain controllers in a public cloud environment for the first time. Without confidential computing, the datacenter operator, host operator, and VM host operator could have been able to access company systems and the Active Directory database. On top of the added security benefits moving forward, the BMW Group IT specialists also remarked that performance for workloads and applications didn’t suffer running on the AMD based confidential VMs, which greatly reduced worries about potential lapses in availability while making the switch.

The group’s Azure DCasv5 confidential VMs using 3rd generation AMD EPYC™ processors have quickly become the center of its architecture and the main component for its domain controllers. Staying within the Microsoft ecosystem for daily identity administration, its privileged access workstation relies on Intune, Azure Bastion, Azure Key Vault, Azure Key Vault Managed HSM, and other Microsoft Security services. Additionally, many of its modern applications that don’t require earlier Active Directory support are onboarded directly to Entra ID.

Changing attitudes, adopting a Zero Trust security model, and measuring success

Many organizations recognize that security and identity and access management are two pieces of the same puzzle, each with an essential role in their organization’s operations. The BMW Group’s staff have helped build a castle, strengthening security from the outside in, and any activity within the network is on the secure side. Now, they are moving to a Zero Trust framework, which removes any implicit trust and requires each component, supplier, and authentication process to be thoroughly assessed and validated before being granted access. From this internal perspective, the main challenge is to upskill everybody in their team. It’s a completely different way to deploy infrastructure, which is now mainly done by code instead of requesting and installing a physical server.

But the result for BMW Group customers is an almost invisible benefit that’s extremely meaningful. It was key not to have any downtime or business impacts, and company staff successfully and seamlessly deployed services for customers with the first bunch of domain controllers running on Azure, without those customers noticing or having to worry about where services were coming from. The group’s main measure of success is getting rid of all its on-premises components, including all on-premises servers and many supporting systems previously needed to offer and support BMW Group services. In doing so, the BMW Group will have all of its systems needed for Active Directory operation hosted on Azure.

Achieving security goals and sharing cloud experiences across the business

The BMW Group’s new highly secure architecture and DCasv5 confidential VMs touch every part of the business across the full life cycle of identities and are used by internal and external employees, large and strategic partners, and joint venture partners. Boosting security and safeguarding its platform were the company’s main goals and are now its main benefits. The BMW Group is heavily reducing its risk, with the main goal of making it very difficult for an attacker to get into its systems. Microsoft's geographically widespread Azure datacenters enhance businesses' ability to support local branches and plants, increasing service availability and distribution around the globe.

Planned IT projects at the BMW Group include transitioning to DCasv6 VMs, the newest confidential VMs on Azure using 4th generation AMD EPYC processors, which will bring with them a 30% performance increase over what the company has already gained. IT specialists are also installing Windows Hello for Business on all client devices within the group, letting employees sign in and authenticate themselves using biometrics.

With continued success moving its sensitive workloads to Azure, the BMW Group plans to share its experiences with other teams across the organization. It also wants to bring the benefits of its architecture to other core systems that have high demand for identity and access protection, with everything it’s done so far showing what’s possible for the future.

Discover more about BMW Group on Facebook, Instagram, LinkedIn, X/Twitter, and YouTube.

Azure Confidential computing VM and OS disk encryption through HSM backed key CMK

AbhishekJha96 — Fri, 02 May 2025 05:23:08 GMT

Why Confidential Computing with HSM-Backed Keys Is Essential:

In today’s cloud-first world, protecting sensitive data during processing is just as critical as securing it at rest or in transit. Azure Confidential Computing (ACC) Virtual Machines, when combined with Hardware Security Module (HSM)-backed Customer-Managed Keys (CMKs), provide a robust solution for organizations with strict security and compliance requirements.

In this blog, we’ll explore a scenario and walk through a step-by-step solution to meet these advanced data protection needs.

Scenario:

Customer needs a highly sensitive application – May be its processing financial transactions, handling healthcare data or supporting a government workload. Customer demands not only high performance and isolation, but also complete encryption backed by Hardware Security Models (HSM)

Solution:

Components:

Azure Confidential Computing Virtual Machine (ACC VM)
Key Vault Premium (HSM Backed Key)
Key Vault Key (CMK)
Disk Encryption Set

Azure Confidential Computing VM with HSM-Backed (Key vault Premium) CMK OS Disk Encryption

ACC VM with HSM CMK disk encryption

Azure Confidential Computing (ACC) VMs are designed to protect data in use by performing computations in a hardware-based Trusted Execution Environment (TEE). This ensures that data remains secure even when it is being processed. Disk Encryption with HSM (Hardware Security Module) involves using HSM-backed keys stored in Azure Key Vault to encrypt the disks of your VMs. This provides an additional layer of security by ensuring that encryption keys are stored in a highly secure environment

Importance of Confidential VMs

Confidential VMs are crucial for organizations that handle sensitive data and require enhanced security measures. They provide the following benefits:

Data Protection: Confidential VMs protect data in use, ensuring that it remains secure even during processing.
Compliance: They help organizations meet regulatory and compliance requirements by providing robust security measures.
Trust: By using hardware-based TEEs, Confidential VMs build trust with customers and stakeholders by ensuring that data is protected at all times
Confidential VM Disk Encryption: Confidential VM OS Disk Encryption with Customer-Managed Keys (CMK) using Key Vault Premium tier backed Hardware Security Module (HSM) key provides enhanced security for virtual machines (VMs). This guide will walk you through the steps to configure confidential vm os disk Encryption with Key Vault Premium (HSM Backed Key)

The following resources must be created in sequence to deploy Azure Confidential Computing (ACC) VMs with OS disk encryption using HSM-backed Customer-Managed Keys (CMKs)

Key Vault with Premium Pricing Tier(HSM Backed Key)
Disk Encryption Set utilizing HSM key
Azure Confidential VM with Disk Encryption Set

Prerequisites to create ACC VM

1. An Azure subscription. Free trial accounts don't support confidential VM.

2. To set up Confidential disk encryption with a customer-managed key, execute the command below to opt in the Confidential VM Orchestrator service principal to your tenant.

Connect-Graph -Tenant "your tenant ID" Application.ReadWrite.All New-MgServicePrincipal -AppId bf7b6499-ff71-4aa2-97a4-f372087be7f0 -DisplayName "Confidential VM Orchestrator"New-MgServicePrincipal -AppId bf7b6499-ff71-4aa2-97a4-f372087be7f0 -DisplayName "Confidential VM Orchestrator"

3. Ensure that your subscription includes the following sizes, as Confidential VMs are supports these VM sizes only

General Purpose without local disk: DCasv5-series, DCesv5-series
General Purpose with local disk: DCadsv5-series, DCedsv5-series
Memory Optimized without local disk: ECasv5-series, ECesv5-series
Memory Optimized with local disk: ECadsv5-series, ECedsv5-series
NVIDIA H100 Tensor Core GPU powered NCCadsH100v5-series

4. OS images for confidential VMs must meet specific security requirements to support a confidential OS disk encryption and ensure isolation from the underlying cloud infrastructure. Refer to the following link for the most up-to-date list of supported OS images for Azure Confidential Computing (ACC) VMs:

OS Support Images

Steps to Configure Azure Disk Encryption Set with Key Vault Supported HSM

Step 1: Create a Key Vault with Premium Pricing Tier

1. Create Key Vault: Use the following command to create a Key Vault with the Premium pricing tier, which supports HSM-backed keys.

az keyvault create --name <keyvaultName> --resource-group <resourceGroupName> --location <location> --sku premium --enable-rbac-authorization false

2. Enable Purge Protection: Enable purge protection to add an extra layer of security.

az keyvault update --name <keyvaultName> --resource-group <resourceGroupName> --enable-purge-protection true

3. Configure Access Policy: Set the access policy to allow necessary permissions to user Manged identity. If you don’t have any user managed identity you can create one.

az keyvault set-policy --name <keyvaultName> --object-id <user-managed-identity-object-id> --secret-permissions get list --key-permissions get list --certificate-permissions get list

4. Create HSM-backed Key: Create an HSM-backed CMK key in the Key Vault.

az keyvault key create --vault-name <keyvaultName> --name <KeyName> --protection hsm

Step 2: Create a Disk Encryption Set

1. Create Disk Encryption Set: Use the following command to create a Disk Encryption Set that will use the HSM-backed key.

az disk-encryption-set create --resource-group <resourceGroupName> --name <diskEncryptionSetName> --key-url <https://<vaultEndpoint>/keys/<keyName>/<keyVersion>> --source-vault <KeyVaultName>

2. Grant Permissions: Grant necessary permissions to the Disk Encryption Set.

az keyvault set-policy --name <keyvaultName> --resource-group <KeyVault Resource Group Name> --object-id $(az disk-encryption-set show --resource-group <rg of diskEncryptionSet> --name <diskEncryptionSetName> --query "identity.principalId" -o tsv) --key-permissions wrapKey unwrapKey get

Best Practices

Use Purge Protection: Always enable purge protection for your Key Vault to prevent accidental or malicious deletion of keys.
Monitor and Audit: Continuously monitor and audit access to your Key Vault and encryption keys to detect any unauthorized access.

By following these steps and best practices, you can ensure that your data is securely encrypted using Azure Disk Encryption with Key Vault's HSM-backed keys

Step3: Azure Confidential Computing VM Creation and Disk Encryption with HSM Key

Create the ACC VM: Use the following command to create an ACC VM and encrypt OS disk with diskEncryptionSet.

az vm create --resource-group <RG of VM> --name <VM_Name> --image <Image name from supported list of os image ex. "Canonical:0001-com-ubuntu-confidential-vm-jammy:22_04-lts-cvm:latest"> --size <confidential vm supported size, ex. Standard_DC64ads_v5> --admin-username <UserName> --generate-ssh-keys --enable-vtpm true --public-ip-sku Standard --security-type ConfidentialVM --os-disk-security-encryption-type DiskWithVMGuestState --os-disk-encryption-set $(az disk-encryption-set show --resource-group <rg name diskEncryptionSet> --name <diskEncryptionSet name> --query id -o tsv)

By following these steps, you can create an Azure Confidential Computing VM and encrypt its Operating System (OS disk) using the Disk Encryption Set created earlier.

Common Questions for Azure Confidential virtual Machine

1. Custom Image can be used for confidential virtual machine (CVM)?

Ans: Yes, custom image can use for CVM. Kindly refer => Create a custom image for Azure confidential VMs | Microsoft Learn

2. What Disk SKU and encryption can be used for OS, TEMP, and DATA Disks in CVM with CMK?

Ans:

For Azure Confidential VMs, the supported disk SKUs are primarily within the "DCasv5" and "ECasv5" series. Supported VM SKUs are => Azure Confidential VM options | Microsoft Learn
Confidential OS disk encryption => About Azure confidential VMs | Microsoft Learn
Confidential temp disk encryption => About Azure confidential VMs | Microsoft Learn

3. Is CVM Backup supported in Azure backup?

Ans: Backup of ACC is not supported in Azure as of now

Announcing preview for the next generation of Azure Intel® TDX Confidential VMs

simranparkhe — Wed, 12 Nov 2025 19:35:31 GMT

Today, we are excited to announce the preview of Azure’s next generation of Confidential Virtual Machines powered by the 5^th Gen Intel® Xeon® processors (code-named Emerald Rapids) with Intel® Trust Domain Extensions (Intel® TDX). This will help to enable organizations to bring confidential workloads to the cloud without code changes to applications. The supported SKUs include the general-purpose families DCesv6-series and the memory optimized families ECesv6-series.
Confidential VMs are designed for tenants with high security and confidentiality requirements, providing a strong, attestable, hardware-enforced boundary. They ensure that your data and applications stay private and encrypted even while in use, keeping your sensitive code and other data encrypted in memory during processing.

Improvements

Azure’s next generation of confidential VMs will bring improvements and new features compared to our previous generation. These VMs are our first offering to utilize our open-source paravisor, OpenHCL. This innovation allows us to enhance transparency with our customers, reinforcing our commitment to the "trust but verify" model.

Additionally, our new confidential VMs support Azure Boost, enabling up to 205k IOPS and 4 GB/s throughput of remote storage along with 40 GBps VM network bandwidth. We are expanding the capabilities of our Intel® TDX powered confidential VMs by incorporating features from our general purpose and other confidential VMs. These enhancements include Guest Attestation support, and support of Intel® Tiber™ Trust Authority for enterprises seeking operator independent attestation.

Offerings

The DCesv6-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 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-series and ECesv6-series preview is available now in the East US, West US, West US 3 and West Europe regions. Supported OS images include Windows Server 2025, Windows Server 2022, Ubuntu 22.04, and Ubuntu 24.04. Please sign up at aka.ms/acc/v6preview and we will reach out to you.

Price reduction and upcoming features for Azure confidential ledger!

ShubhraS — Mon, 03 Mar 2025 21:41:46 GMT

Effective March 1, 2025, you can keep your records in Azure confidential ledger (ACL) at the reduced price of ~$3/day per instance! The reduced price is for the computation and the ledger use. The price of any additional storage used will remain unchanged.

To tamper protect your records: Automatically create hash (e.g. MD5 or SHA256) of your blob storage data and keep those in Azure confidential ledger. For forensics, you can verify the integrity of the data against the signature in ACL. Imagine doing this as you are migrating data from one system to another, or when you restore archived records from cold storage. It is also valuable when there is a need to protect from insider/administrator risks and confidently report to authorities.

If you keep your data in Azure SQL database, you can use their security ledger feature to auto generate record digests and store them in confidential ledger for integrity protection and safeguarding. You can use the SQL stored procedure to verify that no tampering or administrator modifications occurred to your SQL data!

In addition, we are announcing the preview of User Defined Functions for Azure confidential ledger. Imagine doing a schema validation before writing data to the Ledger or using pattern matching to identify sensitive information in log messages and perform data massaging to mask it. To increase your awareness, request access for this preview via the sign-up form.

Get started by reading our documentation and trying out confidential ledger yourself!

_____________________________________________________________________________________________________

What is Azure confidential ledger and what is the change?
It is a tamper protected and auditable data store backed by a Merkle tree blockchain structure for sensitive records that require high levels of integrity protection and/or confidentiality. While customers from AI, financial services, healthcare, and supply chain continue to use the ledger for their business transaction’s archival needs and confidential data’s unique identifiers for audit purposes, we are acting on their feedback for scaling ledgers to more of their workloads with a more competitive price!

How can I use Azure confidential ledger?

- Azure SQL database ledger customers can enable confidential ledger as its trusted digest store to uplevel integrity and security protection posture

- Azure customers who use blob storage have found value in migrating their workloads to Azure with a tamper protection check via the Azure confidential ledger Marketplace App.

- Azure customers who use data stores and databases (e.g. Kusto, Cosmos, and Log Analytics) may benefit from auditability and traceability of logs being kept in the confidential ledger with new compliance certifications in SOC 2 Type 2 and ISO27001.

How much does Azure confidential ledger cost?

- Approximately $3/day/ledger

_____________________________________________________________________________________________________

Resources

Explore the Azure confidential ledger documentation
Read the blog post on: Integrity protect blob storage
Read the blog post on: How to choose between ledger in Azure SQL Database and Azure Confidential Ledger
Read the blog post on: Verify integrity of data transactions in Azure confidential ledger
View our recent webinar in the Security Community
Recent case studies: HB Antwerp & BeekeeperAI

Azure Confidential Computing at Ignite 2024

VikasBhatia — Tue, 19 Nov 2024 16:00:00 GMT

This is another great year for Azure Confidential Computing (ACC) team at Ignite. We are announcing the availability of two new offerings:

The preview of our latest DCa/ECa v6 series confidential VMs running on 4th generation AMD EPYC™ processors, with enhanced performance and security features.

The preview of Azure Confidential Clean Rooms, a totally new PaaS for building privacy preserving multiparty analytics and collaboration solutions.

And we are amplifying the confidential AI use cases of our recently announced generally available confidential VMs with NVIDIA H100 Tensor Core GPUs.

Preview of our latest DCa/ECa v6 series confidential VMs

We are thrilled to partner with AMD to offer these confidential VMs based on 4th generation AMD EPYC processors. They offer up to 25% better CPU performance on Windows Server 2022 compared to their previous generation counterparts. Also, for Windows Server, they offer enhanced security with the option to use Virtualization-based Security (VBS) to protect secrets in a highly secure section of VM memory. And these VMs will be our most widely available confidential VM to date. To learn more and sign up for the preview read the preview blog post: https://aka.ms/Genoa-CVM-Prev-blog

Preview of Azure Confidential Clean Rooms

We are very excited to announce the preview Azure’s first confidential clean room offering, Azure Confidential Clean Rooms, a PaaS for building multi-party, privacy preserving applications, leveraging the Confidential Consortium Framework (CCF) and confidential containers on Azure Container Instances (ACI). To learn more and sign up for the preview read the preview blog post: https://aka.ms/ACCR-preview-blog

Confidential GPUs new use cases

On Thursday, November 21, at 12:30 PM CST, I will be at Ignite presenting a live demonstration of deploying an NCC H100 v5 confidential VM with NVIDIA H100 Tensor Core GPU (aka, confidential GPU) and show several use cases within the context of confidential AI including:

How to do attestation of the confidential VM and its associated GPU
Using confidential GPUs to support confidential retrieval-augmented generation (RAG)
Using confidential GPUs to support confidential speech to text translation with the preview of the confidential inference feature of the Azure OpenAI Whisper model

Please make sure to attend if you are at the event as this event is not being broadcast and will not being recorded.

Figure 1. Architecture of Azure AI confidential inferencing

Other recent ACC related announcements

We are excited to acknowledge the recent announcement of confidential containers on Azure Red Hat OpenShift (ARO). This gives ARO users the opportunity to provide an additional layer of protection of their sensitive workloads in memory from Azure operators and from your own application and tenant administrators. Read the blog post to learn more: Confidential Containers Public Preview on Azure Red Hat OpenShift | Microsoft Community Hub

We are happy to report that Azure Batch is now supported on all AMD SEV-SNP based v5 and v6 confidential VMs.

And finally, as part of Microsoft’s commitment to our Secure Future Initiative (SFI), we are announcing our newest in-house security chip, Azure Integrated HSM, a dedicated Hardware Security Module (HSM) that strengthens key protection by enabling the use of encryption and signing keys while they remain within the bounds of a HSM, without incurring the typical network access latencies for HSM access. Read the blog post to learn more: Securing Azure infrastructure with silicon innovation | Microsoft Community Hub

ACC at Ignite sessions

In addition to my confidential GPU demonstration mentioned above, ACC powered solutions are being covered in multiple sessions at Ignite including:

Azure continues to be a pioneer in confidential computing. There is more to come, and we look forward to you joining us on this journey.

Get started with Azure Confidential Computing

Documentation: https://aka.ms/accdocs
Blogs: https://aka.ms/accblogs
Customer and partner successes: https://aka.ms/accstories

Preview: New DCasv6 and ECasv6 confidential VMs based on 4th Generation AMD EPYC™ processors

Rakeshginjupalli — Wed, 20 Nov 2024 17:43:13 GMT

You can get started deploying your software on these confidential VMs by signing up here.

Additional security enhancements

With the launch of the DCasv6 and ECasv6 confidential VM family – we support AES-256 memory encryption enabled by default. Additionally, we now offer our customers the capability to leverage key protection with Virtualization-based Security (VBS) in Windows. By enabling key protection in Windows CVMs, customers can protect keys in-use from Guest OS and applications. This key protection is enforced by CPU hardware.

Faster performance for confidential workloads

These new CVMs have demonstrated up to 25% improvement in various benchmarks compared to our previous generation of AMD-based confidential VMs.

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

Worldwide Region Availability

These CVMs will be gradually made available across all supported Azure regions and availability zones. Please use the sign-up form to indicate interest in participating in the gated preview and regional requirements.

General purpose & Memory-intensive workloads

Featuring general purpose optimized memory-to-vCPU ratios and support 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, the new ECasv6-series offer high memory-to-vCPU ratios with increased scalability up to 96 vCPUs and 672 GiB of RAM. The ECasv6-series is ideal for memory-intensive enterprise applications offering nearly double the memory capacity of DCasv6. The ECasv6-series scales 672 GiB RAM with up to 96 vCPUs, making them ideal for memory intensive applications that exceed even the capabilities of the DCasv6 series.

	DCasv6	DCadsv6	ECasv6	ECadsv6
vCPU	2 - 96	2 - 96	2 - 96	2 - 96
Memory	8 - 384	8 - 384	16 - 672	16 - 672
Max local disk	NA	75-600GiB	NA	75-600GiB

OS Support

These CVMs support the following guest operating systems: Windows Server 2019, 2022, 2025, Windows 11, Ubuntu 22.04, Ubuntu 24.04, and RHEL 9.4.

Endorsements from our customers

The BMW Group relies on Azure confidential VMs powered by AMD EPYC processors to enable a Zero Trust environment with end-to-end encryption for our identity authentication system, allowing over 200,000 associates to collaborate on building the future of individual mobility. The solution was made possible in part due to the fact that AMD EPYC processor based confidential VMs do not require code changes to protect data in memory. Further, our testing of the newest generation of DCasv6 VMs has shown significant improvements in performance, and we look forward to seeing them go live on Azure. - BMW Group

Having early access to Microsoft’s latest confidential VMs is a game-changer, offering enhanced security and performance. Our customers are pleased that they won’t have to adapt existing algorithms to take advantage of computing within the optimal CVM environment available in their computing region and selected within the EscrowAI platform. - Mary Beth Chalk, Co-founder & Chief Commercial Officer, BeeKeeperAI

Anjuna is thrilled to be among the first to access Microsoft’s latest confidential VMs, powered by the newest version of the AMD SEV-SNP technology. Our ongoing partnership with Microsoft Azure provides us with early access to explore advanced security and performance features. This collaboration empowers joint Azure and Anjuna customers to leverage the newest Azure technologies from day one, enhanced by the capabilities of the Anjuna Seaglass platform. - Ofir Azoulay-Rozanes, Director of Product Management, Anjuna Security

Sign up now for exclusive access

Joining our exclusive preview program gives you an opportunity to work with the product team. To get started deploying your software on the latest confidential VMs sign up here.

Preview of Azure Confidential Clean Rooms for secure multiparty data collaboration

Deepak_JV — Thu, 26 Dec 2024 07:01:27 GMT

Today, we are excited to announce the preview of Azure Confidential Clean Rooms, a cutting-edge solution designed for organizations that require secure multi-party data collaboration.

With Confidential Clean Rooms, you can share privacy sensitive data such as personally identifiable information (PII), protected health information (PHI) and cryptographic secrets confidently, thanks to robust trust guarantees that help ensure that your data remains protected throughout its lifecycle from other collaborators and from Azure operators. This secure data sharing is powered by confidential computing, which helps protect data in-use by performing computations in hardware-based, attested Trusted Execution Environments (TEEs). These TEEs help prevent unauthorized access or modification of application code and data during use.

Organizations across industries need to perform multi-party data collaboration with business partners, outside organizations, and even within company silos to improve business outcomes and bolster innovation. Confidential Clean Rooms help derive true value from such collaborations by enabling granular and private data to be shared while providing safeguards on data exfiltration hence protecting the intellectual property of the organization and the privacy of its customers and addressing concerns around regulatory compliance.

Whether you’re a data scientist looking to securely fine-tune your ML model with sensitive data from other organizations, or a data analyst wanting to perform secure analytics on joint data with your partner organizations, Confidential Clean Rooms will help you achieve the desired results.

You can sign up for the preview here

Key Features

Secure Collaboration and Governance: Allows collaborators to create tamper-resistant contracts that contain the constraints which will be enforced by the clean room. Governance verifies validity of those constraints before allowing data to be released into clean rooms and helps generate tamper-resistant audit trails. This is made possible with the help of an implementation of the Confidential Consortium Framework CCF).
Enhanced Data Privacy: Provides a sandboxed execution environment which allows only authorized workloads to execute and prevents any unauthorized network or IO operations from within the clean room. This helps keep your data secure throughout the workload execution. This is possible with the help of deploying clean rooms in confidential containers on Azure Container Instances (ACI) which provides container group level integrity with runtime enforcement of the same.
Verifiable trust at each step with the help of cryptographic remote attestation forms the cornerstone of Confidential Clean Rooms.

Salient Use Cases

Azure Confidential Clean Rooms caters to use cases spanning multiple industries.

Healthcare: For fine-tuning and inferencing with predictive healthcare machine-learning (ML) models and for joint data analysis for advancing pharmaceutical research. This can help protect the privacy of patients and intellectual property of organizations while demonstrating regulatory compliance.
Finance: For financial fraud detection through analysis of combined data across banks and other financial institutions and for providing personalized offers to customers through secure analysis of transaction data and purchase data in retail outlets
Media and Advertising: For improving marketing campaign effectiveness by combining data across advertisers, ad-techs, publishers and measurement firms for audience targeting and attribution and measurement
Retail: For enhanced personalized marketing and improved inventory and supply chain management
Government and Public Sector Organizations: For analysis of high security data across multiple government and public sector organizations to streamline benefits for citizens

Customer Testimonials

We are already partnering with several organizations to accelerate their secure multi-party collaboration journey with confidential clean rooms.

Confidential computing in healthcare allows secure data processing within isolated environments, called 'clean rooms', protecting sensitive patient data during AI model development, validation and deployment. Apollo Hospitals uses Azure Confidential Clean Rooms to enhance data privacy, encrypt data, and securely train AI models. The benefits include secure collaboration, anonymized patient privacy, intellectual property protection, and enhanced cybersecurity. Apollo’s pilot with Confidential Clean Rooms showed promising results, and future efforts aim to scale secure AI solutions, ensuring patient safety, privacy, and compliance as the healthcare industry advances technologically.

- Dr. Sujoy Kar, Chief Medical Information Officer and Vice President, Apollo Hospitals

Azure Confidential Clean Rooms is a game changer to make collaborations on sensitive data both seamless and secure. When combined with Sarus, any data processing job is automatically analyzed using the most advanced privacy technology. Once validated, they are processed securely in Confidential Clean Rooms protecting both the privacy of data and the confidentiality of the analysis itself. This eliminates administrative overheads and makes it very easy to build advanced data processing pipelines. With our partner EY, we're already leveraging it to help international banks improve AML practices without compromising privacy.

- Maxime Agostini, CEO & Cofounder of Sarus

Read here to learn more about how Sarus is using Confidential Clean Rooms.

As co-leaders on this Data Consortium Pilot, we are thrilled to be working with industry partners, Sarus and Microsoft, to drive this initiative forward. By combining Sarus’ privacy preserving technologies and Microsoft’s Azure Confidential Clean Rooms, not only does this project push the edge of technology innovation, but it strives to address a pivotal issue that affects us as Canadians. Through this work, we aim to help financial services organizations and regulators navigate the complexities of private and personal data sharing, without compromising the integrity of the data, and adhering to all relevant privacy regulations. For the purposes of this pilot, we are focusing our efforts on how this technology can play a pivotal role in helping better detect cases of human trafficking, however, we recognize that it can be used to help organizations for multiple other use cases, and cross industries, including health care and government & public sector.

- Jessica Hansen, Privacy Partner EY Canada, and Dana Ohab, AI & Data Partner EY Canada

Retrieval-Augmented Generation (RAG) applications accessing Large Language Models (LLMs) are common in private AI workflows, but managing secure access to sensitive data can be complex. SafeLiShare’s integration of its LLM Secure Data Proxy (SDP) with Azure Confidential Clean Rooms (ACCR) simplifies access control and token management. The joint solution helps ensure runtime security through advanced Public Key Infrastructure (PKI) and centralized policy management in Trusted Execution Environments (TEEs), enforcing strict access policies and admission controls to guarantee authorized access to sensitive data. This integration establishes trust bindings between the Identity Provider (IDP), applications, and data, safeguarding each layer without compromise. It also enables secure creation, sharing, and management of applications and data assets, ensuring compliance in high-performance AI environments.

- Cynthia Hsieh, VP of Marketing, SafeLiShare

Read here to learn more about how SafeLiShare is using Confidential Clean Rooms.

Learn More

Adams Bridge: An Accelerator for Post-Quantum Resilient Cryptography

MarkRussinovich — Tue, 15 Oct 2024 19:58:50 GMT

The name Adams Bridge is inspired by the mythological structure which was said to span a vast gulf between two landmasses. In the realm of cryptography, a similar vast gap exists between classical asymmetric cryptography and quantum-resilient cryptography. Azure aims to bridge this gap by developing a fully open-source silicon quantum resilient cryptographic accelerator known as the Adams Bridge Accelerator. The Adams Bridge accelerator will be first integrated into Caliptra 2.0, and then delivered as an independent accelerator thereafter. This integration makes Caliptra the first open-source root-of-trust with hardened post quantum resilient cryptography.

The algorithms used in classical asymmetric cryptography depend on complex number theory problems, such as integer factorization or the discrete logarithm problem, for their security. However, research has demonstrated that a quantum computer with enough power can defeat current asymmetric algorithms. Given this, the National Institute of Standards and Technology (NIST) has been working closely with the industry for several years to create new algorithms that are safe from quantum threats. NIST has finalized its selection of quantum-safe algorithms and has released publications, FIPS 203 and FIP S204 in August 2024.

The newly selected post-quantum algorithms are significantly different from their classical counterparts, which calls for a new approach to the design of digital signature schemes and attestation protocols. Hardware device manufacturers and suppliers need to pay immediate attention to these changes as they impact foundational hardware security capabilities such as immutable root-of-trust anchors for both code integrity and hardware identity. Currently, the risks to hardware are more significant than for software, due to longer development times and the immutability of hardware. Therefore, immediate action is needed for new hardware designs.

To accelerate the adoption of these quantum resilient algorithms and to increase trustworthiness of hardware security, Microsoft is open sourcing our new Adams Bridge Accelerator that provides hardware acceleration for the NIST-selected quantum resilient algorithms Dilithium & Kyber.

The Register Transfer Language (RTL) code for the Adams Bridge Accelerator – ‘Dilithium component’ is open-sourced as a discrete crypto accelerator and is also integrated into the already open-sourced Caliptra Root of Trust (RoT). Providing the RTL for all portions of Adams Bridge will allow for easy uptake by industry partners, and save development time that would otherwise be spent developing identical functionality.

This new open-source Caliptra update will be made available in October 2024. The Adams Bridge Accelerator – Kyber component will be released shortly thereafter.

Figure 1 Caliptra Subsystem block diagram

Caliptra 2.0 – Root of Trust Subsystem

Caliptra, an open-source silicon root of trust for which Microsoft is a founding member, is already being adopted by leaders in modern AI infrastructure, storage and network infrastructure.

At the OCP Global Summit 2024, This version of Caliptra is not only quantum resilient, but it expands upon the capabilities of Caliptra 1.0 to include the Root of Trust for Update and Root of Trust for Recovery. Caliptra subsystem meets all the root of trust requirements of NIST 800-193 and offers a fully transparent root of trust subsystem, negating the need for additional boot controllers.

For more information about Caliptra and Adams Bridge, please visit the Caliptra website: https://Caliptra.io

General Availability: Azure confidential VMs with NVIDIA H100 Tensor Core GPUs

Krishnaprasad_Hande — Tue, 24 Sep 2024 14:40:58 GMT

Today, we are announcing the general availability of Azure confidential virtual machines (VMs) with NVIDIA H100 Tensor core GPUs. These VMs combine the hardware-based data-in-use protection capabilities of 4^th generation AMD EPYC^TM processor based confidential VMs with the performance of NVIDIA H100 Tensor Core GPUs. By enabling confidential computing on GPUs, Azure offers customers more options and flexibility to run their workload securely and efficiently on the cloud. These VMs are ideal for inferencing, fine-tuning or training small-to-medium sized models such as Whisper, Stable diffusion and its variants (SDXL, SSD), and language models such as Zephyr, Falcon, GPT2, MPT, Llama2, Wizard and Xwin.

Azure NCC H100 v5 virtual machines are currently available in East US2 and West Europe regions.

Figure 1. Simplified NCC H100 v5 architecture

Hardware partner endorsements

We are grateful to our hardware partners for their support and endorsements.

“The expanding landscape of innovations, particularly generative AI, are creating boundless opportunities for enterprises and developers. NVIDIA’s accelerated computing platform equips pioneers like Azure to boost performance for AI workloads while maintaining robust security through confidential computing.” Daniel Rohrer, VP of software product security, architecture and research, NVIDIA.

"AMD is a pioneer in confidential computing, with a long-standing collaboration with Azure to enable numerous confidential computing services powered by our leading AMD EPYC processors. We are now expanding our confidential computing capabilities into AI workloads with the new Azure confidential VMs with NVIDIA H100 Tensor Core GPUs and 4th Gen AMD EPYC CPUs, the industry's first offering of a confidential AI service. We are excited to expand our confidential computing offerings with Azure to address demands of AI workloads." Ram Peddibhotla, corporate vice president, product management, cloud business, AMD.

Customer use cases and feedback

Some examples of workloads our customers have experimented with during the preview and planning further with the power of Azure NCC H100 v5 GPU virtual machine are:

Confidential inference on audio to text (Whisper models)
Video input to detect anomaly behavior for incident prevention - leveraging confidential computing to meet data privacy.
Stable diffusion with privacy sensitive design data in the automobile industry (inference & training)
Multi-party clean rooms to run analytical tasks against billions of transactions and terabytes of data of financial institute and its subsidiaries.

	Advancing AI securely is core to our mission, and we were pleased to collaborate with Azure confidential computing to validate and test Confidential Inference for our audio-to-text Whisper models on Nvidia GPUs. Matthew Knight, Head of Security, OpenAI
	F5 can leverage Microsoft Azure Confidential VMs with NVIDIA H100 Tensor Core GPUs to develop and deploy GenAI models. While the AI model learns from private data, the underlying information remains encrypted within the Trusted Execution Environments (TEEs). This solution allows us to build advanced AI-powered security solutions, while ensuring confidentiality of the data our models are analyzing. This bolsters customer trust and strengthens our position as a leader in secure network protection. Azure confidential computing helps us build a better, more secure, and more innovative digital world. Arul Elumalai, SVP & GM, Distributed Cloud Platform & Security Services, F5, Inc.
	ServiceNow works closely with Microsoft, NVIDIA, and Opaque to put AI to work for people and deliver great experiences to both customers and employees on the Now Platform. The partnership between Opaque and Microsoft allows us to quickly deploy and leverage the power of Azure confidential VMs with NVIDIA H100 Tensor Core GPUs to deliver confidential AI with verifiable data privacy and security. Kellie Romack, Chief Digital Information Officer, ServiceNow
	The integration of the Opaque platform with Azure confidential VMs with NVIDIA H100 Tensor Core GPUs to create Confidential AI makes AI adoption faster and easier by helping to eliminate data sovereignty and privacy concerns. Confidential AI is the future of AI deployments, and with Opaque, Microsoft Azure, and NVIDIA, we're making this future a reality today. Aaron Fulkerson, CEO, Opaque Systems
	Leveraging the power of the preview of the Azure confidential VMs with NVIDIA H100 Tensor Core GPUs, our team has successfully integrated 'Constellation', a Kubernetes distribution focused on Confidential Computing, with GPU capabilities. This allows customers to lift and shift even sophisticated AI stacks to Azure confidential computing. With 'Continuum AI', we've created a framework for the end-to-end confidential serving of LLMs that ensures the utmost privacy of data, setting a new standard in AI inference solutions. We are thrilled to partner with Azure confidential computing to uncover the transformative potential of Confidential Computing, especially in the era of generative AI. Felix Schuster, CEO and co-founder, Edgeless Systems
	Cyborg is excited to collaborate with Azure in previewing Azure confidential VMs with NVIDIA H100 Tensor Core GPUs. This partnership allows us to leverage GPU acceleration for our Confidential Vector Search algorithm, maintaining the highest degree of security while readying it for the stringent performance requirements of AI applications. We eagerly await the general availability of this VM SKU as we prepare to deploy our production-grade service. Nicolas Dupont, CEO, Cyborg

“RBC has been working very closely with Microsoft on confidential computing initiatives since the early days of technology availability within Azure,” said Justin Simonelis, Director, Service Engineering and Confidential Computing, RBC. “We’ve leveraged the benefits of confidential computing and integrated it into our own data clean room platform known a Arxis. As we continue to develop our platform capabilities, we fully recognize the importance of privacy preserving machine learning inference and training to protect sensitive customer data within GPUs and look forward to leveraging Azure confidential VMs with NVIDIA H100 Tensor Core GPUs.”

Performance insights

Azure confidential VMs with NVIDIA H100 Tensor core GPUs offer best-in-class performance for inferencing small-to-medium sized models while protecting code and data throughout their lifecycle. We have benchmarked these VMs across a variety of models using vLLM.

The table below shows configuration for the tests:

VM Configuration	vCPUs – 40 cores GPU - 1 Memory – 320GB
Operating System	Ubuntu 22.04.4 LTS (6.5.0-1023-azure)
GPU driver version	550.90.07
GPU vBIOS version	96.00.88.00.11

The figure above shows the overheads of confidential computing, with and without CUDA graph enabled. For most models, the overheads are negligible. For smaller models, the overheads are higher due to increased latency of encrypting PCIe traffic and kernel invocations. Increasing the batch size or input token length is a viable strategy to mitigate confidential computing overhead.

Learn more

Azure AI Confidential Inferencing: Technical Deep-Dive

MarkRussinovich — Tue, 16 Dec 2025 17:33:48 GMT

Generative AI powered by Large Language Models (LLMs) has revolutionized the way we interact with technology. Through chatbots, Copilot, and agents, AI is amplifying human productivity across sectors such as healthcare, finance, government, and cybersecurity. Microsoft’s AI platform has been at the forefront of this revolution, supporting state-of-the-art AI models, enabling organizations to differentiate with their business, by enabling developers to deploy AI applications at scale.

At Microsoft, we recognize the trust that consumers and enterprises place in our cloud platform as they integrate our AI services into their workflows. We believe all use of AI must be grounded in the principles of responsible AI – fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. Microsoft’s commitment to these principles is reflected in Azure AI’s strict data security and privacy policy, and the suite of responsible AI tools supported in Azure AI, such as fairness assessments and tools for improving interpretability of models. Whether you’re using Microsoft 365 copilot, a Copilot+ PC, or building your own copilot, you can trust that Microsoft’s responsible AI principles extend to your data as part of your AI transformation. For example, your data is never shared with other customers or used to train our foundational models.

Confidential computing is a set of hardware-based technologies that help protect data throughout its lifecycle, including when data is in use. This complements existing methods to protect data at rest on disk and in transit on the network. Confidential computing uses hardware-based Trusted Execution Environments (TEEs) to isolate workloads that process customer data from all other software running on the system, including other tenants’ workloads and even our own infrastructure and administrators. Crucially, thanks to remote attestation, users of services hosted in TEEs can verify that their data is only processed for the intended purpose.

We foresee that all cloud computing will eventually be confidential. Our vision is to transform the Azure cloud into the Azure confidential cloud, empowering customers to achieve the highest levels of privacy and security for all their workloads. Over the last decade, we have worked closely with hardware partners such as Intel, AMD, Arm and NVIDIA to integrate confidential computing into all modern hardware including CPUs and GPUs. We have taken a full stack approach across infrastructure, containers, and services. We have the most comprehensive IaaS, PaaS and developer offerings including Confidential VMs, Confidential Containers on ACI and AKS, Microsoft Azure Attestation and Azure Key Vault managed HSMs, Azure Confidential Ledger, and SQL Server Always Encrypted.

Our approach is rooted in hardware-based TEEs, in industry standards such as EAT, SCITT and TDISP which we have helped define, and in open source hardware (e.g., the Caliptra root of trust) and software (e.g. the OpenHCL paravisor for confidential VMs). In fact, as part of our Secure Future Initiative, we have committed to protect Azure’s own infrastructure and services using confidential computing.

Azure AI Confidential Inferencing

The Azure OpenAI Service team just announced the upcoming preview of confidential inferencing, our first step towards confidential AI as a service (you can sign up for the preview here). While it is already possible to build an inference service with Confidential GPU VMs (which are moving to general availability for the occasion), most application developers prefer to use model-as-a-service APIs for their convenience, scalability and cost efficiency. Our goal with confidential inferencing is to provide those benefits with the following additional security and privacy goals:

End-to-end prompt protection. Clients submit encrypted prompts that can only be decrypted within inferencing TEEs (spanning both CPU and GPU), where they are protected from unauthorized access or tampering even by Microsoft. All intermediate services (frontends, load balancers, etc.) only see the encrypted prompts and completions.
Stateless processing. User prompts are used only for inferencing within TEEs. The prompts and completions are not stored, logged, or used for any other purpose such as debugging or training.
User anonymity. Users can remain anonymous while interacting with AI models.
Remote verifiability. Users can independently and cryptographically verify our privacy claims using evidence rooted in hardware.
Transparency. All artifacts that govern or have access to prompts and completions are recorded on a tamper-proof, verifiable transparency ledger. External auditors can review any version of these artifacts and report any vulnerability to our Microsoft Bug Bounty program.

These goals are a significant leap forward for the industry by providing verifiable technical evidence that data is only processed for the intended purposes (on top of the legal protection our data privacy policies already provides), thus greatly reducing the need for users to trust our infrastructure and operators. The hardware isolation of TEEs also makes it harder for hackers to steal data even if they compromise our infrastructure or admin accounts. Lastly, since our technical evidence is universally verifiability, developers can build AI applications that provide the same privacy guarantees to their users. Throughout the rest of this blog, we explain how Microsoft plans to implement and operationalize these confidential inferencing requirements.

How Confidential Inferencing Works

Architecture of Azure AI confidential inferencing

Architecture

Confidential inferencing provides end-to-end verifiable protection of prompts using the following building blocks:

Inference runs in Azure Confidential GPU VMs created with an integrity-protected disk image, which includes a container runtime to load the various containers required for inference.
The node agent in the VM enforces a policy over deployments that verifies the integrity and transparency of containers launched in the TEE.
An immutable, append-only transparency ledger records the container hashes and policies that have been deployed to the service, with additional auditing information when available such as pointers to container registries, SBOMs, sources, CI/CD logs, etc.
Oblivious HTTP (OHTTP) is used to encrypt the prompt from the client to the TEE, ensuring our untrusted services between the client and the TEE (TLS termination, load balancing, DoS protection, authentication, billing) only see encrypted prompts and completions.
A confidential and transparent key management service (KMS) generates and periodically rotates OHTTP keys. It releases private keys to confidential GPU VMs after verifying that they meet the transparent key release policy for confidential inferencing. Clients get the current set of OHTTP public keys and verify associated evidence that keys are managed by the trustworthy KMS before sending the encrypted request.
The client application may optionally use an OHTTP proxy outside of Azure to provide stronger unlinkability between clients and inference requests.

Attested Oblivious HTTP

The simplest way to achieve end-to-end confidentiality is for the client to encrypt each prompt with a public key that has been generated and attested by the inference TEE. Usually, this can be achieved by creating a direct transport layer security (TLS) session from the client to an inference TEE. But there are several operational constraints that make this impractical for large scale AI services. For example, efficiency and elasticity require smart layer 7 load balancing, with TLS sessions terminating in the load balancer. Therefore, we opted to use application-level encryption to protect the prompt as it travels through untrusted frontend and load balancing layers.

Oblivious HTTP (OHTTP, RFC9458) is a standard protocol that achieves this goal: a client serializes and seals the real inference request (including the prompt) with HPKE (RFC9180), a standard message sealing algorithm that uses Diffie-Hellman public shares to represent the recipient’s identity, and sends it as an encapsulated request (visible to the untrusted TLS terminator, load balancer, ingress controllers, etc.). Even though all clients use the same public key, each HPKE sealing operation generates a fresh client share, so requests are encrypted independently of each other. Requests can be served by any of the TEEs that is granted access to the corresponding private key.

To submit a confidential inferencing request, a client obtains the current HPKE public key from the KMS, along with hardware attestation evidence proving the key was securely generated and transparency evidence binding the key to the current secure key release policy of the inference service (which defines the required attestation attributes of a TEE to be granted access to the private key). Clients verify this evidence before sending their HPKE-sealed inference request with OHTTP.

Inbound requests are processed by Azure ML’s load balancers and routers, which authenticate and route them to one of the Confidential GPU VMs currently available to serve the request. Within the TEE, our OHTTP gateway decrypts the request before passing it to the main inference container. If the gateway sees a request encrypted with a key identifier it hasn't cached yet, it must obtain the private key from the KMS. To this end, it gets an attestation token from the Microsoft Azure Attestation (MAA) service and presents it to the KMS. If the attestation token meets the key release policy bound to the key, it gets back the HPKE private key wrapped under the attested vTPM key. When the OHTTP gateway receives a completion from the inferencing containers, it encrypts the completion using a previously established HPKE context, and sends the encrypted completion to the client, which can locally decrypt it.

Azure Confidential GPU VMs

Internal architecture of confidential GPU VMs with H100 Tensor Core GPUs

In confidential inferencing, all services that require access to prompts in cleartext are hosted in Azure Confidential GPU VMs. These VMs combine SEV-SNP capabilities in 4^th Generation AMD EPYC processors and confidential computing primitives in NVIDIA H100 Tensor Core GPUs to create a unified Trusted Execution Environment (TEE) across the CPU and GPU. These VMs enable deployment of high-performance AI workloads while significantly in Azure infrastructure and admins. In a Confidential GPU VM, all code and data (including keys, prompts, and completions) remains encrypted in CPU memory and when they are transferred between the CPU and GPU over the PCIe bus. The data is decrypted only within the CPU package and the on-package High-Bandwidth Memory (HBM) in the GPU, where it remains protected even from privileged access using hardware firewalls.

Azure Confidential GPU VMs support a two-phase attestation protocol. When a Confidential GPU VM starts, it boots into a layer of Microsoft-provided firmware known as the Hardware Compatibility Layer (see the recent OpenHCL blog for details). The HCL is measured by the Platform Security Processor (PSP), the hardware root of trust in the AMD EPYC processors. The measurement is included in SEV-SNP attestation reports signed by the PSP using a processor and firmware specific VCEK key. HCL implements a virtual TPM (vTPM) and captures measurements of early boot components including initrd and the kernel into the vTPM. These measurements are available in the vTPM attestation report, which can be presented along SEV-SNP attestation report to attestation services such as MAA.

When the GPU driver within the VM is loaded, it establishes trust with the GPU using SPDM based attestation and key exchange. The driver obtains an attestation report from the GPU’s hardware root-of-trust containing measurements of GPU firmware, driver micro-code, and GPU configuration. This report is signed using a per-boot attestation key rooted in a unique per-device key provisioned by NVIDIA during manufacturing. After authenticating the report, the driver and the GPU utilize keys derived from the SPDM session to encrypt all subsequent code and data transfers between the driver and the GPU.

Applications within the VM can independently attest the assigned GPU using a local GPU verifier. The verifier validates the attestation reports, checks the measurements in the report against reference integrity measurements (RIMs) obtained from NVIDIA’s RIM and OCSP services, and enables the GPU for compute offload. When the VM is destroyed or shutdown, all content in the VM’s memory is scrubbed. Similarly, all sensitive state in the GPU is scrubbed when the GPU is reset.

Hardened VM Images

Confidential inferencing will further reduce trust in service administrators by utilizing a purpose built and hardened VM image. In addition to OS and GPU driver, the VM image contains a minimal set of components required to host inference, including a hardened container runtime to run containerized workloads. The root partition in the image is integrity-protected using dm-verity, which constructs a Merkle tree over all blocks in the root partition, and stores the Merkle tree in a separate partition in the image. During boot, a PCR of the vTPM is extended with the root of this Merkle tree, and later verified by the KMS before releasing the HPKE private key. All subsequent reads from the root partition are checked against the Merkle tree. This ensures that the entire contents of the root partition are attested and any attempt to tamper with the root partition is detected.

Container Execution Policies

Much like many modern services, confidential inferencing deploys models and containerized workloads in VMs orchestrated using Kubernetes. However, this places a significant amount of trust in Kubernetes service administrators, the control plane including the API server, services such as Ingress, and cloud services such as load balancers.

Confidential inferencing reduces trust in these infrastructure services with a container execution policies that restricts the control plane actions to a precisely defined set of deployment commands. In particular, this policy defines the set of container images that can be deployed in an instance of the endpoint, along with each container’s configuration (e.g. command, environment variables, mounts, privileges). The policy is measured into a PCR of the Confidential VM's vTPM (which is matched in the key release policy on the KMS with the expected policy hash for the deployment) and enforced by a hardened container runtime hosted within each instance. The runtime monitors commands from the Kubernetes control plane, and ensures that only commands consistent with attested policy are permitted. This prevents entities outside the TEEs to inject malicious code or configuration.

Stateless Processing

Confidential inferencing adheres to the principle of stateless processing. Our services are carefully designed to use prompts only for inferencing, return the completion to the user, and discard the prompts when inferencing is complete. The prompts (or any sensitive data derived from prompts) will not be available to any other entity outside authorized TEEs.

Confidential inferencing minimizes side-effects of inferencing by hosting containers in a sandboxed environment. For example, inferencing containers are deployed with limited privileges. All traffic to and from the inferencing containers is routed through the OHTTP gateway, which limits outbound communication to other attested services. We also mitigate side-effects on the filesystem by mounting it in read-only mode with dm-verity (though some of the models use non-persistent scratch space created as a RAM disk).

Some benign side-effects are essential for running a high performance and a reliable inferencing service. For example, our billing service requires knowledge of the size (but not the content) of the completions, health and liveness probes are required for reliability, and caching some state in the inferencing service (e.g. the attention KV) or in hardware (e.g. L3 cache) is necessary for competitive performance. All such side effects are implemented in attested and transparent code and are subject to independent review. We are also actively conducting research to understand and effectively mitigate any security risks arising through these side-effects.

Confidential and Transparent Keying

Clients of confidential inferencing get the public HPKE keys to encrypt their inference request from a confidential and transparent key management service (KMS). The KMS ensures that private HPKE keys are securely generated, stored, periodically rotated, and released only to Azure Confidential GPU VMs hosting a transparent software stack.

The release of private HPKE keys is governed by key release policies. When a Confidential GPU VM requests a private HPKE key, it presents an attestation token issued by MAA that includes measurements of its TPM PCRs. The KMS validates this attestation token against the key release policy and wraps the private HPKE key with a wrapping key generated and only accessible by the Confidential GPU VM. Key wrapping protects the private HPKE key in transit and ensures that only attested VMs that meet the key release policy can unwrap the private key.

The KMS permits service administrators to make changes to key release policies e.g., when the Trusted Computing Base (TCB) requires servicing. However, all changes to the key release policies will be recorded in a transparency ledger. External auditors will be able to obtain a copy of the ledger, independently verify the entire history of key release policies, and hold service administrators accountable. When clients request the current public key, the KMS also returns evidence (attestation and transparency receipts) that the key was generated within and managed by the KMS, for the current key release policy. Clients of the endpoint (e.g., the OHTTP proxy) can verify this evidence before using the key for encrypting prompts.

Using a confidential KMS allows us to support complex confidential inferencing services composed of multiple micro-services, and models that require multiple nodes for inferencing. For example, an audio transcription service may consist of two micro-services, a pre-processing service that converts raw audio into a format that improve model efficiency, and a model that transcribes the resulting stream. Most language models rely on a Azure AI Content Safety service consisting of an ensemble of models to filter harmful content from prompts and completions. Each of these services can obtain service-specific HPKE keys from the KMS after attestation, and use these keys for securing all inter-service communication.

User Anonymity

In addition to protection of prompts, confidential inferencing can protect the identity of individual users of the inference service by routing their requests through an OHTTP proxy outside of Azure, and thus hide their IP addresses from Azure AI. Enterprise users can set up their own OHTTP proxy to authenticate users and inject a tenant level authentication token into the request. This allows confidential inferencing to authenticate requests and perform accounting tasks such as billing without learning about the identity of individual users.

Transparency

Confidential inferencing is hosted in Confidential VMs with a hardened and fully attested TCB. As with other software service, this TCB evolves over time due to upgrades and bug fixes. Some of these fixes may need to be applied urgently e.g., to address a zero-day vulnerability. It is impractical to wait for all users to review and approve every upgrade before it is deployed, especially for a SaaS service shared by many users.

Our solution to this problem is to allow updates to the service code at any point, as long as the update is made transparent first (as explained in our recent CACM article) by adding it to a tamper-proof, verifiable transparency ledger. This provides two critical properties: first, all users of the service are served the same code and policies, so we cannot target specific customers with bad code without being caught. Second, every version we deploy is auditable by any user or third party. Although we aim to provide source-level transparency as much as possible (using reproducible builds or attested build environments), this is not always possible (for instance, some OpenAI models use proprietary inference code). In such cases, we may have to fall back to properties of the attested sandbox (e.g. limited network and disk I/O) to prove the code doesn't leak data. All claims registered on the ledger will be digitally signed to ensure authenticity and accountability. Incorrect claims in records can always be attributed to specific entities at Microsoft.

When an instance of confidential inferencing requires access to private HPKE key from the KMS, it will be required to produce receipts from the ledger proving that the VM image and the container policy have been registered. Therefore, when users verify public keys from the KMS, they are guaranteed that the KMS will only release private keys to instances whose TCB is registered with the transparency ledger.

Confidential inferencing will ensure that prompts are processed only by transparent models. Azure AI will register models used in Confidential Inferencing in the transparency ledger along with a model card. Instances of confidential inferencing will verify receipts before loading a model. Receipts will be returned along with completions so that clients have a record of specific model(s) which processed their prompts and completions.

Roadmap and Resources

Confidential inferencing is a reaffirmation of Microsoft’s commitment to the Secure Future Initiative and our Responsible AI principles. It brings together state-of-the-art AI models and Azure infrastructure, with cutting edge confidential computing in Azure Confidential GPU VMs based on AMD SEV-SNP and NVIDIA H100 Tensor Core GPUs to deliver end-to-end, independently verifiable privacy.

We will continue to work closely with our hardware partners to deliver the full capabilities of confidential computing. We will make confidential inferencing more open and transparent as we expand the technology to support a broader range of models and other scenarios such as confidential Retrieval-Augmented Generation (RAG), confidential fine-tuning, and confidential model pre-training.

Learn more about the Azure AI Confidential inferencing Preview
Sign up for the preview by filling this form
Learn about the general availability of Azure Confidential GPU VMs
Discover our full range of Azure Confidential Computing solutions here.

Verify the integrity of Azure Confidential Ledger transactions with receipts and application claims

ShubhraS — Mon, 15 Jul 2024 15:00:00 GMT

In today's digital landscape, the integrity and confidentiality of transactional data are paramount. Microsoft’s Azure Confidential Ledger offers a robust solution for maintaining the privacy and confidentiality of your data. The service utilizes cryptographic techniques to generate transaction receipts, which serve as immutable evidence of the ledger's state at a specific point in time. These receipts are crucial for businesses that require a high level of trust and transparency in their operations.

Write receipts

The value proposition of Azure Confidential Ledger write receipts lies in their ability to provide a verifiable trail of all write transactions. Azure Confidential Ledger leverages the Confidential Consortium Framework (CCF), which ensures the integrity of transactions by using a Merkle tree data structure to store the hash of all transaction blocks that are added to the immutable ledger.

How write transactions are recorded in the ledger using an internal Merkle Tree data structure in CCF.

When a write transaction is completed, Azure Confidential Ledger users can obtain a cryptographic Merkle proof, or receipt, over the entry created in a Confidential Ledger to check that the write operation was recorded correctly. A write transaction receipt is evidence that the system has committed the corresponding transaction and can be used to confirm that the entry has been successfully appended to the ledger. This ensures that once a transaction has been committed to the ledger, it cannot be altered or deleted without detection.

For more details on Azure Confidential Ledger write receipts, their structure, and how to get a receipt from an active ledger, please refer to this dedicated article.

Application claims

Application claims take receipts a step further by allowing users to attach arbitrary metadata to a transaction, which are eventually reflected in write receipt response payloads. This metadata includes details specific to the transaction's context, such as the collection ID and the input content of a write operation. The application claims of a write transaction ensure that the claims digest is signed securely and stored together with the transaction itself, meaning that it cannot be tampered with once the transaction is committed.

Example of an application claim attached to a write receipt response payload.

Later, the application claims in plain format are shown in the receipt payload for the same transaction where they were added. Using the claims in plain format, users can recalculate the same claims digest (available in the write receipt) that the ledger signed in place during the transaction to verify the claim authenticity. The claims digest can help verify the write transaction receipt, giving an offline way for users to check the authenticity of the recorded claims.

By leveraging application claims, organizations can tailor the ledger to their specific needs, enhancing the utility and relevance of the data stored within receipts. Application claims are currently supported in the Azure Confidential Ledger preview API version 2023-01-18-preview and their current format is documented in this article.

Receipts and claims verification

The process of verifying write transaction receipts and application claims is straightforward and secure. Utilizing cryptographic proofs, users can independently confirm the authenticity and integrity of each transaction offline, without having to connect to the ledger or trust any central authority.

The Azure Confidential Ledger client library for Python offers useful functions to validate receipts of write transactions and calculate the claims digest from a list of application claims in an easy and seamless manner. With this verification utility, any write receipt from a Confidential Ledger service can be verified with ease and any application claims associated with the transaction can be fully authenticated.

from azure.identity import DefaultAzureCredential from azure.confidentialledger import ConfidentialLedgerClient from azure.confidentialledger.certificate import ( ConfidentialLedgerCertificateClient, ) from azure.confidentialledger.receipt import ( verify_receipt, ) LEDGER_ID = "acl-test-ledger" # Replace with the ID of the ledger to get the receipt from. TRANSACTION_ID = "2.50" # Replace with the ID of the transaction to get the receipt for. API_VERSION = "2023-01-18-preview" # Use this API version for application claims support. # Build a ConfidentialLedgerClient object through AAD. ledger_client = ConfidentialLedgerClient( f"https://{LEDGER_ID}.confidential-ledger.azure.com", credential=DefaultAzureCredential(), ledger_certificate_path="service_cert.pem", api_version=API_VERSION, ) ### We assume that the target transaction has been committed to the ledger in a previous step. ### Please refer to the Azure Confidential Ledger Python SDK samples and documentation ### for details on how to create an entry and wait for it to be committed. # Get a receipt from the ledger for the input transaction. poller = ledger_client.begin_get_receipt(TRANSACTION_ID) get_receipt_response = poller.result() print(get_receipt_response) try: # Verify the contents of the receipt, with optional application claims (if any) verify_receipt( get_receipt_response["receipt"], ConfidentialLedgerCertificateClient().get_ledger_identity(LEDGER_ID).get("ledgerTlsCertificate"), application_claims=get_receipt_response.get("applicationClaims", None), ) print(f"Receipt for transaction id {TRANSACTION_ID} successfully verified") except ValueError: print(f"Receipt verification for transaction id {TRANSACTION_ID} failed") raise

How to verify receipts (with optional application claims) using the Azure Confidential Ledger Python SDK.

The decentralized and offline approach to verification bolsters the security and reliability of the system, making Azure Confidential Ledger an ideal platform for applications that demand the highest levels of data integrity. To learn more about the Data Plane Python SDK and its receipt verification utilities, check out this section and the full sample code.

Conclusion

In conclusion, Azure Confidential Ledger's receipts and application claims offer a compelling value proposition for organizations looking to secure their transactional data. With its strong focus on integrity, confidentiality, and verifiability, Azure Confidential Ledger stands out as a leading solution in the realm of confidential computing. Whether you are managing financial transactions, supply chain management, or any other data-sensitive operation, Azure Confidential Ledger provides the assurance that your data remains untampered and trustworthy through transaction receipts and application claims.

Resources

For getting started with Azure confidential ledger write receipts and application claims, please refer to our documentation:

Azure Confidential Ledger write transaction receipts | Microsoft Learn

Verify Azure Confidential Ledger write transaction receipts | Microsoft Learn