{"slug": "confidential-computing-in-the-real-world-finding-your-use-case", "title": "Confidential computing in the real world: finding your use case", "summary": "Intel and Canonical detailed how Intel Trust Domain Extensions (TDX) isolate sensitive workloads inside hardware-protected Trust Domains, with Canonical supplying the Ubuntu guest software needed to run them, in a joint webinar-based explainer published 2 October 2026. The two companies said the TDX module and processor prevent the host hypervisor from reading or modifying a protected virtual machine's memory, while remote attestation lets a verifier check the platform's security state and release decryption keys only to an approved environment. Canonical noted that a VM's initial attestation does not cover every application it later loads, so boot-time measurements recorded in TDX runtime measurement registers (RTMRs) and filesystem integrity mechanisms such as dm-verity can extend verification.", "body_md": "[Ijlal Loutfi](https://ubuntu.com/blog/author/ijlal-loutfi)\n\n2 October 2026\n\n# Confidential computing in the real world: finding your use case\n\nConfidential computing is essential when an organization needs to process sensitive data on infrastructure where the operators should not have access to it. You might have seen this requirement before: it appears commonly in public cloud deployments (where organizations want to prevent the cloud vendor seeing data), but also when hospitals evaluate proprietary AI models on premises (to keep patient info from being seen by IT managers) or when businesses analyse data together without disclosing their underlying records.\n\nIntel develops the hardware technologies that isolate workloads from the infrastructure running them, while Canonical works on the Ubuntu software needed to use those protections. Together, we examine where confidential computing is useful and the engineering needed to support it.\n\n# What confidential computing protects\n\nEncryption at rest and in transit protects stored data and network traffic. However, during processing, applications need access to plaintext, which traditional virtualization leaves accessible to sufficiently privileged host software. Confidential computing protects data during this stage by processing it inside a hardware-isolated environment, commonly called a trusted execution environment, or TEE.\n\n# How Intel TDX works\n\nOur examples are inspired by a [webinar](https://www.brighttalk.com/webcast/6793/674907) we ran with Intel. The examples use Intel Trust Domain Extensions (TDX) to explain how this protection works at the virtual-machine level. With Intel TDX, the protected environment is a virtual machine called a Trust Domain. A virtual machine is a software-defined computer running its own operating system and applications. The hypervisor is the host software that creates and manages those machines.\n\nThe hardware and the TDX module enforce protections that would otherwise depend on the host hypervisor. The TDX module is Intel’s security software that works with the processor to manage and isolate Trust Domains. Together, they prevent the host hypervisor from directly reading or modifying the VM’s protected memory.\n\nBefore sending sensitive data to that VM, a data owner also needs to check what environment they are trusting. Remote attestation supplies cryptographic evidence of the platform’s security state and the VM’s measured configuration. A verifier checks that evidence against an agreed policy: a key service can then release decryption keys only to an approved environment.\n\nFor an enterprise, this changes the conditions under which a workload can be outsourced. The infrastructure provider can operate the host without its hypervisor having ordinary access to the protected guest’s memory. The guest operating system and application remain inside the trust boundary.\n\n# The role of the guest side in confidential computing\n\nHardware isolation protects the VM from the infrastructure, but the software running inside the guest determines what happens to the data once it arrives. The “guest” is the operating system and applications inside the VM, as distinct from the host that runs it. At Canonical, this includes the Ubuntu guest operating system and its boot and runtime security.\n\nThat software must preserve the protections the deployment relies on. Teams also need workable processes for managing confidential VMs, including updates and recovery, while data owners need to understand what the attestation evidence actually establishes.\n\nA VM’s initial attestation does not automatically cover every application it will load or every action it will take, but there are additional mechanisms you can use to gather more information. The boot process can record additional software measurements in TDX runtime measurement registers (RTMRs), allowing a verifier to check more of the boot chain. Filesystem integrity mechanisms such as dm-verity can help ensure that an approved filesystem has not been altered. These checks need to be connected to the policy used to release secrets.\n\nRuntime controls remain necessary, even on the guest side. An administrator with access inside the guest may still be able to read application data, and an update can change the software that was previously approved. Therefore, the deployment needs to define which administrative operations are permitted and how new software versions become trusted.\n\nData owners need this because proof that a VM is genuine doesn’t tell them what the VM will do with their data. Before releasing data, a data owner might want to know that the VM won’t persist it, that it has no known critical CVEs, and that someone they trust has audited the code and found no backdoors. Attestation alone cannot establish all of those properties, and needs to be combined with software review, vulnerability information and controls on application behaviour.\n\nTransparency logs help with the audit question. They are append-only records of published software, so anyone can check efficiently whether a given build is included and verify that later versions of the log preserve its earlier entries.\n\n# Four common patterns for deploying confidential workloads\n\nThe webinar groups confidential computing deployments into four common patterns to help you identify where confidential computing could fit your organization. They differ mainly in whose data or software needs protection, and who should be prevented from accessing it. A deployment can combine more than one pattern.\n\n### Protected outsourcing\n\nA company runs a sensitive workload on infrastructure it doesn’t control, usually a public cloud, and uses confidential computing to keep the provider and its administrators away from the data. Regulation, sovereignty requirements, and concern about malicious insiders are the usual reasons for this approach.\n\n[Proximus](https://www.proximusnxt.lu/en/securing-your-data-leveraging-confidential-computing), Belgium’s largest communications provider, uses a tiered design of this kind, with open data in standard cloud deployments, internal confidential data in confidential VMs, and GDPR-regulated subscriber data in confidential deployments that add application isolation and geographic controls.\n\n## Multi-party analysis\n\nSeveral organizations want to derive insights from their data without giving one another access to the underlying records. Examples include detecting money laundering across banks and identifying insurance fraud. They authorize an agreed application to process the data inside a confidential environment and control which results it can release. The application can read the records to perform the calculation while the participating organizations receive permitted outputs, such as aggregate statistics, rather than unrestricted access to each other’s raw data.\n\nBeeKeeperAI takes this approach with Novartis for rare disease research, where the relevant data is spread across hospitals with restrictions on moving or disclosing patient records. [Another example is from an Intel case study,](https://cdrdv2-public.intel.com/788399/Confidential%20Computing%20Partner%20Enablement%20Pkg.pdf#page=8) which describes a deployment in which the analysis runs next to each hospital’s data and updates a shared model, and neither Novartis nor BeeKeeperAI staff see the records.\n\n## Secure SaaS\n\nA software provider uses confidential computing to offer a service, often an AI model, to customers who don’t want to expose their data to the provider, while the provider doesn’t want to expose its model. Here, the customer is using someone else’s application. The design must protect customer inputs from the service operator while also protecting the provider’s software or model from the customer.\n\n[Gemini on Google Distributed Cloud](https://cloud.google.com/blog/topics/hybrid-cloud/gemini-is-now-available-anywhere) illustrates this requirement for a managed AI service deployed on customer premises. Google describes support for Intel TDX on CPUs and NVIDIA confidential computing on GPUs. These protections help customers process sensitive data while protecting Google’s proprietary model.\n\n## Protected end-user applications\n\nA service provider uses confidential computing to process users’ personal data in a protected environment, where the provider’s administrators cannot directly inspect it. This allows the provider to deliver the service while restricting its own access to the contents of users’ requests.\n\nThe focus here is the relationship between an individual and the service they use, rather than organizations contributing datasets to a joint analysis. The user should be able to obtain a result without giving the operator unrestricted access to the contents of their request.\n\nApple’s Private Cloud Compute is one example. Apple has [announced an expansion onto Google Cloud](https://security.apple.com/blog/expanding-pcc/) using Intel TDX and NVIDIA GPUs. Its design combines confidential computing with restrictions on privileged access and verifiable software transparency to support its privacy commitments. Those commitments depend on the complete service architecture, including how requests are handled and data is retained.\n\n# AI as the main source of new demand for confidential computing\n\nAI workloads can fit any of the four patterns. An organization outsourcing model training needs protection from infrastructure operators; hospitals evaluating a model across their datasets face a collaboration problem; a commercial inference service may need to protect both customer prompts and proprietary model weights.\n\nThe hardware isolation and attestation described earlier can protect the environments that perform training, fine-tuning, or inference. Federated learning is a related deployment approach: each participant trains on its own data and shares model updates instead of pooling raw records. Confidential computing is necessary because keeping data local does not, by itself, prevent privileged software from accessing it or stop shared updates from revealing information. Confidential computing can protect local processing and the aggregation of updates.\n\nIn healthcare, [MLCommons demonstrated MedPerf on Google Cloud Confidential Space](https://mlcommons.org/2026/07/medperf-google-cloud-confidential/) to evaluate a brain tumour segmentation model developed at Duke University, working with the FeTS community. The MedPerf confidential environment on Google Cloud protects patient data and model weights during evaluation and helps protect benchmark integrity. This is an example of the multi-party analysis pattern: institutions can contribute to an evaluation while controlling access to their private assets.\n\n# Getting started\n\nYou can now use the four patterns covered in this blog to identify a workload where access to data is preventing a deployment or collaboration. Establish who owns the sensitive inputs, which software must process them, and which operators should be excluded from access. That gives you a concrete basis for choosing the isolation boundary and deciding what must be verified before data is released.\n\nGood candidates include a workload held back from cloud migration by concerns about provider access, or an analysis that requires data from organizations unable to disclose their records to one another. The examples in the session show how confidential computing can address those barriers and where additional software controls are needed.\n\nWatch the webinar\n\nFor a full rundown of confidential computing use cases, check out our [pre-recorded webinar](https://www.brighttalk.com/webcast/6793/674907). The full session, including the customer examples and a closer look at attestation, is available on demand.\n\n[Watch *Confidential computing in the real world* on demand](https://www.brighttalk.com/webcast/6793/674907)\n\nTo discuss your own use case, [get in touch with our confidential computing team](https://ubuntu.com/confidential-computing#get-in-touch).", "url": "https://wpnews.pro/news/confidential-computing-in-the-real-world-finding-your-use-case", "canonical_source": "https://ubuntu.com//blog/confidential-computing-use-cases", "published_at": "2026-10-02 11:59:10+00:00", "updated_at": "2026-10-02 12:06:27.790435+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-policy"], "entities": ["Intel", "Canonical", "Intel Trust Domain Extensions (TDX)", "Ubuntu", "Ijlal Loutfi", "Trust Domain", "dm-verity", "TDX runtime measurement registers (RTMRs)"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/confidential-computing-in-the-real-world-finding-your-use-case", "markdown": "https://wpnews.pro/news/confidential-computing-in-the-real-world-finding-your-use-case.md", "text": "https://wpnews.pro/news/confidential-computing-in-the-real-world-finding-your-use-case.txt", "jsonld": "https://wpnews.pro/news/confidential-computing-in-the-real-world-finding-your-use-case.jsonld"}}