Trust systems have long been a contentious topic in cloud computing. Standard cloud models operate on a passive assumption that you trust your cloud provider and you trust the underlying host OS, and more importantly, you trust the hypervisor not to peek at your running data.
For highly-regulated industries like healthcare, FinTech, and defence contractors, that assumption is ultimately non-compliant. Between nation-state threat models, sophisticated insider risks, and multi-tenant cloud environments, data cannot be left vulnerable while it’s still active. So this is where Confidential Computing was created to address that critical trust problem. Unfortunately, while it solves many of these critical privacy problems, it also introduces some operational trade-offs that might still prevent your security teams from adopting it.
Historically, encryption covered two states:
- Data at-rest (on disk)
- Data in-transit (over the network).
Confidential Computing completes the trifecta by introducing Data in-use protection. Confidential Computing specifically relies on Trusted Execution Environments (TEEs).
- Data at-rest --> Encrypted on disk (AES-256)
- Data in-transit --> Encrypted over network (TLS)
- Data in-use --> Encrypted within memory (TEEs)
TEEs are hardware-level enclaves embedded directly into the CPU. Memory pages inside a TEE are cryptographically isolated so that neither other tenants, host operating systems, nor hypervisors can read or manipulate the running code. Through remote attestation, an application can cryptographically prove to a remote verifier that it is running inside a legitimate, uncompromised hardware enclave before any sensitive data is sent.
For compliance-heavy sectors, Confidential Computing unlocks capabilities that were previously off-limits in shared public clouds. Multiple hospital networks, as an example, could pool proprietary patient data to train large language models or diagnostic algorithms without exposing Protected Health Information (PHI data) to each other or the cloud vendor. Likewise, banks can perform real-time cross-institutional fraud detection on combined transaction feeds while strictly maintaining individual consumer privacy. Finally, any and all organisations could choose to simplify compliance under strict regimes like the GDPR or any newly-emerging AI governance frameworks by maintaining mathematical and cryptographic proof of data privacy during computation.
While TEEs offer powerful hardware guarantees, they are often misunderstood as a complete security cure-all. A clear look at the threat model reveals significant operational boundaries. For example, those hardware TEEs protect the workload from the hypervisor, but they do not protect the hypervisor or any neighbouring workloads from a malicious or compromised application inside the enclave. Similarly, TEEs require specialised hardware instances. These carry encrypted memory limits and in many cases can force organisations into vendor lock-in or complex application refactoring to keep the Trusted Computing Base (TCB) small. And last but not least, these TEEs unfortunately inevitably contain hardware-level vulnerabilities. Firmware updates and side-channel attacks such as CVE-2024-56161 and BadRAM prove that hardware is not infallible. Patching hardware bugs can mean waiting on microcode updates or replacing silicon entirely.
For full transparency, I work at a cloud-native security company called Edera looking to solve this issue through a zero-trust lens. Since TEEs focus on protecting against a compromised hypervisor, Edera compliments this by focusing specifically on protecting against a compromised workload. Most modern multi-tenant environments need both. Edera successfully bridges the existing blind spots between hardware-bound TEEs and Kubernetes, ensuring businesses don't simply have to choose between having strict isolation and improved dev agility.
When paired with physical TEEs, Edera runs within encrypted memory pages. This delivers complete bidirectional security such as data-in-use encryption isolating your app from the cloud provider. Combined with Edera’s hypervisor-level isolation, you can keep your infrastructure safe from untrusted workload code. Unfortunately, it’s worth stating that not every cloud region, edge device, or Kubernetes cluster has access to specialised TEE hardware required for Confidential Computing. For these specific environments, there’s Edera Confidential Core. If you are not familiar with Edera Confidential Core, it’s a feature of Edera’s ultra-slim Xen-based hypervisor architecture that provides hypervisor-enforced memory encryption and SPIFFE identity-driven remote attestation. It isolates the tenant memory on page faults and provides the core benefits that we’ve come to expect from confidential computing such as encryption in memory as well as strict workload boundary protection, without requiring any specialised hardware or forcing disruptive application rewrites.
Securing data in the cloud shouldn’t be about picking a single security term, instead you should think about how you are going to define your threat model. For example, if your threat model demands protection against a cloud provider or hypervisor peeking at your data, Confidential Computing with TEEs is absolutely ESSENTIAL. If your threat model requires protecting host infrastructure from compromised, user-facing container workloads, hypervisor isolation via Edera becomes the right solution for that specific problem. However, if you need a comprehensive zero-trust isolation without being locked into expensive hardware dependencies, I hope I made the case that Edera Confidential Core is capable of bridging the gap. Cloud security should never be about forcing trade-offs between hardware availability, app performance, and data privacy. By bringing workload isolation into harmony with memory confidentiality, enterprises can run their most sensitive workloads anywhere safely.