Who Holds the Keys to Confidential Computing

A friend called last week with a familiar complaint. He had built his workload inside AWS Nitro Enclaves, and he wanted out. His words, not mine: “Pretty easy to get in. Pretty costly to get up. Impossible to get out.” AWS held his keys. AWS ran the attestation. AWS decided, on every request, whether his own code was allowed to touch his own secrets. Then he asked the question that started this article. How do I port this to another provider?

The honest first answer is that most of what feels like confidential computing lock-in is not the silicon. It is the keyring. And the keyring is the one part you were always allowed to own.

Two cost postures sit under his question. One rents the enclave, the key manager, and the attestation verifier from a single landlord, and accepts that the whole arrangement only works inside that landlord’s building. The other owns the identity and the key release, treats every provider’s silicon as a supplier, and carries the same trust model onto the next provider, or onto metal in your own cage. The first is cheaper on day one. The second is the only one you can actually move.

So let me give the verdict before the walk-through. You cannot own the hardware root of trust, and you should stop trying to. You can own everything above it. That single split is the whole portability story, and every section below is just detail hanging off it.

The meter is not on the enclave

Here is the part that surprises people who go looking for the Nitro line item. There isn’t one. Nitro Enclaves carry no additional charge. You pay for the EC2 instance that hosts the parent, and you pay for the other AWS services the enclave calls. AWS says so in its own FAQ, in plain language.

So where does the cost of the trap actually live? Three places, none of them on the invoice.

First, instance captivity. An enclave has no persistent storage and no network of its own. It talks to the world through a local channel to its parent instance and nothing else, which means the parent is load-bearing and always on, sized to carry both itself and the vCPU and memory you carved out for the enclave. You are not renting a feature. You are keeping a specific class of EC2 instance lit around the clock.

Second, the key broker. The moment your enclave needs a secret, it makes an attested call to AWS KMS, and KMS releases the key only when the measurements in the attestation document match the policy on that KMS key. That is a clean design. It is also a leash. The thing that decides whether your code may touch your secret is a managed service you do not run.

Third, and this is the one that actually welds the door shut, the attestation grammar is proprietary. Your key policy is written in terms of Nitro measurement registers and KMS condition keys like kms:RecipientAttestation:ImageSha384. That policy is a dialect. It compiles in exactly one garage.

Put those together and you get the shape of the bill. The cost that traps you is not denominated in dollars. It is denominated in a policy grammar that runs nowhere else. Which is why the monthly invoice looks perfectly reasonable, right up until the day you try to leave.

Whose keyring is it

Think about what actually happens when you hand a car to a valet. You do not hand over the keys to the factory that forged the immobilizer chip. You cannot. That chip was cut, fused, and endorsed in a fab you will never set foot in, and its identity is burned into the silicon. What you hand the valet is a temporary fob. It starts the car, it expires, and you decide which valet gets one and for how long.

Confidential computing has those exact two layers, and the industry keeps letting one company own both.

The bottom layer answers a question you genuinely cannot answer for yourself: is this real, unbackdoored silicon, running the exact code it claims to run? Only the chip vendor can vouch for that, because only the chip vendor holds the key that was fused at manufacture. Fine. Rent that. You were never going to build a fab.

The top layer answers a completely different question: given that the silicon checks out, who holds my secret, and which workload gets a copy of it tonight? That layer has no reason to belong to the cloud provider. On Nitro it does anyway, because AWS KMS is the thing standing at the door holding your keyring.

The condominium manager is welcome to confirm the car is real. He does not get to keep the keys.

Confidential from whom, exactly?

Confidential computing is sold as a shield for data in use. Encrypted in memory, sealed inside the processor, invisible even to the hypervisor. All of that is true. But read the brochure again and ask the question it never answers on its own. Confidential from whom?

Not from the party holding the release key. And in the managed model, that party is the provider.

Walk the real threat list, the one an operator keeps in the back of his mind, and none of the entries are exotic. A cloud operator with standing access and a bad month. A key manager compromised in a breach you read about six weeks after it happened. A supply-chain implant that rode in on an update and now sits one layer below your enclave. A competitor who paid an insider for a chunk of your data and the small key that opens it. Your model weights. Your process recipe. The customer records you are contractually and legally on the hook to protect. Every one of those is the same failure wearing a different costume: a third party holds a copy of your key, and a copy of the key is a door.

Picture the version that has nothing to do with your bill. Not the breach that spends your credits. The one where someone lifts a handful of management-plane credentials, the boring administrative kind, walks across the provider’s parking lot, and opens the cabinet where every tenant’s keys hang in a row. Your workload is the armored car in the corner. Attested, hardened, every option checked. And there on the pegboard is its key, polished, labeled, with a little arrow that says this one starts that car. He does not touch your vehicle. He does not have to. You built a vault and hung the key in the concierge’s cabinet, and when it walks off you cannot even file a complaint, because you handed it over on purpose.

And yes, sitting quietly in that same list, legal compulsion. A provider can be ordered to produce what is in its control, and a key in its custody is in its control. That is not a conspiracy and it does not need to be one. It is a line item in the same risk register as the rogue admin and the breached vault, and it earns exactly one line, because the remedy is identical to the remedy for all the others. Hold the key yourself, and the copy that could have been lost, leaked, sold, coerced, or compelled was never sitting in someone else’s drawer to take.

How the majors vouch for the silicon

Every hyperscaler ships a version of the bottom layer, and under the branding they are more alike than different.

