Skip to main content
DataRidge
Category: Cryptography and Encryption

Confidential Computing

Also known as: Confidential Compute
Simply put

Confidential computing is a security technique that protects data while it is being actively processed, not just while it is stored or moving across a network. It works by isolating data inside a protected, hardware-based area of the processor so that other software running on the same system generally cannot access it during computation. This addresses the 'data in use' state, which traditional storage encryption and network encryption do not cover.

Formal definition

Confidential computing is a security and privacy-enhancing computational technique focused on protecting data in use by isolating it within a hardware-based trusted execution environment (TEE). Data is typically encrypted in memory and processed within a protected region of the CPU whose contents are shielded from other workloads, the host operating system, hypervisor, and cloud operator, with protections rooted in hardware. It complements, rather than replaces, encryption of data at rest and in transit. This entry defines the concept only; it does not cover specific TEE attestation mechanics, vendor implementation details, or threat-model limitations, and applying confidential computing does not by itself render processed data non-personal or remove applicable data protection obligations.

Why it matters

Most established data protection controls address only two of the three states in which data exists: data at rest, protected by storage encryption, and data in transit, protected by network-layer encryption. Confidential computing matters because it targets the third and historically hardest state to protect, data in use, when information must be decrypted into memory to be processed. By isolating that processing within a hardware-based trusted execution environment, the technique is intended to shield data during computation from other workloads on the same system, and in cloud settings from the host operating system, hypervisor, and cloud operator.

For organizations processing sensitive workloads in shared or third-party infrastructure, this narrows a gap in the security posture. As the cited vendors note, it can enable running analytics or AI on sensitive data in the cloud while keeping that data encrypted during processing, which may be relevant where organizational or contractual constraints limit exposure to the cloud provider. This is a security capability that can support, but does not substitute for, a broader governance and compliance program.

A critical caveat for privacy and compliance professionals: confidential computing is a technical control addressing confidentiality of data in use. It does not, by itself, render processed data non-personal, and it does not remove applicable data protection obligations. Personal data remains personal data even when processed inside a trusted execution environment, so lawful basis, transparency, retention, cross-border transfer, and accountability obligations continue to apply and must be addressed separately.

Who it's relevant to

Security architects and privacy engineers
Those designing systems that process sensitive workloads in shared or cloud infrastructure may evaluate confidential computing to reduce exposure of data in use. They should treat it as one control among several, assess the specific TEE and attestation model in use, and confirm it is layered with at-rest and in-transit protections rather than substituted for them.
Data protection officers and privacy leads
DPOs and privacy leads should understand that confidential computing is a confidentiality control for data in use and does not by itself make processed data non-personal or discharge data protection obligations. Lawful basis, transparency, retention, and cross-border transfer requirements remain to be addressed independently, and any reliance on this control as a risk-reducing measure should be documented as demonstrable evidence rather than stated intent.
Cloud and infrastructure decision-makers
Teams evaluating cloud services where the provider is part of the threat model may consider confidential computing to limit the operator's access to data during processing. They should scrutinize vendor-specific implementation and attestation details, since assurance varies by deployment and the concept alone does not guarantee a particular outcome.
Teams running AI or analytics on sensitive data
Organizations processing sensitive datasets or protected models through analytics or AI pipelines may use confidential computing to protect data and models in use. This addresses a specific technical exposure and should be integrated into, not treated as a replacement for, the organization's wider governance and compliance controls.

Inside Confidential Computing

Trusted Execution Environment (TEE)
A hardware-isolated region of a processor that protects code and data in use by shielding them from the rest of the system, including the host operating system, hypervisor, and privileged administrators. TEEs are the foundational technology on which most confidential computing implementations rely.
Data-in-use protection
Confidential computing addresses protection of data while it is being processed in memory, complementing established controls for data at rest (storage encryption) and data in transit (transport encryption). It does not replace those other controls; all three states typically require separate treatment.
Memory encryption and isolation
Mechanisms that keep the contents of the protected environment encrypted or isolated in memory so that other workloads and system software cannot read or tamper with them during execution.
Remote attestation
A process by which a relying party can obtain cryptographic evidence about the identity and integrity of the code running inside the TEE and the environment's configuration before entrusting it with sensitive data. Attestation supports, but does not by itself establish, trust.
Relationship to data governance and security
Confidential computing is an information security control addressing confidentiality and integrity of data in use. It is not a data governance mechanism in itself and does not, on its own, address ownership, stewardship, data quality, lineage, cataloging, or policy definition, though it may be adopted as part of a broader governance and security program.

Common questions

Answers to the questions practitioners most commonly ask about Confidential Computing.

