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 important, but they are not the full story.

A more complete sovereignty model also asks: who can technically access the workload? Can administrators inspect data while it is being processed? Can the infrastructure provider access memory? Can the tenant verify the state of the environment before releasing keys or secrets?

This is where confidential computing becomes a sovereignty control rather than simply a privacy feature.

The French cybersecurity agency ANSSI has described confidential computing in its technical position paper as a set of technologies for executing sensitive workloads in remote environments, complementing encryption at rest and in transit by encrypting data in use and shielding it from direct inspection by administrators on shared infrastructure.

This framing acknowledges both the promise and the limitations of the technology. Confidential computing is not magic: it does not remove the need for secure software, patched systems, measured boot, key management, monitoring, or carefully designed architecture. What it does do is reduce the amount of infrastructure that has to be trusted by default.

For sovereign systems, that reduction is powerful. It enables a more nuanced model: not “trust the provider completely”, and not “never run sensitive workloads on shared infrastructure”, but instead “use infrastructure with stronger technical boundaries, attestation, and cryptographic control”.

Healthcare shows why data in use is important

Healthcare is one of the clearest examples of why confidential computing is becoming relevant to regulation.

Health data is highly sensitive, but it is also increasingly valuable for research, public health, personalized medicine, and AI. The challenge is that healthcare systems need to make data useful without making it unnecessarily exposed.

The European Health Data Space is a good example of this change. It aims to create a framework for the use and reuse of electronic health data across the EU, including secondary use for research, innovation, policy-making, and public health. That kind of model depends on trust: patients, providers, researchers, and regulators all need confidence that sensitive data can be analyzed under strict safeguards.

Traditional encryption helps protect health data when it is stored or transmitted. But research, analytics and AI workloads require data to be processed. That is the point where confidential computing becomes especially relevant.

By protecting workloads and data during computation, confidential computing can help healthcare organizations build stronger technical boundaries around sensitive analysis environments. It can reduce exposure to infrastructure operators, support attestation before data or keys are released, and make it easier to design systems where data can be used without broadening the circle of trust.

This does not make healthcare data sharing simple. Governance, consent, access controls, auditability, anonymization, pseudonymization, and legal safeguards are still mandatory . But confidential computing gives healthcare organizations a practical way to strengthen the processing environment itself.

For healthcare, the regulatory question is no longer only “where is the data stored?” It is also “how is the data protected while it is being used?”

Secure data sharing needs secure processing

Another area where confidential computing fits naturally is data sharing.

The EU Data Governance Act introduces the concept of secure processing environments: physical or virtual environments, combined with organizational measures, that allow data to be used while maintaining legal requirements around confidentiality, integrity, access, and supervision. This is the exact kind of problem confidential computing was built to help solve.

Many organizations want to collaborate on sensitive data without exposing raw datasets more broadly than necessary. Healthcare researchers want to analyze patient data. Public sector bodies want to reuse data for policy and planning. Financial institutions want to collaborate on fraud detection. Companies want to run analytics across commercial datasets without revealing more than the computation requires.

In these cases, the question is not only “is the database encrypted?” The question is “can the processing environment itself be trusted?”

Confidential computing can help create stronger technical boundaries for these environments. It can support attestation before data access, reduce exposure to infrastructure administrators and help organizations design systems where sensitive data can be used with fewer parties in the trusted computing base.

That makes it highly relevant to data spaces, data clean rooms, and regulated analytics.

AI raises the stakes for data in use

AI makes the regulatory relevance of confidential computing even clearer.

AI workloads often process highly sensitive inputs: prompts, embeddings, documents, training data, fine-tuning datasets, model weights, and inference outputs. In some cases, the model itself may be valuable intellectual property. In others, the data being processed may be personal, confidential, classified, or commercially sensitive.

