Data security in the cloud typically covers two states: data at rest (encrypted on disk) and data in transit (encrypted over the network). There has historically been a third, harder problem: protecting data while it is being processed in memory. Azure Confidential Computing, delivered through the DCsv2-Series virtual machines, addresses this gap using hardware-enforced trusted execution environments (TEEs) built on Intel Software Guard Extensions (SGX).
What Is Confidential Computing?
Confidential computing is a security model that uses hardware-based mechanisms to isolate and protect data while it is in use—that is, while code is actively processing it inside CPU memory. The goal is to ensure that even privileged software layers (the hypervisor, the host operating system, or a cloud provider’s own administrators) cannot access the plaintext data being worked on.
The term and the surrounding ecosystem are governed by the Confidential Computing Consortium (CCC), a project under the Linux Foundation. Members include Microsoft, Intel, Google, IBM, and other major technology vendors, who collaborate to standardize TEE interfaces and promote open-source tooling for enclave development.
Azure DCsv2-Series VMs and Microsoft’s Role
Microsoft’s DCsv2-Series virtual machines are designed specifically for confidential computing workloads. According to Microsoft, launching this VM series made it one of the first cloud providers to offer virtualized confidential computing as a generally available product. The VMs run on physical hosts equipped with Intel SGX-capable processors, and each VM can allocate a portion of protected memory—called Enclave Page Cache (EPC)—for enclave execution.
From a DevOps perspective, workloads targeted at these VMs must be either:
- Enclave-aware applications written or ported using the Intel SGX SDK, Open Enclave SDK, or similar frameworks.
- Lift-and-shift confidential workloads where a compatibility layer (such as a library OS) runs an unmodified application inside an enclave.
How Intel SGX Creates Trusted Execution Environments
Intel Software Guard Extensions (SGX) is a set of CPU instructions that allow an application to create private memory regions called enclaves. Key properties of SGX enclaves include:
- Memory encryption: The CPU encrypts enclave memory automatically. Data decrypts only inside the physical CPU package, so DRAM snooping yields only ciphertext.
- Isolation from privileged software: The OS, hypervisor, and BIOS cannot read enclave contents, even with ring-0 access or physical access to the server.
- Remote attestation: A relying party (e.g., a client sending sensitive data) can cryptographically verify that a specific, unmodified enclave is running on genuine SGX hardware before sending secrets to it.
- Sealing: An enclave can encrypt data to a key derived from the enclave’s identity and the platform, so sealed secrets can only be reopened by the same enclave on the same hardware.
Intel describes SGX as the most widely researched and deployed application isolation technology in this category. The Open Enclave SDK, maintained as an open-source project within the CCC, provides a cross-platform API so developers can write enclave code that targets SGX (and other TEE types) without being locked to a single hardware vendor’s SDK.
Why the "Data in Use" Gap Matters
Traditional cloud security controls protect data at rest and in transit well. The remaining exposure occurs the moment a cloud service decrypts data to process it. At that point, a compromised hypervisor, a malicious insider with administrative access, or a memory-scraping attack could theoretically read the plaintext. Regulatory frameworks such as GDPR, HIPAA, and financial sector requirements make this a compliance concern, not just a theoretical one.
Confidential computing shrinks this attack surface by keeping data encrypted even while in use. The attack surface moves down to the CPU’s microarchitecture—a much harder target than software-layer exploits.
Practical Use Cases
Confidential computing unlocks several scenarios that are difficult or impossible to accomplish safely with conventional cloud architectures:
Multi-Party Computation
Multiple organizations can contribute sensitive datasets to a shared computation (for example, banks pooling transaction records for fraud-detection analytics) without any party exposing raw data to the others or to the cloud operator. Each party’s data enters the enclave encrypted; results exit, but intermediate plaintext never leaves the enclave boundary.
Confidential Machine Learning
Multiple parties can collaborate to train a machine learning model on combined datasets—such as anonymized health records from different providers—without sharing the underlying data. The enclave enforces that only the agreed-upon model training code runs on the combined data.
Secure Database Query Processing
Database engines running inside enclaves can process encrypted queries without the database administrator or cloud provider being able to view query contents or result sets. This removes the need to fully trust the database operator with sensitive business data.
Trusted Remote Virtual Machines
Enterprises running workloads in a partner’s or third-party cloud environment can use remote attestation to verify that their code is running in an intact enclave on genuine SGX hardware before transmitting secrets, removing dependence on contractual trust alone.
The Confidential Computing Consortium and Open-Source Ecosystem
The Confidential Computing Consortium, hosted under the Linux Foundation, sets the governance rules for interoperability standards and open-source projects related to TEEs. Its primary open-source outputs include:
- Open Enclave SDK: A cross-platform SDK for writing enclave applications that can target multiple TEE technologies.
- Enarx: A runtime for deploying applications in TEEs without rewriting them, supporting multiple hardware backends.
- Gramine (formerly Graphene-SGX): A library OS allowing unmodified Linux applications to run inside SGX enclaves.
The nonprofit governance model is intended to prevent any single vendor from controlling the standards, ensuring interoperability across cloud platforms and TEE implementations from different hardware vendors.
Architectural Considerations for DevOps Teams
Before planning a confidential computing deployment on Azure DCsv2-Series VMs, DevOps and platform engineering teams should evaluate:
- EPC size constraints: SGX enclave memory (EPC) is limited and managed by the CPU. Applications requiring large in-memory datasets may need architectural changes to process data in smaller chunks.
- Performance overhead: Context switches between trusted and untrusted execution zones and EPC paging introduce latency. Benchmark your specific workload; overhead varies significantly by access pattern.
- Attestation infrastructure: Remote attestation requires integrating with Intel’s attestation service or Microsoft Azure Attestation. This is a non-trivial pipeline addition.
- SDK and language support: SGX development is most mature for C and C++. Higher-level language support (Rust, Go, Python) exists through library OS approaches but adds complexity.
- Patching cadence: SGX has been subject to microarchitectural side-channel research (such as Spectre variants targeting enclaves). Keeping SGX platform software and microcode updated is essential.
Summary
Azure Confidential Computing on DCsv2-Series VMs, powered by Intel SGX, addresses the historically unprotected attack surface of data in use. By running sensitive workloads inside CPU-enforced encrypted enclaves, organizations can reduce reliance on organizational trust in cloud administrators, satisfy regulatory requirements for data confidentiality, and enable entirely new categories of multi-party and collaborative computation. For DevOps engineers, the practical challenges lie in EPC capacity planning, attestation pipeline integration, and the additional complexity of enclave-aware application development—areas worth investing in for workloads where data sensitivity is high.