Does confidential computing make data non-personal or take it outside the scope of data protection law?
No. Confidential computing protects data in use by isolating and encrypting it within a hardware-based trusted execution environment, but the underlying data remains personal data where it identifies or relates to an individual. Like encryption or tokenization, it is a security control that reduces risk of unauthorized access, not a technique that removes data from the scope of regimes such as the EU GDPR, the UK GDPR, or the CCPA and CPRA. Where data is decrypted and processed inside the environment, it is still being processed and the controller's obligations continue to apply.
Is confidential computing the same as encryption at rest and in transit, just extended to data in use?
It is related but not identical. Encryption at rest and in transit protects stored and moving data, while confidential computing addresses data during processing by executing workloads inside a hardware-isolated trusted execution environment, typically with memory encryption and attestation. It generally complements rather than replaces the other two states of encryption; an implementation usually needs all three to reduce exposure across the data lifecycle. Confidential computing also introduces attestation, a verification step that has no direct equivalent in conventional at-rest or in-transit encryption.
How does attestation work in a confidential computing deployment, and why does it matter?
Attestation is the process by which a workload or a relying party verifies that code is running inside a genuine, expected trusted execution environment before sensitive data is released to it. It typically produces cryptographic evidence about the environment's identity and configuration. It matters because the security benefit depends on trusting the right environment; without attestation, a workload cannot reliably confirm it is running in the intended isolated context. Implementers generally treat attestation verification and key-release policies as core design decisions rather than optional add-ons. This entry does not cover specific vendor attestation protocols or their comparative assurance levels.
How should confidential computing be reflected in a data protection impact assessment or risk analysis?
Where a data protection impact assessment is being conducted, confidential computing can be documented as a technical measure that mitigates certain risks, particularly unauthorized access by infrastructure operators or co-tenants during processing. It does not by itself determine whether an assessment is required, and its presence does not eliminate the need to consider other risks such as lawful basis, retention, or data subject rights. Accountability generally requires demonstrable evidence, so organizations typically document the environment's configuration, attestation approach, and residual risks rather than merely stating that confidential computing is used. This entry does not address when an assessment is mandatory in a given jurisdiction.
Which party bears responsibility for a confidential computing control in a cloud arrangement?
Responsibility typically follows the underlying roles and contractual arrangement. A cloud provider commonly supplies the trusted execution environment as part of the infrastructure, while the organization deploying a workload configures attestation, key management, and application logic. Under most data protection regimes, the data controller retains accountability for the processing, and where a provider acts as a processor its obligations are generally set out in a processing agreement. The existence of a hardware isolation feature does not reassign controller or processor status; that determination depends on who decides the purposes and means of processing.
What are the practical limitations of confidential computing that implementers should plan for?
Confidential computing generally protects data while it is processed inside the trusted execution environment, but data leaving that boundary, for example in outputs, logs, or results, is not automatically protected by the same mechanism. The strength of the assurance depends on correct attestation, key-release policies, and the integrity of the code running inside the environment; a compromised or poorly configured workload can still expose data. It does not address retention, cross-border transfer mechanics, data quality, lineage, or governance obligations such as records of processing. Organizations typically treat it as one layer within a broader set of security and governance controls rather than a standalone compliance solution.

Common misconceptions

Data processed inside a trusted execution environment is no longer personal data and therefore falls outside data protection obligations.
Confidential computing is a technical control that protects data in use; it does not change the legal character of the data. If the data relates to identifiable individuals, it generally remains personal data (or special category data where applicable) under regimes such as the EU GDPR or UK GDPR, and processing obligations continue to apply. Treatment can differ across jurisdictions such as the CCPA and CPRA or HIPAA.
Adopting confidential computing guarantees compliance with data protection or security requirements.
No single control guarantees compliance. Confidential computing addresses a specific risk to data in use and must be assessed alongside lawful basis, retention, cross-border transfer mechanics, access governance, and other controls. Compliance depends on context, jurisdiction, and implementation, and accountability generally requires demonstrable evidence rather than deployment of a technology alone.
A trusted execution environment removes the need to trust the cloud provider or infrastructure operator.
Confidential computing can reduce reliance on certain layers of the stack and privileged operators for data in use, but trust is not eliminated. Assurance typically depends on remote attestation, the integrity of the hardware vendor and supply chain, correct configuration, and the code running inside the environment. These dependencies should be evaluated rather than assumed away.

Best practices

Treat confidential computing as one layer of a defense-in-depth strategy, retaining separate controls for data at rest and data in transit rather than relying on data-in-use protection alone.
Continue to apply data protection obligations to data processed within a trusted execution environment, since the data generally remains personal or special category data where individuals are identifiable, and confirm the correct treatment for each applicable regime.
Use remote attestation to verify the identity, integrity, and configuration of the execution environment and its code before releasing sensitive data to it, and document the attestation policy.
Assess residual trust dependencies, including the hardware vendor, supply chain, and configuration, rather than assuming the technology removes all reliance on the provider or infrastructure operator.
Integrate confidential computing into the broader governance program by defining ownership, stewardship, and policy separately, since the control addresses security of data in use and not governance functions such as lineage, cataloging, or data quality.
Maintain demonstrable evidence of design decisions, attestation records, and configuration to support accountability, and scope the assessment to note that cross-border transfer mechanics, retention rules, and enforcement consequences require separate analysis.