Attestation Proves a Hash. It Does Not Prove What the Hash Is.

Confidential computing rests on one promise. Your code runs inside a hardware enclave, and remote attestation lets you verify from outside that the thing running in there is the thing you expected.

The mechanism is real cryptography and it works. The enclave produces a signed measurement, which is a hash of the exact binary loaded into it, and the CPU vendor's key vouches that the measurement came from genuine hardware.

Then you compare that hash to one you computed yourself from the source code.

That last step is the whole point. The hash is only meaningful if you can independently produce it. If you cannot rebuild the binary bit for bit from source, the measurement is an opaque number you are being asked to take on faith. You have not verified anything. You have swapped a trust decision for a hexadecimal string and kept the trust decision.

A paper accepted at ACM CCS 2026, one of the field's top venues, went and checked whether anyone can actually do that last step.

The numbers

The team analysed 115 real TEE deployments across Intel SGX, Intel TDX and AMD SEV. Their finding, verbatim:

a striking 91% of those deployments were not reproducible, with 80% failing to provide both source code and a reference build, the two essential prerequisites for reproducibility

Read the 80% slowly. That is not "the build was fiddly" or "we got a different timestamp." Four out of five did not ship the two things you would need to even attempt a comparison. The verification step in the trust model is not failing. For most deployments it was never available to begin with.

Then they did the part that makes this a good paper rather than a scan. They contacted the maintainers of 50 SGX projects and interviewed 12 developers from industry and academia.

Only one of our participants reported that reproducibility is a priority during development

One out of twelve. The technical finding and the cultural finding agree, which is what you want before believing either.

Why the author list matters here

Preprint scepticism is a good habit, so it is worth saying why this one lands harder than most.

It is accepted at ACM CCS 2026, so it has been through peer review at a venue that is genuinely hard to get into. And the authors include Yuval Yarom, whose name is on a decade of the microarchitectural attack work that defined the Spectre and Meltdown era, and M. Angela Sasse, who essentially founded the usable-security field.

That pairing explains the shape of the study. A hardware-security group alone would have produced the 91% and stopped. A usable-security group alone would have produced the interviews. Getting both is why the paper can say why it is 91% and not just that it is.

The causes split into two very different piles

This is the part with practical consequences, because the two piles need completely different responses.

Pile one is boring and fixable. Timestamps baked into binaries. Absolute paths. Build ordering. Embedded version strings. The reproducible-builds community has been solving these for over a decade and the fixes are well documented. Nobody applied them here because nobody was asking.

Pile two is structural, and the paper's phrasing is the giveaway: the lack of control over the build environment in projects involving multiple stakeholders.

That is not a bug anyone can patch. When the enclave image is assembled from a base image someone else maintains, a toolchain a third party pins, and a CI runner a fourth party operates, no single participant is in a position to make the build reproducible. Each one can honestly say their part is fine. The property is only meaningful end to end, and end to end has no owner.

This is the familiar supply-chain shape, and it is exactly what makes it hard.

Where this actually bites

The word TEE sounds like a specialist concern. It is not, because attestation has quietly become the technical basis for a lot of claims aimed at people who will never read a CCS paper.

Private AI inference. "Your prompts run in an enclave and we cannot see them" is an attestation claim. Whether it is checkable depends entirely on whether the inference image is reproducible.

Confidential VMs in every major cloud. Sold on the premise that the operator cannot read your memory. The hardware part holds. The "and here is proof of what is running" part is the part in question.

Blockchain oracles and key custody, where a TEE is often the only thing standing between a signing key and the person operating the machine.

Enterprise procurement, where "runs in a trusted execution environment" appears on a checklist and gets a tick without anyone asking the follow-up.

The paper's own summary of the failure mode is the line to keep: the industry treats TEEs as a security badge. A badge is a thing you display. Attestation was supposed to be a thing you check.

What to ask, concretely

None of this makes TEEs useless. Hardware memory encryption is real and it defends against a real adversary. The gap is narrower and more specific than "enclaves are broken," so the response should be too.

Ask the vendor for the reference build, not the attestation document. The attestation document is the easy artifact and it proves the part nobody disputes. Ask instead: can I rebuild your enclave image from source and get your measurement? The answer, or the pause before it, tells you where on the 91% you are standing.

Check whether the measurement in the docs is reproducible or merely published. A published expected value is a vendor telling you what to expect. It is not independent verification, and the two are constantly presented as the same thing.

Treat build environment control as the actual requirement. Pinned toolchain, pinned base image, documented build, published reference. If that list is missing, reproducibility is not achievable no matter what the enclave reports.

And if you operate a TEE deployment, note that pile one is genuinely cheap. Deterministic timestamps and pinned dependencies are a known playbook. The paper's finding is not that this is hard. It is that almost nobody tried.

The general shape

There is a pattern here worth naming beyond enclaves.

A verification step that nobody can perform is indistinguishable from no verification step, and it is considerably more dangerous, because it produces confidence. Signed packages where nobody checks the signature. Certificate transparency logs nobody queries. Audit trails nobody reads. The control exists, appears on the diagram, and is load-bearing in exactly the way an unchecked control cannot be.

Attestation is the current best example because the cryptography is genuinely excellent and the chain still breaks, one step before the end, in a place where the maths cannot help.

Sources. "They don't care about this": A Systematic Study of TEE Build Reproducibility in the Wild, Wilde, Gutfleisch, Reichmann, Chakraborty, Yarom, Sasse and Karame, submitted 10 September 2026 and to appear at ACM CCS 2026. All figures and quotes above are from that paper. Related here: six hours from foothold to campaign, everyone shipped agent isolation and nobody agreed on what from, and for what happens when a cryptographic assumption quietly expires, two CA keys factored on a desktop.