Originally reported by CRN. Original publication date: August 22, 2019.
The Problem: Data In Use Remains Exposed
Enterprise security teams have well-established tools for encrypting data at rest (on disk) and data in transit (over the network). The third state — data in use, actively loaded into memory and being processed by a CPU — has historically been left unencrypted and therefore vulnerable.
As Lorie Wigle, Intel’s VP overseeing platform security product management, put it in a blog post at the time:
“Whether running on your own servers on-prem, in an edge deployment or in the heart of a cloud service provider’s data center, this ‘in-use’ data is almost always unencrypted and potentially vulnerable.”
Lorie Wigle, Intel
This gap becomes especially significant in multi-tenant cloud environments, where multiple workloads share the same physical hardware and a compromised hypervisor or operating system could, in principle, read another tenant’s in-memory data.
Introducing the Confidential Computing Consortium
To address this problem, the Linux Foundation announced the formation of the Confidential Computing Consortium (CCC) in August 2019. The founding members committed to making open-source contributions and included:
- Alibaba
- Arm
- Baidu
- Google Cloud
- IBM
- Intel
- Microsoft
- Red Hat
- Swisscom
- Tencent
Jim Zemlin, Executive Director of the Linux Foundation, framed the initiative as foundational industry work:
“The earliest work on technologies that have the ability to transform an industry is often done in collaboration across the industry and with open-source technologies. The Confidential Computing Consortium is a leading indicator of what’s to come for security in computing and will help define and build open technologies to support this trust infrastructure for data in use.”
Jim Zemlin, Executive Director, The Linux Foundation
What Is Confidential Computing?
Confidential computing refers to hardware and software techniques that allow systems to process sensitive data in memory while isolating it from the rest of the system — including the operating system, the hypervisor, and the cloud provider’s management stack. The goal is to ensure that even a privileged administrator or a compromised system layer cannot access data while it is being computed on.
The consortium’s work spans three areas:
- Technical standards: Defining common APIs and attestation mechanisms so that confidential computing solutions interoperate across hardware architectures and cloud platforms.
- Regulatory frameworks: Working with standards bodies to help regulated industries (finance, healthcare, government) adopt these technologies with confidence.
- Open-source tooling: Producing and maintaining libraries, SDKs, and frameworks accessible to any developer or organization.
Trusted Execution Environments (TEEs): The Core Mechanism
A central concept in confidential computing is the Trusted Execution Environment (TEE), sometimes called a trusted enclave. A TEE is a hardware-isolated region of memory where code and data are protected from access by any other software — including the operating system and cloud management stack.
As Wigle explained:
“Combined with encrypted data storage and transmission methods, TEEs can create an end-to-end protection architecture for your most sensitive data.”
Lorie Wigle, Intel
Intel SGX: Hardware-Backed Enclaves
Intel contributed the software development kit (SDK) for Intel Software Guard Extensions (Intel SGX) to the consortium. SGX is a set of CPU instructions that lets an application create a private, hardware-protected memory region — an enclave — with a direct hardware interface that bypasses the OS and hypervisor.
Wigle distinguished SGX from full memory encryption approaches:
“Unlike full memory encryption technologies that leave the data within the attack surface of the OS and cloud stack, Intel SGX allows a specific application to create its own protected enclave with a direct interface to the hardware, limiting access and minimizing the overall performance impact for both the application and any other virtual machines or tenants on the server.”
Lorie Wigle, Intel
At the time of the announcement, Intel SGX was available in Xeon E-2100 processors and was supported by cloud instances from Microsoft Azure, IBM Cloud Data Guard, Baidu, Alibaba Cloud, and Equinix. Intel also disclosed plans for an SGX add-in card for servers and future SGX support in mainstream Xeon chips.
Microsoft Open Enclave SDK
Microsoft contributed the Open Enclave SDK, an open-source framework that allows developers to write enclave-based applications once and run them across multiple TEE implementations — abstracting away the differences between hardware platforms.
Red Hat Enarx
Red Hat contributed Enarx, a project designed to support running “private, fungible serverless” applications inside TEEs. Enarx aims to let workloads run in trusted environments without developers needing to rewrite code for each specific hardware TEE implementation.
Known Limitations and Vulnerabilities in Intel SGX
It is worth noting that Intel SGX is not without a security track record of its own. Research groups had previously reported vulnerabilities against the technology:
- Foreshadow (L1TF): A speculative execution vulnerability that could leak enclave data. Intel stated this had been mitigated through microcode and OS patches.
- Malicious code execution in enclaves: Researchers demonstrated that malicious code could be loaded and run inside an SGX enclave. Intel’s position was that this falls outside SGX’s threat model, since SGX is designed to protect enclave code from the outside system — not to validate that the code loaded into the enclave is itself trustworthy. Intel’s guidance: “In all cases, we recommend utilizing programs, files, apps, and plug-ins from trusted sources.”
These disclosures highlight an important nuance for practitioners: TEEs protect against external access to enclave memory, but they do not independently verify the integrity or trustworthiness of the workload running inside. Attestation mechanisms — which allow a remote party to verify what code is running in an enclave — are a separate and complementary concern that the CCC’s work also addresses.
Industry Reception
Miles Ward, CTO at SADA Systems (a Google Cloud partner), welcomed the initiative:
“Vendors working together, in the open, to drive secure-by-default solutions that work coherently across providers is a big step forward for customers. Building on initiatives like homomorphic encryption (already available in Google BigQuery), CSEK and CMEK controls, secure enclaves for trusted execution can only accelerate progress towards these critical requirements.”
Miles Ward, CTO, SADA Systems
Why This Matters for DevOps and Platform Engineers
For teams running workloads in public cloud environments, confidential computing represents a shift in the trust model. Historically, using a cloud provider required trusting the provider’s entire infrastructure stack, including its hypervisor and privileged system software. TEEs allow sensitive computation to be isolated at the hardware level, so that:
- Regulated data (PII, financial records, health records) can be processed in the cloud without relying solely on contractual trust in the provider.
- Multi-party computation scenarios become more practical — different organizations can contribute data to a shared computation without any party (including the cloud host) seeing the raw inputs.
- Zero-trust architectures gain a hardware-backed foundation for workload isolation.
The Confidential Computing Consortium’s ongoing work — including the Open Enclave SDK, Enarx, and Intel SGX SDK — is available through the Linux Foundation. Engineers evaluating confidential computing for their workloads should review the CCC’s current project portfolio for the latest status of each tool, as the ecosystem has continued to evolve since the consortium’s 2019 launch.