TEE build reproducibility study (arXiv 2609.11411): 91% of deployments not reproducible

What happened on this date

On 2026-09-10 (UTC), Annika Wilde, Marco Gutfleisch, Felix Reichmann, Anirban Chakraborty, Yuval Yarom, M. Angela Sasse and Ghassan Karame submitted v1 of They don't care about this, a systematic study of build reproducibility for trusted execution environment software. The authors note that remote attestation lets outside parties check code running in a TEE, but only if the measured binary can be traced to its source, which requires reproducible builds. Across 115 TEE deployments spanning Intel SGX, Intel TDX and AMD SEV, 91% were not reproducible and about 80% provided neither source code nor a reference build. They contacted maintainers of 50 SGX projects and interviewed 12 developers; only one named reproducibility as a development priority. The paper argues that technical causes such as embedded timestamps are fixable, while ecosystem issues such as limited control over build environments in multi-stakeholder projects are harder.

Why it matters for protecting app logic

The paper studies server-side TEEs, not mobile or desktop apps; the analogy below is our analysis, not the paper's conclusion. App developers also rely on attestation: signing, notarization, App Attest or Play Integrity can indicate that a signed or recognized build is running, but that only means something if you know which source, toolchain and protection configuration produced the build. Transformations such as obfuscation often introduce random seeds, making builds inherently hard to reproduce; if you cannot rebuild the same release artifact, it becomes hard to confirm afterwards what a shipped version actually contained. The paper's warning carries over: do not treat attestation as a security badge.

Checks you can run

First, record build inputs for every release: source commit, toolchain version, protection tool version, configuration and random seeds. Second, build twice from the same inputs and diff the outputs to find unstable sources such as timestamps and paths, pinning whatever you can. Third, keep hashes and signing details for every shipped artifact so you can verify them later. Fourth, map which server-side decisions depend on attestation results, and what those results actually verify and do not verify. Fifth, if your protection tooling uses random seeds, decide whether to record and reuse them so a release can be rebuilt and checked.

Your checklist

• Record toolchain, protection config and seeds for each release
• Build twice from the same inputs and diff the outputs
• Map server decisions that rely on attestation and what they verify