The EU AI Act requires high-risk AI systems to achieve appropriate levels of accuracy, robustness and cybersecurity throughout their lifecycle. That lifecycle framing is important. Security is not a one-time property of the model. It depends on how the model is deployed, what data it processes, how it is updated, how it is monitored, and how its surrounding infrastructure is protected.

Confidential computing can help secure parts of that lifecycle, especially where organizations want to run AI workloads on shared, remote, or hybrid infrastructure without exposing sensitive data or models to the underlying platform.

This is why confidential AI is becoming such an important use case. It is not only about privacy. It is also about protecting intellectual property, reducing third-party risk, supporting regulated inference, and enabling organizations to adopt AI without giving up control over sensitive assets.

The same idea is starting to appear in AI policy discussions beyond traditional compliance. For example, public comments related to the US American AI Exports Program have recommended accelerator-level confidential computing as one way to protect AI model weights and systems in export packages. That is not the same as a regulatory mandate, but it shows how confidential computing is entering wider discussions about AI security, trust, and geopolitical risk.

Other frameworks point in the same direction

Not every relevant framework is built around privacy, financial resilience, or AI. Some are sector-specific or industry-led, but they point to the same underlying issue.

The Payment Card Industry Data Security Standard is designed to protect payment account data through technical and operational requirements. PCI DSS v4.0.1 is not a confidential computing regulation, but payment environments often involve sensitive data moving through memory, applications, and processing systems. For high-risk payment workloads, runtime protection can become part of a broader defence-in-depth strategy.

The Cloud Security Alliance has also highlighted the need for cloud-native security architectures and guidance for protecting sensitive workloads in modern cloud environments. Its work is not regulation, but it often shapes how cloud providers and customers think about practical controls.

Singapore’s Monetary Authority of Singapore provides technology risk management guidance for financial institutions. Like DORA and PRA SS2/21, it reflects a wider financial-sector expectation: organizations need strong governance and technical controls for technology risk, especially where critical or sensitive workloads depend on third-party infrastructure.

The pattern is consistent. Whether the language is data in use, data in memory, secure processing, operational resilience, cybersecurity, or zero trust, the direction is the same: sensitive data needs protection during computation, not only before and after it.

A new baseline for sensitive workloads

The end result of all this is clear to see: regulation is becoming more concerned with how data is processed, instead of solely focusing on where and how it is stored. Financial risk management is becoming more focused on third-party technology dependencies. AI regulation is making lifecycle security more important. Healthcare and data-sharing initiatives are making secure processing environments more important. Sovereignty discussions are moving beyond location and into technical control.

All of these trends point toward the same conclusion: data in use is becoming a regulatory concern.

Confidential computing will not be mandatory for every workload. It will not replace existing security controls. It will not eliminate the need to trust hardware vendors, firmware, guest software or the application itself.

But for sensitive and regulated workloads, it gives organizations a way to shrink the trust boundary, strengthen runtime protection and provide stronger evidence that systems are being designed with confidentiality in mind.

That is why confidential computing is becoming part of the compliance conversation. Encryption at rest and in transit gave us the first two pillars of data protection. Confidential computing adds the third: protection while data is in use.

For organizations building the next generation of regulated cloud, edge, AI, and data-sharing systems, that third pillar is becoming much harder to treat as optional.

The role of Canonical and Ubuntu 

Confidential computing is often described as a hardware capability. That is true, but it is only part of the story. Regulated organizations do not deploy processors in isolation. They deploy platforms. They need kernels, hypervisors, images, firmware, tooling, security updates, and long-term maintenance that work together.

That is why the operating system is important for confidential computing. With Ubuntu 26.04 LTS, Canonical brings integrated host and guest support for both AMD SEV-SNP and Intel TDX. These are two of the main technologies used to protect confidential virtual machines, and supporting both sides of the stack is what makes confidential computing practical for real deployments.

For regulated organizations, this is what turns confidential computing from a hardware feature into something they can confidently deploy at scale. If you’re interested in discussing your confidential computing needs in more detail, don’t hesitate to contact us.