Confidential computing and the new regulatory focus on data in use

Most organizations already understand encryption at rest and encryption in transit. These controls are mature, widely deployed, and often explicitly referenced in security frameworks.

However, runtime is different: when an application processes sensitive information, that data is typically available in memory. In a traditional infrastructure model, the workload owner may need to trust a large stack of privileged components below the workload, such as the firmware, the hypervisor, the host operating system, and the infrastructure operator. For many workloads, that trust model is acceptable; however, for highly regulated workloads, it can become a problem.

This issue can be seen in highly sensitive use cases, such as financial analytics, healthcare research, public sector data sharing, fraud detection, confidential AI inference, or cross-organization collaboration: In each case, the organization wants to use sensitive data, but it also needs to reduce who or what can access it during processing.

Confidential computing is a hardware-backed approach to protecting data while it is being processed. It uses trusted execution environments to help isolate workloads from parts of the underlying infrastructure, reducing the amount of software and privileged access that must be trusted by default.

That is where confidential computing comes in. It does not replace encryption at rest, network encryption, access control, or vulnerability management. It complements them by extending protection into runtime.

Regulations are catching up to this shift in data protection needs. And while regulators may not always use the words “confidential computing” in order to remain technology-neutral, they are increasingly asking organizations to demonstrate outcomes that confidential computing was designed to support: confidentiality, reduced third-party risk, stronger data governance, secure AI systems, and better control over sensitive workloads across cloud, edge, on-prem, and hybrid environments.

In other words, confidential computing is moving from an infrastructure feature to a compliance-relevant security architecture. In the rest of this blog post, we will explore this development.

Data in use is becoming a recognized control area

One of the clearest signs of this change is that data in use is starting to appear as its own control area.

NIST Cybersecurity Framework 2.0 makes this explicit. Its data security category includes protections for data at rest, data in transit, and data in use. The subcategory PR.DS-10 states that the confidentiality, integrity, and availability of data in use should be protected.

This is important because it completes the familiar data protection model. Security teams have long been asked how they protect stored data and data moving across networks. They are now being asked the same question about data during processing.

The same pattern appears in US federal zero trust guidance. The Federal Zero Trust Data Security Guide, published by the CISO Council and CDO Council, includes computational isolation and confidential computing as part of the data security discussion. That is a useful signal: confidential computing is being discussed not only as a cloud feature, but as part of a broader data-centric security model.

Financial regulators are moving in a similar direction. In the UK, the Prudential Regulation Authority’s SS2/21 on outsourcing and third-party risk management expects regulated firms to implement robust controls for data in transit, data in memory, and data at rest. For financial institutions using external technology providers, runtime protection is becoming part of the outsourcing and third-party risk conversation.

This does not mean every framework now mandates confidential computing; Most still remain technology-neutral. But the direction is clear: protecting data in use is becoming a recognized security outcome, and confidential computing is one of the most direct ways to support it.

Standards are catching up with the architecture

A useful signal that confidential computing is maturing is that it is now being formalized in standards and public guidance.

ISO/IEC is developing a dedicated confidential computing standard, ISO/IEC DIS 25093-1, under the title “Cybersecurity , Confidential computing, Part 1: Overview and concepts”. That is a significant development because it shows the term is moving beyond vendor-specific implementation and into international standardization.

NIST has also published guidance on hardware-enabled security and confidential computing. Its draft report, Hardware-Enabled Security: Confidential Computing of Data in Use in Cloud Computing and AI Workloads, frames confidential computing as a way to protect data while it is being processed in memory and active use, with particular relevance for cloud and AI workloads.

This is important for regulated organizations because standards often become the bridge between broad legal requirements and practical technical controls. A law may require “appropriate security” – and a standard can help define what that looks like in practice.

This is also happening outside of Europe and the US. China has also published GB/T 45230-2025, a national standard titled “Data security technology , General framework for the confidential computing”, released in January 2025 and implemented from August 2025. It is another sign that confidential computing is becoming a formal security category rather than only a vendor term.

Regulation is converging on the same problem

The clearest example is the GDPR. GDPR does not mandate confidential computing by name. But Article 32 requires appropriate technical and organizational measures, including encryption and the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems and services. “Processing” is the important part here.

If an organization processes sensitive personal data, then the security question cannot stop at storage and transmission. The organization also has to ask what happens while that data is actively being used. Who can access the workload? What can the host see? What is included in the trusted computing base? Can the workload prove that it is running in a protected environment before secrets are released?

Confidential computing gives security teams a concrete way to answer those questions.

The same pattern appears in the financial sector. DORA, the EU Digital Operational Resilience Act, has applied since January 2025, and it focuses on ICT risk, operational resilience and third-party technology dependencies. The act does not simply say “deploy confidential computing”, but it creates a regulatory environment where financial institutions need stronger evidence that sensitive workloads remain protected across outsourced ICT environments.

The UK PRA’s SS2/21 makes the data-in-use point even more explicit by referring to robust controls for data in memory, alongside data in transit and data at rest. For sensitive financial workloads, confidential computing can become part of the control set used to reduce runtime exposure and strengthen assurance.

NIS2 follows a similar logic as it requires essential and important entities to apply appropriate and proportionate cybersecurity risk-management measures. These organizations include sectors such as energy, transport, banking, health, digital infrastructure, and public administration. Many of them are modernizing through cloud, edge, and data-driven systems. Many of them are also processing data that is operationally or socially sensitive.

For those sectors, runtime protection is not a niche concern. It is part of the broader question of cyber resilience.

Sovereignty is making runtime trust visible

Confidential computing is also becoming central to sovereign technology discussions. Sovereignty is often reduced to geography: where data is stored, where infrastructure is operated, and which jurisdiction applies. Those questions are…