The one-sentence version, and the half everyone skips
Confidential computing encrypts a workload's memory with a key the host kernel and hypervisor never hold, and it emits a signed statement describing what is running inside that boundary. That is the whole mechanism. Everything that matters commercially is in the second half: the signed statement, who checks it, and what you are entitled to say once they have. Most teams buy the first half, turn it on, take the performance hit, and never build the second half. At that point they are paying for a property that nobody in the transaction can actually verify.
The question arrives in two shapes. Either a prospect's security team wants to know whether your engineers can read their records while your service is processing them, and the deal is sitting on that answer. Or your own team has a workload that a regulated customer will not let into shared infrastructure, and somebody has proposed hardware enclaves as the way through. Both are legitimate. Confidential computing answers a narrow, specific version of that question, and if you cannot state which version, you will spend a quarter on it and arrive back at the same meeting.
What follows is the version we give when a client asks us to evaluate it: the four mechanisms and how they actually differ, why attestation and not encryption is the thing you are buying, the claims the hardware supports, the claims it does not, the attacks that are explicitly out of scope, what verification costs to operate, and the two or three situations where we tell people to do it anyway.
You are probably here because
- A prospect's security team has asked, in writing, whether your engineers can read their records while the service is processing them, and the deal has not moved since.
- You already run confidential VMs, you are paying the overhead, and nobody outside your own team has ever checked an attestation document.
- Someone asked what the launch measurement actually covers, and nobody could say whether it includes the container image you shipped last week.
These usually have one root cause: the encryption got deployed and the verifier never did, which is what “Attestation is the product” and “Attested to what, exactly?” below are about.
Four mechanisms, and they are not substitutes for each other
People say "confidential computing" as though it names one thing. It names at least four designs with different units of isolation, different porting costs, and different failure modes. Choosing the wrong one is the most common expensive mistake in this area, because the porting work is not portable.
Process-level enclaves. Intel SGX carves a protected region out of a single process. Your code is split into trusted and untrusted halves, every crossing is an explicit call, and system calls have to be proxied out. Early client parts capped the enclave page cache at 128 MB, which is where SGX's reputation for being unusable came from; server parts raised that to hundreds of gigabytes per socket. Intel removed SGX from consumer desktop parts, so it is now a server-side technology only. Library operating systems such as Gramine and Occlum exist specifically to avoid rewriting an application against the SGX SDK, and they work, at the cost of pulling a large surface back inside the boundary you were trying to shrink.
VM-level enclaves. AMD SEV-SNP and Intel TDX protect a whole guest virtual machine. You do not rewrite the application. You boot a supported guest kernel on a supported host, and the hypervisor loses the ability to read or silently modify guest memory. SEV-SNP, available from EPYC 7003 onward, added a reverse map table so the host cannot remap a guest's physical pages underneath it, which was the gap that made earlier SEV generations unconvincing. TDX arrived on fourth-generation Xeon Scalable with a comparable model built around trust domains. This is the shape almost everyone should be looking at, because the porting cost is close to zero.
Stripped isolated VMs. AWS Nitro Enclaves is a different animal and gets miscategorised constantly. It is not main-memory encryption in the SEV or TDX sense. It is a VM carved out of a parent instance's CPU and memory with no persistent storage, no interactive access, and no external network, reachable only over a local vsock channel, plus an attestation document signed by the hypervisor. The isolation is architectural rather than cryptographic, and for most commercial threat models that distinction matters less than the integration story, which is the best of the group.
Accelerator enclaves. NVIDIA's confidential computing mode on Hopper-class and later GPUs extends the boundary across the PCIe link, encrypting transfers between CPU and GPU and keeping GPU memory inaccessible to the host. Arm's Confidential Compute Architecture, with realms under the Realm Management Extension, is the equivalent story on the Arm side and has a younger deployed ecosystem than the x86 options.
| Mechanism | Unit protected | What you have to change | Where it bites |
|---|---|---|---|
| Intel SGX | A region inside one process | Split the app, proxy syscalls, or adopt a library OS | Highest porting cost, longest published side-channel history |
| AMD SEV-SNP | The whole guest VM | Supported guest kernel and firmware, little or no app change | Ciphertext visibility to the host, I/O bounce buffers |
| Intel TDX | The whole guest VM (trust domain) | Supported guest kernel and firmware, little or no app change | Instance availability by region, measurement chain is yours to build |
| AWS Nitro Enclaves | A VM with no disk, no network, no shell | Rearchitect the sensitive path behind a vsock service | No general-purpose networking, memory reserved from the parent |
| GPU confidential mode | Device memory plus the CPU-to-GPU link | Driver and toolkit versions, attestation of the device too | Transfer-bound work pays for encryption on every hop |
| Arm CCA realms | The realm, roughly a VM equivalent | Platform and firmware support end to end | Thinner deployed hardware and tooling than the x86 options |
Attestation is the product. Encryption is the plumbing.
Encrypted memory on its own buys you very little. If an attacker can already run code with the platform's privileges, they can simply ask the enclave to do things, and encryption of DRAM does not stop that. The property you are actually selling is different: a remote party can obtain a signed document, rooted in a key the silicon vendor provisioned and vouches for, that says this specific software is running inside a genuine hardware boundary on a platform at this patch level. Everything commercial hangs off that document.
The vocabulary is worth learning properly because it makes procurement conversations shorter. IETF RFC 9334, the remote attestation architecture published in 2023, names four roles. The attester produces evidence. The verifier appraises that evidence against reference values and endorsements. The relying party makes a decision based on the verifier's result. The endorser, in practice the silicon vendor, vouches for the attester's key. When a vendor tells you their product "uses attestation," the useful follow-up is: who is the verifier, and what reference values are they comparing against. If the answer is that the workload verifies itself, there is no security property, only a diagram.
Every platform ships some version of this. Nitro produces an attestation document with platform configuration registers you can pin in a key policy. Azure's confidential VMs and its managed HSM support releasing a key only when an attestation claim matches. Google's Confidential Space issues tokens that bind a running workload to an identity that other services can authorise against. Intel Trust Authority provides verification as a service so that the relying party does not need to hold vendor collateral. Pick one deliberately, because it determines who is trusted to say yes.
The four claims the hardware actually supports
Here is what we tell clients they may write in a security addendum, ranked by how much of it the mechanism carries on its own versus how much depends on work you still have to do.
How Much The Hardware Carries, By Claim
Our working scores for how much of each claim the mechanism delivers unaided. The bottom two are yours to solve in software.
The first two are strong and are the reason to do this at all. Confidentiality against a privileged platform is a genuine change in the shape of your threat model, and build identity that a customer can check is a genuine commercial asset. The third and fourth are strong if you build the surrounding machinery, which is a real project. The bottom two are not properties of the hardware and never were, and pretending otherwise is where security teams get embarrassed.
What it does not do
These are the claims we most often have to strike out of a draft security page. Each of them is stated somewhere on a vendor website right now, and none of them follows from the mechanism.
- It does not protect you from your own code. A memory-safety bug, an injection, or an authorization gap inside the enclave is exactly as exploitable as it was outside, and the enclave makes it harder for your own tooling to observe.
- It does not stop authorized output. If the workload is permitted to read a record and then writes it into a response, a log, or a support tool, the boundary held and you still disclosed the data.
- It does not make you compliant with anything. No control in a SOC 2 audit, an ISO 27001 statement of applicability, HIPAA, or PCI DSS says "use a trusted execution environment."
- It does not guarantee availability. The host can still refuse to schedule you, kill the guest, delay it arbitrarily, or drop the network. Integrity of execution says nothing about liveness.
- It does not remove trust. You have replaced trust in a cloud operator, which is contractual and auditable, with trust in a silicon vendor and an attestation service, which are neither.
- It does not defend against a side channel. That exclusion is in the threat model on purpose, and it has been exercised repeatedly by working attacks.
Side channels are out of scope, and that is a design decision
Intel has stated from the beginning that SGX's threat model excludes microarchitectural side channels. That is not a caveat buried in a footnote, it is the architecture's boundary, and it is honest. The consequence is a long list of published attacks that recovered enclave secrets without ever breaking the memory encryption. Foreshadow, in 2018, extracted attestation keys through an L1 terminal fault. ÆPIC Leak, in 2022, read stale data straight out of an architectural interface. The gather data sampling flaw disclosed in 2023 hit enclave data through vector gather instructions. Each was mitigated with microcode and each cost measurable performance somewhere in the fleet.
The AMD side has its own record and its own instructive design detail. SEV's memory encryption uses a mode with a physical-address tweak and no per-write nonce, so identical plaintext written to the same physical address produces identical ciphertext. Researchers turned that observation into a working key-recovery channel, published as CipherLeaks. Separately, CacheWarp demonstrated that dropping writebacks could revert guest memory to earlier values and defeat authentication logic on SEV-ES and SEV-SNP. Both were fixed. The pattern is the point: this is a hardware security surface with an active research community and a steady stream of findings, which means an operational patch cadence, not a one-time architecture decision.
The physical-access line moved, and it moved recently
The most common sales framing is that confidential computing protects you from someone with physical access to the machine. Treat that claim carefully. BadRAM, disclosed with a CVE against AMD platforms, showed that roughly ten dollars of hardware attached to a memory module's serial presence detect chip could convince the memory controller that more address space existed than physically did. The resulting aliases let an attacker read and replay protected guest memory in ways SEV-SNP's integrity protection was supposed to prevent. AMD shipped firmware mitigations. The relevant lesson is not that the platform is broken, it is that the physical-attack boundary is an active research frontier and that memory-bus interposition on modern DRAM is a real technique rather than a theoretical one.
Name the adversary the control is for
The three adversaries people conflate are a compromised hypervisor, a curious or coerced operations engineer, and someone with hands on the server. Confidential computing is strongest against the first, useful against the second, and contested against the third. If your customer's actual worry is a support engineer copying records out of a debugging tool, memory encryption is not the control. Scoped access, a real audit trail, and field-level protection are. We have watched a nine-month enclave project ship against a threat the customer never had.
Attested to what, exactly?
This is the failure we see most often in production deployments, and it is quiet. A confidential VM produces a measurement, and teams assume it covers their application. It usually does not. The launch measurement covers guest firmware and initial VM state. Unless you deliberately extend the chain, it says nothing about the kernel you booted, the initramfs, the root filesystem, the container image, or the configuration file that decides where results get written. You have proved the platform is genuine. You have not proved your software is what you believe it is.
Closing that gap is ordinary engineering, and it is the work: measure the kernel and initramfs, verify the root filesystem with dm-verity so its hash is part of the chain, pin the container image by digest rather than tag, and treat runtime configuration as measured input rather than something mounted in afterwards. Then the attestation has content. Without it, an operator who swaps a container image behind the same tag passes attestation unchanged, which is precisely the case you deployed this to catch.
There is a prerequisite most teams discover late. A measurement is a hash of a specific binary artifact. For a third party to check it against a reference value, they must be able to derive that value themselves, which means reproducible builds. If your CI produces a different image digest for the same commit on two runs because a timestamp or a package mirror moved, then no external party can ever verify your reference values and the whole chain terminates in "trust our published number." Budget for reproducibility work at the start, not after the first customer asks.
TCB recovery: the operational cost nobody budgets
When a silicon vendor patches a vulnerability in the trusted computing base, the platform's security version number moves and the measurements or the acceptable policy change with it. Your verifier now has a decision to make on every attestation, and both available answers are bad if you have not planned for it.
The workable answer is a policy with structure rather than a hardcoded hash list: a minimum acceptable security version, an explicit and short grace window during which older platforms are still accepted while nodes roll, an alert when a node attests below the floor, and a documented owner for raising the floor. Somebody has to own this in the same way somebody owns certificate rotation, and it fails in the same way, silently until everything stops at once. Ask any vendor selling you an attested service how they handle a TCB recovery event. The quality of that answer tells you whether they run this in production.
Two more operational realities belong here. Rollback protection is not free: SGX's monotonic counters, the one primitive that gave enclaves durable freshness, were deprecated years ago, which is why serious designs put freshness in an external service with its own availability story. And debugging changes character. A confidential VM in production is deliberately opaque to the host, so the profiler, the core dump, and the memory inspector your team relies on are gone. Plan the observability story before the migration, not during the first incident.
Where the value actually is: keys that only exist inside a measured workload
Strip away the marketing and one architecture justifies the cost. Instead of holding a decryption key in a secrets manager where any process with the right role can fetch it, you write a key release policy that says: release this key only to a workload whose attestation evidence matches this measurement, from this platform type, at or above this security version. Then the key material only ever materialises inside a boundary whose contents are cryptographically pinned.
Every major platform supports a version of this. Key policies can be conditioned on enclave measurement values, managed HSMs can perform secure key release against attestation claims, and workload identity can be bound to an attested measurement so that downstream services authorise the measurement rather than the machine. That is a control you can describe to a buyer's security team in one paragraph and they can test.
It changes the answer to the question that blocks deals. "Can your staff read our data" stops being a policy commitment backed by an access review and becomes a mechanism: the key does not exist outside a workload whose exact contents are pinned, and here is the evidence document, and here is how you verify it yourself. We have seen that convert a stalled security review in weeks. It is the only justification for this technology that has ever paid for itself in our experience.
Send it over and we will tell you what we would change.
Email the attestation document your workload produces today, the key release policy that consumes it, and a list of what your measurement chain covers (firmware, kernel, initramfs, root filesystem, image digest, configuration) to contact@precisionfederal.com. You get back a short written note naming the three things we would change and why. One business day. No charge, no meeting, no deck.
contact@precisionfederal.comPerformance: plan a range, then measure your own
Published overhead numbers for confidential VMs vary wildly, and the variance is not noise. It reflects how much a workload crosses the boundary. Inside the guest, code runs on the same cores at the same clocks. The cost lands on transitions and on I/O, because device DMA cannot land directly in protected memory, so data moves through shared bounce buffers and gets copied. A workload that computes over resident data pays almost nothing. A workload that streams gigabytes through the network stack pays repeatedly.
Planning Overhead By Workload Shape — Longer Bar Means Worse
Planning figures we start from, not measurements of your system. Benchmark your own path before committing a number to a contract.
Use those as a starting hypothesis and then run your actual workload, because the second-order effects are the ones that hurt. Reserved enclave memory comes out of the parent instance and is not available for page cache. Huge pages and NUMA placement behave differently under some configurations. Live migration support is not uniform across platforms and generations, which can quietly change your maintenance model. Confidential instance families are not offered in every region, and that alone has killed more migrations in our experience than any benchmark result.
GPU enclaves, which is what most people are asking about now
The demand we see today is not for confidential databases. It is a company that wants to run a model over a customer's sensitive corpus and be able to say the customer's text was never readable by anyone operating the infrastructure. That requires the boundary to extend to the accelerator, which is what confidential mode on Hopper-class and later NVIDIA GPUs provides: GPU memory the host cannot read, encrypted transfers across PCIe, and a device attestation report that a verifier can appraise alongside the CPU evidence.
The shape of the cost is predictable from first principles. Encryption sits on the transfer path, not on the compute. Large-batch inference where the model weights are resident and each request moves a small amount of text is close to native. Anything that shuttles large tensors back and forth per request pays on every hop, and the fix is the same as it always was: keep more work on the device and batch harder. Two practical constraints matter more than the throughput number. Driver, firmware, and toolkit versions must line up precisely across the whole stack. And you now have two attestations to verify rather than one, which means your verifier policy has to appraise CPU evidence and GPU evidence together, and both have their own security version numbers that move on their own schedules.
When it is worth it, and when it is theater
The right question is never whether to use confidential computing. It is which adversary this is for, and what that adversary does next once you deploy it. Run that question over the six situations below and most teams find themselves in one of the bottom three, where the money and the quarter are better spent elsewhere.
| Situation | Verdict | Why |
|---|---|---|
| A named deal is blocked on "your staff must not be able to read our data" | Do it | Attested key release converts a policy promise into a mechanism the buyer can test. This is the case that pays. |
| Processing data from two parties who do not trust each other | Do it | An attested workload is the only clean answer to "whose machine is the join running on." Nothing else is as convincing. |
| You run a model on customer text and want the boundary to cover the GPU | Do it, carefully | Real property, real cost. Verify device and host evidence together and pin your driver stack. |
| The worry is a support engineer reading records in a debugging tool | Do something else | Scoped access, field-level protection, and an audit trail address that. The enclave does not. |
| Someone wants it for the security page and the SOC 2 report | No | No audit control requires it. You would be buying overhead and an operational burden for a bullet point. |
| The threat you actually face is credential theft or a supply-chain compromise | No | Both live inside the boundary. Spend the quarter on identity, dependency provenance, and least privilege. |
Compliance: what it is genuinely worth on a questionnaire
Be precise here, because overstating it is how a security addendum becomes a liability. GDPR Article 32 names encryption and pseudonymisation as examples of appropriate technical measures, and a defensible state-of-the-art argument can include an attested boundary, but no article requires one. HIPAA treats encryption as an addressable implementation specification rather than a mandate, and the breach-notification safe harbor is written around data at rest and data in transit. It has nothing to say about data in use, which is the exact gap confidential computing fills and the exact reason it earns you no automatic relief. ISO 27001 and SOC 2 are control frameworks about what you assert and evidence, not about which silicon feature you enabled. PCI DSS protects stored account data and does not name enclaves.
What confidential computing does buy on a questionnaire is a better answer to a specific recurring question, phrased as a mechanism rather than a promise, with an artifact the reviewer can check. That is worth having. It is not a compliance shortcut, and any vendor telling you otherwise has not read the frameworks.
What to ask for, or be ready to answer
- Which mechanism, on which hardware generation, at which minimum security version
- Who the verifier is, and whether the relying party can verify independently
- Exactly what the measurement covers: firmware, kernel, initramfs, root filesystem, image digest, configuration
- Whether builds are reproducible, so a reference value can be derived rather than taken on faith
- The written policy for a TCB recovery event, including the grace window and who raises the floor
- Which secrets are gated on attestation, and which are still fetched with an ordinary role
- What operations staff can still see: logs, traces, metrics, support tooling, crash artifacts
- The measured overhead on the real workload, not a vendor benchmark on a different one
That last one separates the deployments that work from the ones that get quietly disabled. If the sixth item on that list comes back as "none of them," the deployment is decorative. Attestation that gates nothing is a signature on a document nobody reads.
A four-week way to find out
Evaluation Sprint
Four weeks is enough because every expensive unknown in this area is measurable inside it. Whether your workload is transition-bound is measurable. Whether your build is reproducible is a yes or a no you get on day one of trying. Whether a wrong build is actually refused is a test you can write. What is not measurable in four weeks, and what sinks these projects, is the organisational question of who owns the verifier and its policy for the next three years. Answer that in week one, in writing, with a name on it.
Bottom line
Confidential computing is a real capability with a narrow, valuable use: it lets you make a checkable statement about what is running and who can read the data while it runs, and it lets you release keys only into a workload whose contents are pinned. That converts a trust conversation into an engineering artifact, and in the right deal it is worth a great deal of money. It is not a compliance shortcut, it is not protection against your own bugs, it does not stop authorized output, and it does not remove trust so much as reassign it. Decide which adversary you are buying it for, build the verifier, own the recovery policy, measure your own overhead, and it will do exactly what it says. Skip the verifier and you have bought an expensive way to run the same software slower.
Frequently asked questions
It stops the platform software they operate from reading plaintext guest memory, which is a meaningful change. It does not stop data your own application writes into logs, traces, support tools, or responses, and it does not cover data at rest outside the boundary. The strong version of the claim requires attested key release, so that keys never exist outside a workload whose contents are pinned.
For most teams, a VM-level mechanism such as TDX or SEV-SNP, because the application does not have to change. Nitro Enclaves suits a design where one small sensitive routine can live behind a local channel with no network of its own, and it has the smoothest key-policy integration. SGX makes sense when you want the trusted surface as small as possible and can afford the porting cost.
It depends almost entirely on boundary crossings rather than on compute. Plan on low single digits for compute-bound work over resident data, and twenty percent or more for chatty services and I/O-heavy paths where data moves through bounce buffers. Then measure your own workload, because reserved memory, page cache pressure, and region availability usually matter more than the headline number.
No framework requires it. HIPAA treats encryption as addressable and its breach safe harbor is written around data at rest and in transit, not data in use. GDPR Article 32 names encryption as an example measure, not a mandate. What it gives you is a stronger, testable answer to a common questionnaire question, which is useful without being a shortcut.
Assuming the launch measurement covers the application. It normally covers guest firmware and initial state only, so an operator can swap the container image behind the same tag and attestation passes unchanged. Extend the chain through kernel, root filesystem, and image digest, make the build reproducible, and gate at least one real secret on the result.