Confidential computing asks who can read the data. Attestable computing asks what ran. Most products need the second answer first.
Reattested · 2026-11-12
Confidential computing has a clear promise: data stays protected while it is in use, even from the operator of the machine. That promise has two halves. One is secrecy. The other is proof: the machine can show a remote party what hardware and software it is running. The two are sold together, but they are different properties, and many products need only one of them.
Attestable computing is computing whose hardware and software state can be proved to a remote party, on request, with evidence rooted in hardware. It promises integrity and authenticity: this is the genuine machine, and this is exactly what it runs. It does not promise that nobody can read the data.
Put shortly: confidential computing without the confidentiality requirement. What remains is the part that tells you what happened.
A robot in a warehouse has few secrets from its operator. A haul truck has none. A build server compiles open-source code. An agent's sandbox runs tools the customer chose. In all four, nobody is trying to hide data from the host. Everybody needs to know that the approved software ran, and nothing else.
If the only category on offer is confidential computing, these teams either buy memory encryption they do not need or conclude that the whole field is not for them. Both are mistakes. The second is the expensive one.
| Confidential computing | Attestable computing | |
|---|---|---|
| The question | Who can read the data while it is processed? | What ran, on which machine? |
| Promise | Confidentiality and integrity | Integrity and authenticity |
| Protects against | A curious or compromised operator | Wrong, modified or unapproved software and hardware |
| Needs | Encrypted, isolated memory plus attestation | A hardware root of trust, measurement and a verifier |
| Typical hardware | Intel TDX, AMD SEV-SNP, Arm CCA, GPU confidential modes | TPM, DICE, secure elements, and the same TEEs when present |
| Typical products | Private AI inference, data clean rooms, key management | Robots, vehicles, devices, build systems, agent machines, wallets |
Trusted computing has done this for more than twenty years: a TPM records what a machine booted, and signs a report that a verifier can check. No secrecy is involved. What changed is where the idea is used.
One distinction keeps the term honest. Verifiable computing proves the result of a computation with cryptography alone. Attestable computing proves which software ran, with a signature from hardware. The first needs no trusted hardware and is costly to compute. The second is cheap and depends on the hardware vendor.
It also inherits the limits. If an attacker can extract the attestation key, as physical attacks on server memory showed in 2025, forged evidence verifies. Attestable computing does not remove the need to know who can touch the machine. It makes that the only thing left to know.
Integrity is a statement about one moment. An attestable product can prove itself. Whether it has done so since the last update, repair, model swap or published vulnerability is a separate question, and it is the one buyers and regulators now ask. The rules coming into force from 2026 to 2028 ask for integrity over the life of a product, not at its launch.
So the sequence is: make the product attestable, then keep it reattested. The first is engineering. The second is operations, and it is where most products stop.
Take the self-check. Ten questions show whether your product can prove what it runs today, and again tomorrow.
Working on an attestable product? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.