Read the last column top to bottom. Three providers, three token formats, three verifiers, and in every single row the verifier belongs to the provider. That column is the seam. Ownership goes ambiguous exactly there, and ambiguous ownership at a boundary is where lock-in lives. The silicon underneath is frequently the same AMD or Intel part in all three rows. The thing you are captive to is not the chip. It is whose service reads the evidence and whose vault turns the key.

The hard case: neo-cloud, and no cloud at all

Now break the comfortable assumption. Take the workload somewhere that hands you nothing. A neo-cloud GPU shop renting raw capacity by the hour. Or your own metal, in your own cage, which still exists and still matters for the workloads where sovereignty is the point.

Actually, back up one step, because this is the case that clarifies all the others. On your own metal there is no managed attestation service to call. Nobody hands you a signed, pre-verified token. You get the raw hardware evidence, and you run the verifier yourself, or you get nothing at all.

That raw evidence is not exotic. It has been sitting underneath the managed services the entire time.

• AMD SEV-SNP produces an attestation report signed by a per-chip key that chains up to AMD’s root. You check it against AMD’s own key distribution service.
• Intel TDX produces a quote, signed through Intel’s provisioning chain, proving a trust-domain VM booted measured and sealed.
• Arm’s Confidential Compute Architecture brings the same idea to Arm silicon with Realms. It is the newest of the four and the one to watch as Arm servers move into AI fleets.
• And underneath all of it, the TPM. Boring, ubiquitous, bolted to server boards for over a decade. It signs a quote over its measurement registers with a key that chains to an endorsement certificate the manufacturer burned in. The vendor-neutral root of trust that was always already there.

Keep those layers straight, because the marketing blurs them on purpose. TDX, SEV-SNP, and CCA Realms are silicon. Confidential Space, Azure Confidential Computing, and Nitro are products wrapped around that silicon. When a slide lists “TDX, SEV-SNP, ACC, Realms” in one breath, three of those are chips and one is a storefront.

The metal case is the one worth designing for, and the reason is almost backwards. If you can stand up your own verifier and your own key release against raw SEV-SNP, TDX, and TPM evidence, then AWS, GCP, and Azure stop being platforms you are captive to and turn into three more suppliers of signed evidence your verifier already knows how to read. The environment that hands you nothing is the one that forces you to build the piece that ports. Build for the cage, and the clouds come along for free.

Own the CA

This is where the SPIFFE standard earns its keep. SPIFFE gives every workload a cryptographic identity, and its runtime, SPIRE, issues that identity as a short-lived certificate only after attesting the node the workload runs on. The attestation plugins already speak the languages from the section above: cloud instance identity, TPM, SEV-SNP.

So the shape of the answer falls out clean. The chip vendor vouches for the silicon, because only it can. Your SPIRE, rooted in a certificate authority that you own, reads that attestation and decides whether to mint an identity. The workload receives an identity credential that expires in hours, scoped to exactly one tenant, revocable the instant you change your mind.

That expiring, scoped credential is the valet fob. Not the factory key. The fob. You hold the root. You parked the car wherever the price was best this quarter, on Nitro or on a neo-cloud or on the box in your own rack, and the valet got a copy that dies tonight. Change providers and nothing about the identity model changes, because the root of trust never lived in the provider to begin with.

What this looks like running

None of this is theoretical, and I am not going to walk you through the build, because the build is the product. What I will show you is the surface.

One pane. On the left, nodes running on self-owned metal. In the same list, on the same footing, nodes on AWS and on GCP. The identity model is identical across all three because the root of trust is ours, not the provider’s. Cross-tenant access is denied by default, and a revoke kills a node’s reach on the spot rather than at the next renewal.

Per node, the provenance is legible: a signed image, a build record, an attestation method, and an assurance tier. The tier is a rung on a ladder that runs from cloud instance identity at the low end up to full hardware TEE attestation at the top. You can see, for any given node, exactly how strong the proof behind it is. No guessing, no all-green dashboard hiding a weak link.

And there is the valet fob, made visible. A public leaf scoped to one tenant, issued by our own authority, with an expiry measured in a day rather than a year. No private key anywhere on the screen, because the key never leaves the node it was minted for. Multiply that across every tenant and every provider and you have the whole thesis running: managed and orchestrated multi-tenant confidential computing, end to end, on anyone’s silicon, including your own.

My friend’s real problem was never the enclave. Nitro is fine silicon and it costs him nothing to run. His problem was that he let the landlord hold the keyring, and a keyring you do not hold is a keyring you cannot take with you. So rent the silicon from whoever has the best number this quarter. Rent the building. Just keep the keyring, mint your own fobs, and let the valet park the car anywhere you please.

The landlord can keep the garage. I will keep the keys.

P.S. In case you are wondering what this looks like on my own bench: we have been blending GPU and CPU attestation on-prem, wiring NVIDIA’s remote attestation service and the PKI-rooted GPU trust path on Blackwell in underneath Kata Containers on a single server. Honest status, because the piece earned it. Our CPU-side TDX and SEV-SNP coverage is still thin, and the Blackwell cards on this bench are the workstation class, which do not carry the confidential-computing attestation keys at all, so a full GPU-inside-the-TEE chain is not live here yet. What is live is the plumbing. We are pulling our first attestation quotes out of the stack, and the datacenter silicon that actually holds the GPU keys is close. Bleeding edge usually shows up with the firmware half-written. That is the part I enjoy.