Confidential Computing for Sensitive Financial Workloads
Processing Data Nobody Else Can See, Including Your Cloud Provider
Banks have solved two thirds of the data protection problem. Data at rest is encrypted, data in transit is encrypted, and both are routine enough that auditors barely comment. The remaining third is data in use, which has always been decrypted in memory on infrastructure somebody else operates, and which has quietly blocked a long list of otherwise sensible projects.
Confidential computing closes that gap with hardware-enforced isolation. The Confidential Computing Consortium describes it as protecting data while it is in use, closing a data security gap that storage and network encryption leave exposed, using hardware-enforced enclaves such as Intel TDX, AMD SEV, and ARM TrustZone that create isolated execution contexts where even the hypervisor and cloud provider cannot inspect running workloads. Whether that is worth the engineering cost depends entirely on which workload you have in mind.
What problem does confidential computing actually solve?
It removes the need to trust the operator of the infrastructure with the data being processed.
That is a narrow and valuable property. It does not make data more encrypted at rest, does not improve your access control, and does not address application vulnerabilities. What it does is take the platform operator, and by extension an insider or a compelled disclosure at that operator, out of the set of parties who can read what your workload is computing on.
What exactly is a trusted execution environment?
A hardware-isolated context where memory is encrypted and the surrounding software stack cannot look in.
The processor enforces isolation, so the host operating system, hypervisor, and administrative tooling see only encrypted memory. Different implementations draw the boundary differently: some isolate a process, others an entire virtual machine, which matters for how much of your application must change. The whole-virtual-machine model is generally easier to adopt because existing workloads fit inside it, while process-level enclaves offer a smaller trusted computing base and demand more redesign.
Which financial workloads justify it?
Those where the operator's visibility is the specific reason a project cannot proceed.
| Workload | Why confidential computing helps | Alternative to consider first |
|---|---|---|
| Cross-institution analytics on customer data | Compute jointly without exposing raw records | Aggregates or federated learning |
| Model training on sensitive data in shared cloud | Removes provider from the trust boundary | Training on pseudonymised data |
| Processing regulated data where provider access is disallowed | Satisfies a specific access constraint | Sovereign or in-country deployment |
| Key operations and secret handling | Isolation of high-value material | A hardware security module |
| Vendor processing your data on their infrastructure | You verify what runs before releasing data | Contractual controls plus tokenisation |
| Multi-party financial crime analysis | Enables computation none of the parties will host | Privacy-enhancing alternatives |
When is it the wrong tool?
When cheaper controls address the same risk, which is more often than vendors suggest.
If the concern is your own staff, use access control and monitoring. If the concern is data at rest, encrypt it properly. If the workload can operate on tokenised or masked data, do that instead, since it is simpler and removes the sensitive data entirely rather than protecting it in place, which is the approach set out in this guide to data masking and tokenisation. Reserve confidential computing for cases where the operator is genuinely in your threat model and no cheaper control removes them.
Is provider visibility the actual blocker on your project, or is it something cheaper to fix?
Talk to Digiqt about scoping confidential computing use cases
Why is attestation the crux of the design?
Because isolation without verification tells you nothing about what is running inside.
An enclave protects whatever is loaded into it, including code an attacker substituted. Attestation is the mechanism by which a relying party verifies the hardware, the firmware, and a measurement of the loaded workload before trusting it with data or keys. Get attestation wrong and you have an expensive black box with the same trust properties as an ordinary virtual machine.
What has to be verified before data is released?
Hardware genuineness, firmware and platform state, and a measurement identifying the exact workload.
The relying party checks that the report comes from genuine hardware in an acceptable configuration, that firmware and microcode versions meet policy, and that the workload measurement matches an expected value corresponding to a build you approved. That last part is the operational challenge, because every legitimate code change produces a new measurement, so your build pipeline has to publish measurements as release artefacts and your policy has to be updated in a controlled way. Institutions that skip this end up accepting any measurement, which quietly voids the entire control.
Who holds the key release policy?
The party whose data is at risk, which is frequently not the party running the workload.
The natural design is that keys are released to an enclave only on successful attestation against a policy the data owner controls. That is what makes vendor processing and cross-institution computation possible: you release the ability to decrypt only to a workload you have verified, running in hardware you have verified. Hold that policy in your own key management regime rather than the operator's, which brings the design back to the custody questions covered in HSM and key management architecture, and note that FIPS 140-3 remains the relevant certification frame for the modules holding those keys, defining four increasing security levels covering physical security, sensitive parameter management, and self-tests.
What changes when you design for an enclave?
Memory limits, restricted input and output, sealed debugging, and different operational tooling.
| Constraint | Practical effect |
|---|---|
| Bounded enclave memory | Large in-memory datasets may not fit, requiring streaming or partitioning |
| Restricted system calls and IO | Data must be brought in over authenticated encrypted channels |
| No conventional debugging in production | Failures must be diagnosed from designed-in outputs |
| Observability limits | Logs and metrics must avoid leaking what the enclave protects |
| Attestation lifecycle | Every release changes the measurement and requires policy update |
| Performance overhead | Encrypted memory and transitions cost measurable throughput |
| Operational tooling | Standard agents and sidecars often cannot run inside |
What breaks when you lift and shift?
Observability first, then anything that assumed a helpful host.
Teams routinely discover that their monitoring agents cannot run inside the enclave, their log pipeline would export exactly the data being protected, and their incident diagnosis process depends on inspecting memory. Design the observability contract deliberately: emit the minimum needed for operations, sanitise it inside the enclave before it leaves, and accept that you will trade some diagnosability for confidentiality. The segmentation and least-privilege reasoning is the same as in this guide to zero-trust security architecture, applied at the process boundary rather than the network.
Would your observability pipeline export the very data the enclave protects?
How does this relate to residency and sovereignty?
It changes who can see data, not where data is, so both questions remain.
Confidential computing is frequently sold as a sovereignty answer and it is only part of one. If an obligation concerns the location of processing or the jurisdiction of parties who could compel access, isolation from the operator helps with the second and does nothing about the first. Treat the two separately: use residency architecture for location and jurisdictional exposure, as set out in data residency and sovereignty architecture, and use confidential computing to narrow operator visibility where that is the specific concern. Where obligations differ per market, the mapping discipline in this guide to privacy compliance across jurisdictions applies.
Where does it enable something genuinely new?
Multi-party computation on data none of the participants will hand over.
This is the most compelling category, because it enables work that simply cannot happen otherwise. Cross-institution financial crime analysis is the clearest example, and the evidence base is encouraging: the BIS Innovation Hub's Project Aurora, reported in May 2023, found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes while reducing false positives by up to eighty percent compared with siloed rules-based approaches. Enclaves are one route to that, alongside the cryptographic techniques discussed in federated fraud intelligence sharing, and the choice between them is usually driven by governance comfort rather than by capability.
What does the threat model not cover?
Side channels, hardware supply chain trust, your own enclave bugs, and control of attestation policy.
Be precise with stakeholders about the limits. Published research repeatedly finds side-channel and speculative-execution weaknesses in these platforms, so patching discipline for firmware and microcode is part of the control rather than an afterthought. You are trusting the silicon vendor and the attestation service, which is a different trust decision rather than the absence of one. A vulnerability in your own enclave code is fully exploitable inside the enclave, since isolation protects the workload from outside and not from itself. And whoever controls the key release policy effectively controls the confidentiality guarantee, which makes that policy a critical asset with its own access controls and change management.
How should adoption be sequenced?
One workload, managed service, attestation discipline first, then expand.
Start with a single workload where provider visibility is the documented blocker, and use a managed confidential computing offering rather than building enclave tooling, since the platform work is substantial and rarely differentiating. Establish measurement publishing in your build pipeline and a controlled attestation policy process before anything handles real data, because retrofitting that discipline is how programmes lose the guarantee they paid for. Then measure performance honestly against the non-enclave baseline, and expand only where the constraint genuinely applies. Institutions that declare a general policy of running everything confidentially spend heavily and slow delivery for a benefit most of their workloads do not need.
Which metrics are worth tracking?
Attestation failure rate, measurement policy currency, performance delta, workload coverage against justified need, and firmware patch latency.
Track attestation failures and their causes, since a rising rate usually means a build or policy process problem rather than an attack. Report how current your accepted measurement list is, because stale policy either blocks legitimate releases or accepts unapproved ones. Measure the performance delta against the same workload outside an enclave so the cost is visible in decisions. Report coverage as the share of workloads with a documented justification, not as a share of the estate, since untargeted adoption is the failure mode here. And monitor firmware and microcode patch latency, because that is the maintenance obligation the guarantee actually depends on.
Confidential computing is a narrow tool that does one thing no other control does, and the institutions that get value from it are the ones that named the workload and the specific trust problem first. Applied that way it unlocks projects that were previously impossible. Applied as a general policy it becomes an expensive way to run ordinary software.
Frequently Asked Questions
What problem does confidential computing solve?
It protects data while it is being processed. Storage and network encryption leave a gap during computation, and hardware-enforced enclaves close it by isolating the running workload.
What is a trusted execution environment?
A hardware-enforced isolated execution context where the workload runs encrypted in memory, so the hypervisor, host operating system, and cloud provider cannot inspect it.
Which financial workloads justify it?
Cross-institution analytics, model training on sensitive data, processing regulated data in shared infrastructure, and any workload where provider or insider visibility is the unacceptable risk.
Why is attestation the crux of the design?
Because without verifying what is running inside the enclave, isolation proves nothing. Attestation is what lets a key holder decide whether to release secrets to that specific workload.
Can you lift and shift an application into an enclave?
Rarely without change. Memory limits, restricted input and output, sealed debugging, and different operational tooling all force design adjustments, and observability usually needs rethinking.
Does confidential computing solve data residency?
No. It changes who can see data, not where data is. Residency obligations about location and jurisdictional access remain and must be handled separately.
What does the threat model not cover?
Side-channel research findings, hardware supply chain trust, bugs in your own enclave code, and anyone who controls the attestation policy. Isolation is not a substitute for those controls.
Where should adoption start?
With one workload where provider visibility is the specific blocker, using a managed confidential computing service rather than building enclave tooling from scratch.
