Short answer. Confidential computing protects data while it is being processed, the third state of encryption alongside data at rest and data in transit. The computation runs inside a hardware-based, attested Trusted Execution Environment (TEE) that isolates data and code from the operating system, the hypervisor, and the cloud provider itself. Financial services leads adoption: 37% of the sector runs confidential computing in full production, because it lets a bank compute on regulated data without exposing that data to the infrastructure underneath it.
Most security controls cover two states of data. Encryption at rest protects files on disk. Encryption in transit, usually TLS, protects data moving across a network. Both leave one gap: to be useful, data must be decrypted in memory while an application runs. In that window, anyone with sufficient access to the host, a compromised hypervisor, or a privileged insider can read it in plain form.
Confidential computing closes that gap. It performs the computation inside a CPU-level Trusted Execution Environment that keeps data and code encrypted in memory and decrypts them only inside a hardware boundary the operating system cannot enter. Before any secret is released to that environment, remote attestation produces cryptographic proof that the code and hardware are genuine and unmodified. The main hardware families are Intel SGX and TDX, AMD SEV-SNP, and Arm CCA.
The pattern shows up wherever sensitive data meets shared infrastructure:
Adoption is concentrated in regulated sectors. Financial services runs 37% of deployments in full production, ahead of healthcare at 29% and government at 21%. Three of the world’s ten largest banks already use the technology to collaborate on data they could not otherwise share.
For financial entities in the EU, in-use protection moved from good practice to a documented obligation. The Digital Operational Resilience Act (DORA) has applied since 17 January 2025. Its regulatory technical standard on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, requires in Article 6 that firms encrypt data at rest, in transit, and in use where feasible, and record the reasons whenever in-use encryption is not applied. Confidential computing is the practical way to meet the “in use” line rather than explain its absence.
The obligation compounds with data protection law. GDPR Article 25 requires data protection by design, and Article 32 names encryption and pseudonymisation as appropriate technical measures for the security of processing. Confidential computing extends those measures to the one stage they historically could not reach, the moment of computation, which matters most when a bank or insurer feeds customer records to an AI model hosted on infrastructure it does not own.
Confidential computing protects data in use, the third encryption state after at rest and in transit, inside a hardware-based Trusted Execution Environment.
Encryption at rest and in transit both assume data will be decrypted somewhere trusted before it is used. That assumption breaks in shared cloud and multi-tenant environments, where the “somewhere” is memory owned by a provider and reachable by a hypervisor, a host administrator, or malware that has escalated privilege. Confidential computing removes the assumption. Data stays encrypted in memory and is decrypted only inside the processor’s protected region, so the surrounding software stack never sees it in the clear. The three states are complementary, not alternatives: a compliant design encrypts at rest, in transit, and in use.
A Trusted Execution Environment is a hardware-isolated region of a processor that provides three guarantees the Confidential Computing Consortium defines as the core of the model: data confidentiality, data integrity, and code integrity. Data inside cannot be read from outside, cannot be altered without detection, and the code running inside cannot be swapped or tampered with. Remote attestation lets a relying party verify all three before trusting the environment with a key or a dataset. The Consortium sits at the Linux Foundation and includes the main chip vendors and cloud providers, which is why the same guarantees are available across Intel, AMD, and Arm hardware and across the large public clouds.
AI raises the stakes because the sensitive material is on both sides of the computation: the input data and the model itself. Confidential AI runs inference or fine-tuning inside a TEE so that prompts, documents, customer records, and model weights all stay encrypted in use. A bank can send claims or transaction histories to a proprietary model without the host reading them, and the model owner can serve those weights without exposing intellectual property. The same isolation supports secure multi-party setups, where several institutions contribute data to a shared model and none of them, nor the operator, sees another party’s raw records. For regulated firms this is often the control that makes a stalled AI project deployable, because it answers the data-exposure objection that legal and risk teams raise first.
Start by classifying which workloads process regulated data in memory: fraud analytics, credit scoring, document AI, and any inference over customer data are the usual candidates. Map each one to the DORA Article 6 obligation and note where in-use encryption is currently absent. Then pilot a single workload on a confidential virtual machine, require attestation evidence as an acceptance criterion, and treat the attestation reports as audit artifacts. Keep the control inside your wider governance model rather than adopting it as an isolated tool, so that key management, logging, and accountability stay consistent with the rest of the ICT risk framework.
Ableneo builds AI systems that reach production in regulated environments. In 2025 the team shipped 34 production AI projects across four countries, and 94% of them used large language models, much of that work in financial services and insurance across Slovakia, the Czech Republic, and Austria. Confidential computing fits our view of AI as governed infrastructure: one control among data governance, observability, and human oversight, chosen when a workload genuinely needs in-use protection rather than added by default. We help FS&I teams decide where it earns its place and how to prove it to an auditor. More context sits in our AI transformation FAQ.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.